Context over Task Lists

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. <h1>Leading with Task Lists</h1> 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: <a href="https://betterprogramming.pub/context-over-task-lists-2e8912d7df61">Read More</a>