When a bank updates its mobile app, customers don’t think about sprints, release windows or regression testing. They open the app, and a money transfer either goes through or it doesn’t. Everything that happens before that moment is work the customer will never see — but will feel immediately if it’s done badly.
Just a year ago, IT at the bank was measured by how many tasks were closed, how many releases were shipped and how many hours were logged. The numbers kept growing, but they didn’t answer the main question: what had changed for the customer? A task could make it to production and have no effect at all. Or never make it there and quietly settle in the shared queue.
In 2026, we changed the way we count. And along with it, the way value is delivered to the customer.
Who is responsible for making sure value gets delivered?
A task is often handled by several people at once: the analyst is responsible for requirements, the developer for code, the tester for quality, and the project manager for deadlines — but no one is responsible for making sure the customer actually feels the result of the changes.
At Ipoteka bank OTP Group, this function is now performed by the Delivery Manager.
You can see the difference in how each one treats task status:
A project manager asks: “Was the project delivered on time?”
A Delivery Manager asks: “Has the value reached the user — and does it work?”
How the Delivery Manager role came about
By the early 2010s, the British government had outsourced almost all of its software development to external contractors: 80% of government IT was built by just 18 companies. Changing a single line of code cost the Treasury £50,000. The total cost of delays, overruns and cancelled projects reached £26 billion. A 2011 parliamentary report called it “a recipe for rip-offs”.
The way out came from an in-house development team and a person whose role would later be called Delivery Manager. A team of 14 people built a working prototype of the government portal in 12 weeks for £261,000 — instead of the £128 million in the contractor’s estimate. Within this team, for the first time, there was a person who kept the pace, removed obstacles and was responsible for making sure the product reached the user.
The conclusion drawn from this was:
The unit of delivery is the team.
Not a contractor and not a project, but a permanent team that lives with the product.
Vendor model vs. an in-house team with Delivery
| Vendor model | In-house team with Delivery |
|---|---|
| Product expertise lives outside the bank. | A small cross-functional team works inside the bank. |
| Every change requires a separate commercial procedure. | The team has its own development environment and release cycle. |
| Releases depend on the contractor’s schedule. | The Delivery Manager carries value from request to user. |
| You can’t quickly test a hypothesis — you have to order it. | A hypothesis can be tested in the next sprint. |
In 2012, the Delivery Manager role became mandatory for every team in the digital service. Today, Delivery Manager is a permanent position at Barclays, HSBC, Lloyds, NatWest, ING, Revolut, Monzo, Wise and Starling, and in the government digital services of the UK, the US, Canada, Australia and Singapore. In the CIS, T-Bank was the first to turn the role into a profession; in Uzbekistan, Ipoteka bank OTP Group did so in 2026.
Delivery in in-house development teams
We launched our new mobile app at the end of 2025. Within the first months, more than 400,000 customers registered in the app, and two thirds of them use it every month. Growth like this would have been impossible to sustain in a setup where a release is a one-off event.
| Metric | Result |
|---|---|
| Share of production defects found in regression | Down sevenfold |
| In-house team | Grew almost 10x |
| Monthly delivery pace | Up almost 7x |
| Planned release windows postponed since spring | None |
The app is in the top 3 of its category on Google Play and the App Store — and users give that rating not to releases, but to the fact that nothing breaks between them.
Lending: four queues instead of one
In lending, the problem was not so much speed as prioritization. Because of a single backlog for all products, different lending lines competed for the same developers. Everyone pushed their own tasks to the top, lead time grew for everyone at once, and there was no one inside development responsible for any specific product.
In spring, the lending stream was split into four verticals, each with its own backlog, its own lead and its own product owner, with a shared platform underneath.
What splitting the shared backlog into verticals achieved
| Metric | Result |
|---|---|
| Incidents per period | 7x fewer |
| Releases per week | 2–3x more often |
| SLA | 96.9% → 99.5% |
| Share of tasks closed vs. created | 50% → 75% |
| Incoming task flow | Grew almost 10x |
Monthly delivery volume is measured relative to the first month of the period. On average, the stream began delivering 3.3 times more tasks per month, while lead time fell in every stream: the queue got shorter because it stopped being shared.
The last line looks like a growing workload, and it is. Fewer tasks used to be filed not because there weren’t any, but because the team couldn’t keep up with the flow and the business stopped bringing them. Once the stream started coping, the flow came back.
Car loans deserve a separate mention. The time from idea to product launch dropped from two or three weeks to three working days — five times faster. This brought five new partner brands and 45 new dealers, and with them, growth in loan disbursements.
The core system: the whole bank knocking on one door
The core banking system is a platform that all nine business units and more than thirty directorates turn to. Compared to last year, the flow of requests over nine months grew by almost 20%. The team stayed the same size.
Requests used to land in one big pile: priorities were set from above, and one in six requests had no owner at all when it was filed. Now each one has a Delivery Manager who takes it all the way to production or honestly explains why it won’t be done this quarter. Since spring, there hasn’t been a single major incident on the core, and the flow of new defects has almost halved.
What we talk about openly
Hundreds of open requests are still sitting in the core queue. Six out of ten are marked top priority — and wait almost as long as all the others. When everything is urgent, nothing is a priority.
So the team started telling the business its quarterly capacity: how many tasks the team can close and which ones it won’t have the resources for. It’s an uncomfortable number, but now the business learns right away that its task won’t be done immediately, rather than after six months of waiting.
An honest “no” costs less than a task that sits in “top priority” status for a year.
Four things we’ve learned
1. Priority is money
Behind every request is an effect that can be measured. If a request sits in the queue for a year, the effect burns out along with it.
2. Every request needs an owner
Not a department or a committee, but a specific person who takes it all the way to production and is accountable for the result.
3. Stability first, then speed
Rolling out something broken quickly is not an achievement. Stability starts with order in the core itself.
4. We tell the business the truth about deadlines
“We don’t know yet, we’ll get back to you on Friday” is more honest than a nice date nobody believes in.
Next: a single delivery model for the IT unit
By the end of 2026, all platforms will work to one standard: seven mandatory lifecycle stages from planning to operation, one product team per platform and a Delivery Manager in every stream.
Today, each of the IT unit’s six streams has its own Delivery Manager. Behind every release are the development, testing, infrastructure and analytics teams — without them, not a single task would make it to production.
The courage to take the first step
Ipoteka bank OTP Group went from a vendor model to an in-house Delivery team in nine months. Development of key products moved from the vendor into the bank, the engineering team grew almost tenfold, and the delivery pace almost sevenfold. The bank became the first in the region to make Delivery Manager a permanent role rather than a one-off project experiment for a single initiative.
Large corporate businesses are rarely associated with bold experiments. But it was precisely an experiment — creating a profession that didn’t yet exist in the region — that delivered the fastest measurable result of the year.
The business’s trust in IT works the same way as a customer’s trust in a bank: you can’t promise it, but you can earn it to the point where people start relying on it.
Nine months is a short time for a bank with a thirty-year history, but long enough for releases to stop being events and become a schedule. Customers won’t see this — but if they open the app and make a transfer, it means we’re doing everything right.