One of the reasons I write these articles every week is to help people avoid mistakes in their careers. If it is not possible to avoid them, then at least they can make well informed mistakes.
Today I am going to talk about the transition between individual contributor and manager, and how terribly that is often handled.
I have often had to explain to people that when they start taking on leadership roles, they are not providing an incremental increase in value to their employer. In fact, they are providing an order of magnitude more value. The table stakes are no longer just your own salary, but the salary of your entire team. It is hard to understand this initially because your salary does not jump up to that value, and generally that is one of the more obvious yard sticks people use to measure their value to the company.
The problem is that when you first make this transition into leadership, you are going into professional freefall and it is not always clear what you are supposed to be doing.
The first time a software developer transitions into a leadership role, they are generally not given much coaching or mentoring and are not sure how to solve problems at the next level. The first time that there is a crisis in their new role they will probably reflexively resort to their default behaviors. This is the wrong thing to do, and yet, it is okay. Sometimes the only way to learn things is by making a mistake.
If you are a really good individual contributor and you start to code your way out of all your problems, then you will not make the transition successfully into a leadership role. This is where the problem becomes sinister. The first-time-leader here will want to prove they can do the job, and when there is a crisis, they will also jump in directly and solve it individually, usually when nobody is looking. They will spend seventy-five percent of their time doing their assigned role of a leader, and seventy-five percent of their time working directly on the codebase to make sure the work gets done.
Do you see the problem here?
It takes some time to start developing leadership habits and new default behaviors. It takes longer if you are falling back onto existing default behaviors that need to be unlearned. Furthermore, if you are jumping in to directly help your teams without a direct conversation about it, then you also risk alienating or frustrating your teams. If you are cannibalizing their work and doing it yourself, they could fall into a trap of learned helplessness. After all, why should you try anything if your boss is just going to jump in and take it over the finish line for you? At the very least you will go to them before doing anything significant so they can sign off on it, rather than investing some of your own time learning.
This is a difficult place to be. Unfortunately, it is also a common phase of everyone’s careers, especially at small companies. At a larger, more mature company, you might find more support for giving new leaders some room to grow, and more structure for identifying and preventing individual contributor default behaviors.
It is definitely worse in startups. The lack of institutional support and need to have stuff built before the company runs out of money is a pretty severe issue. Finding the right balance between starting to develop leadership and management skills vs building code will require burning some dry powder reserves. What makes that worse is that most startups are run by serial entrepreneurs who have seen this pattern before and think that it is normal and acceptable.
What is fascinating is when you are in conversation for a Vice President of Engineering role at a company and the recruiter or hiring manager asks “Do you still code”? Generally that is a sign that the business is very early, the title is fictitious, or the hiring manager does not know exactly what they need in this role. Sometimes all three could be true. I have had to bite back the urge in leadership recruiting conversations to ask “How much time does the Vice President of Safeway Foods spend stocking shelves?” It is a legitimate urge I experience, and also not very constructive. For clarity, by the way, I have to reply “Yes. I. Still. Code.”
Now we get to the really interesting part of the engineering leadership dilemma. It is not wrong to ask your engineering leadership about their technical experience. In fact it is vital that your engineering leadership has a good grasp of engineering problems and engineering practices. I have seldom met an effective engineering leader who has not been a software developer themselves in the past. Just about all of them have been through that seventy-five-plus-seventy-five transition period. Given the emphasis these days on work/life balance, why is this still so prevalent?
There are a few reasons.
The first reason is the expectation outside of engineering. Right or wrong, there is something ritualistic about startups. It is some sort of crucible that people throw themselves into, to see what gets forged in the fires of possibility. The upside of a successful startup is life changing even if it is very unlikely. This translates into significant material wealth for early staff at a company, and it is also very true for leadership. I have heard more than one serial startup executive state that they do not want to pay market rate for talent because taking a pay cut is a sign of commitment. That burns my soul. Generally there is not much cash on hand in early-stage companies, so maybe this is some sort of rationalization. I do think that the average person does not negotiate enough for more stock in exchange for this trade off. I also think that most of them forget that only a fraction of a percentage of startups make that gamble worthwhile.
The second reason is the expectation inside of engineering. Let’s face it—engineers are smart people. Smart people like to work for other smart people. They want to believe that their leadership has good, well-informed plans, and that they are making well-educated decisions. The instant that they work for someone who is not making well-educated decisions or does not have well-informed plans, they immediately lose trust and confidence in their leadership and perhaps even their company.
I have experienced this. I had a boss who had a poor understanding of technology. I offered to help them be successful in their role after they made a few obvious mistakes. They rejected my offer, reasonably politely, and pointed to their title as to the reason why they did not need my help.
It did not go well after that.
So what can we do here?
For starters, we can do what I am doing now. We can talk about it.
If you are in this position, you should examine your current role, your long term expectations, and what you are getting out of it in terms of rewards.
Most of the time someone is in a transition role between being a leader and an individual contributor, there is a short window of time on it. If it is more than a year and there is no sign that this will change, then you have a problem in your hands. If you are stuck in this role, you could potentially burn out, or even more likely, your self-preservation instincts will kick in and you will find a new role elsewhere that relieves the symptoms of your pain. Everyone loves to hire someone who is stuck in this position. First of all, it gives them an opportunity to be grateful to you for rescuing you, which is an added incentive to be successful in their new role. Secondly, you just got a new leader trained up on someone else’s dime.
Before you bail out or burn out, you should have a clear conversation with leadership on where you are, where you are going, and what needs to change for you when you are stuck in this place. In that event, if you do leave, they at least understand what happened and maybe understand that they were part of the problem. If they are unable to make a substantive change due to business reasons, they should at least bump your equity as consideration for your struggles.
Alternatively, you should reach out to people who have been through this before. I am presently mentoring a couple of people who are in this position. It does help to have someone inside or outside of your organization to discuss these struggles and to come up with things to do that help make things better, or at least help you develop new habits and break through any potential cognitive dissonance.
The road to being an engineering leader is long and hard. It does not have to be lonely.
Thank you again for reading! If you are in this position and do not feel like you are in a position to talk to anyone in your company about it, please reach out. I would be happy to spend some time learning about your situation and your struggles and I am happy to share my perspective.
See you all next week!
