The cow and the chicken: overcoming resistance to change

Introduction

I had already been through multiple interviews, and by the time I reached the third, I was exhausted and nervous. And then, the interviewer threw me a curveball. “Tell me about a difficult challenge you drove,” he said. 

That’s when I remembered how I overcame the organizational resistance to a shift-left model. I knew I had to do more than recite the events, actions, and results, so I used the cow and the chicken fable. 

The Fable of the Cow and the Chicken 

The Cow and Chicken are journeying through the countryside and see a diner with a sign that reads “Steak and Eggs”. The chicken nudges the cow and cackles delightfully: “Look! Look, Cow!! We’re famous!!!”. Whereupon, the cow looks at the same sign and snorts derisively: you’re involved! I am committed!!

Chickens lay eggs, while cows get butchered for steak.

The product with king-sized technical and product debt

The product was an absolute disaster; from confounding features to architectural atrocities, it was a nightmare for users and developers. It seemed like everything that could go wrong did go wrong, and it was always worse than anyone could imagine. Every day was a battle, as engineers had to fight the system to get anything done. It was a constant uphill climb, and there seemed to be no end in sight.

My team was amid the cauldron – in addition to our core feature areas, we were saddled with the thankless responsibility of packaging and releasing the entire organization’s code to production every month. This arrangement generated many grumblings, murmurings, and mutterings.

Partner teams would often sneak in half-baked or buggy features to meet release deadlines, these secretive and hasty bypasses predictably broke features, and my team bore the brunt of investigating, triaging, and routing bugs¹.

Misaligned Incentives – the Cow and Chicken

The cause of the release angst was misaligned incentives – peer teams wanted to get features out at any cost, while my team had to ensure releases were stable. If anything went wrong, the onus lay on my team – we had to investigate and make it right. Unfortunately, the teams responsible for causing the problems had no stake in the game, leaving them with no motivation to resolve the issues. They would rush a quick fix and throw it over the wall without testing it. If anything failed, they would provide another half-baked fix and start the cycle afresh.

Oh, it broke? Here’s another half-baked fix, let’s try again. wink, wink

The situation perfectly exemplifies the Cow and Chicken metaphor. Our team was fully committed to the project, while partner teams were only marginally involved. Such behavior was counterproductive to the organization, causing a breakdown in morale and trust. 

Shipping timelines were consistently delayed, leading to a lack of trust in the release schedule. In addition, there were difficulties in coordinating the requirements of multiple self-interested parties. The situation was akin to getting ten toddlers to sit quietly for ten minutes.

I wanted to pivot my engineering organization’s focus to higher-ROI efforts instead of constantly babysitting other people’s problems. To be honest, I had an ulterior motive – I was tired of dealing with ongoing morale issues, finger-pointing, and constantly putting out fires. I knew there had to be a better way to do things.

I suggested a shift-left engineering solution allowing feature teams to conduct tests before merging changes. The idea was well-received by everyone, and we got approval to proceed. However, when my team implemented the shift-left pipeline, we faced a new obstacle. Although everyone acknowledged the benefits of the tool, there was always some contrived reason for not using the tool, and no one was willing to commit fully.

Pushing Organization Change

Persuading my entire organization to ditch a throw-over-the-wall release model for a self-service model turned out to be more challenging than I thought. The invisible blockers were two:

1. Organizational Inertia to change (aka we’ve always done it this way): The organization was clinging to tradition, hindering the adoption of new concepts. Any new idea had to overcome that barrier to gain a foothold in people’s minds. 
2. Self-interest (aka what’s in it for me?): My proposal meant more work for peer teams; they could no longer chuck their half-finished work over the wall and expect another team to handle the last-mile delivery. 

Understanding resistance to change

“People hate change . . . and that’s because people hate change. . . . I want to be sure that you get my point. People really hate change. They really, really do.

Steve McMenamin, Principal, The Atlantic Systems Guild

It’s understandable that people may feel hesitant to adopt new ideas or alter their current beliefs. Emotions can often play a bigger role than logic, despite our belief in human rationality. When driving for change, it’s important to recognize that it takes time to see results.

Techniques to overcome this

1. Reveal the true costs: Most teams balked at the extra upfront work they’ll have to own. I appealed to their self-interest by revealing the hidden but exorbitant costs of constantly ping-ponging defect ownership. Their reluctance melted when they realized the true costs of constantly missing releases, addressing easily preventable bug fixes, and engaging in dreary postmortems. Everyone was paying a high price, and the new model promised a more efficient engineering solution. 
2. Cut the Gordian knot: Is there a creative way to completely eradicate the problem? Perhaps, there is a way to automate some of the tedious aspects of the job. If not, consider exploring alternatives such as outsourcing, ownership rotation, or finding new owners. You may also propose the creation of a shared team specifically for this purpose to ensure the continuity of operations. 
3. Limit the costs: To limit the costs and burden on your team, you can establish a deadline or cap the expenses of your commitments. It helps to make clear and firm statements about your investment expectations. Make sure to account for any hidden costs such as low morale, attrition, hiring, retention, etc. When executed well, this approach can ensure you are focusing on the most important strategic objectives.

Conclusion

The journey from skepticism to support was long, arduous, and frustrating. It took six months to get to trials and involved cajoling, bartering, explanations, and support building. However, it was worth it.

When my manager, who had previously been unenthusiastic, agreed to present my idea to the entire organization, I knew I had achieved a breakthrough. He even came up with an amusing story about freight drivers to garner organizational support.

And yes, I did pass that interview. Despite the risk involved in using storytelling, I’m glad I took the chance, and it paid off.

What techniques have you found helpful in navigating steak and eggs situations?

1. A post-release postmortem revealed the magnitude of this problem: peer teams had caused 11 out of 13 release blockers! A whopping 85% failure rate!! ↩︎