How I Managed With Buy-in Instead Of Authority
September 18th, 2018 by Vlad Giverts
I had insisted for my team to use a feedback tool that they weren’t bought into. For months, I watched my people use it halfheartedly. I started to feel a tinge of embarrassment every time I saw it up on someone’s screen.
It turned out to be a low-value distraction for 50+ people and I felt like they all knew it.
I spent a long time beating myself up over it because I should have known better. I resolved to do better next time.
In between my mental beatings, I reflected on where I went wrong. What follows is the fruit of those reflections.
Alignment & Buy-in
I realized that I failed because we never got aligned about what problem we were trying to solve. And my leadership team was not bought into the solution that I imposed.
I used to throw these buzz words around so I could feel like I was part of the “in-crowd” of senior leaders at Workday. But I didn’t understand them at the time.
Alignment and buy-in are related–but different–concepts. And I had conflated them for the longest time.
Here’s what they mean literally:
If two objects are aligned, they are oriented in the same direction.
And when someone buys-in, they are purchasing a stake in some venture (like a poker game). They are literally invested in the outcome.
When groups of people feel aligned, it means they share a common perspective of some situation. They still might not agree on the way forward. But they recognize the same underlying facts. And they agree on an interpretation of those facts.
My leadership team was definitely not aligned about what problem we were solving. I wish we had talked it through as a group. I had my own ideas, but we didn’t have that conversation out in the open.
Buy-in is a whole different animal. It’s not about shared perspectives. It’s about commitment.
When someone buys into a course of action, they are prepared to carry out that action in earnest. And they won’t drag their heels or undermine the action in any way.
The SYMAN managers didn’t get in the way of rolling out the feedback product, but they did little to help it succeed. They didn’t spend much time looking at the metrics from the product. And they didn’t have ongoing conversations with their teams about it. Had they talked to their people at a group and an individual level, maybe it would have had a chance.
They weren’t bought in.
In my rush and excitement to help them, I dispensed with the whole idea of buy-in. My results were about what I should have expected.
Management 2.0
I took this lesson to heart at my next job as CTO of Clara Lending.
I adopted a whole different attitude in my management style. The first initiative I introduced at Clara was Scrum agile management.
While I was interviewing there, I noticed a pattern in the frustrations of my interviewers, both among execs and engineering leaders. I suspected that Scrum could be a solution to their problems.
When I started, I took it slow, for me at least. I didn’t say anything about Scrum. Instead, I took the team through a process to systematically get them aligned on the issues and then bought into a solution.
This was my first time being so deliberate. I had no idea how it would play out. I didn’t have a plan so much as an intention. I was winging it every step of the way.
It worked better than I expected and it’s been my go to approach ever since.
I’ll call it alignment-oriented management.
I had operated on intuition and didn’t have a structure in mind at the time. Looking back, I can see a pattern of three separate phases:
- Align around our needs and desires
- Explore possible ways forward
- Plan and take action
1. Aligning On Our Needs
I spent my first two weeks speaking with the engineering leaders one-on-one. And I had group meetings with the wider team.
We all recognized how time and again we delivered later than we said we would. Our business stakeholders were complaining about it. We sensed they were losing trust in us as developers.
And from the other side, developers felt frustrated with the business stakeholders. They often changed what they were asking for last minute. The devs had to re-do and throw work away more often than they’d have liked.
I was simply the facilitator. My role was to steer these conversations to uncover our unmet needs.
The team did most of the speaking. Both feelings and facts were fair game.
2. Exploring Possibilities
There was an offsite scheduled for two weeks after I joined. I decided this would be my chance to make a grand proposal to solve all the pains we had been talking about: Scrum!
An arrogance had crept into my attitude. I was feeling like a savior with the magic powers to solve everyone’s problems.
This was my first misstep.
As soon as I brought up my solution, several people objected, some strongly. In my eagerness to get a “win” under my new belt, I had jumped the gun.
The “right” way would have been to explore a number of possible solutions with the team. And slowly settle on one approach. But I was impatient and too attached to my own “expertise”.
So what could I do now? How could I help the team without insisting on my way and face likely failure, as I did with the SYMAN team at Workday?
Well, I heard them out.
I treated every objection as valid and full of merit. For hours, we talked through their concerns. What were their past experiences and current opinions? What were their fears? How might things break down for us?
It took a while for everyone to feel truly heard. And every second of it was worth it.
I could sense my influence with the team growing with every objection that I heard fully and with an open mind.
After all that, even the strongest nay-sayers were willing to give me the space to walk through my ideas. Though I suspect some of them were giving in to the popular will of the team to hear me out.
I addressed every fear and concern. I gave nuanced explanations of how Scrum works when it’s done right. I also spoke with a flavor of humility by speaking tentatively rather than categorically.
I couched everything as theoretical.
It might not actually work for us! It would not be a new dogma, it would be an experiment. We would tweak it to suit our needs as we went. And if it wasn’t working, we would let it go.
With the potential for big benefits and what seemed like a low risk, we all decided it was safe enough to try.
3. Taking Action
I scheduled a full day of scrum training for all the eng leaders with a great trainer I knew on the SF Peninsula.
They all came back from the offsite excited and ready to try it out. They adopted the various bits of the process, meetings, story points, etc.
For several weeks, I attended all the Scrum meetings. I acted as the coach, offering mini-lessons and clarifications at every opportunity.
It took a couple of months for everyone to get the hang of it. I started attending the meetings less and less. We got to the point where I only joined in to get looped into things, not for training purposes.
Speed Bump
I was surprised how well this alignment-oriented management worked.
But I left out a detail in my story. The “action” step didn’t go quite so smoothly.
One of our three eng leaders never bought in. His team never did Scrum quite right. They abandoned it at their first opportunity, only a month after they started with it.
This eng leader felt triggered by Scrum. He felt it was a bunch of overhead with minimal benefit. He didn’t believe that the problems Scrum solved were particularly serious problems. He wasn’t aligned from the start.
I thought of him as a thorn in my side and a speed bump to my first “win”.
We never managed to connect. And I regret that I never cared about his needs and desires.
I willfully got just enough buy-in from the rest of the team to press ahead and hoped he would fall in line over time.
Management vs Leadership
I used alignment-oriented management to get what I desired. And unlike my attempts at Workday, I got the results that I wanted, for the most part.
But I’m left with the memory of the pain of that one Clara eng manager.
Looking back, I can sense that he was hurting all along. The company had grown and his influence got diluted. We had more stakeholders and more interdependencies. These cut into his sense of autonomy.
His resistance to my initiative was mostly from the pain of feeling diminished. His issues with Scrum were only reminders of that pain.
I realize now that there might have been another way. A way that I could have respected everyone and not leave anyone behind.
In my experience, the point of a manager has been to get groups of people to fulfill the desires of a select few.
But what makes those few desires more important than the needs of everyone else?
That’s where leadership is different. A leader supports the group in fulfilling the needs and desires of all its members.
So for my next few posts, I’m going to explore leadership. What is it, really? And how can one develop leadership within themselves?