The dark craft of engineering management

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.

20 thoughts on “The dark craft of engineering management”

  1. Interestingly, this coincided with a blog post of mine on why leadership is not management – .

    Dan Pink’s work is amazing but he’s book Drive! (and the underlying theory that he covers in it) does not cover the attraction of the new. Mastery in itself could become boring without the ability to learn new skills so managers need to be aware that technies want to play with new things. This will be blindingly obvious to any manager that has come from a dev background but given the numbers of those that haven’t, it can be a real issue.

    If I may end by adding to your descriptions: “leadership is the craft of enabling people to get things done and to do them willingly.”

  2. A friend pointed me to your blog. Nice write up. I am an Software Engineer, going on 9 years now, and am aspiring to be an Engineering Manager. Much to the chagrin of some of my “individual contributor” engineering friends who don’t see the value in management or understand the desire to want to do it… One of them asked me “Why?” today at lunch. After some though, I said “Because I want to help people.” We both thought that was kind of a weird answer but it is still the best I can come up with. I really liked how you put it, a “want to serve.”

    Anyway, thanks for the write up. I’m hopeful/confident the move will happen in the next year or so, and this was useful for me. 🙂

  3. Almost. Think of more like engineers running hurdles. So long as they don’t stop as they go over each hurdle, your job is to stay out of their way. When they stumble over a hurdle or stop before one, your job comes into play: help them, by giving them what they need, get back on track.Your job as manager is to do nothing more or nothing less.

  4. Hi. Nice post 🙂 So I think a lot of what you are saying here is true. I wouldn’t like to say you are the “servant” of the team myself as I feel the manager is part of the team but just has a different role to play. To me a servant is told what to do by someone and has to do it without any reasoning or discussion. I’d also like to ask you to clarify autonomy, do you mean that the individual or the team? Encouraging people to work autonomously when they should be working as a team could not be beneficial, maybe I have misunderstood what you are trying to say here.

    Anyway I like what you have to say and your ethics around being a Manager, thank you for your contributions to the interwebs!


  5. I think this post confuses project management with management – they’re not the same. Management is about ensuring that everything work as it’s supposed to – and it includes resource management, office procurement, etc…

    Project management, on the other hand, is about ensuring that something gets done according to a standard process.

  6. To agree with you and disagree just slightly with DeveloperDame, my favorite managers have always behaved as if they served their team. These same managers have not been team members (they were members of the management team instead). They didn’t do the things we did, or go to the meetings we went to, or talk about the things we talked over. Instead, you could see them out there pushing roadblocks out of the way, getting us resources we couldn’t command by ourselves, and generally being an advocate for our project to more senior management. A formative work-memory of mine was listening to my manager, a couple of cubicles over, talking on the phone and basically ripping some beamcounter a new one because we needed to purchase something and the beancounter was in the way.

    As leaders, the best managers are cat herders. You can’t *make* a cat do anything. They are very independent and solitary (vs. dogs, whose pack instinct makes them tractable), they have teeth and claws, and they can run faster than you can. Tell me cats aren’t an apt metaphor for developers! It takes gentleness and patience to herd cats. You basically have to convince them that where you want them to go is where they want to be.

  7. I don’t think your own version of the quote is a complete replacement for the original. In particular, the word “enable” is too passive. There are plenty of great engineers who need to be actively led on a regular basis. The original quote allows for this. The revised quote, on the other hand, implies that engineers have inherent to them a good sense of what needs to be done, and how best to do it, pretty much always, and that all the manager needs to do is grease the skids. I have found instead that sometimes active leadership, persuasion, cajoling, etc., is required. It is the hardest part of the job, actually.

  8. No good and passionate engineer ever becomes a manager, unless he becomes greedy and wants more money instead of more professional satisfaction. I was temporarily managing engineers, the reason being that somebody had to do it and I thought I can do it better than others – and I did, although definitely not perfect.

    There’s a saying about a good manager, not related to engineering management alone: a good manager is the one who can skip work daily for six months before her/his absence starts to influence the good working of whatever (s)he manages.

  9. This was an awesome article, I will have to show this to my business partner. It definitely fits in line with how we are running our business and when we scale up, this advice will be invaluable. Thank you and god bless!

  10. I don’t see anything less grammatical about your version.
    You sound like a great manager, assuming you practice what you preach.
    You’re a bit optimistic thinking that devs should be passionate about everything they ship. Who is passionate about a new payroll system? That’s just semantics though, as they should certainly be passionate that their code is the most effective and efficient way of accomplishing the task. You also need to make sure everyone agrees on what the task is, but you covered that.
    Well done & keep it up. There is nothing more irritating than a manager who calls too many meetings that are spent explaining the detailed idiosyncrasies of code to the manager especially where that manager is not as technical as they think they are.

  11. The author gets it. The best line is, “Then I’m going to leave you the hell alone to get stuff done.”

    It’s the hardest thing a manager can do – rely on people to function and succeed.

    I couldn’t manage a team to save my life, but feel good with a strong IC role. I work with others who do the same and we just collaborate and make it happen. The management doesn’t necessarily have to be very technical, although it helps, but they have to be the BS protector and fight the (sometimes to often) horrible business and political aspects of the org/company for their team.

    Engineers who can deliver with little management are the easiest and best to manage, but they need that environment from their manager. Engineers who could deliver but need more management due whatever commitment or other issues they have are lower tier.

    PS: Constant Micromanaging is always a demotivator and will cost you good people (and is it normally even worth the trouble? The boss is basically saying they don’t trust you). At that point, no one is happy anyway.

    PSS: The best people vote with their feet because they can, and remainder sticks around.

    PSSS: The revised quote in the first paragraph is better since it sounds less like exploitation and more encouraging/motivating.

  12. I see you want automony in your team (leave them alone), but you also say you’ll do all you can to get them te resources they need.

    Please hire me to work for you 😀

Leave a Reply

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