Someone once asked me, “What’s it like being a manager, as opposed to being a developer?” Having done both, the transition was a central pivot point in my own career, but it’s taken me a while to come up with a satisfying answer to this really important question.
I was able to make a happy and successful career out of a pastime I started when I was six years old. For one of the first programs I “wrote,” I literally copied the source code for a Mastermind game from one of my dad’s books, and was immediately hooked. From there, I coded off and on for fun before turning it into a full-time job. I worked on software for IT, for notebook computers, for compact-disc labeling, and even for big digital commercial printing presses. I solved all sorts of interesting and complex technical problems, and after a while I felt I was ready for a new challenge.
But making the leap to management meant giving up, at least to some extent, the skills and workflow that I’d carefully honed over the years. Nevertheless, after some soul searching and speaking with trusted mentors, I dove in head first.
Now, after three and a half years in management, I’m finally in a position to answer that question. Drum roll… the biggest difference between being a manager and being a developer is in how you measure your success.
Managerial success is different than programming success. In particular:
- Your successes are further apart
- Your successes have a more strategic impact
- Your successes are often achieved through others
Let’s take a closer look at each of those differences.
Your successes are further apart
When I was a programmer, I knew I had a great day when I made several commits I was proud of. I walked into work every day with an idea of what I wanted to accomplish, and usually left at the end of the day having accomplished it. The most satisfying part of my job was feeling like I was making progress every single day.
As a manager, there are days where I go home wondering whether I accomplished anything at all. It’s not like I didn’t do anything, but there are times where I leave with no measurable results. That’s only one of several factors that make managerial success difficult to achieve and measure:
- One of a manager’s roles is to help people change, but that doesn’t happen quickly—change takes time and focus and often comes in small, modest increments
- The kind of change we’re trying to achieve can be gray and fuzzy to define
- It can be hard to realize that there’s a need for change
- It’s easy for engineers to slide into old habits—lasting change requires constant awareness, and pushing beyond peoples’ existing comfort zones can be challenging and uncomfortable
At New Relic, we hold quarterly reviews as a way to check in, provide feedback, and focus on long-term growth. Sometimes you’ll see big changes in a single quarter, but other times the same topics come up in an engineer’s review quarter after quarter with only modest improvements.
While real change has to come from the people on the team, the manager’s job is to consistently guide them. One tool that can help is what we call “regular info-bits.” The idea is that engineers send their managers quick emails about how their careers are progressing. For engineers, the topics usually relate to professional development, teamwork, project updates, communication and information flow, and work-life balance. The process helps people think through how things are going more holistically, and you can get a really good feel for an individual’s growth through these messages.
It may take a long time to see results, but when you finally see people building confidence and growing, it is extremely rewarding.
Your successes have a more strategic impact
A single good developer can make a huge, long-term impact on the business. However, the job of a manager is to enable an entire team to be successful. A good manager can be the difference between a highly productive team and a dysfunctional one.
Engineering problems often come in black and white: You usually know whether you have a good solution to a technical problem. People problems, though, are almost always cast in shades of gray. Even if you know what problem you’re trying to solve, the solution isn’t always clear, and just because you solved a people problem one way in the past doesn’t mean you’ll be able to solve it the same way in the future. There are simply too many variables in human behavior.
Think of it like black box testing. You know some of the inputs and you have an expected output. But you can only guess what might be going on inside the box.
For example, building a functional team that works well together poses a number of strategic challenges:
- Building a team is not as simple as rounding up a group of all stars
- A cohesive team must be pieced together with an understanding of individual strengths and weaknesses
- Team dynamics are a constantly changing puzzle that needs to be revisited whenever people join or leave the team
Finally, team building becomes even more complicated when you consider the added challenges of hiring. You won’t always be able to hire the ideal candidates and you may not have the resources to avoid important gaps in the team.
As manager, it’s your job to make sure your team is set up to run as efficiently as possible. But you can’t just wade in and make drastic changes to processes and expect immediate improvements. Given these challenges, effective managers need to:
- Constantly evaluate what the team needs to get the job done
- Be aware that needs can differ with different jobs and different teams
- Use and invent the right tools to support the process
The key to making processes work is to make incremental changes, measure them, and then improve them. For example, if you see that your team is being overwhelmed by support issues, find a way to make it less chaotic. Give your team tools to prioritize. Work with your partners to filter out noise and let only important issues surface to your team. And then check back to make sure the changes are making a difference.
Your successes are often achieved through others
At New Relic, we believe in the concept of the Invisible Manager. This means that we work behind the scenes to put our engineers in positions to succeed and highlight their successes—while we stay out of the spotlight.
We make sure our engineers get the credit because they deserve it. So when New Relic delivers a cool new feature, we encourage the team to talk about it to a broader audience rather than having product managers or engineering managers present it. At our recent engineering offsite, for example, most presentations came from engineers, not just business leaders.
Most people who manage groups of programmers were probably successful engineers first. Losing that can hurt, but being a manager offers a chance to have a bigger impact, not just in business but on people’s lives as well. And many managers find that helping others helps them grow, too.
Managing yourself first
It’s very easy for me, with an engineering background, to focus on the problems at hand rather than the big picture. So I maintain a strategic plan that covers everything required for the team to be successful: team growth and dynamics, quality and support, product delivery, conferences, blog posts, and so on. I try to have a clear vision of where I want the team to be in a year, and I reference this vision before 1-on-1 meetings, when setting monthly goals, etc. It really helps provide context so day-to-day decisions end up contributing towards our long-term goals.
Managing a team properly takes lot of work. But it can also be a great source of pleasure and pride. One of the best things you can do as a manager is to take time to reflect. Once a month, go find a quiet space. Think about each person on your team. Go through old emails and project status reports. If you’re doing your job well, you’ll realize how much of an impact you had not only on your products but on the people you lead. And that’s the real measure of success.