Developer Turned Manager

In February of 2015, I was promoted to Engineering Manager at Stack Overflow. This has made a lot of people very angry and been widely regarded as a bad move.

There are tons of things I’ve learned so far, some of which I’ve learned the hard way. There’s also a world of difference between managing code, and managing people who code. Your day to day work routine changes completely. You define success differently. You feel a little bit like you just rebooted your career and are starting over at the bottom of the skills ladder. It’s intimidating.

I’m going to discuss my experiences and insights over the last 6 months as a new manager. This one goes out to all of the developers out there who wonder what it’s like to be a manager, or are considering taking the leap into the realm of Pointy Haired Boss.

Trust is the most important thing

To be a successful manager, you must earn the trust of your team members. People won’t work for someone that they can’t trust. Combine this with the fact that a large reason that people leave their jobs is their boss (even above money, benefits, commute, or vacation), and it’s clear that this is your biggest priority as a manager.

Trust is earned, not given. A manager can’t talk people into trusting them; you have to show them that you can be trusted. In my experience, the time it takes to earn trust varies from employee to employee. I had the advantage of having already worked with my employees for almost a year, so some people trusted me on day 1 as a manager based on prior interactions. Others took a few weeks or even months to come around. The important thing to realize is that you can’t rush developing trust. Patience is key.

To earn your team’s trust, you must demonstrate good professional and personal character:

  • Hold everything told to you by employees in confidence. Don’t gossip or talk about employee issues with other employees.
  • Have an “open door” policy: make it clear that people can talk to you about anything, at any time that you’re free.
  • Be a person of your word. Say what you mean, and do what you say.
  • Don’t promise anything that you can’t deliver on. It’s better to say “I’ll see what I can do, but no promises” about a raise, promotion, or bonus than to say “sure we can work that out! No problem!” and then not deliver.
  • Never lie to anyone. Being a liar in the eyes of your employees is the fastest path to failure. They will not only distrust you, but actually start avoiding you as well.
  • Be direct with your people about things that you need to address, especially when it’s uncomfortable to do so. Don’t dodge subjects. Don’t avoid elephants in the room. These problems grow and only get worse if left unresolved.
  • Never be passive-aggressive. Don’t gossip about people. Don’t talk about person A to person B behind their back. It’s important to have an outlet to vent, but make that outlet your spouse or family in complete confidence – not your employees.
  • Praise publicly, punish privately. Never alienate someone in front of the team.
  • Be as objective and fair as possible at all times. Don’t give anyone special treatment or status.

All of these things (and more) are essential characteristics of a good manager.

Code scales, humans don’t

The great thing about code is that when written properly, it scales very well. The same code can easily handle both the 1 user case and the 100,000 users case if it’s efficient and optimized. As a developer this is what we aim for, and it’s easy to measure.

A manager, however, doesn’t scale. The work is done on humans, not computers, and human interactions don’t scale. Just imagine trying to reach consensus on a subject in a meeting of 20 people. It’s much easier to do in a room of 10 or fewer.

No manager can effectively manage 20 direct reports. In fact, people experienced in the field feel that 4-10 employees is the maximum. It’s important to recognize that you can’t get stretched too thin; this will cause you to pay too little attention to your employees and make them feel resentful and unimportant. It will also prevent you from getting any work done. If your team grows too large, split them up and get another manager on board to share the work.

Make people a priority

As a developer, people were an interruption and distraction to my work. As a manager, people are my priority. You must always prioritize people. Not just your people, either. It’s not uncommon for people from other teams to want to talk to you for an outside perspective – make those conversations a priority as well. This means being flexible: if they want to call you and chat at 5pm on a Friday, try and make it happen. If they work in another time zone and want to meet at 7am on a Tuesday, get up early and do it.

Another important aspect of prioritizing people is having a regular 1 on 1 with each of your employees. The 1 on 1 is your employee’s safe place to talk. They will tell you about what’s going on, bring up personal or professional issues, or give you feedback on things that you can do better. I have a recurring 45 minute meeting with each of my employees every 3 weeks. They have been incredibly valuable to me so far.

