“I think we really need to slow down.”
That is one sentence you probably will never hear uttered by a typical CEO. In fact, almost all companies want to move faster. They want to develop more products more quickly and otherwise radically shorten the time it takes for an idea to become a product.
Yet many companies make the mistake of assuming moving faster is merely an act of will, like going on a diet or saving more of your paycheck. In fact, the reasons product development seems to drag on forever or technology projects take too long have more to do with underlying processes, technology and culture than a failure of will. That’s what I discovered after spending a few months analyzing our technology and product development processes at The New York Times. It was then that I had an uncomfortable conversation with my CEO. “You know,” I said, “I think we really need to slow down.”
The second part of that sentence, I suppose, is why I’m still CIO of The Times. “We need to slow down so we can speed up,” I said. And to move faster, we need to stop a lot of what we’re doing so we can implement 'continuous delivery' (CD). CD and its cousin, 'lean product development,' have been all the rage in Silicon Valley since 2011, shortly after Jez Humble and David Farley published a book by that name, and Eric Ries came out with "The Lean Startup." But those concepts were still fairly new to most East Coast companies two or three years ago, when I first proposed that The Times adopt these methodologies.
Slowing down in order to speed up
The complicating factor, however, was that to implement CD, we would have to stop at least half of our new development projects. That was initially a tough sell to a business hungry for new products and enhancements to existing ones. But fortunately, The Times CEO and other executives agreed, persuaded by the promise of at least 30 percent faster development times.
We laid the groundwork during the summer of 2014. Then, in October, with the help of ThoughtWorks, a consultancy that specializes in CD, we began to retrain our teams. For the next three months we throttled back new development on many, but not all, teams as we standardized and automated as many aspects of our process as we could. And while we are by no means finished (not that anyone is ever finished), the results have far exceeded our most optimistic expectations. Here's a bit of what we’ve seen:
- Dramatic improvements in the number of releases we put into production.
- Significantly faster speed of release and delivery. One team reduced its release time from seven days to 35 minutes.
- Higher quality of code in terms of lower errors in production. We cut the number of errors in production by more than half.
As the rest of our teams implement CD throughout 2015, we expect to see even greater speed in releasing new code. But CD is also supporting the next phase of our evolution as a lean product development organization.
Moving faster with lean methodologies
The dream of many large companies is to operate more like a startup. We want small, dedicated teams to build new products unburdened by legacy code and the myriad dependencies and roadmaps of other teams. Yet we also want them to take advantage of all of the technology services we already have in place and not reinvent the wheel.
It seldom works out that way. These teams either go off on their own and end up wasting time replicating existing technology with a few important differences or grow frustrated waiting for other groups to get their acts together. But the problem is almost never the people involved – it’s the underlying technology and processes, which haven’t been designed for that kind of structure.
As our technology teams began to implement CD, we had a parallel project whose goal was to train our product development staff on lean product development. Even though we had already implemented Agile, our product development process still wasn’t hypothesis driven, data driven or incremental enough. Product managers as well as our journalists, who are also deeply involved in product development, needed to learn how to work with our engineering teams in a much more fluid, iterative way than they had even in an agile environment. Adopting those best practices is an ongoing initiative.
CD and lean product development have helped us move faster. But we still had the problem of interdependencies among various teams. To solve that, we have started to implement a microservices architecture, something we couldn’t have done well without first rolling out CD. It’s true that we were probably the first major media company to develop APIs for our content. But you can’t have a well-defined API architecture for all of your major services when tools and processes aren’t standardized across teams. CD imposes its own levels of standardization, and has raised the overall level of maturity of our technology organization.
CD is a journey, not a destination
One of our initial fears in implementing CD was that the standardization and rigor it imposes would dampen the freewheeling spirit of technology innovation at The Times. We were worried that people would feel constrained, or worse, we might meet resistance or skepticism that increase our risk of failure. But in fact, our developers enthusiastically embraced CD. Part of that, I think, was because the positive feedback loop was so immediate. But there was another important factor: Far from stifling innovation, CD has helped unleash it. By allowing developers to test and release code faster than they ever could before, we are beginning to see more rapid advances in our products – and more time for experimentation.
CD is also helping us expand our measures for success. It’s not only about shipping code more frequently but also avoiding rework and time wasted correcting errors that should have been caught much earlier in the process. For example, our monitoring tools uncovered a few lines of bad code in a release that, left unchecked, would have degraded performance over time – code that would have been difficult to isolate if it was a small part of a much larger release. But we spotted and fixed it before it did any damage. So yes, when we talk about CD, it’s certainly the big advances in speed and performance that get all the attention. But sometimes it’s the little things that matter most.
ALSO READ
- Create a culture that's comfortable with continuous improvements for new IT rollouts
- How smart CIOs solve the mobile-delivery problem
Marc Frons is the senior vice president and chief information officer of The New York Times, where he is responsible for all technology strategy and operations atthe company. Prior to being named CIO in 2012, he served as chief technology officer of digital operations for The New York Times Media Group, where he was in charge of technology and product development for digital platforms.
