agile5d ago

The How-To Thread: How to Use Narayana Murthy's Global Delivery Model to Build KPIs That Actually Matter

If you work in enterprise technology, you've probably seen this. Dashboards full of numbers. Executives asking for more metrics. Teams buried in spreadsheets. But nobody can point to a single KPI that tells you whether your global delivery engine is working or just staying busy. (1/14)

Show threadagile5d ago

Narayana Murthy built Infosys into something massive by solving this problem. He designed metrics that matched how work actually moved across continents, time zones, and teams. Here's how you can apply that same thinking to your own metrics.

What Murthy Actually Did (2/14)

Show threadagile5d ago
He started Infosys in 1981 with almost no capital. Companies in the US and Europe needed skilled engineers. India had them at a fraction of the cost. But nobody believed software work could reliably cross oceans. Clients wanted proof. (3/14)
Show threadagile5d ago
So Murthy built a measurement system to prove it. The Global Delivery Model was about making work visible across distance. Timelines, defect rates, client satisfaction, process maturity. He didn't measure activity. He measured outcomes that mattered to his clients. (4/14)
Show threadagile5d ago

His thinking was straightforward. If you can't see value flowing across your distributed system, you don't have a strategy. You have a hope. Every metric was a proof point designed to build trust with skeptical enterprise customers.

How to Apply This Yourself (5/14)

Show threadagile5d ago
1. Map your value stream first, then pick metrics. Murthy didn't start with dashboards. He traced how a client request in Chicago became working code from Bangalore. Take one major delivery workflow. Get your whole team together. Map every handoff, every queue, every approval. If you have multiple sub-teams, have each one map their piece. Then connect them. You'll see exactly where work stalls and where nobody owns the outcome. That map is your foundation (6/14)
Show threadagile5d ago
. Without it, any KPI you build will measure the wrong thing. (7/14)
Show threadagile
2. Create three tiers of metrics. Murthy's model measured at multiple levels, and you should too. First, pick one or two client-facing outcome metrics. On-time delivery rate, defect density in production, net revenue retention. These prove value to your customers. Second, track internal flow metrics. Cycle time per feature, work-in-progress across sub-teams, handoff delays. These show whether your distributed engine is healthy. Third, track learning metrics (8/14)
May 27 at 4:48amWeb
Show threadagile5d ago
. How often you run retrospectives, how many process experiments each quarter, how fast you close feedback loops. This is how large teams stay agile instead of just getting bigger. (9/14)
Show threadagile5d ago
3. Run a two-sprint trial. Don't launch a full KPI framework across your whole team on day one. Pick one product line or one client engagement. Run the new metrics for two sprints. Treat the measurement system as its own pilot. After each sprint, ask three things. Did these metrics help us make a better decision? Did anyone game the numbers? Was the data fast enough to act on? If any answer is no, change the metric. Murthy constantly refined how Infosys measured things (10/14)
Show threadagile5d ago
. Metrics aren't permanent. (11/14)
Show threadagile5d ago
4. Set up a regular cross-team review. With a large distributed team, metrics get siloed fast. One group optimizes for speed, another for quality, and they work against each other. Murthy brought delivery leaders from every geography together regularly to look at the same numbers. Try a biweekly 30-minute review with one representative from each sub-team. Keep it tight. Put the data on a shared board everyone can see between sessions. The goal is shared understanding, not blame. (12/14)
Show threadagile5d ago

5. Every metric should inform a specific decision. Most KPI efforts die here. Teams collect data out of habit. Murthy was strict about this. Every metric at Infosys existed because someone needed to make a specific call. Before you lock in any KPI, ask who uses it, what decision it informs, and what happens if the number is wrong. If you can't answer those clearly, cut the metric. A small set of decision-driving KPIs beats a dashboard nobody uses.

One Last Thing (13/14)

Show threadagile5d ago

Good metrics don't just measure your work. They shape how your team thinks about value. Start small, be honest with your data, and let us know what you tried and what actually made a difference.

#GlobalDeliveryModel #KPIs #NarayanaMurthy #Infosys #EnterpriseTech #MetricsThatMatter #DistributedTeams #AgileLeadership #ValueStream #DataDriven (14/14)