How to scale your digital transformation
When a team of top executives from a North American bank entered a converted warehouse run by a European telecom giant, they couldn’t believe what they were seeing. Engineers were live-coding in small teams with designers and businesspeople and reviewing the results right away with customers. They were making adjustments to feedback on the fly. They were launching products and marketing campaigns at record speed, and data were available quickly for rapid adjustments—and everyone was clear on their priorities, which were displayed in simple metrics on their team boards. The CEO of the bank team turned to his colleagues and said, “This is what we need.”
What the banking executives saw was a Digital Factory in action—a model for running a digital transformation where dedicated teams of people work on change-the-business programs alongside existing run-the-business functions.
It works. At a time when our research reveals that just 16 percent of executives say their company’s digital transformations are succeeding, companies we have worked with over the past three years using the Digital Factory (DF) model have been able to:
We see reductions in management overhead of 50 percent for technology teams in the DF, 70 percent in the number of business analysts needed to write technology requirements, and, as test automation becomes the norm, a drop of 90 percent in the number of testers. Finally, we see top engineering talent performing at eight times the level of their peers, as measured with metrics such as code commits.
What is a Digital Factory?
A Digital Factory is the “construction site” where change happens. It comprises dedicated, cross-functional teams that work together on change-the-business programs. They resemble factory workers in that they employ reusable tools and repeatable processes to build specific “products” in the form of new experiences, services, or solutions. The secret to the Digital Factory’s success is that its small teams, working closely with the business side, function as a start-up accelerator. As one business-unit leader recently told us, “It’s like having my own start-up.”
Management of the teams is “mission based”: they are given clear goals (missions) and the autonomy to deliver on them as they see fit. These missions are unlike traditional projects, in that they are end to end in scope, clear on the expected outcome, and add value that can be explicitly tracked.
The exact composition of each team varies by what the team is tasked to do, but teams typically comprise ten to 15 people. The lead DF team prioritizes daily tasks. Importantly, each team is dedicated full time to its own mission and has light reporting lines to keep relevant people informed.
A single center of excellence functions as a nerve center or control tower, supporting the DF with expertise and guidance on particularly complex areas, such as deep learning analytics, standards for cybersecurity, coding practices, and agile methodology; coordinating resources; and ensuring execution quality (Exhibit 1). An operating committee tracks the Digital Factory’s work, unblocking issues and providing funding based on progress.
Five principles that make a Digital Factory work
Different transformation models can vary, depending on the company’s situation. Enterprise-wide agile transformations, for example, can help those that are under such intense competitive threat that they need to quickly and completely reinvent their business structure. Launching new “sidecar” digital businesses, on the other hand, is a model that can help established companies learn how digital companies operate and generate new revenue streams.
The Digital Factory helps companies transform their existing businesses, not completely reinvent and replace them. For the North American bank mentioned earlier, the Digital Factory was attractive because it was a workable model for digitally enabling its businesses at scale—something it knew it needed to do—while continuing to run a very successful legacy company.
A project at one of the leading North American banks kicked off under the leadership of a vice president in the retail business line to reduce the number of paper statements by creating a digital (email, online) substitute. She was already juggling three other projects, so she delegated the project to a recently hired associate vice president (AVP). While he also had his hands full, he managed to secure a team of IT engineers who, he was told, were using “agile,” which would really speed up their work. The engineering team sat in a building across town with other IT resources, so the AVP could visit them only infrequently.
Exploring the current e-statement capability, the AVP realized that many changes were needed. However, since the project sponsor was the retail business unit, he was told to stick to graphic redesign and not innovate new solutions such as an e-locker for statements (which would be a “new product” that the corporate innovation team oversaw), not to change the policy requiring customers to actively opt out of a paper statement (legal-department turf), not to meddle with the marketing campaign (marketing-department turf), and not to change the number of clicks (six) needed to opt in for an e-statement (that was the territory of the online-channel leader, who didn’t get along with the head of the retail business).
Reliable data were hard to find—and he didn’t have a data engineer anyway—so the AVP made some guesses about the current level of e-statement penetration and how much it should be increased. However, in one of the meetings to syndicate his progress before his presentation to the steering committee, he was told to take those numbers out because they would make the marketing executive vice president look bad.
Then one day, on a visit to the IT building, he noticed that there were fewer people on his IT team than he expected. He later discovered that many engineers had been moved unilaterally by IT to a more pressing regulatory remediation project. They restaffed his project a few months later, but the new engineers had no context for the work and had to be brought up to speed from scratch.
Finally, almost two years later, a refreshed webpage with e-statements launched relatively unnoticed. Customer uptake of e-statements barely changed. By then, the retail vice president had been promoted to another role, and the AVP had left the company. The head of the agile center of excellence within IT did, however, log the e-statements project as a market launch and counted it as one more “agile project” he had supported (“Forty percent of our projects are now agile,” he wrote proudly in his year-end review).
That makes the Digital Factory a practical option for many incumbents. What makes it successful, however, is that it directly addresses the key issues that tend to derail digital transformations (see sidebar, “The slow death of a digital project: A story from the front lines”). Through our work helping some 50 companies establish successful Digital Factories, we have distilled their successful practices into five principles that address the key blockers to transformation.
1. Clear missions
Often the goals of a digital transformation are articulated at such a high level that it can be difficult to translate them into concrete initiatives. Confused teams then focus on “looking busy” rather than on impactful outcomes. To truly change the company, organizations need to reshape project portfolios into clearly defined missions that link directly to corporate strategy. The word “mission” is important, because it elevates and signals the importance of purpose.
In our experience, the best missions exhibit the following qualities:
The bank was very practical about developing its missions. Within an hour, the senior leadership team aligned around clear missions to launch their Digital Factory: one mission was to reduce loan-approval times from ten days to five minutes. It was clear, grounded in strategic customer insight, and valuable, and the mandate was designed to ensure that all functions required to deliver on the mission were within its scope.
2. Purposeful collaboration with embedded functions
One of the biggest advantages of the DF is how its change-the-company teams interact with run-the-company functions—in particular, control functions such as legal, risk, compliance, and procurement. While most companies accept the need to be cross-functional in the digital world, they rarely put in place the necessary processes and align them at the leadership level to be successfully applied at scale.
Digital Factories are deliberate and thoughtful, not just about who should be on each team, but also about the process for allocating people to teams when they’re needed. When a multinational bank was creating its plan for developing a five-minute loan, the CIO and the heads of lending, digital channels, risk, and compliance met in a room for two days. Together, they worked out who should be on the team, for how long, and what resources they needed. They determined what kind of people would be part of the full-time core team (developer, designer, product owner, architect, marketer) and which control-function experts (risk, regulatory, legal, and so on) they would need to support them. These people were responsible for quick decision making, guidance, and mining their departments for additional input, as needed. They still reported to their functional leads, but they were responsible for delivering on the missions to which they were assigned.
Leadership recognized that teams didn’t need these particular experts all the time. In this case, when the mission was to develop a process to approve loans quickly, expertise in fraud was important. But fraud-management expertise was needed primarily at the beginning of the mission, and only at key times thereafter. During the “off” time, the fraud experts could be allocated to other mission teams.
Importantly, no company risk or compliance procedure is altered to give a “free pass” to the mission. If more lengthy approvals are needed, it is the assigned functional lead’s job to make sure that teams plan for them so there are no surprises later on. This dramatically facilitates a mission’s speed without compromising quality.
This collaborative operating model is particularly important for working with tech, which generally makes up about 60 percent of each working team within a DF. Successful companies approach the Digital Factories as a joint business–IT effort, with high levels of mutual accountability based on close collaboration between the CIO and the business-unit leaders.
If done right, the Digital Factory is a powerful engine to enable and accelerate not only the business but also the IT transformation agenda. That’s because the missions that Digital Factory teams work on have sufficient scale and clarity of focus for IT to develop next-generation capabilities such as automated testing, cloud-based applications, secure coding practices, and application programming interfaces (APIs) that can be put to immediate and practical use. In fact, we have found that a given company’s top ten most important missions will touch 70 to 80 percent of all IT infrastructure.
3. Balance of leadership guidance and team autonomy
The base unit of a Digital Factory is the team or “squad,” whose members work in the same place, testing and learning their way to the best answers. 1
For this agile approach to succeed, however, teams need a sense of ownership over the work they do. Leadership defines the mission and then gets out of the way. It’s up to the team to figure out how to deliver, including deciding on the technologies to use and how to implement them. The governing mindset for a DF team is “we’ll do what it takes” to make the program work.
That ownership mindset was clear in the bank’s five-minute loan team. One part of the mortgage process entailed checking consumer applications against a government agency’s database, a process that generally took two days to complete. The process had been in place for years, and teams had assumed that regulations mandated the two-day wait time. But when the team questioned that assumption and called the appropriate regulatory agency to ask if the process could be accelerated, they were pleasantly surprised to learn that the agency would work with them. As a result, the team built a simple API that enabled continuous file transfers between the agency and the bank, which made the response almost instant.
This ownership mindset is reflected in the attitudes and responsibilities of the team. As an example, the mission owner is responsible for delivering the mission. That includes determining what the product should be, making all prioritization and allocation decisions, assigning people, and ultimately owning the results—a very different role from the traditional project-management function. Similarly, a good developer on the team is willing to take on hard problems, not just fishing for “easy points” that he or she can deliver on time. These behaviors are supported by performance-management practices that differ from those of “business as usual” organizations, such as aligning incentives for all team members, including IT, with market outcomes. More important, however, is persistently developing and supporting a team-ownership culture. Daily check-ins provide for a high degree of transparency into what people are doing. If someone is not pulling his or her weight, that person can be quickly assigned to a different project.
Autonomy doesn’t imply lack of oversight. While there are no steering committees in Digital Factories, there is an operating committee that comprises senior individuals across business and technology as well as key control functions. This operating committee provides the vision and objective of the mission, serves as the clearinghouse for escalation issues, and reviews successful outcomes against original goals. It operates like the investment board of a venture-capital firm, holding the teams accountable while helping them remove any roadblocks.
The committee reviews missions against outcomes only, not activity or output. Instead of fixing budgets by project over several years, budgets are allocated in the way venture capitalists would do it—at stage gates, where evidence of actual production is reviewed based on the outcomes of sprints. At one financial-services company, the operating-committee members dedicated two hours to a “speed-dating” session, where each member met everyone else individually in order to understand and align on any required changes over the subsequent few quarters. Operating-committee members are expected to informally keep themselves updated on progress by visiting DF teams.
To ensure missions are continually aligned with the organization’s strategic imperatives, the operating committee also holds periodic planning events, typically quarterly business reviews (QBRs), in which leading stakeholders meet over a couple of days to assess the past quarter and plan for the next two. They determine resourcing needs and anticipate technical architecture and other issues that need to be resolved, eschewing process for more fluid discussions with relevant stakeholders on important issues. The operating committee validates the plans that come out of these sessions and ensures that they are linked to the company’s strategy.
4. Active business involvement and sponsorship
Many pilots or “incubators” fail because their “products”—solutions and processes—are never adopted by the company. That’s usually because the development process is divorced from the practical needs of the business.
While Digital Factories are ring-fenced to enable the required velocity, they exist to serve the needs of the business units. At large enterprises, DFs are embedded within individual business units, whereas at smaller enterprises, a single DF serves multiple business units. The DF operates as the execution engine for every business owner’s change agenda.
Business-unit leaders act as sponsors, determining which projects get done, setting the goals and agenda, and providing the funding for the Digital Factory’s work. The business unit also provides people to staff the missions, including the business owner, who personally guides the project in conjunction with the mission owner, and all the other stakeholders, who are physically present and embedded in the team. These steps help to align the goals of the business unit with the work of the DF.
It’s important to make sure that functional and business-unit leaders provide their best people, not just those who are available. In some cases, we’ve found that senior managers will not provide their best people for fear of losing their own influence. This issue must be tracked and managed, in some cases sending people back to their parent function.
Even as the DF develops and manages the products it builds, reporting lines are to the business. Teams work on products, but the product’s business-unit owners keep track of them on a long-term basis.
5. Active support from a centralized team
We have found that for this approach to scale, DF teams need additional support from a central team, a control tower or nerve center (Exhibit 3). This team’s principal role is to enable the squads to deliver value—and to ensure that they do so. It also provides an important coordinating function by maintaining best practices, sharing code, coordinating staffing, and allocating resources.
One of the most important roles in the nerve center is the lead product owner. This person is not a manager but a “doer-in-chief,” who works with the local product owner to ensure quality of execution, provide weekly coaching, pressure-test business cases, and review team progress with the goal of understanding bottlenecks and helping to break them. The lead product owner is particularly involved during the first month that the squad is in place and ideally acts as its mentor.
At one wealth-management company, it quickly became clear that traditional recruiting methods weren’t meeting the squads’ talent needs. So the nerve center assisted the DF in establishing its own recruiting function in order to move more quickly. It helped the DF find different vendors to source talent, establish a new interview process, clearly define what roles it was looking for at each position, and create a scorecard to measure each person. The team created a talent funnel, which they tracked every day. Whereas before it had taken three to four months to find a single designer, this newly established team supported by the nerve center was able to get almost 20 top designers in place in less than three months.
The nerve center at an Asian financial-services firm provided an additional function by taking a “shark tank” type of approach in reviewing business cases for proposed change-the-business work. The nerve center chose those cases that met a number of criteria, including which would have the largest impact and which had active support in terms of people and matching financing from the business unit. When a proposal was approved, the business unit supplied the team and funding was released to the DF to begin work on the initiative.
Getting started
Companies that want to establish an operating model around Digital Factories to change the business need to make the following interrelated moves:
Many companies have scaled their agile-enabled units with impressive speed. But speed is just the beginning. Unlocking the true value of digital will require rapidly scaling the way of working more broadly. Such a change does not come without risks, but in the digital world, standing still is the biggest risk of all.
This content was originally published here.