Thomas Carney on December 09, 2015 From Developer to Manager and Back Again
You start out as a developer, and your job is to develop a new feature, to write a few tests and fix some bugs.
You might work with a designer. You’ll have interactions with managers of various titles such as product owners or product managers.
Ideally, you spend as little time as possible on office politics, presenting in boardrooms and creating reports. And if you love what you do, that’s probably a really great outcome.
The question arises of how you should progress in your career. Should you stay in a technical role? Or do you want to start venturing into “management”?
You might worry that you’ll end up in a position where you’re not doing what you enjoy on a day-to-day, but rather you’re doing exactly what you wanted to avoid by following a technical career path.
There’s an idea in management called the “Peter principle”. Basically, you’re usually assessed for promotion to another role based on your performance in your current role. That means you’ll only ever stop receiving promotions once you’ve reach a role that you’re incompetent in.
Put another way, employees “rise to the level of their incompetence".
Doesn’t sound good, does it?
At the same time, you might feel that your career will be in danger of stagnating if you don’t move into management.
There might not be a path in your company to advance while staying in a technical role. You don’t want to end up as a team member with decades of experience, while some pointy haired manager is taking the foolish advice of some young hipster. Just because the young hipster has fallen in love with a new javascript framework over the weekend doesn’t mean anyone should listen to them instead of you.
And then there’s the issue that management is actually, well, hard. Middle managers, in particular, are often wedged between upper management and their team. You can end up feeling you have a lot of responsibility without much power.
There’s an entire skill-set of management that doesn’t come naturally to anyone. You have to spend your days conducting one-on-ones, giving reviews, hiring and firing.
It all has to be learnt.
I talked with three different developers who’ve taken different paths in their career.
Stephen Haunts transitioned from working as a developer to working as a manager, and he loved the change. Rob Walling moved from a developer to a manager, but ultimately, he was drawn back to coding. Jan, the founder of Planio, took a middle path: he still works on code on a daily basis, but he also runs Planio as well as LAUNCH, a co-working space in Berlin.
Stephen Haunts: Transitioning from a Developer to a Manager
At some point, every developer will have to make a decision: will they stay a developer, focusing on code, or will they move into a management level position, managing others?
Back in 2011, I was working as a senior developer. I started getting involved as a mentor to students, and I ended up running the academy program while carrying on my role as a lead developer. I later moved into a role as a development manager.
First off, you have to figure out whether moving into management is right for you. A pay rise alone won’t be enough, because how long will that keep you motivated? The question is whether you want to help build a strong team that will deliver for the business. That will be your core role.
A pay rise alone isn't enough reason to become a manager, because how long will that keep you motivated?
I found it very helpful to get mentorship or formal leadership training. Even something as simple as getting a coffee once a week with someone who has experience in management will mean you get invaluable advice on handling challenging situations.
One of the hardest things when transitioning from a coding position to a management one is letting go. You can’t jump in to solve technical issues every time they come up. You have to learn to let your team solve the problems. Otherwise, you run the risk of turning into a micro-manager.
Based on my experience, I’ve created a Pluralsight course on how to decide whether becoming a manager is right for you and how to tackle your first 90 days as a manager.
Stephen Haunts is an experienced Software Developer and Leader who has worked across multiple business domains including Computer Games, Finance, and Healthcare Retail and Distribution.
Rob Walling: From Management Back to Coding
Early in my career, I found I was often pushed upward out of coding and into a management role. The most common reason is that businesses tend to promote those who are best at writing code into project management roles, because they deliver on key projects.
Unfortunately, putting someone who loves writing code in a position where they won’t write code doesn’t make much sense. It’s similar to promoting your starting quarterback to coach.
Putting someone who loves writing code in a position where they won’t write code doesn’t make much sense.
Instead of this approach, I think businesses should focus on promoting developers who show management skill into management, as opposed to those with excellent technical skills.
Secondly, technical tracks within a company can be a way for developers with exceptional technical skill to move up in terms of power and seniority without moving into management, where they are likely to feel frustrated and probably leave the company eventually.
Personally, I enjoy running a small team. But when I moved into management years ago I missed being able to focus on “creating.”
I love building things. Turning ideas into something alive.
That’s why I eventually decided to leave management at a large company in favor of running a small consulting firm. Where I could do a bit of both - build and manage. I eventually left consulting to build products...but that’s another story altogether.
I’ve written here about how you can avoid the pitfalls of leaving management for development.
Rob Walling is a serial web entrepreneur and founder of Drip, Lightweight Marketing Automation That Doesn’t Suck.
Jan Schulz-Hofen: A middle ground?
Moving into management can be very scary. Coming from a software engineering background, I was scared as hell when I hired my first employee.
I always enjoyed working with code and computers. If they didn't do as I said, I'd spend some time debugging, but eventually they'd follow my orders. If I did something wrong, there'd be an undo button somewhere, and if all else failed, I'd just shut the thing down and start over the next day.
Working with actual people is very different. People have feelings, personalities, moods, motivations and goals of their own. There's no undo – it can take a lot of time and work to take that thing back you said. And there's no shutdown button. You can't simply start your day with a few hours of "managing" and then move on to other things. Management is a constant process. It consumes most of your time – and it tends to stay on your mind, even when you're not working.
So what can you do?
Option A: Be a manager
As a founder, there's hardly any other way. If business is good and customers sign up, you'll eventually end up being overwhelmed. There are only so many hours in a day – last time I checked 24 to be precise. As an engineer, you can (and should!) automate away as many tedious and repetitive tasks as you can before you hire folks to do them. Still, you'll need help eventually.
It took me almost three years to realize and accept this fact. Fast forward to today, as a manager of my small team of ten, my work is mostly about enabling everyone to do great work. It's about removing roadblocks of all kinds, be it technical, within the team or with your team member herself. Your job as a manager is to help bring out the best in everyone. It is about relationships and guidance, about trusting and being trusted. As a good manager, your conversations will be more about the vision and goals, less about the steps to reach them.
This is still a very real challenge for me, having done everything myself during those first years. It is, however, extremely rewarding. When your team does great work without you being part of the process, and when you realize how much your team achieves, bringing the company forward, when you sense that feeling that people are happy about their jobs and the fact that they can focus on it while you take care of the managerial aspects of it, it really feels awesome. I enjoy this every day.
Option B: Become a specialist
In some (more technology focused) companies, you can remain a developer and be perfectly fine. If you are a specialist in your field and this field adds real value to your company's business, your manager should be more than happy about you staying exactly where you are, excelling at what you do.
Your manager should be more than happy about you staying technical, excelling at what you do.
Your knowledge and your technical vision make you a great asset to the company. It should not be hard for a good manager to realize this and your decision to not "move up" to a management role should not affect your career (and pay grade) advancement.
Should that not be the case, you might consider switching companies, though. (But be sure to talk with your manager about it first, you might be surprised at the outcome.)
Option C: The middle ground
Here's a secret that keeps me sane. Being a developer-turned-manager, I used to miss the quiet time when it's just me and the computer. For me, writing code is recreation. It's a way of calming down and relaxing. Similar to reading a book.
My advice is: when you want to code, code! Find a feature, or a bug that nobody is working on yet, and set a few hours aside. Tell your team that you need some quiet time or work from home. There's nothing wrong about it and if you're like me, it will give you back that energy that being a manager consumes and actually helps being an even better leader to your team the next day.
Jan Schulz-Hofen is the CEO of Planio, issue tracking and project management for software projects.
What was your biggest takeaway from the stories above?
