What does that look like and how do you get there? For me, it means that I don't shy away from asking dumb or obvious questions. Over time, my teams have learned that this is one of the ways I go about getting around hidden assumptions and misunderstandings. I've talked about the importance of clear communication with stakeholders around requirements in other posts. But the same holds true within your team. Unless you have very detailed requirements, product goals and customer requests mean different things to different engineers. If I guide the team discussion in such a way to ferret out these assumptions and misunderstandings, we come to a place with clarity about what it is we actually need to do and how we're going to do it.
In addition to asking obvious questions, another way I work through this is to constantly come back to the stories we have on our board for a feature and ask, "OK, if we finish all of these stories, are we DONE?" This is a real opportunity to look at body language (or listen carefully on calls) to find out if there's more to be done. As tempting as it is to just take the team's answer at face value, you'll be thankful later on if you did the work to suss out that there was actually more work to do than you had originally thought.
By working with the team to create stories and tasks, you not only foster a collaborative team culture, but you diminish risk, too. Assuming that one person (either you or someone else on the team) has all the answers and knows what to do is a recipe for missed deadlines and features that don't delight customers. This reinforces your team's agency to not only diminish risk, but it makes working together more rewarding because every team member knows that their input will be listened to and taken into consideration during planning. This has the added benefit of encouraging people to speak up when they see a problem - even junior engineers.
I don't think that you should never assign tasks to your team; rather, fostering collaboration will help create a happy team with a manageable workload and trust among members. When are times when you need to take control and start assigning? For me, the most obvious answer to that question is during a crisis - like downtime in production or something similar. As a manager, that's a time when you need to lead to get things fixed quickly while not making problems worse. Similarly, there will be times as amanger when your team can't come to agreement and you need to make the decision to move forward. But even in both of these situations, when you have a trusting, collaborative team culture, your team will act as guide rails to help keep you from making mistakes.
