See the system you're in

Here’s a totally made up hypothetical situation…

Xavi, a Customer Success Champion, wants, like, anyone from Engineering or whatever to fix an urgent bug, as it’s impacting Tasha, a VIP user from an important customer.

Having never done this before, he writes up a hasty, emotionally charged paragraph in a Slack channel, tagging @engineering. Words and phrases like “red alert!”, “ASAP!”, and “critical relationship!” are liberally sprinkled in, but it’s scant on actual details; there’s only a cropped, low-resolution screen grab showing a generic error message, and of course, the name “Tasha”, to go on.

(Xavi is not wrong to do this; it really is important, he just doesn’t know how best to get this sorted out.)

Given how many other inbox items there are to get to, he swiftly moves on with his day, feeling that he’s done a good job of delegating this important customer need to the right people, with no delay. And with plenty of exclamation marks!

—

Andrea, from Engineering, who’s on the internal support rotation today, sees the request and responds to Xavi, asking him to log a formal bug report.

“Formal” in this case means that he is to go to a specific Asana project, hit New Task, choose the Bug Report template, and fill in the necessary details.

Included in the template are steps to provide useful screenshots, links to affected pages, email address of the affected user, as well as the actual text and attachments of the user-reported issue.

Anything that’s missing should be sought from the user first; the task should be parked in a waiting area until they’re provided.

Andrea mentions that the Asana project link is in the internal support channel topic, next to the words “FILE BUG REPORTS HERE →”.

Andrea tabs back to working on the documentation updates she was busy with before the ping came in, feeling that she’s done a good job of guiding this clearly important task into the right channel for accurate resolution.

Neat and orderly, wrapped in a bow.

—

So… now what?

The work is stalled at this point, but everyone believes they’ve already done the right thing.

Dr. Ron Westrum, a sociologist, who, as part of his research into what makes for safe, successful outcomes more likely in high-risk, high-complexity fields (such as air flight), found that the following cultural human factors are predictive of respectively low, middling, and high quality and safety outcomes.

He grouped them into three broad descriptors of the organisation in which these humans operate, collectively, Westrum’s Typology of Organisational Cultures.

Here they are:

Let’s explore what it might be like in each of these cases for Xavi and Andrea, and therefore also for Tasha.

See if you can find elements of the model as you take the different scenarios in.

In the Pathological case, they could stall out — neither of them wants to take the next step because it’s “not my job”. They each believe they’ve done what their role requires (and they’re technically correct), but nothing comes of it.

After nothing happens, it’d probably be escalated. Fingers would be pointed. Blame assigned. Perhaps even some outright conflict, if this is finally the proverbial “feather that breaks the camel’s back“ for this team.

Either way, it’s a bad outcome for Tasha; who is either going to wait a long time, or not get any help at all.

Indeed, in a Pathological organisation, there may not even be an Andrea around to guide Xavi, or a place for Xavi to go to get this guidance. There may even not be a Xavi to represent the user to begin with!

—

In the Bureaucratic case, we have already seen this begin. Andrea’s guidance is to follow a carefully prepared channel. That’s pretty bureaucratic, so far, which doesn’t necessarily mean it’s a bad thing, if it produces good outcomes. In this case, it does; it’s designed to scale to meet a high degree of concurrent demand.

Xavi doesn’t know this, or care about this, he just wants to get back to the next thing. So he rolls his eyes a little, and ‘maliciously complies’ by pasting the Slack message he’s just typed into the new task, and hits send. He doesn’t really take in the goals of the template’s information design; after all, he’s not An Engineer.

Andrea (or whoever’s on inbox triage at the time), then has to review the report and ask for the missing bits to be completed again. Eventually, after enough back and forth in the task comment thread between Xavi and whoever’s on duty, enough information is gathered, and an Engineer starts working on the bug. This may take hours due to the delay incurred during this back and forth.

Later, once the bug itself is fixed, there’s no feedback beyond “fixed” followed by the task being marked complete. Xavi writes a flowery and apologetic message to Tasha, with a politically correct version of “welp, engineering folks, what-ya-gonna-do?” threaded in there.

—

In the Generative case, Andrea follows up her standard ‘use the template please’ response with an offer to coach Xavi via screen-share. Xavi happily accepts the support, and they spend 15 minutes working through it together.

Andrea shares a bunch ‘why this process is helpful to us both’ type context in this conversation, which helps Xavi to understand why his part is important, and how doing it helps Andrea’s team to help both him and the important customer he’s representing. Xavi is able to connect the dots between his personal effort of learning the process and the template, and getting the outcome he wants.

Not only do they fill the task in together, but they also work through all the source material they can find. The support request email itself, whatever they can see in their proprietary platform’s user activity log, the configuration governing Tasha’s experience… really anything that helps them both to form as complete a picture as possible of what the user is struggling with.

They still come up a little short, but as Xavi understands the importance of this, he’s able to go back to Tasha with a clear, actionable request for additional information (which he and Andrea prepare together — Andrea has a playbook of copy-paste steps to draw on, which Xavi bookmarks for next time). The task itself is parked in a “Waiting for Input” list with everything they’ve gathered thus far.

As soon as Tasha responds with that information (who appreciates the prompt attention, and crystal clear next steps to follow), Xavi adds it to the task and moves it back into the “Inbox” area. Marko, the next engineer available, sees it within 10 minutes, and his diagnosis work begins.

