Fintechs ship in days. Most banks still ship in quarters.

Watch one feature travel through a bank and the lesson is not that the people are slow. It is that the work spends almost all of its life waiting, parked in a queue between one desk and the next.

Ask a bank executive why a challenger can launch a feature in the time it takes their own organization to schedule the kickoff, and you will hear about legacy systems, regulation, and scale. Every one of those answers is true, and none of them is the actual constraint. The challenger does not have better engineers. It is not working from a thinner rulebook, and in many cases it now answers to the same regulators. What it has is flow. Work moves from an idea to production without stopping at a dozen desks on the way, and that single difference accounts for most of the gap that keeps bank leaders awake.

This matters because the usual explanations point at things you cannot change quickly, or should not change at all. You will not rip out the core banking platform this year, and you would be foolish to loosen the controls that keep the institution licensed and trusted. Flow is different. It is something you can see, measure, and improve without asking anyone to be braver than their job allows.

Follow one feature and watch it wait

The most useful exercise we run with a bank leadership team is also the least glamorous. We take a single real change, something modest, and we trace its whole journey, from the moment someone asks for it to the moment a customer can use it. Not the time engineers spent building it. The whole calendar.

The pattern we see most often is that the building takes days and the waiting takes months. The work sits in an intake queue. It waits for a quarterly planning cycle to bless it. It waits for an architecture review, then for a security review, then for a change-advisory board that meets on a fixed schedule whether the work is ready or not. Each station is staffed by capable people doing exactly what they were asked to do. The cost is not in any one of them. It is in the handoffs between them, where the work goes cold and someone has to pick it up and remember what it was for.

This is why coaching a single team so often changes nothing the business can feel. The team was never the bottleneck. You can make the fastest station on the line faster still and the line moves at the same speed, because the work is queued upstream and downstream of the part you improved. Lead time, the wait from request to delivery, is the number that actually describes the customer’s experience, and it lives in the spaces between teams, not inside them.

A challenger is faster because nothing it builds sits in a queue, not because it cuts corners. The waiting is the cost, and the waiting is the part you can fix.

Controls and flow are on the same side

Here is the objection we expect, and it is a fair one. A bank’s reviews and approvals exist for good reasons. They are the institution’s memory of every way things have gone wrong. A risk officer who slows a release down is not being obstructive; they are doing the job the regulator and the board hired them to do. Any consultant who tells you to route around that has not sat in the room when an audit finding lands.

So we do not argue with the controls. We argue with where they sit. The slow version of a control is the one applied at the end, as a gate, on work that was built without it in mind, so the review keeps finding things and sending the work back. The fast version is the same control moved earlier, into how the work is built. When access scope, auditability, and the change record are settled while the feature is being designed, the review at the end has less to catch and moves quickly, because the evidence it needs is already there. The careful people stay careful. They simply stop paying for that care twice.

That is the part leaders find counterintuitive and then never forget. Better flow does not mean fewer controls. Reliable flow gives the controls cleaner work to inspect, and a steady cadence of small, well-formed releases is far easier to govern than a quarterly flood of large ones. We saw this clearly with a financial-services client whose onboarding team was drowning until they capped the work in progress and made the queues visible. Cycle time fell by roughly 80%, and nobody lowered a standard to get there. You can read how that came together.

The org chart and the toolchain have to move together

There is a final trap worth naming. A bank can redraw its teams, adopt the right ceremonies, and still not out-ship a fintech, because the work runs through a tangle of aging instances and disconnected systems where status disappears into the gaps. Ways of working and the tools that carry them have to modernize together, or the new structure just produces the old delays in fresh language.

When the platform makes the whole flow visible, where the work is, what it is waiting on, who has to act next, the queues stop hiding. That visibility is most of what a well-run Atlassian platform earns its keep doing in a bank, and it is also the surface a control can attach to cleanly: an audit trail that exists because the work happened on it, not because someone reconstructed it afterward.

None of this asks a bank to behave less like a bank. The institutions pulling level with their challengers kept every control that mattered and made delivery flow anyway. They stopped treating speed and safety as a trade, traced where the time was really going, and fixed the whole line instead of polishing one station. Their scale, once the reason they were slow, turns out to be the advantage a challenger cannot match, once the work stops waiting.

If you want to trace where a feature is really waiting in your bank, see where delivery is getting stuck.