Getting Ops Right
Before we can agree on how to change something, we need to agree on why it shouldn’t change.
Every deck I’ve ever seen does the opposite. The classic “FROM-TO” slide. FROM is on the left. TO is on the right. And it’s always thoughtful and objective… even nuanced. FROM the expensive, inefficient, risk-laden living hell we currently experience TO free puppies.
I try not to think about it but our FROM is what the dumber people before us thought was their TO… which can only mean that their FROM was… [shiver].
[Give me a minute. I’m shook.]
So… before we talk about the hardest part of getting to our fully-automated Ops future (our TO), here’s a quick look at how we tackle the problem today.
Our FROM
We have a process factory. And it’s working pretty well.
The raw material (the inputs) are all our painful processes. Its product (the outputs) are less-painful alternatives. And just so we’re clear, it’s not an idea factory– with ideas going in and ideas coming out. Our factory’s output is a fully-implemented, fully-adopted, less-painful process.
It’s not a fancy FROM— but it’s good enough that I wouldn’t mind if we kept it as-is until I’m the dumb guy in my successor’s deck.
Here’s how it works.
Step 1: Prioritization. Once we have an inventory of problems to solve (and a living process to keep adding more), we figure out which ones get to land first, second and third on our assembly line.
We can do that because we’ve already defined “pain” and “less pain.” In our case, it started as manual = pain and automated = less pain. And because we’re a bank, we refined it to risky = pain and controlled = less pain.
Your definition can vary. But you can’t bypass the need for some definitions up front because being crisp on intent allows you to measure the before and after. And what you measure is what changes… especially when you’re not looking.
Step 2: Discovery. This part entails getting a fully-dedicated, cross-functional team deep, deep, deep(!) into the details of each problem/process that’s been prioritized in step 1. Two goals: understand the problem so well that the team can propose a very specific solution (tech and/or process)… and make sure that the potential tech execution doesn’t create a million redundant, bespoke solutions.
Reusability and sustainability are key. And to that end, we do this step in chunks, not onesie twosies. We go deep with a lot of processes that we got from step 1 before any go to step 3. Because it’s better to discover themes of process dysfunction and solution patterning early.
Step 3: Execution. Simple enough. Deliver the needed changes outlined in step 2.
In our case, the tech delivery themes that emerged during Step 2’s discovery phase followed an 80-20 rule. Most of the solutions (the 80%) simply needed to arm Ops with self-service tools like workflow, data matching, robotics, and automated report creation. Nothing you wouldn't have discovered by just asking an operator off the line.
And the other 20% needed a governed but agile (small a) process for rapid application development using common frameworks.
So… 80% no code, 20% low code.
–
Quick, simple real-world example. And normally I wouldn't bore you with this much detail but we’ll use this example in the next section when we talk about the hardest part of getting automation right.
Our factory prioritized the automation of a 5 step high-risk manual process for tracking the manual receipt and dispatch of physical documents. Tech and ops specialists swarmed the problem in the discovery process and highlighted the need for workflow, automated reporting, a management dashboard and an immutable audit trail.
Our factory team had already invested in a highly-configurable no-code workflow builder so the execution team built a simple 5-step digital checklist – naming each step of the workflow and specifying who can perform each step. It’s worth noting that while the checklist added steps to the process– i.e., the digital check-outs and check-ins– the Ops team got the value of supervisory controls (to track timelines and completeness) and a digital goldmine of time-and-motion metrics.
The workflow mitigated the risk – our definition of pain. And the factory moved on– even though every step of the workflow wasn’t fully automated.
—
That’s a decent FROM.
So why not just do that over and over again until the factory runs out of broken processes?
The Hardest Part: Our TO Needs a Mindset Shift (or 3 or 4)
Funny thing. This is where the blog originally started. I began by describing why workflow creation was *the* healthiest foundation for transformational change– directionally correct and filled with promise– but clearly not enough. I waxed poetic about how process solutions drift away from their original intent at a speed equal to the rate of change in your business. Bla bla bla. Just smug truisms, now deleted.
The real issue is that in large orgs, there are more process problems than anyone has time or appetite to fix. And so we try to be pragmatic about it. With the best of intentions, we bring three seemingly-reasonable but necessarily-destructive mindsets to our automation/execution:
* The Once-and-Done mindset. This is that bold and confident voice in our heads that wears a Stetson and hates paving the cow path. “If we’re going to do something,” it says in a deep, wise voice, “if we’re actually going to spend real money– then let’s do it right the first time.” Who can argue with that? “Let’s not leave it half-baked, 80% automated. The goal is 100% or close enough to it that we don’t have to come back in a year.” By the way, in our industry (banking), we call that ambition Straight-Thru-Processing (STP) and it is– motivationally– the perfect that ties the good to the railroad tracks.
* The Boil-the-Puddle mindset. This is the thoughtful whisper we all share that’s deathly afraid of boiling the ocean. It used to love POCs (Proofs of Concept) until someone important complained about the business value of “concepts”… at which point it started loving Proofs of Value. Because… you know… they’re different. It's a very practical voice– a distant echo of why we value “minimum viable products”-- that says the way to eat an elephant is one tiny bite at a time. Who can argue with that? It’s a great analogy that’s never been taken far enough. Because if you take enough tiny bites of an elephant, the poor beast will die, leaving the next thousand bites rancid.
* The Make-the-Donuts mindset. Always starts with: if you’re going to redesign the Donut shop, and dangerous construction is involved, then you’ll obviously want to keep driving customers into that work zone. This is the run-the-bank voice that uses analogies like “we’re rebuilding the plane while it's flying.” Another apt metaphor… because a whole lot of people are about to start screaming. And this one’s especially tough for me because it uses a value I respect– patience– to slowly justify what I don’t: the status quo.
–
We need to ground Ops automation in longer-term regenerative mindsets (that map one-for-one back to the three destructive ones we just covered).
* The Intentionally-Iterative mindset. If you’re designing a 5 step workflow, add a 6th step that only kicks in once a week/month/quarter that asks how the process should change. If your first implementation of that 5 step workflow doesn’t automate any of the steps (i.e., it adds much-needed structure and controls), then have the factory keep coming back to it weekly/monthly/quarterly to see if your other tech tools are now ready to automate a step.
Our factory recently integrated robotic process automation (RPA) with our self-service workflow tool so our intentionally iterative process is going back to all the digital checklists we created and seeing how many 5 step workflows can become 4 step or 3 step workflows. We’ll iterate again when we integrate data matching, ETL, etc.. This is the exact opposite of once-and-done.
* The End-to-End mindset. There isn’t a single substantive workflow that I’ve ever come across that’s genuinely end-to-end. Because workflow designers are either trapped by organizational- or functional boundaries. Show me an example of an end-to-end workflow and I’ll show you constrained thinking. A borderless, end-to-end mindset even challenges institutional boundaries (i.e., our automation investment needs to start at our client’s shop– funded by us, not them).
So a process factory that is intentionally iterative needs to regularly append and prepend every workflow to include more and more of its upstream and downstream capabilities. In plain English: when I revisit my 5 step workflow every week/month/quarter, I need to seriously consider adding a step 0, -1, and -2… and a step 6, 7, and 8– expanding it upstream and downstream. Each iteration gets you closer to a borderless end-to-end; closer to the ocean that we’re all afraid to boil… where the goal is to discover and redirect currents, not to boil.
* The Eat-the-Donuts mindset. Change– like a simple, glazed donut– is joyful. It’s hope. It’s that sense of possibility that the word tomorrow is meant to capture. We don’t need to shield our stakeholders from tomorrow… or tomorrow’s operating model. And if we were being honest with ourselves… most automation isn’t facilitating tomorrow. It’s making today less painful.
Our factory is failing on this front. When we step back and look at that metaphorical 5 step workflow, its contribution to tomorrow’s operating model is that it frees our best and brightest to do something more complex, more client-driven, more meaningful. But that other activity is usually rooted in today’s operating model.
So when we intentionally iterate on that workflow every week/month/quarter… when we knock out steps 2 and 4 with even better automation… when we pull in our upstream and push into our downstream… we should also hold ourselves to the promise of possibilities; to tomorrow. We should… eat the damn donut.
–
Oh… and there’s a bonus mindset– a horizontal one that spans all three above: an engineering mindset. I don’t mean “bring an engineering mindset to the tech you’re building.” I mean bring it to the process redesign, to the operating discipline, to your daily execution on the line.
Let’s never forget that Operations is an engineering discipline. If it were to be starved of all tech funding, it would still flourish with engineering creativity.
Final Thoughts
There are no new ideas. Type that into Google and in .68 seconds, you’ll get 11 billion results. Put the sentence in quotes and it’s still about 371,000 results.
In other words… fight the urge to say “In my company, we call that ‘continuous improvement.’”
In theory, you’re right. In practice… especially if you work for Big… not so much.
–
A process that doesn’t scale isn’t a process. It’s inertia.
And a process that does scale… well… usually, it’s been simplified enough that it fails to capture the complexity of competing mindsets.
In banking, we use the language of run-the-bank vs change-the-bank. And many times, we incorrectly frame the former as simple and the latter as complex… when both are fluid and deeply interconnected.
Look, I’m still processing it all. But what I know is that if we’re rooted in a simple, static operating model, it's just a matter of time before a competitor with a dynamic operating model eats our lunch.
It’s that fear that leads us to the three mindsets that limit the power of automation.
So maybe the hardest part of getting Ops automation right is getting past the fear; getting past “Look… what I know is….”
LinkedIn Tease:
I love washing dishes.
It’s comforting to see a big, dirty pile and know that “getting to done” requires no meetings, no consensus building, no annual budget cycles.
It’s deeply satisfying to feel the sponge, to smell the soap, to get the water juuust right and then to see a dirty spoon transform into a shiny new one.
It’s magic really.
You can’t help but feel a real sense of accomplishment once you’ve cleared the mess.
Oh, and if all that wasn’t enough, you can pretend that all your scrubbing wore you out and land some pitytude from someone you love.
Like I said— magic.
—
When you deal with complexity for a living, manual labor is therapeutic. It explains why so many of us garden as leisure. Or woodwork. Or knit.
—
So… what’s this article about?
I used to get that post-dishwashing glow when I’d automate a simple process at work with a burst of creative tech.
I’d imbed myself with Ops. Feel their pain. And be inspired to do some anger-driven-development.
But the more I’ve embedded, the more I’ve soured on the nirvana of tech and automation; the more I’ve realized that a sprint or two will never be enough; and that the rules of the much more needed marathon aren’t as obvious to the people who love meetings and consensus building and annual budget cycles.
So.. this piece doesn’t even try to explain the problem. It doesn't use fancy words like “digital transformation” (which— let’s be honest— is already way too pretentious for something that was fresh 10 years ago).
It’s just me processing some lessons-learned– to reduce the need to hang out behind Applebee’s— jonzing for that sweet smell of lemon-scented Dawn.