A change was supposed to go live for one of the UK's banks. The date had been agreed, the work scoped, everyone had moved on to the next thing. Then the day arrived and… nothing happened.
Not because the change was hard. Not because something broke. Because no one could see that it hadn't been picked up. The task had slipped quietly through the gap between a plan in one person's head and an engineer who never knew it was theirs.
This was at MasterCard, on the team behind Consumer Fraud Risk — the system that decides, in real time, whether a bank transfer is a scam before the money leaves someone's account. Serious, high-stakes engineering. And the system of record for who was doing what? A director's notebook and a chat channel.
The problem was never the tooling
You'd expect a story about DevOps at a payments company to be about Kubernetes, or pipelines, or some clever piece of automation. It isn't. The most valuable thing I did in my first months there had nothing to do with infrastructure. We had brilliant engineers and a serious platform — the talent and the tools were never the problem. The problem was that the work was invisible.
Here's what I actually believe DevOps is, after fifteen years of doing it across medical devices, loyalty platforms, and finance: DevOps is not a role or a toolchain. It's a philosophy about feedback loops. And the first loop you have to fix is not the technical one. It's the human one.
The canon, briefly
If you've read The Phoenix Project, you know the shape of this. Gene Kim's "Three Ways" — flow, feedback, and continual learning — are the closest thing DevOps has to a constitution. The First Way is about the flow of work: make it visible, limit work in progress, and stop the silent killer — unplanned work. Dave Farley makes the same case from the engineering side in Modern Software Engineering: shorten the feedback loop, take small steps, and let evidence — not opinion — drive decisions.
I won't re-summarise those books; they're worth reading in full. What I want to talk about is what happens when you try to actually apply them inside an organisation that has every reason to move slowly.
Listen first, change second
I didn't touch anything for the first few weeks. I spent them listening — talking to as many people as I could, reading years of internal docs, trying to understand how work really flowed, and where it didn't. Walk in and start rearranging things on day one and you'll be confidently wrong, and you'll spend trust you're going to need later.
What I found was a team permanently fighting fires. Work came top-down from a director, landed in a chat channel, and got picked up by whoever happened to notice. Overdue tasks sat forgotten in a backlog nobody opened. A dashboard existed but was never updated. There were no ceremonies — just a weekly catch-up. One example stuck with me: an infrastructure migration went ahead that quietly depended on an engineer creating a database view the application needed. Nobody had visibility of it, so it fell to whoever was on call to rescue over the weekend. That's unplanned work, straight out of the book — and it's expensive in a way that never shows up on a roadmap.
The most important thing I shipped was a board
So the first thing I introduced wasn't a pipeline. It was a Kanban board.
I chose Kanban deliberately, not Scrum. We supported a live, unpredictable system where priorities could shift by the hour; committing to a fixed two-week sprint would have been fiction. Kanban let us do the thing that actually mattered: see all the work in one place, limit how much was in flight at once, and reprioritise continuously without ceremony. Three columns to start — to-do, in-progress, blocked. Nothing clever.
The hard part was never the board. It was buy-in — especially from the director whose notebook I was, in effect, replacing. I didn't lead with theory. I led with pain: I walked him through the concrete incidents — the go-live that silently didn't happen, the weekend lost to an invisible migration. Only once we agreed on the problem did I bring in The Phoenix Project as a shared language for the fix. Principles land far better when they're the answer to a problem someone already feels.
It worked — slowly
It didn't work overnight. It took a couple of months of consistently tending the board, running the conversations, and holding the discipline before it became how the team worked rather than something I was imposing on them. But it worked. Throughput roughly doubled — engineers who used to close two or three tasks a sprint were closing four to six. Fewer things fell through the cracks. And the change I cared about most was the hardest to measure: people started collaborating, because for the first time they could see what everyone else was carrying.
Then, and only then, the technical loops
Once the human loop worked, I pushed on the technical ones. The same principle — fast feedback, small steps — applies to infrastructure, and it's where most teams stop short. We wrote hundreds of automated tests for our infrastructure code, so a change to how the platform was deployed got the same quick, honest feedback that application code gets from its unit tests. Testing infrastructure sounds excessive right up until the first time a test catches a misconfiguration that would otherwise have taken down a service at 2am. That's Farley's point made concrete: treat infrastructure as engineering, and let the feedback loop tell you you're wrong — cheaply, before production does.
If you lead engineers
Here's the uncomfortable version of this. The most common thing I see mistaken for a DevOps problem is actually a visibility problem. Teams reach for another tool, another platform, another pipeline — when the real issue is that no one can see the work, so it can't flow. Tools don't fix that. Tools amplify whatever process you already have: a good one gets faster, a bad one just gets faster at being bad.
So before you buy anything, ask a cheaper question: can everyone on your team see the work — all of it, including the unplanned kind? If the answer is no, that's where your DevOps journey starts. Not with a pipeline. With a board, and the honesty to put everything on it.
That's the whole philosophy, really. Shorten the loops — and start with the most human one.