Breaking hero behaviour with systems thinking


 What follows is my script for the brief Ignite talk I gave at DevOpsDays Toronto 2019, with relevant slides injected.  Here's the video: https://www.youtube.com/watch?v=MtLT3KMkfHU
My goal today is to firmly convince you that hero behaviour is actually an anti-pattern. It should not be praised or rewarded, but rather be viewed as a warning flag signifying greater systemic problems.

I’ll show you the result of my own hero efforts, and how until I was introduced to systems thinking, I never realized that I’d been missing the forest for the trees. Most importantly, I’ll show you how you have complete control to change this.

A number of years ago I was working at a software company that was struggling with siloing, production fires, long deploy times - all the stereotypical issues you’ve seen before, or perhaps experience today. A colleague and I took it upon ourselves to guide the dev teams to freedom and very hastily built a prototype pipeline system to replace their sneaker-net deploys. To the best of my knowledge, that prototype is still running, years later, as that company’s only gateway to production.

We exhibited hero behaviour.

A few years later, I was working at another software company with different problems, and once again found myself saving the day. This time, the systems were on fire and customers were getting errors and timeouts! Can’t let that happen! But wait, oh no, it’s on fire...again. At 3am. On Sunday. But I’ll keep restoring it, because customers can’t be let down!

Once again, hero behaviour.

These are simple examples of what it can look like. The stories pan out like this...

By putting in vast hours to create the automation systems I envisioned would change everything, I, as the hero, took all the hard jobs onto myself. But after several years, a few trusty comrades and I had created something only maintainable by...me.

And when a job opportunity came up that I could not turn down...I left. And everything ground to a halt. My hero behaviour - doing all the hard tasks myself - had turned out to be hugely destructive. Thankfully they recovered from this, but it wasn’t exactly the legacy I’d hoped to leave behind.

The next time, I promised myself, things would be different.

But old ways persisted.

I picked up the torch of ‘never let customers down’ and ran with it, until I realized that I was the only one running. And this time, my hero behaviour was instead destroying me - very nearly burning me out.

Perhaps you hear echoes of your own story here. How could this happen?

Simply put: my behaviours had not changed, because I had not changed.
Generally speaking we are conditioned to see life as a series of events and reactions to events. The housing market is going up - buy now! You’re stressed - take a vacation! The system is on fire - fix it! This mindset causes us to believe that there are events, and even patterns of events, but that’s as far as we consciously take it.

Systems thinking is seeing past the events - trying to understand the interdependent, interconnected, interrelated systems that generate the behaviours which generate the patterns of events we see.

The behaviour-generating systems can never be controlled, but we can seek to redesign the systems to generate new behaviour. In the cases we started with, the hero behaviour was a product of my values and paradigms.
I began to understand that unconsciously seeing my job as ‘hero’ created this reaction to individual events. Seeing my job as ‘hero’ meant acting as a lone wolf where I intended to spur teamwork. Seeing my job as ‘hero’ meant that though I genuinely intended to strengthen the system, I actually weakened it. 

And so we come to the key of practical systems thinking:

Because we are all actors in the systems we inhabit, if we change ourselves, we change the system.

By applying this simple thought and striving to change, my system was redesigned!

To what result?

Well, we had this Slack channel that was still getting alerts, but due to acquisitions, I was the only one left who was really paying attention to it. That fact had bitten us a few times, but we hadn’t prioritized migrating it out. An alert came in one day and my redesigned system more clearly saw the likely result from being a hero.

So I let the system break. And eventually someone found me, and I showed them where the alert came in, and how to fix the issue. And I continued this behaviour until I was no longer the hero, but just another player on the team.

Where before I would have immediately saved the day and received praise...now instead I waited patiently, and redesigned the system to be more transparent, more resilient.

An unlooked-for benefit of this new system was that I was then free to work at showing others that their responsibility lies first within themselves and the part they play in their systems. That they matter as individuals, as people. Because only through someone changing themselves first will the system truly be changed for the better.

Shed your hero behaviour, understand the systems which you inhabit, and redesign them by first changing yourself.

Comments

Popular posts from this blog

Fixing duplicate SPNs (service principal name)

DFSR - eventid 4312 - replication just won't work

Tracking down Peter's lockout