If I’ve seen any theme come up repeatedly over the past year, it’s getting product cycle times down. It’s not the sexiest or most interesting theme, but it’s everywhere: if it’s not on the front burner, it’s always simmering in the background.
Cutting product cycles to the bare minimum is one of the main themes of the Velocity Conference and the DevOps movement, where integration between developers and operations, along with practices like continuous deployment, allows web-native companies like Yahoo! to release upgrades to their web products many times a day. It’s no secret that many traditional enterprises are looking at this model, trying to determine what they can use or implement. Indeed, this is central to their long-term survival; companies as different from Facebook as GE and Ford are learning that they will need to become as agile and nimble as their web-native counterparts.
Integrating development and operations isn’t the only way to shorten product cycles. In his talk at Google IO, Braden Kowitz talked about shortening the design cycle: rather than build big, complete products that take a lot of time and money, start with something very simple and test it, then iterate quickly. This approach lets you generate and test lots of ideas, but be quick to throw away the ones that aren’t working. Rather than designing an Edsel, just to fail when the product is released, the shorter cycles that come from integrating product design with product development let you build iteratively, getting immediate feedback on what works and what doesn’t. To work like this, you need to break down the silos that separate engineers and designers; you need to integrate designers into the product team as early as possible, rather than at the last minute.
Data scientist DJ Patil makes a similar point in Building Data Science Teams. Data isn’t new, nor is data analysis. Our ability to collect data by the petabyte certainly is new, but it isn’t revolutionary in itself. What really characterizes data science is the way data is incorporated into the product development cycle. Data analysts are frustrated and ineffective when they live in silos, and all they do is design complex queries and generate reports. They need to be integrated into decision making and product design. A data group that’s isolated from the organization’s business isn’t going to have the understanding they need to create insights from data. Their role will be limited to confirming what some manager or other thinks, and that’s neither fulfilling or effective.
If you’ve ever optimized code, you’ve experience this phenomenon in a different way: neatly designed, modular code may be well-architected and easy to work on, but when you need to tune for performance, the biggest gains usually come by breaking down these carefully designed modules. The well-designed boundaries that characterize many modern software projects are the silos that need to be broken down for the sake of efficiency.
Organizational structure and culture are no different: boundaries make large organizations manageable. That’s ultimately why we start by developing an idea into a prototype, getting it working, then handing it off to a design team to make it look good. And when it looks good, we throw it over the wall to the operations group. The org chart looks nicer when all the designers report to a design manager, all the software developers report to a software manager, and the operations team is part of IT. But that kind of product development is inherently slow, inefficient, and prone to turf battles and misunderstandings between departments.
And whether you’re building products that weigh tons or products that weigh a few ounces, whether you call it Industrial Internet, Smarter Planet, Internet of Things, Sensor Networks, or some other name, the current wave that re-connects computing with the physical world is no different. You can’t separate that electrical engineering team that makes circuits from the mechanical engineering team that builds the moving parts, or from the software team that does the programming. All of these groups have to work together from the start.
DevOps, data science, and even software development are teaching us that nice organizations with well-defined boundaries may be easy to manage, but they don’t get the job done. Siloed development locks you into long and ineffective product cycles; they lead you to build products that are obsolete when they’re finished, or aren’t what the customer wants. The results are inflexible: they are hard to modify, extend, or fix, and it may take months, not days, to get from version 1.0 to 1.0.1.
Innovation is intensely collaborative. Whether we’re building products to help fix health care, or building jet engines, or just making better online web sites, the boundaries created by traditional management are just getting in the way. We can no longer afford that. It’s time to burn the silos.