Look inside the organizations demonstrating the most success with digital transformation, and you may see what looks more like a set of interlocking software components than a traditional reporting hierarchy.
Or, at least, that is one way of thinking about it, says Jeanne W. Ross of MIT Sloan’s Center for Information Systems Research and co-author with Cynthia M. Beath and Martin Mocker of Designed for Digital: How to Architect Your Business for Sustained Success. The book lays out observations of how digital businesses organize their people as well as their software, drawing on examples of companies doing it well.
[ Read also: Digital transformation success: 5 takeaways from MIT Sloan experts. ]
The goal: Agility for digital transformation experiments
One of the recurring themes is the need to think in terms of components. Componentization is a longstanding principle IT architects have elaborated on through waves of technological innovation including object-oriented programming, service oriented architecture, and, more recently, microservices and APIs . But the book is not primarily about IT architecture, and the authors see the technological design behind a digital business as necessary but not sufficient for transformation.
This is what people mean when they say digital transformation “is not really about technology” — even though technological innovation provides the impetus for transformational change, Ross says in an interview. “What people mean when they say that is technology won’t be the hard part,” she says. “Clearly, the thing that’s transforming is not the technology — the technology is transforming you.”
She argues one reason “big, old” organizations find it difficult to embrace the possibilities of digital transformation is that they focus on structuring themselves for success. They need to think more in terms of designing, rather than structuring their businesses. That design can be thought of as a set of interlocking components that have greater autonomy and operate within an accountability framework.
You do that in search of the agility required to promote productive experimentation and ultimately achieve transformational change.
[ Get answers to key digital transformation questions and lessons from top CIOs: What is digital transformation? A cheat sheet. ]
Organizational pieces that can be modified or replaced
This organizational design also happens the resemble the rationale for making software and systems more componentized, and less monolithic. Giving each component responsibility for performing a discrete function within the overall system makes it easier to modify or replace components independently and for the overall system to evolve.
“There is a big opportunity, captured in the concept of APIs,” Ross says. ““The model is a technology model, a software model, but the manifestation of it in the design of the organization looks more like a set of APIs as well.”
Consider Schneider Electric, which Ross frequently cites as a digital transformation success for the EcoStructure product it introduced to help customers manage their power consumption across its product lines, from data center power management to circuit breakers and building automation.
Adding digital controls and monitoring came more naturally to the data center unit that grew out of Schneider’s acquisition of APC, Steven Carlini, Vice President of Innovation and Data Center at Schneider Electric, says in an interview. But the goal of EcoStructure is to provide a comprehensive overview to facilities managers who are responsible for the overall power consumption and reliability of buildings, including cooling, heating, breakers, transformers, and IT operations.
Typically, “IT managers never see the electric bill, but facility managers do,” Carlini says. “For the facility manager, unless it’s a dedicated data center, there are other parts of the building they’re responsible for as well. It’s a big job, with a lot to do, and we’re trying to make it as seamless as possible.”
Making all Schneider equipment, and the business units that make it, fit into this scheme is still a work in progress, coordinated by an overarching group called Schneider Digital. Some of the industrial and power distribution equipment already includes sensors that report back data, but not necessarily using common metrics or over the TCP/IP protocols that are standard in the computer world. The data needs to be normalized and made available over standard APIs, but in the process the knowledge of experts in different domains also needs to be respected, Carlini says.
“As an IT guy, my feeling is everything should be realtime, but some of the facility guys are more old school and may be more comfortable with a weekly or monthly report,” Carlini says. Those intervals may in fact may be appropriate for temperature readings from a transformer or switch, for example, as a prediction of equipment failure, which typically happens over months or years, not seconds, he says.
Digital transformation teams and tribes
Squint hard enough, and you can see those interlocking components taking responsibility for their problem domain and interacting through APIs. Another case study, detailed in the Designed for Digital book, is how Spotify organized its development teams in parallel with moving from a monolithic software architecture to a more componentized one. The authors use this as an example of balancing autonomy with alignment and accountability. That is, we want to give teams the autonomy necessary for innovation but without allowing them to all run off in different directions.
Spotify organizes its “teams” into tribes, which have end-to-end responsibility for a function (for example, the Music Player tribe and the Infrastructure and Operations tribe) and “squads” responsible for more discrete services (for example, the search component of the Music Player). “Spotify leaders emphasize the need to define boundaries and limit the need for collaboration across squads,” the authors write. Similarly, the software components are isolated to have a “limited blast radius” if they fail.
Spotify promotes alignment between autonomous teams with the concept of a “mission” assigned to each tribe and each squad, where all missions are expected to align with bigger bets the company is making on its direction.
A mix of stability and agility
Your organization may or may not be comfortable with adopting such newfangled terminology, but the ideas behind them are worthy of consideration. The point is not that all the traditional business structures like departments and reporting hierarchies will melt away, but that those structures are best at enforcing stability rather than promoting agility, Ross says.
If your goal is to become a more digital, agile organization, you don’t want to “lead with structure,” she says, “but the reality in a complex company is that it will be a mix of the two.”
What is the right mix? Ross acknowledges she and her colleagues are still feeling their way toward a more precise understanding. “All we have in the book right now is a set of principles,” she says.
What those principles describe is how successful digital companies organize themselves for agility and how established companies can adapt those practices. “It’s not hard when you’re small, but it seems impossible when you’re big,” she says.
Break your organization into smaller components to give yourself a fighting chance.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]
