DevOps at Scale: What Managing 27 Parallel Workstreams Teaches You

Running a global automation programme across 27 concurrent activity streams at Citibank was one of the more complex coordination challenges I've encountered in 35 years of IT delivery. The technical complexity was significant, but the harder problem - as it almost always is - was coordination, communication, and keeping 27 teams aligned without creating a bureaucratic bottleneck at the centre.

It's a useful lens through which to think about what DevOps at scale actually requires.

**The Coordination Problem**

The promise of DevOps - faster delivery, fewer handoffs, teams that own their work end to end - is genuine. The challenge is that as organisations grow, the number of dependencies between teams grows faster than the number of teams. What works for five teams rarely works for fifty.

The Citibank programme illustrated this clearly. Each of the 27 streams had its own delivery cadence, its own technical stack, and its own stakeholders. The risk wasn't that any individual stream would fail - the teams were capable. The risk was that changes in one stream would create unintended consequences in others, and that nobody would notice until it was too late.

**What Actually Worked**

The approach that proved most effective was establishing a lightweight but consistent set of integration points across all streams. Not a heavy governance structure - those tend to slow everything down and create the illusion of control without the substance. Instead, a shared definition of what "done" meant at each stage, a common approach to dependency tracking, and a regular (but brief) cross-stream sync that surfaced blockers early.

The other critical element was making it easy for teams to raise issues without it feeling like an admission of failure. In large programmes, bad news travels slowly because people are reluctant to be the bearer of it. Creating an environment where surfacing a problem early is seen as good programme management - rather than a sign of incompetence - is harder than it sounds, but it's essential.

**The RBS Migration: A Different Kind of Scale**

The RBS MacMerry data centre migration presented a different challenge. Here the complexity wasn't breadth - it was the zero-downtime constraint. Moving mission-critical banking infrastructure without any service interruption requires a level of planning and rehearsal that most organisations underestimate.

The 99.8% availability achieved during that migration wasn't the result of heroics on the night. It was the result of detailed runbooks, multiple rehearsals, clear rollback procedures, and a team that had practised the migration enough times that the actual cutover felt routine.

That's the unglamorous reality of reliable DevOps delivery. The exciting stuff - the automation, the tooling, the pipelines - matters. But it's the discipline around testing, rehearsal, and rollback planning that determines whether you actually achieve the uptime you're promising.

**What This Means for Smaller Organisations**

Most Irish organisations aren't running 27 parallel workstreams. But the underlying lessons apply at any scale. Define what done means before you start. Make dependencies visible. Create an environment where problems surface early. And invest in rehearsal, not just delivery.

The organisations that do this consistently tend to have fewer dramatic incidents and more predictable delivery. Which, in the end, is what most businesses actually want from their technology function.