If I wanted to represent a software team with a 3D graph, the axes I’d choose to map its members are: fluency, alignment, and leverage. These are the three things that I think can most succinctly summarize and predict the health & productivity of a team, based on where its individuals are and what’s being done to move them on this spectrum. Momentum matters as much as position.

I’ve studied every publicly available software engineering skills tree and evaluation rubric that I could find on the Internet, from all the usual suspects and a few hidden ones. As Director of Engineering in a small software organization, I worked to build a comprehensive system we could use internally for evaluations over the course of several years, but I always felt like these systems were a bit heavy to digest at a high level — a few too many categories, a few too many company-specific values. A year removed from the job, this is what I feel like is the distillation of what those tools are trying to communicate.

alignment

First, a team member needs to be aligned with their own team. Are they adapting to the existing processes and contributing to it? Are they prioritizing (or at least trying to prioritize) the same things as their teammates? This is primarily a cultural alignment.

Second is alignment with their immediate leadership, including a tech lead and/or manager. Do they feel they’ve gotten expectations clearly communicated to them in an actionable way? Are they getting iterative feedback to help them improve this? This is a performance alignment.

Lastly are external alignments, which are much trickier. This can include other departments, leaders further up the chain, customers, or a wider audience. These alignments generally come from a great deal of experience and can be separately evaluated in many contexts. A strong, supportive engineering culture supports this growth by giving them a framework for creating complex external alignment.

leverage

First is evaluating if they have the tools they require to be effective. These could be physical things about their environment or input devices, or their software. They need to realize what they could have access to and assess whether it would help them. Beyond that, they need to be explicitly encouraged learn how to use those tools effectively.

Second is collaborative leverage. How well can they talk thru a problem with a peer, mentor, or mentee? Can they confidently fill a role on a cross-functional team to build more efficiently? This is primarily about partnerships with 1-2 people in service of their primary work goals.

Lastly is group-to-group leverage, which is about identifying leadership. Can they coordinate with other leaders in a way that creates success for all parties? Are they able to rally their team to cohesively meet challenges? Finding elegant solutions that solve many problems at once requires sensitivity and deep understanding, both of which require honed leadership skills.

fluency

The obvious first dimension here is language and framework fluency. Do they know the language they’re programming in well enough to function independently? To collaborate and review others’ implementations? To teach others? This is always the first and most obvious thing folks look at when doing “performance evaluations” of other developers, sometimes to a problematic degree.

Second is product and systems fluency, which can succinctly be described as knowing what decisions were made that got us here. Folks who joined a company early often excel at this, since they were in the room when it happened. Later-stage documentation efforts often result from a realization that this fluency is lacking amongst later hires. Developing this fluency is sometimes overlooked by junior and mid-level engineers.

Lastly you have goal and priority fluency, which is understanding why those decisions were made and being able to credibly translate them into future plans and actions. Faking this fluency is what gets you premature optimizations and useless abstractions. Real fluency here is demonstrated with just-ahead-of-the-curve adjustments that mesh seamlessly with product goals over the arc of years, demonstrating mastery of team alignment and leveraging their ability to socialize knowledge.

conclusion

Each section started with a very concrete and basic job function, pulled back to involve their interactions with others, and finally got a bit abstract and even cross-referential with the other sections. I think a lot of startups get as far as the first piece or two of each section. When the upper tiers of a career ladder have a lot of hand-wavy or gatekeepy requirements, it suggests to me they punted on the third dimension of each section, which is perhaps the most important.

Thinking about teams in this way and even physically plotting individuals on a line that represents mastery of each section (and/or sub-section) above can be a powerful tool to thinking about outliers on your team in both directions. Who has pulled away from the pack in their ability to achieve alignment with other teams? Who has drifted behind and needs remedial work in their systems fluency? Most importantly: how can you borrow momentum from the former to help the latter?

As a leader, you can’t always attend to every shortcoming or celebrate every glint of excellence. But frameworks can help you quickly prioritize and make sure you don’t miss the work entirely.