Let Your Team Make Technical Decisions

Problem

When people first start out in management, they sometimes have trouble with letting go of technical details. Nowadays a split is becoming more and more commonplace. Some people will have a technical job and technical decisions will rest with them, while others have a management role where the happiness and effectiveness of the team rest on them.

I had someone who was struggling in their first management role. I started to talk to the team members and the recurring theme was that this person was trying to make all of the technical decisions instead of making sure the team was functioning well and empowering them.

Actions taken

If you are an engineering manager you should still have responsibility for the technical side. After all, there is a reason we ask people who have prior technical experience writing code to be managers. At the same time, you need to ensure that your team is empowered and that they have the flexibility to make their own technical decisions.

From talking to the team, I found that the place they were feeling the most pain was during architecture and design meetings. They were fine day-to-day and when reviewing their code, but meetings when architectural decisions were being made were difficult by the manager. I talked to the manager, and gave him my recommendations in two parts.

First, I told him to go into the meeting thinking about what his goals for the project were, and I told him to be very upfront with the team about what his goals were. Your goals shouldn't be related to implementation, but should be high-level, such as when a product needs to be shipped, how many customers need to be supported by it and what involvement is required from other teams. This provides a framework for a project. It's important to be upfront about constraints such as resources available or time, but don't get too bogged down in the technical design of a project.

Secondly, I advised the manager that if he had some technical opinions, that's fine. But your goal should be to provide guidelines and to let the team decide on how the project should be done. Sometimes your ideas may not be the best and by giving your team flexibility they may even come up with a better solution. It's unwise to assume your idea is better than a team's worth of smart engineers.

Lessons learned

This goes to the heart of management, for me: when you become a manager you need to find your personal success through others. The most important things are that software is delivered in an efficient way and that the team is happy. So your goal shifts from the goals you had as an IC: as an IC, more participation in the technical details was success. On a manager track, the less you need to participate in the technical details, the better you should feel about the team, and by extension, your own performance! It can be a difficult mindset shift in the early days and I still haven't fully gotten over my instincts to jump in and micromanage some technical design details, 15 years later. The manager in this story crafted a process by which he could lay out goals and set up high-level expectations, but would leave the technical decision-making to the team as much as possible. Very quickly, his team's happiness improved and he went on to be one of the most successful managers in engineering.