“You build it, you run it” is a fine principle, but it means you need to let your teams make their own choices. No one wants to support a system running on [insert inappropriate or flaky technology here] just because that’s the company’s recommended queue technology or data store. One size does not fit all.
But what happens when you end up with multiple CDNs, data stores, queuing technologies, issue-tracking systems, communication tools, build and deployment tools, and languages? What’s the implication for ongoing support of your services? It’s all fine when a big team is working on the new shiny thing, but what happens when they leave and you have five people supporting all the “legacy” stuff? And what about first responders who need to work out what system is broken from a web of interconnected services?
Relatedly, how can the technology leadership make sure program teams still pay attention to department goals that may not match their short-term incentives? You want to save costs on AWS; they want to get stuff out there and optimize performance later.
At the Financial Times, teams are pretty empowered to make the right decisions for themselves, but this means they’re very resistant to top-down dictates. As a result, company leadership has had to find other ways to influence people to do the right thing, including nudge theory.
Sarah Wells offers a brief overview of nudge theory and the EAST framework developed by the UK government’s Behavioural Insights team (the Nudge Unit) for influencing behavior. Sarah then shares the things that worked at the Financial Times and, drawing on real-world examples, explores what nudge theory can teach about how to make it easy and attractive for development teams to do the things that matter at a cross-team level.