This is the last in a series of articles about engineering management, the first one was about valuing people, the second about business value, and the third about coding in the trenches, and earning the respect of the team. This last article is a set of assorted tips about managing people, and building a great team and running it sustainably.

Hire for and Value Performance

Building a great team starts from step 1: hiring the best folks. Hire for and value performance, not “hours on the desk”, “desire to learn” or loyalty. Performance and commitment, professional behaviour and the ability to deliver value are what should matter for you. This is not to say you have to be an automaton and willy-nilly fire or hire based just on this metric, but at the end of the day, performance and delivery should drive these decisions. Use compassionate candor to communicate, and make sure that your hires align to your company values. A good hire should either be a hell yeah, or a no.

Autonomy, Mastery, and Purpose

Daniel Pink’s Drive should be required reading for anybody who wants to manage people, but a few people mistake autonomy for letting engineers do anything that they want. Cultivating good drive is about setting clear boundaries, and very clear expectations, and teaching people that the why of what they do is as important as the how:

• Make sure that your engineers understand the why (business context) and the what (the specifics of the requirement) for a story really clearly. Why are we doing this? What is the customer need? And what is it exactly that we’re doing? If necessary, spend time with them to collaboratively shape some of the details.
• Make sure that the success criteria for story delivery are extremely clear. What is the process through which an engineer gets a story to done? Maybe it’s PR reviews, maybe it includes some automation tests. Make sure that this is not a surprise to a new engineer.
• For beginning engineers, make sure that they understand how to solve the problem. Most new folks are stuck trying to figure out the how: teach them that learning how to get themselves unstuck is also an important lesson in autonomy.
• Then, leave the rest to the engineer. The trick here is to get involved when they need help, and to give folks a lot of space when they don’t.

I also think Drive is a rediscovery of a universal truth about what motivates people, and there are deeper understandings of this concept out there. Ikigai for e.g. is at once both simpler, and more comprehensive.

Valuable Books

This last section is about books I’ve read that has shaped my thinking around engineering management. The best way to read these books, especially if you are a new engineering manager is to not read them cover to cover. Skim through them, find a section that is interesting, and dig deep. And if you are struggling with a difficult scenario at work, come back to these books and see if you can learn more lessons.

1. Julie Zhuo’s Making of a Manager is probably the most wisdom/page of an engineering management book I’ve read. It’s probably the best book for a new engineering manager, and one that I’ve recommended many times over the last year.
2. Camille Fournier’s The Manager’s Path is also common-sense advice, but it’s a bit more geared to somebody who’s been on the engineering-management path for a few years.
3. Basecamp’s Shape Up is an opinionated way to plan and manage your work. It’s not something you can implement by yourself unless you have top-management support, but the lessons it teaches are still valuable. All of Basecamp’s books are good reading, and offer a view of an alternative way of working that just might suck you in 🙂
4. I’ve already mentioned Daniel Pink’s Drive, but there’s no harm in a further plug.
5. The Goal is a book that has long been required reading for all MBAs. The Pheonix Project is its equivalent for engineering management: how an agile philosophy and simple truths around keeping work-in-progress low and ensuring slack can turn around a business. It’s a bit of an utopian read, and it’s definitely a caricature, but it’s a great intro to agile and how it can deliver value.

So that’s it! Took a month to write these series of articles! If you found it useful, I would really appreciate a comment or a tweet. Thanks for following along!