Finding Keystone Developers

When working in software development for a while, you begin to realize that good software developers arrive in many different forms. All software engineers inherently come with a degree of ego, a drive to accomplish, and a need to share their passions. A big thing that does not innately come with each of us is an understanding of a particular domain without prior exposure to it.

Many developers are a proportional balance of domain knowledge and technical skill, and it is in that, which undervalues a developer the most when hiring or investigating the possibility of finding new candidates to fill a role or replace a lost development team member. Personality derives from an unseen component from each individual, cultural, and subcultural belonging, language, as well as a base underlying sense of curiosity. People are complex, but our personalities are diverse, and combining the right people together to form a team is a tough thing to do.

When a team works well together, it is difficult to compensate and recover fully from that cohesiveness. At the end of the day, an amazing development team is there to understand the solutions conceptualized by other people to create the equations and functionality that ultimately provide those solutions. Development teams are, for lack of a better term, problem makers. We make mathematical problems to fit a particular piece of puzzle that comprises a larger portion of the greater solution.

When you work with a particular software developer long enough, you come to value the developer for domain knowledge, performance, skill, trust, and reliability. The loss of any developer on a team is directly proportional to these five concepts in varying degrees.

Domain knowledge is expensive to replace to replicate in a new team member, probably the most difficult to recover from in a financial perspective. Domain knowledge loss costs a company more money typically than any technical performance, skill, or any other aspect of a developer. Every new developer must undergo domain knowledge training and already possess it, such as a developer who departed and returns to a role. The investment any business makes when getting a new employee is not just on the person's ability with technology, but the person's ability to learn the domain of knowledge pertinent to do business.

The performance of a developer is a difficult thing to measure in a developer. A truly high performing developer can be isolated to a developer who produces fewer bugs, develops more conceptually solid and thoughtful solutions, and does so in a measured and quick fashion. There are very few high performing software developers using these metrics, which is honestly just fine. High performing developers can be threatening to many people and must navigate a difficult path in the world of software engineering. I have enjoyed the personal company of a few high performing software engineers in my life and appreciated every single one of them. They all taught me a lot, and an unyielding work ethic like those you see in them is inspiring.

The skill of a software engineer is a measurable concept, but varies by technology stack. I prefer to measure technical ability using more theoretical computer science concepts to get an understanding of whether someone can code. If a person can explain theoretical logic and talk freely about the way it works, then I can comfortably avoid talking about the nuances of a specific programming language. Learning programming languages quickly comes with the territory of software development, so it is more important to me that the skill of a person comes out in theoretical discussions.

Trust is not something anyone can place reliable metrics around, nor measure for during an interview. We try to base our ideas of what makes a software engineer trustworthy on how long they worked at a job, meeting them in person, et cetera. Unfortunately, without really bearing down and working with another person, it is difficult to discover a good way to find a person trustworthy or not. The only other way is using references, or for direct referrals who have a history providing reliable candidates to an organization.

The reliability of a software engineer is not the same as trust and can use a simple metric. Reliability is not skill or performance, but the concept that a software engineer produces code within the confines of original estimates, and does so consistently. The worst thing a software engineer can do to damage reliability is to underestimate and continuously go beyond that estimate, creating a bad reputation for unreliability. A project manager can handle higher estimates far better than estimates that are systemically too low over time. It is dangerous to assume that any fix is easy and simple without context.

I have a long history of providing high estimates for my work. This typically raises eyebrows, but when people realize I do it as a safety mechanism to get them to ask me why my estimate is so high I can quickly answer: “I did not have enough information available in context of the work at hand to simply place a low estimate on the work.” This is my canned response, because it is true. When I have the opportunity to grasp a reasonable understanding of the needs to do some work, I can provide more and more accurate levels of effort. This approach, I hope, keeps my reliability as high as possible. I think it really depends on the culture and direction of an organization, as well as how the management of projects occurs as to whether my way of doing things is the “right way.”

If we take two developers in a hypothetical situation and compare them:

We are hiring for a position that has interviewed two developers.

• Developer 1 is slightly more experienced in the specific technology, but has no understanding of the domain.
• Developer 2 is slightly less experienced in the specific technology, but a stronger understanding of the domain.

Based on this hypothetical case, I am more inclined to hire a Developer 2, around the domain knowledge than Developer 1 who possesses greater technical experience. While we all know that so much more than just skills and domain knowledge play into hiring someone, but given this comparison the domain knowledge matters more in the evaluation process as to the net gain for an organization. Greater technical experiences are far cheaper to acquire over time than solid domain experience.

While domain experience can override technical skill, we can account for some other components to what makes one developer a better fit for a role. A big one is temperament. Like artists and writers, the best of developers put passion and expertise of craft into what they do. Ego is often a problem in the world of technology, let alone in the world of software developers, and the humble developer is a rarity.

A high performing developer is one who puts all that passion and effort into the work with a sense of personal responsibility towards doing a good job, but without an unreasonable amount of ego weighed into it.

While personality carries all this weight, it matters mainly when talking about that person working with a team. Just about every piece of enterprise software needs one or more teams of varying sizes, so having a good temperament and personality should matter when it comes to professional software development.

When interviewing for positions, I found it was super important to me to get an understanding of the maturity of the software development process of an organization. The more people who understand this process, especially across an organization, the better the process goes.

A software developer's sense of that process is key. If a software developer has a good grasp of a particular approach, you can find common ground and talk about ways to improve the theory and the practice. Software development hinges a great deal on the process every company uses and is willing to discuss, and when developers are interested in discussing process, I find those developers tend to be better with introspection and reflection on the constant struggle we share in improving the things we do.

When you lose a developer and teammate from a company, the void is far more difficult to fill than we sometimes want to admit. It is always possible to fill the void, but sometimes it makes me wonder about just how much we really tried to retain a person who will likely take years to replace. When a developer with years of domain knowledge leaves, it is difficult, but when a person also possesses a multitude of other traits, it makes the loss even more significant.

When any software engineer is a great team member, a great domain knowledge resource, high performer, reliable, skilled, and trustworthy, an organization is making a mistake to allow person to leave without really putting a lot of fight into it. I have seen it happen repeatedly in organizations across my career, and can only surmise that companies have a difficult time really understanding how important the combination of these components play in together with one another to make a company better just by having the right individuals in place.

Those people, those software engineers are the people I like to refer to as keystone developers. I wish there was a way to identify and flag those kinds of people in an organization so that companies really put greater efforts in sustaining the career of those individuals for the long haul. It ultimately leads to lower overall attrition, greater consistency in products, and increases the overall morale across teams.