For an in dustry that prides itself on it s analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.

You're sitting there in your cubicle, innocently coding away, when the email client chimes and the email comes in. Or, worse, you're at a company all-hands, and as announcements are being made, your name comes up. Maybe, if you're lucky, you're consulted about it first, but the end result is the same: you've been promoted and made a manager. Now there's a team looking at you, waiting for you to make the decisions and you've got no idea what to do next.

I've heard this scenario play out several different ways, but ultimately the questions that I get asked at conferences and over email are some variant of the same thing: “What the heck do I do now? I want to do a good job. I want to be one of those managers who does good things for the team, but I have no idea what to do first. How do I transition from developer to manager?”


The first stage, as they say, is acceptance: In this case, accepting the fact that you are now a manager. Assuming that you don't immediately quit and go try to find a job elsewhere as a developer, you're now in charge of a team. And, truthfully, if you're ever going to advance beyond “just” being a developer, you'll need to develop management and leadership skills, whether you look to advance within your current company or start your own. Deep breath. What now?

Start from first principles. As a developer, your job was to build something, using software, that people were paying you to build. Ideally, said thing was adding value to the world, but ultimately, added value or not, the job is - was - to build something. As a manager, your responsibilities shift. This isn't about what you can do anymore - it's about what your team can do. Where you used to manage tasks, now you manage people. Some part of the job might be to set down tasks that your people will need to do, but ultimately, it's about the people, not the tasks. To be more precise about it, your job “managing” people is to direct and develop people. “Direct” means to give them a direction to head toward, and “develop” means to help them improve themselves. Your problems are no longer code problems, they're people problems. (Truthfully, most problems are people problems, but software developers spend phenomenal amounts of time convincing themselves that the problems are all code problems and therefore solvable by applying more code, and I don't have the space to fix that here.)


As tempting as it would be to revel in all the great things that a manager-leader could do, it's important to realize that this is a huge step for most individual contributors to take. You'll feel a ton of things: excitement, pride, anxiety, and even loneliness. (Loneliness? Indeed - aside from the fact that there's a power disparity between you and your former peers, there's also the fact that when they start making fun of management, they're making fun of you, too. That's always awkward.) It's normal to feel all of these things; in fact, I'd venture to say that if you don't feel these things, you're either not taking the job seriously or you're a touch sociopathic. Maybe both.

That said, you have to get past it fairly quickly. The team needs - and deserves - to see their manager at the top of her game, and you owe it to them to feel at least a little in control of yourself as quickly as possible. It's also sometimes much easier than you think, if you've got a reasonable set of self-empathy and insight.

First, label what you're feeling. Is it performance anxiety (“I'm totally scared I'm going to botch this up”)? Humility (“Wow, maybe I'm not as ready for this as I thought”)? Confusion (“Where, exactly, do I fit in here now”)? Labeling it allows us to take a certain amount of possession over the feelings, and putting energy into the analytical parts of your brain helps take a step back from whatever powerful feelings are currently in control.

You don't want to bury those feelings beneath a veneer of logic and reason. Feelings are powerful and demand to be felt one way or another. Acknowledge them, admit that you're feeling them, and take a moment to examine them.

This is what leads us to the second step: What's the source of the stress? What's causing you to feel this way? Where's the source of the feelings?

For a lot of new managers, the source comes from one of four places:

  • Role strain. There's conflict, ambiguity, or overload in your position. Too much work and too little time, information, or resources to get the job done, perhaps, or perhaps you have conflicting responsibilities. The easiest scenario to imagine here is the classic one of software: You must ship a project by a given date and the customer keeps changing what their top priority is, or the team keeps getting short-changed on supporting resources (like not having time to clear out tech debt or build out reusable components). Solving this requires three things: first, acknowledge that you can't be an expert on everything that might come your way, so find some people that are good at those things and depend on them. (I call this "Hiring for My Weaknesses.") Second, embrace imperfection; you can't ever meet every demand that's made of you. Adapt, negotiate priorities as needed, and use your best judgment as situations arise, then learn from your mistakes as you go. Third, set time aside in your day for uninterrupted work (block it out on your calendar so nobody can schedule a meeting during that time), and pick out some tasks that will allow you to solve some of the problems facing you.
  • Problem-solving fatigue. Humans are funny creatures: if there's a boss, we like to take our non-trivial problems to him or her and ask for solutions. Kids do it, husbands do it, and employees do it. What's worse, sometimes, it feels like they're doing it just to frustrate you or “show you up” and prove that you're not the boss because you can't solve these ridiculously hard issues. Getting past this requires discipline: Draw clear boundaries around the problems that you will and won't (not “can” or “can't”) solve and use those opportunities for coaching the team on how to solve them for themselves (if that's reasonable). The bigger discipline is on you: Don't fall into the trap of using “solving problems” as a way to escape back to your original developer role no matter how comfortable it may feel. If you must write code to find your happy place, do as a former manager of mine did, and carve out some trivial and meaningless part of the project as yours and yours alone, such as the About box or page.
  • Isolation. Like it or not, you are “the boss” now, and your relationships with your peers, colleagues, and former teammates will change. Your “tribe” is changing, and over time, the people who used to include you in their lunch plans don't anymore. Sometimes it'll be because you keep having to bail out to deal with one fire or another, and sometimes it'll be because they are concerned that their idle jokes and comments will have a farther “reach” now that you're in the management chain. What's worse, this won't change: Your direct reports are not, and should not, be your friends. The military has known this for years, which is why the officers have a separate set of facilities for relaxation and fraternization. Bluntly, you need to seek out a new tribe, people who have similar concerns and positions as yours. You don't want to lose all social contact with your team, of course, but you need to accept that now that you have responsibilities for them, including their salaries and bonuses, and that changes up the dynamic.
  • Imposter Syndrome. Over the last few years, this has become a catch-phrase for anybody feeling any amount of insincerity or inadequacy, but it's definitely a real thing for new managers, particularly because most developers have little to no management training to fall back upon. In fact, most developers don't even have the right tools to go learn how to get management training. Many things often get labeled as “imposter syndrome,” but at the heart of it, if you have a deep whisper in the back of your head saying, “If they only knew how out of depth you feel right now, they'd rip you to shreds,” then you're in it. Solution? Ironically, admit your ignorance on various topics. There are some topics on which you have good knowledge, but others, not so much. Talk to your boss - or find a confidant - and admit that you're not sure what to do here. Ironically, this is exactly what Human Resources departments are chartered to provide, and frequently, HR folks welcome these sorts of conversations, rather than the social shunning they typically get, particularly from developers. If you make a mistake, be willing to admit it in front of your team; ironically, it'll help them feel more comfortable doing the same, which is critical to building trust in the team over time.

Finally, step three: Take care of yourself. Before you became a manager, you had stress in your life, too. What did you do to help alleviate that? Do some of that again. Rod Paddock recently wrote how he'd lost some of the love of coding and decided to take up music and art as a way to “get off the grid” and get into doing something new for a while. A few years ago, I took up glassblowing just for the helluvit, and although I didn't stick with it for long, it was enough to help me escape for a while. Protect your downtime - take time away from work, and absent any actual emergencies at the office, make sure you're not still at work even when you're at home.

Still worried? Good. You should be. No, seriously, you should be. Managing people means that you have a responsibility to them, and if you're more worried than enamored of the power, then you're coming at it from the right emotional direction. The more you can view management as being a support role to the people doing the “actual” work, the more you will begin to understand the notion of “servant leadership,” and the more your team will come to appreciate working for you.