Steve, a software development manager, thought John was a “10x” developer. He explained that John could:
- Coded faster than anyone else.
- Write and release full applications over a weekend.
- “Mind-meld” with the users.
No one else in Steve’s group could do this. Was I willing to support and coach the other people in Steve’s group to all become “10x” developers?
Maybe.
I had a hunch that Steve didn’t see the entire picture. Did Steve want some sort of team improvement that didn’t jibe with reality?
Steve-and the team-needed to see their system.
Visualize the Team’s System
Managers can support their teams in many ways. One of the most important ways is to see the team’s system.
You might create an image of the feedback loops, as in Unearthing Your Project’s Delays. You might facilitate the team in creating their value stream maps for the various kinds of work so they can measure their cycle time.
Consider quantitative perspectives, too. If the team feels as if they can’t quite get a handle on requests, ask the team to draw a picture of incoming requests over a week or two. Maybe even draw a picture of when the story/product completes. (I did this once, attempting to draw a bird. Everyone laughed at my birds. However, the birds got the point across.)
Since Steve was convinced one person excelled and the others didn’t, I needed to be careful. I asked Steve first, could we collect these measures:
- The team’s feature cycle time. (Just the time to release a feature)
- The team’s fixes cycle time. (Just the time to release a fix.)
- The team’s fault feedback ratio, the ratio of bad fixes to total fixes. See Fault Feedback Ratio.
He said that was fine.
I asked the team, how about if we measured these things together? Yes, that was fine with them.
Measurements Helped Everyone See the System
We measured the team’s cycle time for just features: how long did it take the team to release features?
We discovered the team-as-a-whole had an average cycle time of 3-7 days. John, the supposed 10x developer, had a cycle time of 1-2 days.
If we only looked at the feature cycle time, it looked like John was a “better” developer than the team, if “better” == faster.
However, what caused the team to take longer to deliver their features? The other measures helped us see the problems:
- The time to find and fix problems (defects) ranged from 3 to 18 days. (That’s a huge range.)
- Their fault feedback ratio ranged from 20-50%. That’s enormous. IME, an FFR greater than 12-15% means the team can’t make forward progress on anything.
Defects took longer than features. And, the team had a terrible time fixing the problems.
Where were the problems? In John’s code. Why? John wrote and ran unit tests on his code. However, he only created happy-path functional tests to see how his code worked with the rest of the system.
What about alternative path tests? Or reliability or security or performance tests? Nope. He didn’t create or run any of those tests.
And, where were the problems? All the ways John’s code connected—or didn’t—to the rest of the product.
That’s why the team had such trouble integrating John’s code and fixing problems. He didn’t really integrate “his” code.
John looked good to the outside observer, Steve. However, John made the rest of the team miserable.
John was not a 10x developer.
Steve had several choices. First, we discussed what a real 10x developer might look like.
What is a Real 10x Developer?
While John was speedy, he wasn’t really a 10x developer. In my experience, real 10x developers focus on their learning.
They learn how to think with others. They might pair with others to both support other people’s learning and what they can learn from others.
In addition, they work to simplify their code and the entire product. If they have a lot of knowledge, they might lead the team’s refactoring efforts. Or, they might create tools that assist the rest of the people on the product.
Real 10x developers rarely work alone to create an entire feature set. They more often work with others to build the entire team’s knowledge.
Steve realized that while John was fast, he wasn’t a 10x developer. Yet, he had specific domain expertise that Steve didn’t want to lose.
What could Steve do? He had several options.
Consider Your Options if You Have a Solo “10x” Developer
What if you, like Steve, have a solo “10x” developer? For years, you or the company has recognized—and rewarded—this person for their solo work.
What now?
Explain that the world has changed. You don’t want to reinforce resource efficiency, even though you rewarded the person for that all along. Instead, you want to reinforce flow efficiency. Discuss why you want flow efficiency and overall lower cycle time.
I’ve had good results when I’ve said, “Think how you can work with the rest of the team. Pairing, mobbing, anything that requires you to explain what’s in your head where you don’t work alone on the problem.” (See myths about indispensable people.)
Once you discuss the problem with the person, discuss the problem with the team. Explain that you made a mistake. You used to recognize John for his solo work. You now realize that if you want an agile culture, you want the team to collaborate. Not just to reduce cycle time, but to reinforce the idea that the team learns together to create a sustainable product.
Now, ask the team, “Do you need suggestions from me?”
They might not.
If they do, remind them that you want the team to work in flow efficiency. That you want the team to learn together. And, to start with fixing the existing problems before they create more features.
Then, if they want more concrete suggestions, ask everyone to pair in short rotations or mob as a whole. And, ask the team to track their various cycle times and fault feedback ratios over time.
Steve chose to do all these things. He felt quite uncomfortable when he had to admit he’d made a mistake rewarding John for John’s solo work.
However, he did, and the team appreciated his honesty.
Rethink Your Idea of 10x Anyones
I’ll be honest. I wish I was a 10x anything. I’m not.
I’m good at many things, and horrible at some. Even with what I’m good at, I’m not a 10x.
Back when we thought in resource efficiency terms, we might have made the mistake of thinking we could have 10x developers (or testers or DBAs). Agile thinking and culture shows us that no, we don’t.
What about those rare people who excel all by themselves? First, they are rare. Much rarer than you might think. I think I’ve met a handful of these people over my 40+ year career.
Even if we have people who excel, they need to excel with other people. That’s why 10x developers or 10x managers make no sense.
Steve worked with the team over several weeks to support them as they changed from too much individual work to more collaborative work. He had to work with HR to change how the organization rewarded people and teams.
People behave according to the system of work. If you want to change your system of work, check out Modern Management Made Easy. I addressed this particular issue in books 2 and 3.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Why Very Few (If Any) People Are “10x” Developers-Or Managers Opinions expressed by Java Code Geeks contributors are their own. |
“Even if we have people who excel, they need to excel with other people.” – to the point!
One needs a competent leader/mentor in every team but then other team members must support. It’s like in soccer. You need every team member to push forwards, but then you need gifted striker to make the difference.
Some of my thoughts about this :
https://www.codeproject.com/Articles/5279276/The-Surgical-Team-in-XXI-Century
Lukasz, that’s a great article. Thank you for the link. Glad you enjoyed this article.