A huge part of leading a Product Development team is learning how to work on a problem indirectly.

So many managers are used to the fact that when they were an IC they could solve a problem by going to the source. If you’re an engineer you can make the code change. If you’re a PM you can write the product spec and success criteria. If you’re the designer, you’re designing the user experience and product flows and can make changes to them.

When you become a manager you lose direct access to these tools. Instead, now you have access to a team of people that have access to these tools.

Leading with Task Lists

It’s so easy for leaders to just think of their team as an extension of themselves. They try to take what made them successful as ICs and just imagine that they have way more hands now that they can get work done with. “I have the problem and answer in my head, if I could just explain to everyone what they need to do we’ll be able to get it all done!” Instead of giving their team context they give them a task list.

This approach doesn’t work (at least not well). It might get your project off the ground but it’s not sustainable. The symptoms of this approach are things like:

• Projects are always a lot slower than you expect.
• The project seems to get off track often, prioritizing the wrong details.
• The team seems to not be able to fill in the gaps by themselves. Why do they need answers to every question that comes up?
• The end result is not that inspiring. No one is really proud of it.
• The team seems frustrated and less engaged.
• Attrition. Often people leaving to start their own thing, or joining a tiny company where they can be more deeply involved in decisions.

And the explanation for that is really simple. If your team is just executing on your task list, of course they don’t know how to fill in the gaps, they don’t know what to fill those gaps with. They could guess but they won’t guess what you have in mind. They’re also going to be more likely to be distracted by random things that come up and might not make as much progress on their tasks as they thought they would. If they don’t understand the problem, they’re less likely to have ideas that they contribute back into the project making it better. They’re more likely to want to be done with the project and move on instead of iterating and polishing it until they’re proud. It’s not their project; it’s your project and they’re just helping you.

This is not how great products are developed.

Leading with Context

Great products are made through shared mission and ownership. They’re made through understanding the problems, working together to come up with solutions that the group believes in, and trusting each other to do great work, making their own decisions along the way. You want to bring out the creativity of the team, not squash it behind yours.This builds trust with the team. You can trust them to make great decisions and products and they can trust you to not lead them in the wrong direction. The symptoms of this approach are things like:

• The energy and excitement of everyone on the team feels really good.
• Projects start to go faster. They don’t seem to get hung up on details that don’t matter.
• Better decisions get made along the way. The details of the project really shine.
• The team trusts each other, including leadership, to make good decisions.
• Everyone is excited to launch and promote the project. Taking an extra week to polish and get it just right is instinct to the team.
• You’re able to attract and recruit new employees, often through referrals.

So if it’s really that simple why do so many teams (or leaders) fall into the bad habits of leading with task lists? It’s because it’s hard. It’s simple, but it’s hard. It takes more effort up front to tell that story clearly, to rally a group around a problem, to get buy in from the ground level. You need to be a good communicator and storyteller. You need to spend time with individuals that aren’t seeing it to understand what either you or they are missing.

I think most people (at least subconsciously) understand this concept. They’ll often start with trying to build shared context and understanding but when it takes longer than they want, or not getting the reaction they hope, they then jump into task list mode. They decide that things will move faster if they just assert the answer and tell people what to do. And they hope that once people get into the work they’ll see it better and then they’ll understand. It’s why teams so often end up in this mode. But this is the manager’s failure, not the team’s.

I’ve seen it at every company I’ve ever worked at. When I think back to my favorite teams they were ones that operated with a real shared sense of understanding. Everyone knew what was happening and why.

When I think back to my best managers they’ve always been ones that lead with context. They want to make the objective clear, then make room for other people to contribute to the solution. They understand that they themselves might not have the best answer but that the best answer is somewhere in between all the smart people in the room.

Your team is not an extension of yourself. You hired a talented group of people with great (and different!) ideas and opinions. Make room for them. Give them the respect, attention, and context they need and deserve to do great work. Support them and then get out of their way. You’ll be blown away with both how fast and how good the outcomes are. Better than your lame task list.