As he has all the details he needed before he started work, he’s able to replicate the issue clearly, identify the cause quickly, write up a new regression unit test that probes the issue, fix the bug itself, merge into the staging branch, and then, after it’s peer-reviewed by Andrea, deploy the staging branch to the production environment.

Then, Marko and Andrea write a concise summary of the issue and how it was resolved, and provide any next steps for Tasha to take. The task moves into the “Waiting for input” area again, and Xavi is notified.

Marko also creates a documentation update task, citing the bugfix task, and shares a few bullet points of what needs to change, and how.

Xavi writes to Tasha with the good news, informs her clearly what to do to move past the issue, and the job is done. Everyone rightly feels the ‘job well done’ feeling, each having played their part and provided suitable peer support at key moments.

—

In each of these scenarios, a bunch of attention and energy is expended, for a certain amount of value.

In the Pathological case, the value-to-effort ratio is so low, it’s laughable. No one is satisfied. Apathy and contempt are likely present in equal parts. Sadly, we’ve all either been on the receiving end of such service, or been unlucky enough to work in an organisation where this is the way things (don’t) work.

In the Bureaucratic case, the value is there, but the associated waste and delay is higher than anyone really wants. Each person probably believes they personally would make it better if they could, but ‘this is just how it is, sorry. I did my job.’ And, there’s still some apathy and perhaps even some contempt. No one really knows why things kinda suck.

In the Generative case, everyone genuinely gets their needs met. Yes, the effort is still non-trivial for some folks, but the value return for that effort is much longer lived, and it’s optimised such that the next investments everyone makes are more likely to solve something novel, rather than on repeating the same old patterns. That is, Xavi doesn’t need to be guided again; Andrea has the bandwidth to help someone new.

Xavi learned a valuable process, which he and anyone he represents will benefit from. Indeed, he’s able to bypass the Slack channel step entirely now, and go straight to filling that task template in himself, and, he has a fairly good chance of requesting details from those he supports without any assistance from Andrea or any of her colleagues. He’s also well positioned to guide his peers to do the same!

All of this reduces demand on the system, and it all reduces delay. Both of which contribute to an overall increase in throughput of the system. Everyone performs their roles well, and are spending their respective ’attention budgets’ appropriately.

Andrea, or whoever’s on duty, has more time to help other folks out, or perform other tasks, because now Xavi is self-serving.

And, the system they both support got better, not just for Tasha, but also for anyone who follows in Tasha’s footsteps next time, thanks to the improvement in documentation.

Also - stepping back from the work, and looking at the social side - Andrea and Xavi likely had a good time working together. Andrea felt good because she got to teach Xavi something she cares about, and Xavi appreciated the attention and care in ”leveling him up”. They now have a shared experience — a bond — which will help them when their shared system of work is placed under stress in future.

And let’s not forget Tasha, who got some stellar customer service!

My goal is to help you to see the systems you’re in. I believe that once you do see, it’ll be hard to unsee. You’ll have become more conscious.

Seeing is the first step to making improvements, and to removing pain.

With each person seeing the systems that they are in, they are far more likely to have empathy for each other’s responsibilities and needs, and to recognize that neither of them can succeed without the other. It’s a team game.

Perhaps you’ll be able to do the same for your peers, your manager, your direct reports, and for the extended organisation around you.

You might already be a leader of people, whether as an engineering manager, one of the many flavours of P manager — Project, Product, or Portfolio. Perhaps you’re more senior, working in upper management or in the C-suite. Or, perhaps you’re someone who is specialized, working to deliver some key part or another of the product you’re building or supporting.

If you see the system, you can think through interactions with greater objectivity. You can think in terms of roles, incentives, feedback loops, waste, delay, demand, and many other wonderful models for sense-making.

—

In systems thinking, we have this profound quote from Dr. Russell Ackoff:

…the performance of the whole is never the sum of the performance of the parts taken separately, but it's the product of their interactions.

Paraphrased, that becomes:

A system is not the sum of its parts, but rather the product of its interactions.

Too often, we deal with performance as something to do with the individual.

That is, that the ‘wrong action’ is an individuals’s action. Someone is usually ‘to blame’.

However, the reality is the ‘problem’ is not due to the behaviour of one individual or another, but rather the emergent outcomes of their collective behaviours.

That is, it’s possible for two ‘rights’ to make a ‘wrong’.

My hope is that I can help you — and anyone you’re working with — to find these interactions and work on them at that level, which means being able to see these interactions; to see the system. And help everyone involved — not just those that would be ‘blamed’ — to do better, and to have a better life at work.

So that you can guide your system of work more towards living those Generative stories, just like Xavi and Andrea, Marko and Tasha got to experience together.

—

Credits and sources

1 — Westrum’s Typology of Organisational Cultures

The original paper:

• https://qualitysafety.bmj.com/content/13/suppl_2/ii22

An overview published by the Google Cloud folks:

• https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture

I first learned of this topic when listening to Gene Kim speak with Dr. Westrum himself. I hugely recommend it, and the whole IdealCast series.

2 — Dr. Ackoff on Systems Thinking

http://deming.org/ackoff-on-systems-thinking-and-management

There’s plenty of video (including in the link above) of Dr. Ackoff’s lectures. He’s a wonderful, engaging speaker, and has many interesting stories to tell. Another big recommendation from me!