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.”