Getting the Most From Your Teams - Part 1

This is the first in a series of articles on how to structure and elicit the highest performance from your teams without resorting to heroics.

“We would do it ourselves,” Bob told me, “but we don’t have the staff to handle it. I’d hire your company to help us but we don’t want to pay for your staff’s stupidity.” 

Bob was a corporate Koolaid junkie from a Silicon Valley company. For years the terrible sucking sound we all heard in San Diego and many other cities was from the Bay Area tech titans and startups hoovering up the best talent. In those days I heard from many Silicon Valley leaders that if you’re technical and you’re not in the Bay Area, you don’t matter. There was a lot of corporate Koolaid to go around, and the hubris seemed to feed on itself, growing more bloated each year. In this case, as Bob made clear to me, if I hoped to win work for my consulting company, we had to perform better than their own staff. 

I wasn’t worried. For years I had been able to get superb performance out of my engineering teams, despite the attraction of Bay Area salaries and exclusive-club elitism. In fact, the thing I worried about most with those kinds of companies was that their culture would infect my teams if we got too close. But we needed the work so I put my best practices into action for their projects, and we succeeded with many follow-on projects over the course of four years. 

Here’s how I did it. It began when I observed that two of the smartest people I ever met had fundamentally different results in software projects. 

Meet Ahn and Samir

On the left is Ahn. She dropped out of high school, hit the road, and ended up counting cards in Las Vegas (yes, she was represented as a character in that card counting movie). When it got too boring to cheat at Blackjack, run from casino security, and tote around six figures of cash stuffed into suitcases (hard to believe but true) she decided to write code. Within months she did this with astounding fluency. 

On the right is Samir. He got a Master’s degree in Computer Science, worked at a defense contractor company, and through his extraordinary capabilities he eventually became the solitary engineer responsible for a hugely complicated system that had required twelve people to maintain until Samir took over. 

They both worked on my project. Ahn blazed through everything in sight. Samir grew more and more ashamed that he was not able to do what Ahn did. Leadership adored Ahn. At the same time they began to reconsider hiring Samir. Observing him I could see he was miserable with this direct comparison to Ahn. He felt like a failure, and he naturally responded to his situation by working more intensely and more carefully, which is what he did when pressure increased. But the rub is, I had experienced many deep conversations with Samir and even played chess with him. Whenever he checked in code everyone who saw it was blown away by how complete and elegant it was. There was no question in my mind about his intelligence, and in fact I believed he was genius level.

Back to Ahn. She was a 10x engineer. In case you haven’t heard of that, software creation is one of those rare occupations where two people with identical backgrounds, training, ethnic roots, education, and experience can be vastly different in terms of performance. You see this in art, musicianship, sales, public speaking, and a few others. Bottom line: one person can perform exponentially better than someone who by all measures should be their rightful equal.

My company specialized in finding the 10xers like Ahn. We developed a penetrating candidate evaluation process, and I had several 10xers within my group. To continue outperforming my customers, I wanted to make the best performing team in history, in a way that was repeatable and scalable. So I stacked up several 10xers on a single project, expecting them to blow the lid off the universe. Can you guess the result? 

Meh is a generous way to put it. That made no sense so I tried it again. And again. Wash, rinse, repeat. It defied reason but I never got better than Meh. Now everyone else thought these projects were great successes, and commercially they were. But I knew that the exponential leaps of project performance I was expecting simply were not there. Individually they were each a 10x, but as a team they were Meh.

Solving the puzzle

This was a puzzle. And I love puzzles. Eventually it occurred to me that Samir’s predicament might reveal insights into this situation. I thought, “If we use Samir in those cases where we need complete, comprehensive, elegant code, and we use Ahn when we need brilliant innovation... but why couldn’t Ahn and another 10x do that same work? Why do we need Samir?” 

That’s when I began to consider how best to play resources to their natural strengths. Can every 10xer do everything? Maybe not. This thought led me far beyond the exclusive use of 10xers, and in the end I found a formula that yielded the highest performance from a team in a scalable way, meaning we never resorted to heroics. Read the next article in this series to learn more about my approach.

Part 2 in the series can be found here: https://empathic-insights.com/getting-the-most/