One of the hardest parts of being a PM, in my experience, is embracing the needful thing of saying no… all the time.
It’s a sad contradiction that when you employ and empower creative people, you will then often have to stifle the same impulses they also thrive on. This means: the better the team, the more often you may have to tell people who are smarter or better at their jobs than you, “no”.
One aspect of managing this tension is knowing when to when to shut something down or let it play out, especially an early idea or loose talk. There is no formula for this. You have to know your team and the person who’s idea it is. If you constrain all thinking you get mindless pap, and work is a tiresome chore. But ideas can be dangerous. When an idea contradicts or undermines a core strategy or goal, it can be worth pointing that out early. If it’s more ambiguous or tangential, it matters less. Just be aware of who takes ideas too far, or can become obsessed with their own idea at the expense of the team or it’s goals. And, accept that creativity and smart people are risks to rigid plans.
To me, the hardest interpersonal aspect of managing with space for creativity is saying no without crushing people’s dreams. Especially if a shy or introverted team member is making an effort to express an idea. Be direct, don’t lead them on if the idea won’t be pursued. But also be encouraging, use a compliment sandwich, and let them know the reasons, if you can. Giving credit when someone does bring something to the table that ends up having impact, also is key. It’s ethically good, but it’s also a way to encourage similar efforts in their peers.
You might not be able to stand up to people, or to be able to tell the well meaning, shy, engineer his prototype he spent his weekends building won’t be turned into a product. Then you probably need a different career. Being a PM means saying no. If you’re not saying no (nicely), all the time, in all directions (up, down and to peers) you won’t last long.
Of course, don’t always say no! Don’t be a closed minded stubborn ass. Just be comfortable, or at least capable, when you do need to say no. You can also reduce the amount you have to say no by reducing distractions and by having strong buy-in from the team on strategy and goals. The more you can positively constrain their cognitive labor, the less you’ll have to do this. In particular, I have come to dislike open brainstorms. I believe they rarely result in anything useful, and there are many more effective processes for group ideation and creative thinking. They are political minefields in dysfunctional orgs, as well. Similarly, I am a big fan of concepts like hack-a-thons and ideas like 10% time, which encourage safe spaces for creativity, rich in cross-pollination and skill sharing. BUT, I’ve seen them go very wrong when there becomes an expectation that side projects, or hack-a-thon projects, will be incorporated into products. These should be temporary autonomous zones, not feeders for product development. If some new product emerges, that’s only a bonus.
Making software well, and enjoying doing it with talented teammates, means breaking their hearts sometimes. But you can learn how to minimize the chances, and the damage, if you get to know your team, and give them a clear vision.