How To Manage Software Engineers
10 points to cut your engineering churn:
- Encourage them to call you out on any technical decision you make. Since they are in the code all day, they will know much better than you what is what. Since you are managing people all day, and therefore not in the code, listen to everything, even if you are as technical as them.
- Be 100% predictable. Things go wrong. You want engineers to tell you about it. They won't if they don't know how you'll react, especially if they've screwed up somehow. Errors are human, and your response should be: "Thanks for telling me. Let's talk about how we can fix it".
- Proscribe as little as possible. You hired them for their brains, so let them use them. Trust that they'll make the best choice given their talent and experience. Only stop them doing things you absolutely can't live with. For example, it might be unacceptable for them to include an open source component without legal review, or change the tech stack arbitrarily. But do you need to specify that pattern X is the way we do problem Y?
- Tell them the destination, but not the route. Challenge them to find their inner genius to find the most elegant, or most efficient, or most [insert adjective] way to achieve the outcome. Smart people like opportunities to demonstrate their gifts.
- Select the least terrible consensus. Which is a different way of saying choose the path that gets you the most buy-in. Engineers who don't believe in what they're doing write terrible code. And if you have to make decisions which no one agrees with, do it infrequently.
- Make the refactor a point of pride. No mistake is so bad it can't be fixed, particularly if you know about it early enough (see 2). And some mistakes aren't bad at all because they teach us things. Encourage the mistake, the experimentation, the risk taking, by making it clear that refactoring is something the best software organizations love and do routinely.
- Handle exits with ultimate respect. Sometimes engineers don't work out. If you're going to exit one, tell them candidly and give them the gift of a long runway to find their next gig. This will be a story they tell all the people that are staying and anyone who ever asks if they should join you.
- But exit bad eggs fast. If an engineer isn't working out, there is no upside in drawing it out. All that will happen is your good engineers will start complaining, or worse, their performance will tail off as they get drawn into whatever politics are happening. Exit the under-performer with ultimate respect as quickly as you can.
- Extra hours are their gift to you. It is not something you're entitled to. And if you have a crisis and need longer hours, you want them to volunteer because they are part of the mission, not because you ordered it. You can maybe get away with ordering overtime once. After that, your engineers will start to churn out.
- The ultimate benefit is cool work. You only need lunches, and massages, and free laundry, and [insert latest benefit offered to attract engineers] if you don't have cool work. Here is the litmus test for cool work: if I wasn't being paid, would I make this anyway? Your job is to maximize the percentage of cool work each engineer gets in a day. It won't be 100%. But the further away it is from zero, the better off everyone is.
Yesss!!! My current management team is the first time I've enjoyed this style of leadership. Treating people this way inspires a staggering amount of loyalty. #grateful 👍
Thanks James - nice article - points 1, 2, 3 and 10 particularly resonate. And I've found that the opportunity for contact between engineers and the customer for whom they're developing something new, is also a great motivator: "I can see my efforts are wanted, needed and making a difference".
Good points. And good timing since I am about to start working with a team! Thanks!
Some good points here that are also applicable to leading in general