The Power of Buy-In
I’ve been fortunate to work on an ambitious high-tech project that had a large global team (100+ people) where the collaboration was just incredible and we delivered a game-changing product. In spite of the intense demands of the project, the attrition rate was very low. The team bought into the significance of what we were trying to achieve, understood the plans, and were excited that it was an ambitious but attainable goal.
I’ve also been an observer of initiatives that hit dead ends or went in circles because, in spite of having the resources with the relevant technical skills being brought together, collaboration problems held them back from reaching their potential. Often it’s because one or more contributors didn’t get the importance of their role or task, or they had problems because they were confused.
Getting buy-in from the relevant stakeholders is key to successful collaboration.
What Does It Mean to Get Buy-in?
Getting buy-in means getting commitment and active support from the relevant stakeholders. When they understand the reasoning behind decisions and feel like their concerns have been heard, they're more likely to contribute their best efforts & support when needed. Buy-in transforms individual contributors into advocates, driving momentum, and creates a positive team culture.
Investing Time for Sustainable Results
Often in product development there’s a feeling that there is so much to do, not enough time, and not enough people to do it and hit your milestones.
A pattern that I see in collaboration success stories is that, in spite of the deadline pressure, time is invested up-front to gain buy-in. It can feel excruciatingly slow to spend so much time on the big picture and have so many discussions - clarifying objectives, talking through concerns, teasing out areas of confusion, etc. But those discussions have been key in getting the buy-in it takes, so that once the team knows what they need to do, they are like a freight train charging towards the objective.
The collaboration flops usually rushed through important decisions without sufficient explanation, requiring escalations to managers to sort out conflict, resulting in delays or abandonment of the initiative. They saved time up front, but paid dearly later.
Isn’t This Contrary to Fast Iterations In Technology Development?
You definitely don’t want to get into analysis-paralysis and over-do the time up-front. But, clarifying objectives, talking through concerns, and teasing out areas of confusion ARE a form of iteration!
A wise verification lead at one of my clients pointed out that it’s much cheaper to hash out (a.k.a. simulate) some basics on paper before the “real implementation” begins.
Consider 2 scenarios:
3 team members have a rough idea of the objective. They spend the first day implementing their pieces of the project, then come together and realize 2 pieces don’t fit together properly and the other isn’t done because the 3rd person had a priority conflict. The second day they spend a few hours debating, making assumptions, and go back to work on their pieces. On the third day, the pieces fit together, but management says they wanted something different. Repeat this cycle of 3 days a few times. A couple weeks later, they lost the 3rd resource, 2 of the team members finally deliver the result, and people are frustrated because there was a lot of work thrown away.
3 team members have a rough idea of the objective. They spend the first day debating, sketching rough diagrams, teasing out confusion, listing assumptions, asking questions. They come to an agreement on the priority of the effort. The second day they spend clarifying/validating with management about what the objective really is, once you get to the next level of detail. On the third day, management makes adjustments to their request, based on the feedback. The team members do some thought experiments & update their rough diagrams. On the fourth day, they build their pieces and the pieces are pretty close to fitting together and being what management wants. They feel a sense of collective accomplishment. Then they can spend a 5th day tweaking and polishing the deliverable for this milestone.
Tips For Getting Buy-in That Apply To All Industries
You don’t have to be in technology development to use these tips to get buy-in:
Understand who the relevant stakeholders are: Creating a RACI (Responsible Accountable Consult Inform) chart can help.
Encourage active participation: Get the relevant stakeholders involved in the discussion, welcome their concerns, and value their inputs.
Clarify objectives: Does everyone understand what you’re trying to achieve? If the objective statement is not clear, fix it based on the feedback you get. Post the clear objective statement someplace central for everyone to refer back to it.
Talk through concerns: Uncover the root of the concern and figure out its validity. If it is valid, how will you address it or mitigate a risk that it points out?
Tease out areas of confusion: Listen carefully! Often people are afraid to say that they are confused, so be mindful of silence or disengagement and consider talking to them 1:1. Other times people don’t realize they are confused and you have to detect it - different areas of the business may have a different meaning for the same word, or similar terms that shouldn’t be used interchangeably are.
Validate assumptions: Make a list of assumptions with the stakeholders & figure out who are the right people to ask to validate that they are true.
Draw diagrams to understand & confirm how concepts are connected. A picture can be worth a thousand words.
Conclusion
Collaboration is essential to project success in business. Getting buy-in from the relevant stakeholders takes an investment of time up front, but can save you a lot of wasted time and effort in the long run. Investing the time to get buy-in also promotes a culture of ownership, active participation, and mutual respect because stakeholders feel heard and valued. I hope you found my tips to get buy-in useful!