Personal stories of failure are the hardest to write, because failure hurts. I do believe that It's important to remember failure, because the consequences of failure affect so many people around me, it's not fair for my colleagues and teammates that I repeat the same mistakes when it hurts them too.
We all want to work more closely with our teammates across the whole organization. Silos in organizations hurt communication, morale, and ultimately affects our ability to solve problems for our clients. I've worked in organizations that are highly silo-ed (and those that claim there are no silos, but they clearly exist), and they're not fun.
We can throw our hands up and live with it, or we can do something to break down those silos.
If you're lucky, you'll meet other people who are fed up as much as you are. If not, you're going to go up against some who thrive in highly-siloed organizations. They may never buy-in to your argument, methodology, or execution to break down those departmental barriers.
Unfortunately, without buy-in, your efforts to collaborate will ultimately fail. Let me relate a story of how I tried to make collaboration better, but ultimately failed because there was never any buy-in from my counterpart that there was any problem between the Professional Services and Product teams.
The Setup: PS and Product Don't Talk Very Often...
The PS and Product teams weren't communicating very well. The PS team feels their feedback isn't being heard and actioned on, and the product team feels that the PS team is griping about the same things over and over again. The teams didn't have a good cadence to create a good feedback loop, so I booked a meeting with the VP of Product to discuss this problem and to figure out a way to solve it.
The First Failure: No Buy-In on the Problem Ever Existing
When I met with the VP of Product and described what I saw as a broken feedback loop, I was taken aback when the VP disagreed that a problem existed. The VP believed that ad-hoc feedback to individual product managers was sufficient. Any additional meetings or initiatives would just take the Product team's focus off of was deemed "important" by company executives.
I made the argument that the PS team's responsibility is to delight clients, and we simply cannot do that if we all continue to behave reactively. I pushed the need for PS to dig for anticipatory pains and that we needed to proactively address those pains in product roadmaps.
The VP didn't agree with my assessment. The VP, however, wanted to "try out" having a better cadence of structured feedback between PS and Product.
I considered that as a win. In retrospect, I shouldn't have. This is a clear sign of a lack of commitment. The VP says...
- to try out a potential solution, but
- didn't agree that there was a problem in the first place.
If there is no buy-in that there was a problem, then any action afterwards is just lip service. It's not genuine, and any action is destined for failure because there's a party that doesn't believe that there is anything that needed fixing.
The Second Failure: No Buy-In On the Effort to Fix Things
Thinking I was on the right track to make things better for the Product and PS teams, I set out to try to create a better process for the Product and PS teams.
The VP was willing to try new initiatives, but wasn't willing to put in the work. I understood. The VP had a big team to lead and the organization's product to manage, so I offered to take on the planning and execution for the both of us.
One of my most trusted team members even stopped me and asked "Why are you doing all of this? This is an inter-team exercise, but the VP isn't doing any of the work". I was so eager to make the situation better that I was willing to do anything in the name of "teamwork".
Big mistake.
Try as I may, every time I thought I had come up with a good system, it was met with indifference. The VP never bought in that there was a problem, and it seems like he wasn't going to be bought into the solution either. Sure, at the end we came up with a process that we would try, but it just led to the third failure...
The Third Failure: No Buy-In On Execution
We rolled out the new process to both the Product and PS teams. I had kept the senior members of the PS team in the loop as I was developing the solution, so what was being presented came as no surprise to them. The VP of Product was barely involved, and the product team was absorbing this new initiative for the very first time during the first rollout meeting. There were a lot of questions and scepticism, from both teams, but the PS team, being involved from the very beginning, was committed to making this work.
The VP of Product couldn't be more lukewarm in his endorsement of the new initiative. I think the most ringing endorsement was "We'll try it out, and see what happens".
My heart sank. I had spent weeks iterating through a plan that was designed to make collaboration better between two teams that had difficulty working together previously, and the leaders of the teams couldn't be consistent in our support and commitment.
I can only imagine what the teams were thinking. They were probably musing "Another make-work initiative destined for failure".
They wouldn't be too off-the-mark if they had thought that.
The Bottom line - Commitment is Everything
Looking back, the entire endeavour was destined for failure because it was lacking in buy-in and commitment. There was a...
- Lack of Commitment to the Problem - We couldn't agree there was a problem, so we didn't have the urgency to create a solution
- Lack of Commitment on an Effort to Fix Things - One party couldn't care less to participate in developing a solution to the problem
- Lack of the Commitment to Execute a Solution - The best-laid plans are destined for failure when some can't be bothered to actively and enthusiastically execute
From failure comes lessons, and from lessons come improvement. Next week I'll cover the things I do to improve commitment to cross-team projects!
My approach to collaboration and buy-in is based on the writings of Patrick Lencioni of the Table Group.
This week's article is inspired in part by his book The Five Dysfunctions of a Team.
Thanks this week to Neil Nimkar, Director for Sales Engineering at Rubikloud, for his insight and feedback in making this article better.