Make an effort to be organized and use your time effectively. Do everything that you can to avoid rescheduling, being late for, or missing a 1 on 1. If you do this regularly, your culture and morale will suffer greatly. Nothing says “you’re not important” more clearly than missing or rescheduling a 1 on 1 for no good reason.

Embrace uncomfortable conversations

As a developer I sometimes found myself gossiping about, or venting to, other developers about people and policies that were annoying me at work. As a manager, your job is to help people address their problems with each other directly. Encourage people to approach the other party to address their concerns, rather than gossip or vent to co-workers. Be sure to lead by example and practice this consistently yourself.

When someone comes to you with an issue they’re having with someone else, get both parties into a private room with you. Mediate a constructive conversation where they directly discuss their feelings and resolve their concerns. These situations can be awkward and uncomfortable, but you must embrace them and make them a part of your culture. Do this consistently until people start doing it without involving you at all. Make sure that you don’t let problems go unresolved; they only get worse with time.

Success is really hard to measure

The great thing about being a developer is that you usually have a specific problem to solve. “The application needs to do this new thing,” “Fix this bug,” and so on are well scoped problems. When you finally complete the work you get the satisfaction of having accomplished something. You might even get some accolades in a team meeting or town hall.

Management is not a race but a long-distance marathon. You will not be crossing any measurable finish lines anytime soon. As a manager, your work is in affecting the often-intangible aspects of human beings: their thoughts, feelings, soft skills, and overall growth. These types of progress are on-going and arguably never-ending. We are never truly finished growing, learning, and bettering ourselves.

Instead of “fix this bug,” a manager’s task is “help Person improve their interpersonal communication style” or “grow Person’s soft skills so that they can be promoted in a year” or even “figure out a way to help Person get to work on time more often because they keep sleeping in.” None of these are break-fix problems, and thus it’s rare to feel like you’ve succeeded or finished something you’re working on. I find that feelings of success come from the feedback of others: an employee thanking me for some great advice or feedback, someone telling me they’re noticing a positive change on my team, or even a “keep up the good work!” from someone outside of your team. Nothing feels better than knowing you’re making a positive impact in the day to day of your people, but it again requires patience to see results.

Nobody sees you do work

As a developer, your work is done overtly. You’re a better developer for being outspoken about what you’re working on, and creating transparency so that anyone – from other developers to the CEO – can see what you’re working on and what’s getting accomplished. It’s easy to show that you’re doing some real work.

As a manager, almost all of your work is done behind the scenes. As a result, being a manager becomes this “out of sight, out of mind” thing where some people will perceive you as doing very little work. This is because when I talk to an employee about their communication style and issues they’re having interacting with others, I do it privately. It’s not as if I can send a status report e-mail to the team that says “I had a chat with Person about their communication issues, high fives everyone!” As a result, nobody other than the person I talked with directly knows that the interaction happened. Thus, to others, it might appear that I never addressed the issue.

The way that a manager shows that they’re doing work is in observable team member improvements. It’s a slow process (like many things management), but it will become obvious that you’re doing good work when the team starts to notice that Person is interacting in generally more positive ways, or on time for work more often. As your people grow and develop, your team will become stronger and more effective; people may remark on your team’s positive changes as well.

Ultimately, your success is the success of others

If you’re in it for the praise, you’re gonna have a bad time. Management is about trust, having direct and sometimes difficult conversations, and doing your work behind the scenes but in direct and fair ways. It’s a very empowering, challenging, and rewarding job that I’m enjoying immensely.

One of my favourite quotes from Futurama was pretty much written for managers, so I’ll leave you with this:

“When you do things right, people won’t be sure you’ve done anything at all.”

Tags: , , , ,

