Developer to Manager

TL;DR I've been working on Developer to Manager for the last few weeks. It's a collection of interviews with software developers who moved to management, and explores what they learned, the best advice they received on this topic, and so on. Check it out!

In the software industry, the progression from being a "software developer" to being an "engineering manager" is considered fairly normal. Well performing developers are often "promoted" to a role where they are not writing code anymore, but are instead responsible for managing a team of developers.

As a software developer, you write/review (at least a little bit of) code every single day. You're fixing bugs, implementing product features, pushing commits, reviewing/merging pull requests, you know the drill. Your life basically revolves around code.

As an engineering manager though, most of this changes. Depending on your company, you might still write code every now and then, but it won't be your main job. Your main job now is to support a team of developers and figure out how to juggle everything to be able to add maximum value to the business you're working for. Sounds vague? Yes, it is. You are now responsible for shielding your developers from external factors, aligning their career goals with the daily work they do at your company, regular one-on-ones with them to make sure things are going alright, some other responsibilities you don't know about yet, and a few more responsibilities you don't even know that you don't know.

In a nutshell though, your life is now revolving around people.

If the two roles are that different, is a "developer -> manager" transition really a promotion?

The Back Story

About two years ago, I co-founded a startup with a few friends, where initially I was the only person responsible for software development. We did bring a few other people on board later who now handle a major chunk of work, but the team is still quite small.

Anyway, when you're the only developer co-founding a startup, you're often considered the "face of software" for the people doing business development. This additional responsibility requires you to do a lot more than just write code. Additionally, since you're personally vested in the success of the company, you're not in the "employee mindset" anymore, which means you can't just sit back and wait for someone else to give you things to work on. You need to interface with business development, make sure that software is being written smoothly, there are no bottlenecks, the developers working along with you are happy, their career goals are being met, you're meeting deadlines, and so much more.

It's a very delicate role, and depending on what makes you tick, it can either be the best thing to happen to your career or the worst. I personally don't think there's anything in the middle.

The Motivation

When I found myself in a similar role (which was way outside my comfort zone btw), I realized I was both excited and apprehensive at the same time.

Excited, because this is an opportunity that allows you to impact your organization like you could have never imagined. Such a position requires you to step out of the "coder in the corner" mindset and try to figure out how to help the business succeed, and then go ahead and do all of it. The leverage you have here is immense.

Apprehensive, because with great power comes great responsibility. And how do you assume responsibility without knowing much about what you're getting into?

With this chain of thought, I started looking for resources to prepare myself to handle things better. I like learning from books, so my first instinct was to search for books on this topic. It's difficult to sift through the typical "how to become a manager in 24 hours" noise, but I managed to find two really good books - The Manager's Path, and Managing Humans. Both of them are written from the point of view of a software developer, and are highly recommended reading if you're interested in this domain.

To my surprise though, I couldn't find that many more resources. Maybe my DuckDuckGo skills are getting rusty, but I found it frustrating that there aren't that many good resources written from a developer point of view, especially given how crucial such a role can be to a software company.

What I would have really liked to have when starting out, was to just know how others handled it. Nothing fancy, but just having some other engineering managers answer a common set of questions about their transition so I could get a sense of how best to prepare myself for something like that.

I wasn't looking for an exact set of steps I should take to become a good manager (not to imply that something like that exists), but just knowing that someone else has been in your shoes and managed to come out successful goes a long way, and helps in a way no article/book/teacher probably can.

The Process

Since I couldn't find something like that, I decided to try building it on my own.

I started by contacting a few of my manager friends and talked to them on this topic. After almost all of them agreed with the premise, I realized that the idea cannot be completely stupid and that there could be something worth exploring here.

I then brain-stormed a short list of questions that I would have liked to have other engineering managers answer, and then emailed it to a few of my friends and a few more people I found on the web. The idea was to have different people answer a common set of questions so that the readers can get different perspectives on the same topics.

The response I received was extremely encouraging. People were more than willing to invest the time into talking about their transitions to help younger developers make this transition successfully. And there was a ton of stuff to explore here - best practices, things to keep in mind, things to avoid doing, and much more.

The Product

Developer to Manager is what has come out of all this.

The site currently hosts a collection of interviews with software developers who moved to management. I ask them a few basic questions about their background, what their transition felt like, what their takeaways were, and so on. As I mentioned before, the idea is to get different perspectives on similar situations.

I try to publish one interview every week, but of course this depends on the availability of interviewees.

In the longer term I would like to see "Developer to Manager" evolve into the website you open when you want to learn more about how to become a good engineering manager.

How do I plan to do that? I don't know yet. There are a ton of things floating around in my head right now which don't necessarily fit together, but I have the feeling that given enough time it should be possible to incorporate all of them into the product.