📌Info
This is English version of the post originally written in Ukrainian.
Let me share a little story. It’s Thursday evening, tomorrow’s a sensitive deadline and who hasn’t been there, right? We just noticed that an essential feature crashes the server with requests over 100 entities (we tested with 5-10 entities, and it worked fine). Obviously, we screwed up somewhere with O(n²)
, or even worse.
I dive into the code, grab my head, and prepare arguments on why we need at least 5 days to fix this shit (#architecture
, damn it!).
Then the product owner walks in. I describe the problem, take a deep breath to spill my speech. He gently takes the initiative and starts brainstorming at Eminem’s speed in Rap God.
Just generating ideas.
20 of them in 5 minutes.
I barely had time to process such a performance.
Of course, 15 ideas were, well, mediocre (impromptu, come on!). Three more were damn complicated to implement. But the last two were fucking brilliant!
Moreover, the ideas were completely non-technical, like “let’s show a spinner when N>20”. But that’s what saved the release: it was easy to implement on Friday morning, and I got my 5 days to implement it properly!
In teams where ideas get buried before they even take off, I just needed one or two attempts to shut down and fake minimal enthusiasm for all further discussions. Where ideas were discussed, always something new and interesting got implemented. It often differed significantly from the original idea, but it was something new and interesting!
Unfortunately, I grew up in an environment where the modus operandi was to criticize ideas. So, for a long time, I defaulted to going contra in discussions. Moreover, I was proud that I could pick out cunning and non-obvious aspects of why this shit wouldn’t work. I thought it was a sign of professionalism: look at me, predicting shit!
After that story, I realized that killing ideas in their infancy is unproductive. It’s not the way to progress in the long run. And new ideas, no matter how crappy they may seem at first glance, evolve the product after all.
At first, it was damn hard to suppress the internal prosecutor critic. I had to make active efforts not to unleash the critic (and also to keep the pokerface 🥸 not to express my attitude that way)
👉Tip
What works for me?
- Listen to the idea to the end. Don’t interrupt!
- Try to imagine the idea. Imagine that we’ve already(anyhow!) implemented it.
How would the product look with this new functionality? What would it enable? - And only then let the criticism loose.
YMMV.
Of course, the critic sometimes does have a point. However, perspectives from the second point are often too attractive. So we continue the discussion: how exactly will we achieve this result? Did we miss something? Will it interfere with our future plans?
❗Important
The role of a leader is extremely important in shaping the environment where the modus operandi is to encourage the ideas, not to shut ‘em down.