Running an Engineering Team Is About People
Leading a successful engineering project requires deep technical knowledge, but more than that, it requires working well with people. Teams are made up of people. You have to know how to keep people working together smoothly, and position team members so they can do their best work. Even if every engineer is replaced by AI(spoiler alert: they won't be) the users of the software we build are still other humans, and we have to understand their needs.
Leading a successful engineering project requires deep technical knowledge, but more than that, it requires working well with people. Teams are made up of people. You have to know how to keep people working together smoothly, and position team members so they can do their best work. Even if every engineer is replaced by AI(spoiler alert: they won't be) the users of the software we build are still other humans, and we have to understand their needs.
In managing engineers all these years, I've found a few things that work well, and some ideas for things I'd like to see more of in the future. A lot of this, I hope, is already common knowledge. But sometimes it's helpful to have it all written down in one place.
1:1s are essential. Hold regular 1:1 meetings with all of your direct reports. Let them do most of the talking. This is one of the best ways to stay connected to your team, and spot problems before they become a major issue. A 1:1 doesn't have to be anything complicated, it's just a meeting between a manager and one of their direct reports that allows them to keep up with everything going on.
Put it in writing. I don't just mean in a cover your ass way, but in a way that everyone on your team has a shared reference. The more people you work with, including vendors, clients, etc, the more side conversations and confusion there will be. Set up and maintain a single source of truth that everyone can reference back to when decisions are made, so it's easy to stay on the same page.
Hire good people and let them do good work. The more you move into management, the less day-to-day experience you have with the realities of engineering. What's the current best practice for testing React components? What are the tradeoffs between running virtual servers on a cloud provider vs going with a complete SaaS hosting solution? You need to trust your engineers to be experts in their field, and position them to be able to work effectively. Sometimes this means leaning in to offer support, and sometimes it means stepping back to avoid micromanagement.
Be a shield. Stop problems from moving down the org chart, and keep praise moving up the org chart. One of the best managers I had described himself as a "poop umbrella" at one point. (Ok, he may have used a slightly different version of that phrase.) His job was to keep his dev team focused on the work, and keep them from getting distracted by every problem that came down to us.
Praise in public, criticize in private. Celebrate wins with the biggest group possible. Never make a public example of someone's honest mistakes, pull them aside later and explain what they should do to fix it. The one exception to this I'll add is that if someone publicly does anything that hurts other members of your team, it should be addressed in front of the same people to make it clear you don't tolerate that behavior. If someone makes a sexist comment on your daily standup, don't wait to talk to them privately, make sure everyone who heard the comment hears you say it's not ok. Ideally that person will be issuing a public apology after you talk to them, but at least you can make sure you're supporting all of your people.
Fit the process. Make your management work fit your company's processes as much as possible. Using an HRIS or any goal/performance software is always a little bit of a pain, especially as companies inevitably grow and change their software, but it's important for your team. It makes way more sense for you to spend a few hours to understand the software and get your team on board than for every single person on your team to spend a few hours having to figure it out. More importantly, it's what your engineers will be evaluated on.
Of course you know how your people are doing, but if you leave the company, or even if one of your people moves to another team, the new manager won't have any of the context in your head. So do your team a favor and make sure they have progress tracked in writing. Use your regular 1:1s to leave comments in the system. Use project kickoff meetings and retrospectives to encourage team members to leave feedback for each other. When your engineers are up for a promotion, it will help.
Read good books. There's no substitute for hands-on experience, but there's a lot you can learn from other experts. I've found a lot of books on management to be light on usable information, but there are a few that I really liked. The approach described in Radical Candor to both care personally and challenge directly is a great way to approach leadership. You have to care about people to learn how they work, and you have to hold everyone to high standards to accomplish the most. The Manager's Path is one of the best books on tech leadership, and really leadership in general, that I've read. It has real actionable advice, and I recommend to to most of my engineers. It has a few useful chapters for folks who aren't in leadership yet. The Unicorn Project is a great book that uses a fictional story to explain some really useful lessons about tracking work accurately and avoiding single points of failure.
There's also one book about technology that I recommend to everyone on my team, which is The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Clifford Stoll. It's a brilliant nonfiction book about a Berkeley astronomer learning computer networking and tracking and international hacker group back to Germany. It takes place in the 1980s, before much of our modern web infrastructure existed, but modern engineers can learn a lot from the examples of inquisitiveness and self-learning. And it's a really fun story.
I hope some of these suggestions were useful, and feel free to get in touch if you have any thoughts or suggestions.
I've intentionally chosen not to support comments on this site. If you feel a strong need to discuss something, you can use the social sharing links above to write your own comment. If this post has sparked any big ideas, either positive or negative, I encourage you to write your own post and share it on your own website. Feel free to drop me a link in the contact section, and I'll add links here to interesting responses.