Fearing Opinionated Voices in Design Meetings? Try these tips.
Getting the opinionated voices on your side unlocks successful leadership.
Have you ever been in a large meeting where an idea was introduced, only to be brutally shot down by a few opinionated voices?
What do you think the issue was?
The problem statement was not clear.
The solution was incorrect.
The problem was mistimed.
The opinionated folks felt blindsided by this "disruptive" proposal.
Today, I focus on the last reason. I will leave you with tips that have worked for me to build alignment especially when you think you have a sound technical proposal. In the end, I will also share my embarrassing story where my proposal was shot down in front of 30 people.
Wow! I am less than 150 subscribers away from hitting 10K! I am also humbled by the kind words I have gotten from some of you. Thank you!
If you love what you read here, please share it with others and help this newsletter grow. Also consider hitting that ❤️ button. It actually helps.
Smart software engineers ask great questions but can fail to frame them well. When they listen to a "disruptive" proposal, they may momentarily lose their composure. They ask seemingly nit-picky questions and be against the proposal.
Why are proposals brutally shot down?
This happens because your peers do not understand the problem statement, scope of the proposed solution and more importantly they feel critical concerns are unanswered. They may also be worried that your proposal ignores reliability & maintainability. They have a lot of unaddressed worries.
So who’s at fault here?
The engineers shooting down proposals or the engineer proposing the solution? It could be both but in this case I will prematurely put the blame on the the engineer proposing the problem.
Technical due diligence is not enough. You need to help others see why your proposal works. So, here are some dos & don’ts to keep in mind.
Dos
1. Identify key stakeholders upfront
You know who would be more opinionated about problem X. So, do not surprise them by sending a meeting invite to discuss proposal X, expecting a thumbs up.
2. Give them time
You may have spent hours thinking about the problem and arrived at the disruptive proposal. Your proposal may be technically sound. However, most of us are not great at documenting our entire thought process and the alternatives considered. So, give them enough time to absorb the problem, ask questions, and internalize your decisions.
E.g., Saying "I tried to summarize my thought process and the alternatives I considered. Let me know if you would like more in-depth details." can help them understand that you have more thoughts than what is apparent in the document.
3. Be approachable
Some problems need dedicated brainstorming discussions. Forcing an async conversation results in unanswered questions. These can come back to bite you in the final design review meeting. Personally, I like to hop on a quick call to resolve concerns and brainstorm ideas.
Eg: Hey did my response to your concern ABC make sense? It is an important element of the project so I want to ensure we are aligned.
4. Seek Input
Ask for specific input on complex problems.
Eg: Problem XYZ is critical for us. I am concerned about getting the details wrong. Can you spot any gaps?
Now, they feel they are part of the decision-making process. This can make them your strongest supporters. Also, this tells them you are not taking those complex problems lightly.
5. Pivot
Don't be too attached to your proposal. If someone makes a valid suggestion, then take it. Your goal is to find a good solution, not to prove that your solution is good.
Don’ts
1. Over-perfect the proposal
You can't address all questions upfront. Send your early drafts to your close collaborators and gradually expand your circle. That way, you will get early feedback that can solidify your proposal.
2. Waiting for someone who's ghosting you
It happens. A stakeholder doesn't review your proposal for a long time. Sometimes, it's okay to proceed without their explicit approval. Use your manager to help with situations like this to prevent any escalations later on.
3. Share the document as a pre-read for the sake of it
I've done this! Don't hide the crux of the proposal with subtle document titles.
Eg: Saying we are deprecating API X and tell us what we are missing is better than Future updates to API X.
That's when people will read it and give feedback!
My Story
Almost a decade ago, my team was starting a new product development cycle. We had finished planning and I volunteered to go first for the dev design review. The proposal was for a core component that was designed for making the “best” use of cpu & memory resource. The larger team of 30+ people gathered because it was the first one and we were all excited to "kick it off".
Just 5 minutes in, after I shared the problem and the high-level direction, a loud voice cut me off. We exchanged many questions and answers. Although there were over 30 people in the room, there were just two voices - a confident one shooting down the idea and a flustered one trying to defend it.
I had gone prepared for the meeting, at least, I thought so. I had gotten detailed feedback from another senior engineer and my manager. Though this architect felt the proposal was over-engineered.
To be honest, if I heard that design today then I would have the same reaction. The core design was good, but it was over-engineered. It added dynamic job scheduling to optimally use CPU and memory. However, this would fail in the real world. The proposal should have focused on the simpler part.
The discussion ran for another 20 mins and then my manager intervened to take the conversation offline. That 1 hour meeting ended in less than 30 mins. The architect was nice enough to sit with me 1:1 for an hour after that to review my design and suggested we keep the core and drop the complex parts.
Have you recently been part of a meeting that was brutally shot down? If yes, share them in the comments about what happened next.
> Don't be too attached to your proposal. If someone makes a valid suggestion, then take it. Your goal is to find a good solution, not to prove that your solution is good.
Step 0. In most of the software engineering in our world, whether it's feedback, PR reviews, proposals, or technical docs, is leaving the ego at the door. These are our systems, and we're responsible for building them to the best of our knowledge.
Also, good tips on making proposals that people will actually read by using clear titles and sharing them early.
Great stuff, Raviraj!
I couldn't help but relate to a situation I'm living in right now.
We are making changes in our team dynamics, from agile ceremonies to technical procedures of operational excellence.
Trying to put it all at once because "it's a best practice" would only create resistance.
I was super delighted with my manager making every week one little change. All of them fell into a larger vision, but in an approachable way that left nobody behind.
These tips apply to any change we try to introduce in any group of people. Thanks for sharing them, Raviraj!