22 Responses to “Developer Turned Manager”

  1. Tuan Ha says :

    Thank you for this helpful post.

    I have the same situation with this post, promoted to team lead from a developer 6 months ago. It’s really my difficult time but I get it throught. If I have these informations at that time, I think everything will be easier for me.

  2. CL says :

    It is always interesting to read and learn about a job from another perspective. A very interesting read. True, I also used to have an impression that managers do not do work. They talk. But, actually, talking is also work, just a different kind of work.

    P.S.: I was redirected from CodeProject’s newsletter because of this quote “When you do things right, people won’t be sure you’ve done anything at all.” 🙂

  3. Just retired says :

    The characteristics you cite for a good manager are those everyone wants in a co-worker — and that’s the point. At this year’s West Point graduation, Gen. Martin Dempsey, Chairman of the JCS, told the cadets to “lead with the soul of a servant”. That’s a good attitude to have, and it also means not asking anyone to do anything you wouldn’t do yourself. If your team sees you clearing the roadblocks, sharing the burdens equally, and dealing with the slackers, they will trust and follow your lead.

  4. Ted McLeod-Morris says :

    Here’s a piece of free advice, which could be what is is worth.
    Look into the difference between power and authority. Power is that ability to make people do what you want. A man standing outside of your car, with a gun, has the power to make you get out. Authority is the power given by an organization. So, returning to our example, if that man with a gun wears a police uniform and wants you to get out, his authority compels you to get out.
    As a manager, you have been given the authority to make your reports ‘do things’. And you have been burdened with a requirement to keep your area productive and free from trouble. Management is not about trust; it is about authority. The people reporting to you will trust you if you are direct and open with them. You lay out some very good rules for treating people in order to earn their trust. I disagree with the statement that you reward publicly and punish privately only in that punishing publicly must only be done for egregious offenses. And by egregious, I mean challenging your authority. Because when one person defies your authority in front of the group, everyone else gets nervous. By showing the group that you will act decisively when challenged, you reassure them that you will keep the group peaceful. Think of a troop of apes. You are the alpha and when you are challenged for control, it would mean an all out fight which could hurt every other animal in the troop. They may not like you, but they hate having the leadership and control of the troop undecided.
    A really good manager knows that people want a parent who pays attention to them. People respect a manager who rewards and punishes in a fair even handed way, in just the way that a good parent deals with their children.
    Upper management should understand that your job is to handle your authority properly. The cardinal sin of management is failing to control your people; you have been tasked with using the authority of the organization properly. If they see you failing to use your authority then they will talk about productivity and blah, blah, blah and you are not working out, here’s a box, go stand in the parking lot while we gather your things.
    Good luck with transitioning from plain old programming to management.

    • MrSuaveh says :

      I am curious about your response to your authority being challenged. Is it egregious to simply challenge your authority or only if challenger’s solution is inferior to yours? Consider a situation where a manager proposes a solution that is challenged by an employee. For example say a manager wanted to move employees out of their cubes and into an open work space to foster communication in an Agile environment? If an employee were to challenge the manager’s authority by arguing the benefits of working in cubes and resist moving would it appropriate to publicly punish them for that? How would you handle a situation like that?

  5. Mickey Mantle says :


    We feel your pain. The transition from Programmer (i.e., individual contributor) to Manager is a difficult one.

    We felt so strongly about it that my friend/co-author and I wrote a book for new programming managers to help distill the over 70 years of programming and managing programmers experience we have titled “Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams”.

    It is filled with insights and rules of thumb (that we’ve collected over the years) to help anyone be a better managers.

    Good luck on your journey; it is a hard but rewarding one.


  6. Ri Caragol says :

    What an excellent write up! I hope all present and future managers of the world read this, remember it and apply it.


  7. Maciej says :

    Thank you for sharing your thoughts on the subject.

    I have made this jump myself a few months ago and the things you have written resonated deep within me. I feel strongly about talking with my team, holding 1-on-1s – someone once told me “you cant have a top performing team without holding candid discussion with each team member AT LEAST once a month”. It enables both sides to establish good relationships and trust. Another thing I have found important is setting clear, meaningful and achievable goals – most people want to know what they are working towards – once they achieve it, if they have done a good job, it is important to let them know about it.

    If you don’t mind me asking, what were some of the reasons for transitioning into this new role? And what do you hope to achieve in it? From my perspective I have always been intrigued by what makes things work (hence my interesting in computer science and coding), being naturally inquisitive translated into trying to understand what makes people behave the way they do and how that can be used to better organize software development teams.

    I wish you all the best in your new role!


    • David Haney says :

      Thanks for the comments Maciej. To answer your question: I’ve always had an interest in people and workplace psychology as well as cognitive biases. I really enjoy helping people succeed, and working with others. I have little fear of difficult or uncomfortable conversations, which also helps as a manager. I hope to achieve a happier, more productive team where each member feels like they can trust one another and is not afraid of healthy conflict. Cheers!

  8. Paul says :

    A challenge I experienced when moving from Senior Developer to Development Manager is the expectation that you will still continue to do the work of Senior Developer – or to put it another way the business’s expectation (possibly without really thinking about it or realising what they are asking) is that you are Developer, Team Leader and Development Manager. Clearly this is unrealistic and not sensible.

    In this situation I have had to do what I feel my job title says I am, and that means resolving issues in the team comes first, answering team member’s questions comes first, removing obstacles to the team’s work comes first, 1 to 1 catch-up meetings come first. If after all that I still have time to code then given the chance I still will, but it comes second to the things I list above. But when you don’t always get the recognition for this it is often difficult and frustrating.

    Also being a manager can be quite a lonely position, in that you are no longer a member of the team in the way you were. You are in the position where you are in the middle between the team and the business. It often helps in the situation to have other managers in the business on the same level as you to be able to talk to (and let off steam too!).

    I read a while ago that the role of Development Manager is to represent the team in the business and the business in the team, and is the approach I have tried to take.

  9. Alastair says :

    I think you should reference some of these ideas, you clearly didn’t work all this out in 6 months as a manager (hope I read that right) and some are pretty familiar. Otherwise a great piece.

  10. Scott says :

    Nice article. I, too, have recently moved from a technical role (Sr. DBA) to manager. I am lucky, in a sense, that my transition was to a team with a different set of responsibilities. I know if I managed a team of DBAs, I’d be much more likely to just jump in and do the work I should be managing.
    When I took some Management Fundamentals courses, some of the things that we learned have proven to be very helpful to me in this new role; they are GUIDE, CARE and SPIN.

    GUIDE is a model used for task-driven events or issues:
    Gather information – Gather first, give second and remember Who, What, When, Where, Why and How.
    Understand the available information – Summarize, Check your and their understanding. Find agreement.
    Investigate Alternatives – Who are the stakeholders? Is it doable? What are your areas of control? Seek and build Ideas.
    Decide on the best course of action Develop a plan and Do it – Win-Win? Pain vs. Gain, Weighted Options, etc. Rember Who, What, When, Where, Why and How
    Evaluate progress & results, Express gratitude

    CARE is for relationship-driven events or issues:
    Commit – Offer and ask for a commitment
    Affirm – Remember your team members have value as individuals
    Recognize – Praise contributions and/or accomplishments (these are the behaviors you want repeated)
    Empathize – Situation and Emotion (Joy, Pride, Fear, Anger, Disappointment, etc.). It is typically better to overstate an emotion than to understate it.

    SPIN is used for feedback:
    Situation – In a specific situation an employee/team member…
    Performance – did a specific task or had a specific response…
    Impact – that resulted in a specific result
    Next Time – Explain how the behavior will result in a positive experience next time by either changing behavior or repeating the behavior.

    From “Achieving on Purpose Your GUIDE to Managerial Success” by Donald E. Simmonds

  11. Gary says :

    Excellent post.

    Just as there are resources out there to become a better developer there are tools to help you become a better manager.

    Take a look at which contains over 10 years of podcasts covering a wide range of subjects.

    I can’t claim to be the worlds greatest manager but that tool and an excellent IT Director help me get much better.

  12. Steve says :

    Early in my management career, a mentor once shared this truism concerning both horses and people….”Speed of the leader, speed of the pack!” Your passion, energy, excitement, attitude can be contagious, whether positive or negative. Thanks for sharing and good luck in your career growth!

  13. Marcos P. Silva says :

    Great article! Thank you very much.

  14. Chopstik says :

    I read this shortly after you first posted it and stumbled across it again today. I had become a manager a year prior to this post but this helped me tremendously and I have found today that I practice most of what you preach in this article. I feel so strongly about it that I have shared it with my current management team as well as a few of the team working for me who are hoping to one day move to management. Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *