Getting the Most From Your Teams, Part 3

This is the third in a series of articles on how to structure and elicit the highest performance from your teams without resorting to heroics. I recommend reading Part 2 before this one to understand the context.

Here’s a brief recap of our story so far: My company had many 10x’s (programmers with multiples of productivity beyond mere humans). Ahn was one of those. I also had Samir, a truly brilliant programmer who wrote exemplary code but simply could not deliver like a 10x. My quest was to understand the most optimal configuration for a software team, making it a breeze for my team and my company to outperform any judgy Silicon Valley customer, and therefore continue to win follow-on work. My quandary was that stacking up a team with 10x’s just wasn’t delivering much beyond a normal team. 

At the end of Part 2 I shared the breakthrough graph I conceived. 

The Need for Speed… or For Completeness

Ahn clearly resided in Q4, as did her 10x peers. Samir, I realized, showed the characteristics of a Q3, slower but capable of working through complex problems perhaps even beyond Ahn’s or other 10x’s abilities. 

A key point about the graph I sensed is that speed is not necessarily aligned with intelligence. Ahn’s speed was more about a willingness to trust her instincts and take big risks on her technical decisions, to leave pieces untouched, and to focus on the hardest stuff because that was the interesting parts, whereas Samir had a deep commitment to leave no stone unturned. He simply couldn’t permit himself to skim, skip, disregard, or overlook any aspect of the system he created. I came to the startling (for me) realization that these measures were more about personality traits than they were about intelligence. 

Handling Complexity Is Not Always Important

Through more observation I identified resources whose strengths had more to do with less complexity. 

I examined the traits exhibited by Maria, a contemporary of Ahn’s, who had a real knack for the Q2 quadrant. What really satisfied her was the act of checking the “done” box. She loved coming to daily standups and running through her assignments, saying “Done. Done. Done. Done.” Over time I found these traits to be consistent with others I’d categorize in Q2 along with Maria. When I applied Maria to similar jobs as Ahn, she turtled into a quiet sort of flail cycle. Her work was incomplete and she grew to be less communicative, less spirited, and genuinely unhappy very rapidly. The exact opposite was true for Maria when she had a boatload of less complicated work on her plate. 

Bob, a smart guy at the beginning of his career, personified the Q1 quadrant. Eager for experience and assignments, he took over the mundane and routine work, dotting i’s and crossing t’s, so that no one had to think twice about any of it. He worked as a test developer, build engineer, gap-filler, and bug fixer. He collated the group status reports, trained all the new hires on the software environment and our processes. Bob handled all the mundane assignments that usually gravitated toward Ahn and other 10x’s, since that was our institutionalized habit when no one was thinking about how appropriate the work was for a 10x. He was everyone’s favorite teammate because he handled so many details behind the scenes and made everyone's code a little bit better (except Samir, of course).

For Bob and those like him, the opportunity to contribute, be a part of something, learn from the real pros, and carry his own weight on a high performing team was all the juice they required out of work to be happy and engaged. In fact, they provided a real lift to their teams. 

And when they were given that opportunity, on those tasks that were either too simple for Samir or too slow for Ahn, I began to see that the work they did was truly important to the highest possible performance. 

Stop Playing Resources to their Weaknesses

Playing with the Matrix (I call it that because it sounds cooler) over the course of a couple of years, I found the failure instances to be at least as valuable as those that had great results in great work; problems were not indicating that the Matrix was wrong, but rather that the team had fallen victim to assignments of work outside the Matrix. And when they were instead played to their strengths as defined by the Matrix, performance was outstanding. This was particularly true for Samir, who became our superstar when applied to defining technical requirements, writing specifications and interface control documents, code reviews, and developing our software architecture. 

That means that the key to the highest performing teams are, first, understanding which type each developer falls into, and second, how best to populate the resources in the team to maximize their best performances. I’ll discuss these matters in more detail in the fourth and final article in the series.

Part 4 in the series can be found here: https://empathic-insights.com/getting-the-most-from-your-teams-part-4/