Getting the Most From Your Teams - Part 2

Getting the Most From Your Teams, Part 2

This is the second 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 1 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. 

After repeatedly getting meh results from teams composed exclusively of 10x’s, I decided to drill into those situations to discover exactly what caused them to ease off the gas pedal. So I embarked on autopsies of those projects. What I found was that so much horsepower simply wasn’t efficient. 10x engineers worship efficiency as much as or more than most other engineers. While having that much horsepower on the same project was great for camaraderie (it was cool to have people to talk to who understood them and could keep up), they saw no purpose or virtue in the overkill of talent. 

“Why should I do that,” said one of them to me, “when Maria can do it just as well and she’s already deep in the code? I knew she wouldn’t have any problem hitting the deadline.” There were many statements made to me of a similar vein. I asked each one who said this, “Do you have to be the one in the spotlight before you’ll completely engage?” They scoffed at that, remarking that recognition had nothing to do with their level of interest. The work itself was what mattered. 

I found that out of about six 10x’s on each project, only two or three of them at a time applied themselves to doing all the hard work, since that was the entirety of the work suitable for a 10x. There were simpler tasks to do, and they did that work, but those assignments failed to challenge them so they just moved through the work routinely, as quickly as possible, and then got involved with other things. This was not something I cared to discourage, but it was still an interesting finding.

Diving Deep

I considered Samir’s case as a factor in the puzzle. The constant comparison of his abilities to Ahn’s distressed him, making it harder for him to perform at all. I experimented with different kinds of assignments for each of them but did not learn anything of real value until I had Samir do a code review of Ahn’s work. 

Samir wasn’t at all surprised at finding some areas of concern in Ahn’s code. He mentioned to me that he had never conducted a code review anywhere that was completely clean. But Ahn’s reaction was interesting. 

“He is correct,” she told me. “All the issues he pointed out would result in better code.”

“I don’t have a problem with what you created, Ahn,” I told her. “Your work solved some really hard problems. But did you know there were issues like these when you wrote it?” 

“Sure, Ken,” she said. “I don’t try to write perfect code. That’s inefficient, because it takes so much more effort and you only get minor improvements beyond a certain point. When Samir programs he writes perfect code. Even the complicated stuff is bullet proof. But it takes him forever. Very inefficient.” 

Now I was getting somewhere. One of my laws of good management was that to get better results you need to play each person to their strengths as much as possible and minimize their exposure to their weaknesses. I’d been using Samir as if he were a 10x, which he couldn’t (or perhaps wouldn’t) do. And I’d been using 10x’s on less challenging work and getting meh results. That was not playing them to their strengths.

Okay, now that I had centered on the problem as one of strengths and weaknesses, what could I do to guide my decisions in the future and help teams get maximum performance? To make a team composition that I could replicate and scale, where the resources were happy because they always delivered to their greatest strengths? I envisioned a simple graph where I could chart each engineer’s position. A sort of cheat sheet. If I could see it that way, I knew I could elevate their strengths and guide them away from their weaknesses. To define it, I asked the question, “What are the factors about programming that are nearly immutable to every engineer who is working under normal conditions?” Speed was one answer, as that was the crux of my analysis of Ahn and Samir. What else? 

The Breakthrough

It occurred to me that while Samir was slow, he could go really deep. Ahn had said he could handle the complicated stuff. Ahn could also handle the truly complicated stuff, but would produce suboptimal code quickly whereas Samir would produce perfect code slowly. So I came up with this graph: 

This was the breakthrough I needed. Working with it over time, I learned a ton about each type of engineer’s strengths and weaknesses. With insight into strengths and weaknesses I was able to experiment with different team compositions until I found one that consistently delivered the strongest possible performance, with happy team members, and I could replicate it and scale it. To learn more about that team composition, and why it works, read Part 3 of “Getting the Most From Your Teams.”

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