Host Intro (Gene Kim)

All right. Yesterday, I described that the goal of the DevOps Confession format was to bring stories to the stage that you would normally only hear only if you were at the right place at the right time with the right number of drinks at the bar.

Yesterday, we had Courtney Kissler, who's on our programming committee, present an anonymized confession, which I so much appreciated because I think it shows how important it is that as leaders we create viable career tracks for everyone and what happens if we don't.

Today, Jon Smart, another programming committee member, will be delivering today's anonymized confession. And remember, it's not actually Jon's story. Jon is presenting an anonymized story that was gathered by the programming committee members.

So with that, Jon Smart.

Jon Smart

Do you ever have that eerie feeling like you're being summoned to the principal's office?

A new VP had just started with the company and was anxious to bring in a new approach.

Shortly after he started, I reached out and introduced myself and explained how my shared services team was helping his organization.

I was happy to share our transformation journey and goals, especially our charter to keep tearing down silos, reduce time to market, eliminate waste through lean processes, and the empowerment of multidisciplinary teams.

He seemed supportive, and he said he was looking forward to working together.

Several months passed, and we continued our transformation work, championing DevOps principles and practices focused on people, processes, and tools, in that order.

You can imagine my shock when I received an urgent request to come to his office to discuss this DevOps stuff.

I arrived at his office. He sat behind a large desk. He stood up when I entered the room and greeted me with a smile and a booming voice.

He invited me to sit down. However, I was already sitting down.

I noticed the chairs seemed noticeably shorter than the rest of the chairs in the room, and I had a flashback to my childhood where it seemed everything was bigger. I could literally put my chin on the desk without bending over.

None of this helped with the principal's office feeling that I was experiencing.

"So tell me again, what is all this DevOps stuff you're doing?" he asked.

I reminded him of our first meeting and explained again that our goal is to empower people so that we can ship better value sooner, safer, and happier.

The development teams had become mired in organizational scar tissue, dysfunctional processes, and finger-pointing.

I went on to explain, features were slow to be released and plagued with operational issues. As we dug deeper, it was clear that the people who knew how to fix the issues were not empowered to do so.

We were intent on changing that and put dev and ops teams together in order to swarm on the issues to deliver better outcomes for everyone.

A grin formed across his face as he sat back in his chair with his arms folded.

"Ah, so there is the problem," he said smugly.

"DevOps does not work," he continued, "because you cannot trust engineers. They'll stab you in the back and throw you under the bus every time."

Boo.

My mouth literally dropped open. It is true, there have been times in my operations role where developers seemed to be at odds with reliability, maintainability, resiliency, or even just plain decency.

But that was the whole point of the DevOps transformation: bringing people together.

Sure, there were setbacks at times, and some people were more intent on covering their back than backing their teams, but that was the reason we were pushing the change. We were building new relationships and empathetic understanding by aligning priorities, collapsing silos, and putting those roles together as one team united with a common goal.

Realizing my mouth was still gaping, I closed it. I took a deep breath. I attempted to convince him.

I explained that while I understood the mistrust, we have learned that we can build trust by working together and aligning goals. We have seen some amazing improvements with some of the product teams, and feedback from the business is that they love it.

However, he interrupted to say, "I have tried this before, and I promise you, DevOps doesn't work. You simply cannot trust engineers. You can only control them."

Now, I was stunned. If we can't trust each other, the only thing left is a control structure. I had seen the command-and-control clouds forming on the horizon, and this was validation that the new leadership supported that culture and leadership style.

Despite many more attempts to change his mind, I was unable to persuade him or his expanding team that there was a better way.

It became clear to me that their beliefs and behaviors were not going to help in delivering better value sooner, safer, happier. They were more interested in building their own fiefdoms.

I had taken my stand, and I was clearly on the outside in terms of intention and direction.

This eventually resulted in a reorg, which left me and my team outside that part of the organization. We were unsubscribed and unable to help. I was devastated and felt that we had failed.

While I would love to say that the group we left eventually took a positive turn, sadly, that has not happened. Instead, the organization we supported with 10 engineers exploded to a team of several hundred.

They created more specialized roles and segmented groups through increased process, governance, handoffs, and ticket queues. Sadly, many key engineers and leaders in that organization left the company, and the business still struggles with getting releases out of the door on time.

Operations has only gained some sanity through multi-week freeze periods, but that only pauses the chaos. Businesses are frustrated, talented engineers are leaving, and that group continues to expand.

I know what you're thinking: that can't be the end of the story. And you'd be right. They say every cloud has a silver lining, and in fact, even in this difficult situation, some good did come of it.

We were able to pivot our focus to support other business units within the company. Instead of facing resistance and critics to overcome, these new groups welcomed our expertise and were enthusiastic to have us help them with their transformation.

My team members reported feeling liberated, elated, and invigorated to be contributing to organizations that appreciated their help, trusted them, and wanted to partner together to deliver better value sooner, safer, and happier.

Our list of successes quickly exceeded our imagination. While the prior setback was disappointing, the resulting turn of events unleashed our ability to help many more businesses than we would have been able to do before.

Morale in the team was at an all-time high.

So, dear listener, if you find yourself in a similar situation where leadership does not support, recognize, or trust you, the learning from this experience is to pivot, and pivot fast.

Identify the natural champions.

Focus yourself and your teams on those who want your help.

Help those who want help. Empower those who seek to empower others. Invest in those who want to invest in you.

Hopefully, you will see what we have seen, and the dividend will be higher quality products, greater value to business, faster learning and pivoting, safe processing of customer data, and happier colleagues and customers.

Good luck.

Let's take a bow.

I'd like to thank my very talented actors here. We're all wearing our unicorn socks. Let's take a bow. Thank you.

And thank you very much to the author of that confession as well.