Noah Brier
Editor’s Note: Noah Brier is the co-founder of Percolate, a New York-based marketing technology start-up, and is a member of the World Economic Forum Global Agenda Council on Social Media.
Over the last few years I’ve gotten the pleasure to work with a large number of really talented engineers — some of whom I’ve asked to make the leap into management.
Like any individual contributor moving into a new role, they’re asked to fundamentally change the way they approach their day. As I’ve done my best to coach them through this experience, I wrote down a few ideas on how to best translate their engineering skills into management skills. Some of these are very specific to managing engineers, but most are general observations that should be applicable to managing just about anyone in a growing company.
Pragmatism
I tell this story a lot now, but the main difference I see between a junior and senior engineer is their ability to be pragmatic. A junior engineer looks at a problem with bravado and says, “I know exactly what the problem is,” and sets out to solve it. A senior engineer looks a problem with pragmatism and says, “I don’t know exactly the problem is, but I know where to look to understand it,” and begins to dig in to the data.
The metaphor I like to use is that every bug or challenge looks like a tree: You have a trunk with branches of possibilities. The junior engineer is starting from the top of the tree, at an individual branch, and trying to work their way down, while the senior engineer starts at the trunk, cutting off large portions of the tree at a time as a way to eliminate possibilities.
As a manager a big part of what you are is a teacher and a big part of what you can teach is pragmatism: How to look at problems and solve them in the most logical way possible. Obviously everyone has a little bit of a different style, and the key to being a manager is to not stifle that while also helping them become better at their jobs.
Systems/Scale
Every great engineer I’ve ever met is naturally a systems thinker: They always think about how to build things in a scalable way.
Essentially the job of being a manager, beyond the human side (which I’ll get to, I swear), is about building a system of people. As you’re growing a company you should absolutely be thinking about how to make this system scalable. On this point, specifically, you need to think about every decision and task you take control of and how that would work if you had 20 more people reporting to you. Micromanagement, in other words, is bad engineering on your part, not bad behavior on the part of the employee you’re managing (no matter how much you think you could solve that problem better or faster).
Now obviously people perform differently than code, but that’s just a variable you need to include in your calculations in the same way you would think about the speed of servers or the functionality of Python versus Go. In the same way I would expect you to understand the strengths and weaknesses of the language you choose, you should understand the strengths and weakness of the individuals on your team. That’s on the manager to understand, not the person to communicate. (I’ll talk more about this in the next section.)
One last point on scalability: Every time you solve a problem for the company or team you should be thinking about how do you incorporate that solution into the system. If it’s a process change then you need to ask yourself both how you’re going to communicate/enforce that change for current employees, but also how you will communicate/enforce that change for the employees who you haven’t hired yet. This could be as simple as documentation, but the key is to make sure
you’ve considered the question.
Motivation
This is less something I’ve learned from working with engineers and more something I’ve learned from being a manager. The key, I believe, to being a great manager is to understand what motivates the people who are reporting to you.
For every person on your team you should know their strengths, weaknesses, and, most importantly, what drives them to come to work every day. From there you need to try and calibrate the way you work with that person based on that motivation. This can play out in a number of different ways: Some people are motivated by recognition, others by fear, others by the pure desire to solve really hard problems. Understanding which one of these (and there are many more) motivates an employee will make your job of managing them much easier.
The thing about getting to motivation is that you need to move beyond the analytics and actually start to know the person. That means 1-on-1s and other conversations that aren’t exclusively about work (after all, they might be motivated by things that don’t happen in the office). You should be checking in with your direct reports weekly both to build a good rapport as well as to get to know them on a deeper level.
Something Assigned To Everyone Is Assigned To No One
This is not something particular to engineering, but I still think it’s a useful lesson as you’re transitioning to being a manager. As a general rule giving a group something to do will mean it won’t get done. If you want to ensure things are done you need to make someone responsible. This is pretty obvious, but still worth stating.
In the end, the transition from individual contributor to manager is tough in just about any discipline. However, as I hope I’ve articulated, despite their reticence, engineers are actually better prepared for management than almost anyone else in the organization. The transition won’t be easy and management certainly isn’t for everyone, but hopefully this helps a little bit.
Comment