Pun intended… For years, that I spent in the software development, I've seen that again and again: an individual contributor gets a "lead" title and fails miserably. It almost feels like the "lead" title is the leading career killer.
Have you ever thought about that? Or about why does it happen?
The high-level answer is that software developer and a lead or manager are very different jobs, which require different skills and balance of strengths and weaknesses. It looks natural to us that best performing ICs are promoted to leadership roles, but only because that's essentially the only career path existing in most of the industry. In reality, it's as natural as promoting a good fish to do a job of a bird – in most cases it just won’t not fly.
Want more specifics? Let me tell you a story of two leads…
The first story is about a guy, let's call him Kemal, who was a good strong developer with well thought-through code, good productivity, and low bugs level. He managed to find a style which worked great to his strengths and kept in control his weaknesses, whatever they were. One of the things, he always did, was to build code incrementally, if necessary refactoring previous levels on fly. It worked well for him in IC role, but then he become a lead. Worse than that, he become a lead for a new large component, essentially a product, where tons of new code had to be created.What happened next was that Kemal began spending a lot of time at work trying to get things together in his head and his new code, while the rest of his team was treading water or simply did not know what to do. He was occasionally sending them on some fool errands, for example, he could give them pieces to write, but then changed design on fly and all their work was thrown away. Sometimes, in the middle, Kemal could force a developer to rewrite perfectly working code many times to satisfy Kemal's style and views on the software development, just to throw it all eventually away with another change in design by Kemal. Just for reference, the project was fairly high profile, so Kemal's developerы were very good hand-picked developers. It's just he wanted everything written in his style and according to his latest opinion. Testers found some ways to entertain themselves, while program managers were treated like public enemies with an exception of one, who was eagerly rewriting his specs every day based on what Kemal mentioned this time. Naturally, the "spec" after that was completely useless.The project got stuck. Like, dead stuck. Finally, the manager of the project has convinced Kemal to try his luck in another group, appointed a new lead, who did not kept the project at throat, and the things started to develop.The second story is a little different. The guy, let's call him Chuck, was friendly and smiley, you know, dog style friendly, which could be really annoying to a cat person, but still everybody liked him. Chuck was not as much a developer as a hacker. I never seen any really complex code produced by him, but if you needed to borrow one million lines from another product and make it compile, build and work in your code base or quickly produce tons of more or less linear code with tons of calls to obscure APIs or fix tons of trivial bugs fast – Chuck was your guy.Once promoted to a lead, it occurred that his definition of a "lead" is not far from a slave driver on a plantation. To make things worse, he actually did not got much of a charter or a project to drive. Which, frankly, I believe to be the fault of the dev manager, who just wanted to delegate 1:1s and review paperwork instead of really building the team structure. In fact, all interesting and important work happened to be in the hands of the second lead, situation which did not work well with Chuck's idea that he gives his people tasks and they do those. I personally heard him saying "Why other team uses my RESOURCES?", where "resources" were people. I good lead could still handle the situation and make lemonade out of lemon by making his team a sort of service team driven by the requests of another team, but Chuck was not an experienced lead and he wanted his own projects, which clearly were not available.To make things even worse, he's got two people one of whom was fairly senior guy keeping good view of the whole project and driving on his own what needs to be done. In addition that guy also owned a piece of fairly complex multithreaded infrastructure code. Other team members occasionally did changes to that code, but when Chuck tried to do so, he almost inevitably was introducing new bugs to it ranging from dead locks to memory leaks. You can guess how well did it go with Chuck. In fact, he blamed the guy's programming style and eventually drove him off the team.Chuck still had support of the management, so he's still got more people who, after being mistreated as well, eventually also moved away, left the team and one of them even quit the company.
Of course, these are two extreme examples and I hope you don't experience anything close to it on any side of the equation. Still, they are characteristic of milder problems most ICs experience when moving to a lead role. What are they? Let's start from the #1 rule of any business:
Know thy business.
The answer is often surprising. There is an urban legend that when one of founders of McDonald was asked what is his business, he said "I am not in a burger business, I am in real estate business." Most ICs think that lead is supposed to build the product, but that's not true. Lead is supposed to build the team, the team that will build the product or provide a service. And that changes a lot of things.
While lead is supposed to write code and contribute to the design, and sometimes he may have no choice but do so, these are not his prime responsibilities. The question which should keep him awake at night are not "How my product will scale?" or "How this feature will work?", but rather:
- Who (maybe me) on my team is responsible to make our product scale and can he do that?
- Who (maybe me) on my team is responsible to decide how his feature will work and can he do that?
- Is workload on my team even? If one person (maybe me) has too much, can I unload some of it to somebody else (not necessarily and preferably not me)?
- Does that somebody else has capability to take over?
- Why would he want to?
- Does that piece matches his strengths or weaknesses?
- What are my team members strengths?
- How do I play their strengths and avoid their weaknesses?
- Does my team scale?
- What are the bottlenecks that prevent my team from working faster and better?
- How do I remove those?
- What is my team's "bus factor"? Is every piece understood and supported by at least two people?
- Should every piece of code has primary owner or all the code should be owned by everybody? How I make sure it really is, one way or another?
And even if the new lead understands that he should build the team, there is question how? How would one build a team? And the truth is that the only way to build a team is by combining their strengths. You may wonder, what about tons of team-building techniques in management books? Am I trying to say they don’t work? No, some of them work. Those that help you build your team by combining people’s strengths. Each time you try other techniques, let it be number of bugs or bug fixes per developer, “everybody should be able to do X”, you risk building the team by combining their weaknesses. Guess where does that bring you?
Let’s consider an example. Suppose, you have X bugs in area A and X (same number) bugs in area B. Developer A can fix N bugs per day in area B, but 4*N bugs per day in area A, while developer B can fix N bugs per day in area A or 4*N bugs per day in area B. How do you assign those bugs to developers?Ok, you may play a hardass and claim that "everybody should be able to fix bugs anywhere in the code". You may even have a legit reason for that - if you only have three developers including you, and one gets sick while another is on vacation, the one left will have to handle whatever will come his way. If so, pay with 4 times more time to do the same job. It's not like they are "bad developers", it's you who plays to their weaknesses and does not want to pick the bill – more time spent on the same amount of work.
When I showed the draft of my article, I was told it makes an impression of written by a technical person. Well, I am a technical person, but the truth is that the article talks about something opposite to what an average technical person believes. Most strong technical ICs believe in a uniform set of skills and strengths. And the truth is that most of them don’t really have that uniform skill set, in fact, most of them believe in different skill sets. But as long as they are ICs, they can afford living in an ideal world and believing whatever they want. Leads and managers simply cannot afford that. They must understand that people are different and should be handled and used differently.
They are not you!
But there is more, when an individual contributor gets promoted to a lead, he, like Procrustus from Greek myths, starts to measure everybody in the team with his own ruler, trying to make short longer and long shorter, and that’s wrong. He does not realize that he formed his strengths over many years, but similarly other people developed other strengths over many years, and there is no way they will develop his strengths overnight. If it would be possible, all you would need would be a bunch of guys straight from the college, or even without it.
It’s tempting to try make your people fit your ideals, but by doing so, you will become like Moses, who led his people 40 years in the desert because they were not perfect enough to enter the Holy Land. You are not Moses. Nobody in the software industry can afford wondering in the desert for 40 years, you will need the results much faster.
And now we come to the final key part. By holding too tough grip on the project, you become the bottleneck. If nobody can breath without your blessing, everybody needs your blessing, and you won’t have time for so many blessings, and so nobody can really breath in your team or, what’s more important, do any work.
You have to not just “delegate”, you have to trust people. And “trust” does not mean sending them without direction and expecting them to do exactly as you want or imagine, but rather letting them do their job their way. Of course, their way must work, but that’s what should be your primary criteria, not a fit to your ideals, like Kemal did. What’s next? Simple things take huge time, people quit, project fails. When you want everything being your way, your team won’t scale.
Why? Because people are not computers. For years you created code for computers and then they did exactly as you wanted. Why did you become a lead? You wanted to do more. What limited you? Computer required every smallest detail to know what you want it to do. Now you’ve got people. If you want them to do exactly like you want to the smallest details like computers did, you will have to specify the same (if not more) amount of information, and so, you will end with the same (or even more) amount of work, that you already was not able to handle, with the exception that it’s a human on the receiving end, not a machine. Makes sense?
So, as a summary, if you are a new lead:
- Don’t build the product, build the team.
- Combine people’s strengths, not weaknesses.
- Let people reach goals in their own way.
