How DBS runs 33 platforms with two leaders each

By 2017 DBS had brought engineering in-house, moved applications onto a private cloud and opened 155 APIs. What still ran the old way was the project-and-approval model that decided how money and people moved. In 2018 the bank reorganised into 33 platforms across four categories, with the stated aim, in then-CIO David Gledhill's words, of letting groups of people operate like a platform rather than queue for project funding.

Each platform is run by a pair: one business lead and one technology lead who share the same KPI outcomes. MIT CISR describes this as joint accountability, and the practical effect is simple. When a target is missed, there is no second party to blame. Money follows the platform too. Each holds its own budget, roadmap and outcomes instead of returning to a committee for every change. Gledhill set twenty percent of the scorecard on digital transformation, tied to compensation, and forty percent on strategic initiatives. Oversight sits with a Platform Council of senior managers who review progress on live dashboards, so the council and the teams look at the same numbers.

Platforms own capabilities, but customer problems rarely respect platform boundaries. In 2021 DBS added a second layer, managing through customer journeys, with cross-functional teams organised around outcomes that span several platforms. By 2024 more than sixty journeys covered over sixty percent of revenue. Release volume rose from 30,000 a month in 2019 to 64,000 a month in 2022.

Speed had a cost. Digital outages between November 2021 and October 2023 led MAS to raise DBS's operational-risk capital multiplier to 1.8 times, roughly S$1.6 billion in additional capital, and to impose a six-month pause on non-essential IT changes. The lesson is that resilience and change control have to be built alongside the operating model, not bolted on once something breaks.

A smaller organisation can adapt the model without copying its scale. Choose four to eight platforms around customer-facing services, plus one shared data platform. Name a business owner and a technology owner for each, put both on one shared scorecard line with a fixed share of their assessment tied to it, fund each platform annually and review it monthly on live data. Add journeys only once the platforms are stable, starting with the journey that generates the most complaints. The first step is a mapping exercise: tie every technology person and system to a service, pick the service with the most visible customer pain, name its pair, and run that pair for two quarters before mapping the rest.