Earlier this week, I Interviewed a developer who was planning to quit a once-loved job after four years. It’s a story I hear often.
Like most programmers, he can be an “A” player when on the right team and working on the right types of projects. For four years he was just that.
Six months ago, a new architect was hired and his once-loved job has become a constant war.
The new architect is talented. Also an “A” player. The problem is he is incompatible with the rest of the team. He has fundamental differences in how he thinks about his job, does his job, and considers himself successful.
This situation occurs over and over in companies around the world: Two “A” players you’d love to have on your team who are fundamentally incompatible and can’t work together.
After seeing this same scenario play out a few times, I created a better way to evaluate programmers for team fit based on the following eight facets of developer compatibility.
1. Innovative or Pragmatic
Some programmers love exploring new technology because there is always a better way to do something. They use the latest versions of everything and you can bet C# and Python are installed on their workstations because each is best at something. These programmers believe the technical status quo is never good enough. These are Innovative programmers.
Other programmers like to keep things simple and stay with well-tested and known-safe solutions. They typically stay a version or two behind. Sure, Python might be a bit easier for that task, but the more technologies used, the more risk is incurred. These are Pragmatic programmers.
2. Technology Control: Tight, Negotiable, Loose
Some programmers are happy working in any language and any stack. They believe programming is about process and technique and they welcome the opportunity to use different languages.
Other programmers stick to one primary language and stack. They believe that in most cases, one stack is just as effective as another so why keep switching around?
Candidates can be rated in one of three ways:
Tight Control means a programmer is committed to one stack and core set of technologies and isn’t interested in anything else. Don’t try to convince them to change.
Loose Control means a programmer is flexible. They are up for anything and find technical variety fun.
Negotiable means they prefer one stack, but if something else is a better solution for a specific problem they can be swayed.
3. Architecture Control: Tight, Negotiable, Loose
Architecture control is similar to technology control, but it’s about how technologies are used, not what technologies are used.
This is the biggest point of debate in most teams. Some prefer using an ORM, others prefer stored procedures and ADO. Some think heavy use of design patterns is good, others want to take a simpler and more accessible approach.
It’s important to gauge how flexible your team is to changes in architecture, and how flexible a candidate is. If neither are flexible, you need to ensure they both take the same approach.
4. Business-Oriented or Technical-Oriented
For some programmers, most conversations stay centered on who will use the software and the desired business outcomes. Technology is merely a tool to achieve business results, and those business results will be celebrated. These are Business-oriented programmers.
For other programmers, most conversations quickly move into the technologies they will use and nothing is more exciting than finally getting a tough technical problem solved. It’s a technical win they will celebrate for weeks. These are Technology-oriented programmers.
5. Doer or Planner
When given a task, some programmers like to jump in and do. Yes, they’ll do some planning, but they find it easiest to think through a problem as they build it. The classes, methods, and challenges become clear as they write a little code and refactor. These are Doers.
Other programmers like to step back and deeply assess the situation. They want everyone’s feedback and want to explore all of the options before deciding the best way forward. They think that the more planning they do, the less code they will have to write. These are Planners.
6. Clear or Concise
Some programmers love white space and comments. They write full if-statements instead of using shortcuts because they believe it will make their code more understandable to a future programmer. These are Clear programmers.
Other programmers believe you shouldn’t use 50 lines of code if you can get it done in five. They use very few comments because they believe proper naming and structure is more than enough to help a future programmer. These are Concise programmers.
7. High-Level or Low-Level
Some developers are happiest designing database schemas and class models, and working in high-level languages like C#. They are perfectly happy using Bootstrap without needing to know every last detail of how it’s implemented. These are High-level programmers.
Other programmers like digging deep into the underbelly of how things work. If a programming language doesn’t allow them to directly manage system resources, they believe they can’t do a great job. These are Low-level programmers.
8. Social or Solitary
Some programmers are all about being together. They like sharing a space with other programmers, getting the team together to think through problems, and involve everyone in a solution. These are Social programmers.
Others like to put on headphones or shut the door and get away from it all. They want space to focus. These programmers can be great with clients, be part of and even lead teams, but they need space and some quiet time. These are Solitary programmers.
In the example above, an innovator was hired onto a pragmatic team, and a war ensued. Both the innovative architect and pragmatic team also demanded very tight control of technology and architecture and neither would budge. They all had fundamental differences of how to do their jobs.
Step one in putting this to use is to assess existing team members, management, and organizational needs on these eight facets. Armed with that information, you’ll have a good idea who will be a good or bad fit.
These facets are not about having all team members exactly alike. You need some diversity especially in Doers or Planners and Technical-oriented or Business-oriented. But be aware of these differences and make sure you’re bringing someone onto a team who will fit and not be disruptive.
No matter how good or qualified a candidate may seem, if they won’t mesh well with your team, project, and organizational needs, they won’t be an “A” player for you.
Let them find someplace they’ll be a better fit.