Return from the Dark Side
There comes a time in a software engineer’s career when they start asking the dreaded question. Do I continue writing code as an ‘individual contributor’ or should I start the gradual descent into management?
Here is my tale of exploring the ‘dark side’ and eventually coming back. Take it for what it is, pseudo-philosophical ramblings on an unoriginal topic, as compiled from several anonymised places of employment.
Motivations
What motivates these forays into management? There are good reasons, such as realising that you’re great at mentoring people and enabling them to do their best work. This article won’t cover those as plenty of LinkedIn listicles already do. Here are some bad reasons.
Some people in the industry seem to think that reaching a certain age implies that it’s time to close your IDE, open your email client and become a manager. The exact age varies but it’s a popular enough theory to warrant a mention.
Money is another one. In larger companies your pay is determined by which ‘band’ you belong to and these bands usually separate the managers from the non-managers. As a result, you get people who are in management only because their annual pay reviews hit the wall.
Then there’s the old ‘nobody else for the role’ scenario. Your manager got promoted up a level and somebody needs to fill his/her shoes. You’re the tech lead, you practically already manage the team, right? So who better for the job than you?
That last one is what happened to me. At the time I considered it a specific situation that only happened in our team, but after telling others about it, I quickly realised that it’s hardly rare. Regardless, that’s how I embarked on my journey from ‘tech lead’ to ‘team lead’ (if these terms sound the same to you, please look them up before reading any further).
Learnings for Make Benefit Glorious Reader
I have no idea why I called it that. I don’t even like that movie. The point is, experiencing the ‘greenness’ of the grass on the management side leaves you with some lessons that you can carry further into whatever you end up doing next. Even a failed experiment yields data.
Meetings are Mostly Pointless
Communication is important, nobody is disputing that. If everyone is just writing code 100% of the time without aligning on what is being built and why, you will be extremely productive at achieving absolutely nothing. But there’s useful communication and there are meetings for the sole purpose of having a meeting and appearing more busy than you really are.
Unfortunately, managers are constantly subjected to meetings that produce less results than going out for coffee. ‘Power play’ meetings to show dominance, ‘get everybody in the room’ meetings to dilute blame if anything goes wrong, ‘lip service’ meetings to assure somebody important that a project is being worked on even though no resources are allocated to it, and many other types of meetings specific to each company.
How do you navigate these situations? No idea. Some people might get away with declining meetings that they don’t have to be in, others just use the time to get some work done on their laptops. The argument that sitting in meetings is not your job does not fare so well anymore now that writing code is no longer as high up on your job description.
If only companies with prevalent ‘meeting cultures’ installed conference room counters to measure the monetary cost of each meeting. Surely the dollar figures would help curb some of that behaviour.
Exposure
What you often don’t realise as a software engineer is how much you’re being shielded from. You may have some idea, perhaps you even think of your manager as a great ‘sh*t umbrella’, but you never truly appreciate what falls on the fibres of that umbrella until you are it.
It’s not just pointless meetings but any number of things: pressures from senior management to deliver faster, inter-departmental politics, attempts from people with no expertise in what your team does to dictate how they should be doing their job, take a pick. All of this is now your business. These things might annoy you, even piss you off, but when you return to the area of the office that you and your team inhabit, you have to be cool and collected as if nothing happened. Anything you do relay to them has to be filtered and carefully phrased, otherwise you might start a chain reaction of rumours, overreactions and panic that won’t end well.
This balance between being completely transparent and as secretive as a press secretary for a totalitarian regime is incredibly hard to master. There’s no one stable solution for it. It completely depends on the culture within your team and how impressionable specific individuals in it are.
If you filter too much, you risk being perceived as a Frank Underwood-esque ‘puppet master’ who uses inside information to their own advantage. Conversely, if you’re completely transparent and relay everything that’s happened in this morning’s planning meeting to everyone, your most junior team member will start losing sleep fearing that everyone will be fired over an impulsive outburst from your CEO that engineers aren’t delivering quickly enough. Go figure.
As much of an inexcusable cliché it is, with great power, and in this case knowledge, comes great responsibility. No matter how minor the increase in that knowledge, you can either help or hurt your team with it.
Satisfaction Not Guaranteed
A software engineer’s job is engineering software. That’s what your performance is measured by and where your job satisfaction comes from at the end of a hard day.
A manager’s job is managing these people by removing any barriers standing in their way, guiding them through an oft-complex maze of company politics, and taking on unimportant (often unpleasant) tasks that would distract them from achieving their goals. It requires you to be a selfless jack of all trades who only succeeds when his/her whole team succeeds and who takes all the blame if everything goes south.
That’s easy to say, harder to do and harder still to get satisfaction from, when only a short while ago your main objective for the day was making all of your integration tests pass. Suddenly, it’s five o’clock and all you’ve done is attended some meetings, wrote some emails and maybe reviewed some code, if you’re lucky. What a frustratingly unproductive day, says your unadjusted brain. It’s draining!
Like with the last two points, I don’t have a universal solution. What helped me was making mental notes of things that you do throughout the day that provide value to somebody: you answered a question that unblocked somebody from working on their task, you found a potential bug while reviewing somebody’s code, you contributed to some design discussion, anything like that. The gratification is not as instant as running code and seeing it work, but it’s something.
No Life Sentence
Regardless of whether you’re enjoying management or not, it should not be a life sentence. There’s absolutely nothing wrong with your LinkedIn status changing from ‘Manager’ or ‘Team Lead’ to ‘Senior Software Engineer’, unless you’re the sort of person who’s a little too invested in job titles.
While I can’t speak for every hiring manager out there, I personally see alternating between ‘doing’ and ‘managing’ in people’s resumes as a positive. It means they’re never too far away from management to understand their perspective and they still know what they’re talking about from the technical standpoint. There’s nothing worse than a person in power who makes technical decisions having been off the tools for decades.
As long as there’s opportunity, focus on doing what you’re good at and what you enjoy doing, not what you think your career path has cornered you into doing. It’s not a sign of defeat or a downgrade, it just means that you missed doing things that you were helping your team do.
That reminded me of a quote from Kris Howard’s article where she announced her departure from organising technical conferences:
After being around such inspirational folks tackling big problems… I suddenly realised that I missed being those people.
That’s precisely what I did, I went back to being one of those people. It’s not that I’m completely ruling out the possibility of going into leadership again, but I’m enjoying the return to being an individual contributor for now.
Your Mileage May Vary
Here comes the disclaimer. Everything in this article is based solely on my own experiences in specific companies. While I’m sure many readers will identify with the problems that I encountered, that doesn’t mean that they are unavoidable.
Many software companies, as opposed to regular companies with software departments, encourage managers to remain hands-on. I’ve personally met a CEO of a software company with around 1000 employees who still regularly writes code.
Similarly, the ‘meeting culture’ isn’t as bad everywhere. Startups and smaller companies are often good places to escape it. The reason being that smaller businesses rely on everyone pulling their hardest to survive, unlike, say, a major bank that has enough redundancy to afford such inefficiencies.
So don’t be discouraged. Just ensure that your move into management is for all the right reasons and do your research before committing to it.
A piece of trivia for the afterword is that I started writing this article shortly after I resigned from my management job and only finished it over a year later. While it admittedly smoothed out and added perspective to some of the harsher points, none of the overall opinions have changed. Hence why I decided to publish it after all this time and not relegate it to the eternal drafts folder.
