VM Brasseur and I had a chat about what it means to be an engineering manager, as a follow up to her excellent talk on the subject at Open Source Bridge. I promised her I would put my (lengthy, rambling) thoughts into an essay of sorts, so here it is.
“Management is the art of getting things done through people.”
This is a nice pithy quote, but I prefer my version:
“Management is the craft of enabling people to get things done.”
Yes, it’s less grammatical. Sue me.
Why is management a craft?
It’s a craft for the same reasons engineering is a craft. You can read all the books you want on something but crafts are learned by getting your hands in it and getting them dirty. Crafts have rough edges, and shortcuts, and rules of thumb, and things that are held together with duct tape. The product of craft is something useful and pleasing.
(Art to me is a good deal purer: more about aesthetics and making a statement than it is about making a thing. Craft suits my analogy much better.)
Why enabling people to get things done?
Engineers, in general, know their jobs, to a greater or lesser extent. My job, as an engineering manager, is to make their jobs easier.
What do engineers value? This is of course going to be a sweeping generalization, but I’m going to resort to quoting Dan Pink: Mastery, autonomy, and purpose.
Mastery has all kinds of implications. As a manager, my job is to enable engineers to achieve and maintain mastery. This means helping them to be good at and get better at their jobs. Enabling them to ship stuff they are passionate about. To learn the skills they need to do that. To work alongside others who they can teach and learn from. To have the right tools to do their jobs.
Autonomy is the key to scaling yourself as an engineering manager. As an engineer, I hate nothing more than being micromanaged. As an engineering manager, my job is to communicate the goals and where we want to get to, and work with you to determine how we’re going to get there. Then I’m going to leave you the hell alone to get stuff done.
The two most important things I do as a manager are in this section.
The first is to act as a BS umbrella for my people. This means going to meetings, fighting my way through the uncertainty, and coming up with clear goals for the team. I am the wall that stands between bureaucracy and engineers. This is also the most stressful part of my job.
The second is in 1:1s. While I talk to my remote, distributed team all day every day in IRC as needed, this is the sacrosanct time each week where we get to talk. There are three questions that make up the core of the 1:1:
- How is everything going? This is an opportunity for any venting, and lets the engineer set the direction of the conversation.
- What are you going to do next? Here, as a manager, I can help clarify priorities, and suggest next steps if the person is blocked.
- What do you need? This can be anything from political wrangling to hardware. I will do my best to get them what they need.
In Vicky’s talk she talked about getting all your ducks in a row. In my view, the advantage of empowering your engineers with autonomy is that you get self-organizing ducks.
The key thing to remember with autonomy is this: Hire people you can trust, and then trust them to do their best.
This is key to being a good manager, because you’re providing the purpose. You help engineers work out what the goals should be, prioritize them, clarify requirements, and make sure everybody has a clear thing they are working towards. Clarity of purpose is a powerful motivator. Dealing with uncertainty is yet another roadblock you remove from the path of your team.
Why is management fun? Why should I become a manager?
Don’t become an engineering manager because you want power - that’s the worst possible reason. A manager is a servant to their team. Become a manager if you want to serve. Become a manager if you want to work on many things at once. Becoming a manager helps you become a fulcrum for the engineering lever, and that’s a remarkably awesome place to be.