One day I got call from an executive at Ticketmaster. They are a multi billion dollar company selling tickets to the world’s largest concerts and sporting events. Ticketmaster was having three problems.
One problem came from the marketplace: Lots of companies were trying to get into the online ticketing business, like StubHub and other startups. These companies, since they were small and nimble, could do disruptive things quickly, so Ticketmaster was scared of them.
The second problem was customer satisfaction: Too often, their web site went down. When it did, customers experienced a world of anguish. They were trying to buy tickets for concerts that were selling out in seconds, yet when they went to pay, their shopping cart would just hang, unresponsive, and they were unable to purchase tickets. Not only were these frustrated customers not getting the tickets they wanted, Ticketmaster wasn’t getting their money, and its reputation was taking a horrible hit. So Ticketmaster wanted to get its web site up quicker when it went down, and wanted it to be more reliable so it wouldn’t go down so much.
The third problem was technology: Ticketmaster relied heavily on decades-old technology. They knew that a newer technology platform could allow them to move faster, but they were terrified. The new technology platform held the promise of working better and alleviating some of the downtime, but they feared the incompatibilities and unknown amount of work to adopt the new platform.
So they hired me.
I spoke to their executives. I interviewed their technical leaders. I reviewed their structure, goals, and strategy. And I noticed something they weren’t seeing: Their product teams were often fighting each other. They were all vying for resources from the same pool, including time, money, and executive attention, often stepping on each other’s toes in the process. With all that conflict and tension, the important stuff just wasn’t getting done. And this issue was slowing everything down, causing their main problems: the hesitation to adopt new technology, the slow progress to create a more reliable web site, and the worrisome pace of their competition against upstart newcomers. I knew we would need to solve that one problem—the problem of teams working at cross purposes—and it would be a linchpin for relieving all three problems they were having. So I said, “If we give the product teams the ability to conduct multiple projects simultaneously, without conflict between them, the three other issues you’re having will be solved too.”
And that’s what we did. We restructured the organization to reduce interdependencies between teams, granting each product team full control over the financial performance, technical performance, feature roadmap, support, and work priorities for its product. We refined the product strategy in order provide more relevant guidance to these newly independent and empowered product teams, yet allowing them to set their own priorities within the strategic framework. And we established clear criteria for product teams to judge the value of the various investment options they faced simultaneously at any moment.
As a result, tension between product teams was dramatically reduced, allowing the work to proceed much more quickly and with a much more healthy mix of short- and long-term projects. This encouraged both maintenance of existing services—short-term investment—together with rapid innovation—longer-term investment. The newly-independent product teams were able to significantly improve the website uptime because they now had the time and inclination to work on addressing the underlying core technical issues, instead of firefighting the issues as they occurred—and customer satisfaction skyrocketed. Very soon thereafter product teams began to seek guidance on how to move to the new technology platform—now that they could invest in the long-term, they quickly appreciated the benefits of the new technology platform. And over the next several months large numbers of product teams migrated their software to the new technology platform. The pace of product development was dramatically increased, and innovative new features and services were coming to market more rapidly than ever before.
We could have solved Ticketmaster’s three problems by creating multiple problem solving teams, but that would have been duplicate work. What I saw allowed them to solve the one problem that had a cascade effect on solving all the problems they had with minimal effort: If the teams were freed up to work without conflict, they could take on all these problems in the normal course of their work. And that’s exactly what happened.
And today Ticketmaster is still number one in their space.