Software Engineering Leadership is not (Only) About Coding Well
Software Engineers tend to think that being a successful engineer means being an awesome coding machine.
It’s true that with the ability to code, you’ll be able to get things done and move quite fast.
It’s also true that without the ability to code well you’ll find it hard to succeed in the tech world.
I’d like to suggest that once you get to a certain engineering level, the amount of responsibility you take increases dramatically. At that point — you understand: keeping responsibilities only to yourself becomes impossible, you can not grow alone.
This is also the point you have to “give up” parts of yourself, and this isn’t trivial psychologically. Two important skills that demonstrate this are building consensus, and scaling out your engineering skills.
Who is this post for
This post is for those confident and independent engineers that are used to being effective in code-bases, that are able to execute, that find themselves taking responsibilities and holding them close. These engineers might be on the path of being blocked by their inability to understand how growing the environment is critical to growing ourselves.
Building Consensus
Let’s define consensus. According to the Cambridge Dictionary: a generally accepted opinion or decision among a group of people.
In a sense, creating consensus means to make sure the group as a whole believes in the path that is being taken, and forming, as a group, a single opinion that is shared with all members of the group.
As a leader within a group of Software Engineers, you make things happen by creating consensus. You lead by understanding what should be done, and by creating an overall agreement that the subjects you bring up are the most important ones to deal with.
If you won’t build consensus — you will eventually find yourself quite alone.
I used to work on the performance of a framework we built in my team at FB. We created the framework, we were responsible for it, and as we scaled it, we had to improve its performance.
Back then, since the framework was rather new, we didn’t have a lot of tools to measure which areas of the code consume most of the time. But we had a hunch towards a specific, non-trivial area that was hurting performance.
We tried to work with other teams and explain the situation. They didn’t really believe us that the issue is there.
It became a political challenge. We needed to convince other engineers about an issue that they don’t believe exists at all. How do we do that?
You need to build consensus smoothly and slowly.
You know it works when someone else, that is not you, says they believe there’s an issue with the framework in a non-trivial area.
In the story above, it took us a few months of a process. Finding a right person, building a good connection with them, building a mutual understanding of the problem, letting them lead the discussions with other people, letting them bring more people in, initiate a project to execute on it and eventually show the impact.
The psychologically nontrivial part here is that you have to be prepared that someone else will get big parts of the credit. This is great. You need to be confident enough about the path you are taking, about the place you take in the company, about that the relevant people (usually leadership) know your part in this, in order to succeed in this.
Scaling Out (as opposed to Scaling Up) your engineering skills
It’s just like a web-tier you want to scale. You have two options: optimize the current implementation, or rather add more servers.
It depends, but usually both is true — keep optimizing, but add more servers as long as needed.
Scaling up your skills stands for getting better in writing code, creating architectures and building them, solving complex problems and creating and executing engineering plans.
Sharpening these skills is something that is worth doing as long as you are a software engineer. Read books, read tech blogs, understand where the industry is going.
So, how can we scale ourselves better? By scaling out!
Scaling out engineering skills stands for the ability to grow other people around you, to make them as effective as you.
Specifically, I’m referring to taking your best skills, and growing others to master them too.
For example — Consider you are very skilled in getting around very large code-bases and in changing code you never saw or touched. Let’s say this is your mastery and this is what you are known for.
Scaling out means to teach other people how to do it as effectively as you would instead of keeping this ability to yourself and “enjoying” the fruits of being the only one who does it so well.
This process might also be non-trivial. In a way, our strengths are what differs us from the rest, it’s the thing that makes us special. Growing other people around us to be as effective as us, means that other people will get the credit on the same strengths that we currently have and no one else does. Wouldn’t it make us less special?
The answer is that the same underlying personality that helped you build the unusual strength, will help you understand and build the next unusual strength that can do more while leveraging the stronger people around.
This is comparable to management growth. If we want to grow the organization, we bring in more people, open more teams, and promote a manager to be a manager’s manager, thus adding a layer in the middle. Without bringing more teams to the table, we wouldn’t be able to increase the responsibility of the promoted manager.
You have to be confident you are good enough in order to genuinely wish for people to take over your strengths and execute on them. It isn’t easy to just “give up” responsibilities and letting other people do the work you know you can do best.
Did you ever have the feeling that if you are going to be gone for a month things will just stop working and everyone is going to fail? This is the kind of feeling that good scaling out prevents. You genuinely build the people around you, you actually believe in them, and they actually provide the results. You should be able to disappear for a month, and things should just keep moving at the same pace. It shouldn’t depend on you.
At the End of the Day
Being a leader in the tech industry means that you should be confident enough to let others take the credit, and build the skills of others, for the sake of your growth. It is building the understanding that only when you “give up” those, you actually can build your own new set of enhanced skills.
