Introduction

In the introduction, the authors talk about how while most companies have attempted digital transformation, few achieve the results they expect. Research shows that, on average, organizations realize only a fraction of the anticipated benefits, around one-third of potential revenue gains and just a quarter of expected cost savings. According to the authors, the issue isn’t a lack of effort but a flawed approach. True digital transformation goes far beyond implementing isolated technology initiatives. It requires a fundamental shift in how a company operates, bringing in new talent, adopting modern ways of working, upgrading technology, and ensuring data is accessible and usable across the organization. To support this, the authors analyzed 80 global banks over a five-year period. Those identified as digital leaders significantly outperformed their peers, achieving notably higher annual shareholder returns. Their success wasn’t driven by surface-level improvements like better apps, but by deeply reworking core functions such as sales, marketing, customer service, and operations. The book outlines six essential capabilities organizations need to build, creating a clear transformation roadmap, attracting and retaining digital talent, implementing agile team structures, modernizing technology systems, enabling widespread data access, and effectively scaling changes across the business.

Chapter 1: Get Your Top Team Inspired and Aligned

Successful digital transformation starts with three essential elements. The first element is a clear vision that provides the “why” behind the transformation. It must go beyond vague ambitions like becoming more digital and instead be specific, measurable, and tied to business outcomes. When a vision clearly defines what success looks like, such as improving customer experience or achieving a concrete financial impact, it gives the entire organization a shared goal and direction. The second element is alignment, which means more than superficial agreement among executives. It requires that each leader understands their specific role in the transformation and takes responsibility for it. Because digital transformation cuts across functions like sales, marketing, operations, and IT, it cannot succeed if leaders think in silos. Organizations where leadership teams share accountability are far more likely to achieve meaningful results. The chapter also points out that many executives begin with different levels of understanding of digital concepts, so building a common foundation through targeted learning and exposure to more advanced organizations is essential. And the third element is commitment, which goes beyond approving budgets or endorsing initiatives. It involves leaders taking personal ownership of outcomes, consistently investing in long-term capabilities rather than short-term fixes, and demonstrating the behaviors they expect throughout the organization. This visible and sustained involvement from leadership is what ultimately drives transformation forward. The key message is that digital transformation is not just a technical effort, it is a leadership challenge. Without clarity, shared ownership, and real commitment at the top, even the best strategies are unlikely to succeed.

Chapter 2: Choose the Right Transformation ‘Bite Size’

A common mistake in digital transformation is misjudging the scope. Some companies aim too small, making minor improvements like adding features to an app, which leads to limited impact. Others go too far in the opposite direction, trying to transform everything at once and ending up overwhelmed. The authors argue that the most effective approach is to focus on a handful of “domains.” These are distinct, self-contained parts of the business, such as customer onboarding in a bank or supply chain management in a manufacturing company. Instead of spreading efforts across many disconnected initiatives, organizations should select two to five key domains and fully redesign them from end to end. A helpful way to think about this is through a renovation analogy, repainting one room won’t transform a house, but trying to renovate the entire house at once is unrealistic. It’s more effective to fully renovate one area, like the kitchen, before moving on to the next. To decide where to start, each domain should be evaluated based on two factors, the value it could generate, such as improved customer experience, cost savings, or revenue growth, and the feasibility of transforming it in the near term, including factors like data availability, leadership support, and how easily changes can be implemented.

Chapter 3: Have Business Leaders Define What’s Possible

After selecting the domain to transform, the focus shifts to defining what that transformation should actually look like. This stage requires close collaboration between business and technology leaders as it’s not something IT can or should do alone. Business leaders, in particular, need to actively engage in reimagining how the domain could operate in a fundamentally better way. The authors outline a structured five-step approach. First, clearly define the core business problem or customer pain point. Next, connect that problem to specific value drivers, such as reducing churn, automating manual work, or improving personalization. Then, determine the necessary technology and data capabilities required to support those changes. After that, estimate both the investment needed and the expected benefits. Finally, prioritize and sequence the initiatives, while also planning how to manage the organizational change that will come with them. A key message in this chapter is the importance of ambition. The authors suggest that a strong digital roadmap should aim for at least a 20% improvement in EBITDA. If the expected impact is only marginal, it likely means the transformation is not bold enough or is not targeting the right opportunities. The chapter also touches on the rise of generative AI tools such as ChatGPT. While cautioning against chasing every new trend, the authors recognize that generative AI has real potential to reshape areas like content creation, product development, and software engineering. Their recommendation is to revisit transformation plans and identify where such technologies can create meaningful value while staying grounded in practical business outcomes rather than hype.

Chapter 4: Figure Out What Resources You Need

The core building block of a digital transformation is what the authors call an “agile pod” also known as a squad or scrum team. This is a small, cross-functional group of about 5 to 10 people who work full-time on a single digital product or service, taking end-to-end responsibility for its development and success. Each pod brings together a mix of roles: a product owner who defines priorities and is accountable for outcomes, a scrum master who ensures the team runs effectively, and a combination of software engineers, data specialists, UX designers, and business experts with deep knowledge of the domain being transformed. The key is that all necessary skills sit within the same team, enabling faster decisions and tighter collaboration. A useful way to think about a pod is as a kitchen team in a restaurant. Each person has a clear role, they work closely together in real time, and they share responsibility for the final product. Success depends not just on individual expertise, but on how well the team operates as a unit. Not all pods look the same. Their composition depends on the problem they are solving. For example, a team building an AI-driven recommendation system will rely more heavily on data scientists, while one developing a customer-facing app will emphasize UX design and software engineering. Most organizations standardize a handful of pod types to match their most common use cases. Once a company has identified the domains it wants to transform and the solutions it plans to build, it can determine how many pods are required. This, in turn, clarifies the number of people and the specific skill sets the organization needs to hire or develop to support the transformation.

Chapter 5: Build Capabilities for Now and the Next Decade

Although a digital transformation roadmap typically spans just two to three years, the capabilities built along the way, like talent, ways of working, technology infrastructure, and data systems, are long-term assets that will shape the organization for the next decade or more. This chapter emphasizes the importance of building these capabilities deliberately, rather than as a byproduct of short-term projects. The first step is an honest assessment of the current state. The authors recommend going beyond org charts and job titles by surveying employees and interviewing managers to understand the real level of skills, behaviors, and ways of working across the organization. This helps reveal gaps that might otherwise be overlooked. A central point is the level of investment required. As a rule of thumb, digital initiatives should account for at least 20% of total IT spending. Companies that allocate only a small portion of their budget to digital efforts are unlikely to achieve meaningful transformation, as they are not investing at the scale needed to build lasting capabilities.

Chapter 6: The Digital Roadmap Is a Contract for Your C-Suite

The culmination of the work described in the earlier chapters is a digital roadmap, which is a detailed, sequenced plan outlining which domains will be transformed, which solutions will be developed, in what order, with what level of investment, and the expected returns. But the roadmap is more than just a project plan, it is a formal commitment, or “contract,” that the entire leadership team signs onto. Business leaders pledge to deliver specific improvements in customer experience and operational performance, the CFO commits to providing funding, the CHRO to securing the right talent, and the CTO to building the necessary technology foundation. A strong roadmap has five defining characteristics. First, it sequences initiatives to generate value in both the short and medium term. Second, it ties every effort to measurable KPIs so progress can be tracked rigorously. Third, it explicitly accounts for the time and investment required to build foundational capabilities. Fourth, it includes a financial plan that is both realistic and ambitious. Finally, it integrates change management to ensure that people, processes, and culture evolve alongside the technology.

Chapter 7: The Ultimate Corporate Team Sport

Digital transformation cannot be handed off to a Chief Digital Officer and then ignored, it demands active, specific involvement from every member of the C-suite. The CEO plays a central role, setting the vision, fostering cross-functional alignment, holding leaders accountable, and dedicating roughly two to four days per month to overseeing progress. Without CEO engagement, transformations often stall when they cross departmental boundaries, which happens frequently. Other executive roles are equally critical. The Chief Transformation Officer, typically a temporary role lasting two to three years, manages day-to-day coordination and keeps the program on track. The CTO, CIO, or CDO focuses on technology strategy and solution delivery. The CHRO is essential early on for recruiting and developing digital talent. The CFO manages the business case and ensures value is realized. The Chief Risk Officer safeguards compliance and security without slowing progress. Leaders of individual business units must champion transformation within their domains, ensuring initiatives gain traction across the organization. The authors compare a digital transformation to an orchestra, every instrument matters, and no single player can produce beautiful music alone. The CEO acts as the conductor, coordinating the ensemble, but cannot play all the instruments themselves. Success depends on each leader performing their role in harmony.

Chapter 8: Core vs. Non-Core Capabilities — Strategic Talent Planning

This chapter tackles a question that confuses many organizations. And that is, which digital skills should be developed internally, and which can be outsourced? The authors are clear about this that any capability that underpins your competitive advantage, such as proprietary product development, unique data analysis, or designing your customer experience, must be owned in-house. Outsourcing these areas risks losing what makes your business distinctive. At the same time, not every capability needs to be internal. Highly specialized services like cybersecurity penetration testing, cloud infrastructure management, or certain data enrichment tasks can often be handled by external partners. The recommended target is to have roughly 70–80% of your digital talent in-house over time, even if early stages rely more heavily on external resources. Identifying the right talent, however, goes beyond job titles. A “data engineer” could range from a beginner to a world-class expert, so understanding actual skills and proficiency is critical. The authors suggest four ways to assess this. Evaluations by managers, employee self-assessment surveys, online technical tests, and interviews conducted by qualified technical experts. This rigorous approach ensures that the team you build truly has the capabilities needed to drive the transformation.

Chapter 9: The Talent Team That Can Build Your Digital Team

Traditional HR structures are often too slow and bureaucratic to attract and retain digital talent. Engineers, data scientists, and other in-demand professionals have many options and won’t wait months for approvals to move forward. The authors recommend creating a dedicated “Talent Win Room” (TWR), a small, agile team within HR focused solely on finding, hiring, and retaining digital talent. The TWR operates like a startup: it moves quickly, experiments with different approaches, and treats candidates and employees as its “customers.” To be effective, the TWR must combine the right skills. It needs tech-savvy recruiters who can accurately assess coding and technical capabilities, HR specialists who understand career paths and performance management for digital roles, and diversity and inclusion experts to ensure the organization builds a broad, balanced, and inclusive team. This focused, fast-moving approach helps companies compete in the tight market for critical digital skills.

Chapter 10: Hiring Digital Talent When They’re Actually Interviewing You

In this chapter, the authors talk about how top digital talent has abundant options, and how they can choose to work at tech giants like Google or Amazon, or join a high-growth startup. To attract these individuals, companies must offer a compelling experience and demonstrate it consistently, from the first point of contact through the employee’s first day. According to the authors, what matters most to top digital professionals is not just salary. They value the chance to work on modern technology stacks, opportunities to grow their skills, inspiring peers at a similar level, meaningful problems to tackle, and a clear sense that their work has impact. The hiring process must reflect these priorities. It should be fast, ideally moving from initial screening to offer within four weeks, technically rigorous, with real coding exercises and interviews led by true technical experts, and candidate-centric, treating the process as a two-way evaluation rather than an interrogation. Onboarding is equally critical. New hires should gain access to the right tools immediately, be assigned to meaningful projects in their first week, and receive clear context on the company’s digital plans so they understand how their work contributes to the broader transformation. This approach ensures that top talent feels engaged, capable, and motivated from day one.

Chapter 11: Recognize Distinctive Technologists

Not all software engineers are created equal. The difference in productivity and quality between a top developer and an average one can be five to ten times, yet many companies pay based on seniority or title rather than real skill. This approach leads to overpaying mediocrity while losing the best talent. To address this, the authors recommend creating clear “technology competency markers”, which are specific, observable skills and accomplishments that define excellence at each level. A junior data scientist who trains their first model has a different set of expectations than a principal data scientist designing systems used across the entire organization. Compensation should align with these competencies. Salaries need to benchmark against “Big Tech” levels, and companies that fall more than 30% below that standard risk losing talent. Top performers may earn bonuses equal to 100% of their base salary. Beyond financial rewards, non-monetary recognition is critical. Titles like “Distinguished Engineer” for those solving the company’s toughest technical challenges, opportunities to speak at conferences, high-quality mentorship, and a sense of being valued as a professional all play a major role in retaining and motivating top digital talent.

Chapter 12: Fostering Craftsmanship Excellence

Hiring top talent is only half the challenge, companies also need to create an environment where employees can grow, develop their skills, and remain motivated. Most digital professionals are not interested in traditional management roles, they want to deepen their technical expertise and tackle increasingly complex problems. To accommodate this, organizations must provide two distinct career paths: a managerial track for those who want to lead teams, and an expert or engineering track for those who aim to become technical masters. Continuous, tailored learning and development are critical. The authors recommend three core programs: a “digital on-ramp” bootcamp for new digital pod members, covering the company’s tech stack, agile practices, and digital vision; long-term learning journeys for each skill family, such as data science, cloud engineering, or product management; and intensive reskilling bootcamps for employees from other parts of the business who wish to move into digital roles. The key idea is that skills are the currency of the digital age. Engineers measure their value by what they can do, not who they work for. Companies that invest in helping their people grow will retain them, while those that neglect development will inevitably lose their best talent.

Chapter 13: From Doing Agile to Being Agile

“Agile” is one of the most discussed and most misunderstood concepts in business today. Many companies adopt the rituals of agile, like daily stand-ups, two-week sprints, and backlogs, but then wonder why results fall short. The chapter clarifies that the real difference between “doing agile” and “being agile” lies in four critical factors, which are a clear, measurable mission tied to business outcomes, fully dedicated, cross-functional teams with all the skills needed to deliver, real autonomy to make decisions, and a relentless focus on learning from actual users and iterating quickly. The authors highlight three practices that truly make agile effective. First, setting OKRs (Objectives and Key Results) gives each pod a mission lasting a year or more, broken into quarterly objectives with measurable outcomes. OKRs should be ambitious if teams hit 100% consistently, the targets are too easy. This approach, pioneered by Intel CEO Andy Grove, is widely used by companies like Google and Amazon. Second, two-week sprints ensure that every couple of weeks, a pod delivers something tangible like a feature, prototype, or model and tests it with real users. This rapid build-test-learn cycle allows teams to improve continuously rather than spending months building something that might not meet user needs. Finally, quarterly business reviews (QBRs) let domain leaders meet with pod owners every three months to review progress, adjust priorities, and focus teams on the most important work. Done well, QBRs can even reduce the total number of management meetings by as much as 75%, keeping attention on outcomes rather than busywork.

Chapter 14: Operating Models That Support Hundreds of Agile Pods

Coordinating five pods is manageable, but scaling to 500 requires a formal operating model. This chapter outlines three of the most effective models and explains how to choose the right one. All digital operating models are built from three core components. Product pods create customer-facing or employee-facing digital experiences. Platform pods build the shared technical infrastructure that product pods rely on. Chapters are communities of professionals with similar skills such as all data scientists or all UX designers, who share best practices and support career development. The first model, Digital Factory, consists of a self-contained team, often located separately from the main business, that builds digital products for various business units. It is the simplest model to start with and suits companies where technology is important but not the primary differentiator. Examples include BHP in mining and Scotiabank in banking. The second model, Product & Platform (P&P), reorganizes the entire IT function around products and platforms. Business and technology staff work side by side in persistent pods. This model is common in industries where technology is a critical differentiator, such as banking and retail, with Amazon and JPMorgan Chase using variations of it. The third model, Enterprise-Wide Agile, extends agile ways of working across the entire organization, not just technology teams, but also sales, contact centers, HR, and finance. Companies like ING and Walmart Mexico have successfully implemented this approach to achieve enterprise-wide agility.

Chapter 15: Professionalize Product Management

Among all roles in a digital transformation, the product owner, sometimes called a product manager, is the most critical. Positioned at the intersection of business, technology, and the customer, the product owner ensures the pod is building the right solutions in the right way. The authors describe the product owner as a “mini-CEO” for their product. They set priorities, manage the backlog, engage with users, collaborate closely with engineers, and are ultimately accountable for outcomes. Finding individuals with this combination of skills is challenging, and many companies under-invest in developing and supporting this role. In fact, a McKinsey survey found that 75% of business leaders believe product management best practices are not being consistently applied in their organizations. To address this, the authors recommend establishing a formal career path for product owners, from junior associate to senior product director, with clear expectations at each level and dedicated training programs to build the necessary expertise.

Chapter 16: Customer Experience Design — The Magic Ingredient

No matter how excellent the engineering is, it won’t matter if people don’t want to use the product. This chapter emphasizes that customer experience design, the practice of deeply understanding users’ real needs and building around them, is essential. It’s what separates digital solutions that are adopted from those that are ignored. Research cited in the book shows that design-driven companies significantly outperform their peers in both revenue growth and shareholder returns, whether in consumer apps or B2B industrial settings. The authors outline a two-stage design process at which the first stage is the “designing the right thing,” which involves observing real users in their environment to uncover their true needs, not just what they say they want and the second stage, “designing the thing right,” which means building, testing, and iterating until the solution is genuinely delightful to use. A key insight is the concept of a “minimum lovable product” rather than just a minimum viable product. A minimum viable product functions correctly, while a minimum lovable product creates a positive, enjoyable experience for the user. For example, instead of simply narrowing a service appointment window, you could send users a real-time notification when the technician is 10 minutes away, with the same capability, but a much more engaging experience. The authors stress that designers should be embedded in pods from day one, not added at the end to “make it look nice.” Building first and designing later often leads to products that no one actually wants, undermining the entire transformation effort.

Chapter 17: Decoupled Architecture for Development Flexibility

Traditional software systems are often built like a single, monolithic machine, every component tightly connected to the rest. Changing one part requires touching everything else, making innovation slow, risky, and costly. Modern digital architecture takes a different approach. It consists of small, independent components that communicate through standardized interfaces called APIs. This decoupled design allows multiple teams to work on different parts simultaneously without breaking each other’s work. A famous example comes from Amazon. In the early 2000s, Jeff Bezos sent an internal memo mandating that every team must expose their data and functionality exclusively through APIs no exceptions, no backdoors, no direct system connections. He reportedly concluded the memo with “Anyone who doesn’t do this will be fired.” This strict rule is widely credited with enabling Amazon to scale into the technology powerhouse it is today. Beyond APIs, the chapter highlights three other key architectural shifts. First, infrastructure is provisioned through code, enabling new environments to be set up in minutes instead of weeks. Second, systems are modular, so they can evolve over time rather than becoming fixed and brittle. Third, organizations move from batch data processing, which updates data periodically, to real-time data streaming, where information flows instantly as events occur. Together, these practices create the flexibility and speed required for large-scale digital transformation.

Chapter 18: A More Surgical Approach to Cloud

“Move everything to the cloud” is common advice, but the authors argue that it’s overly simplistic. Simply shifting legacy systems to cloud servers, a process called “lift and shift,” creates minimal value. The true power of the cloud comes from redesigning systems to leverage cloud-native capabilities: virtually unlimited scalability, built-in AI tools, pay-as-you-go pricing, and the ability to deploy new features in minutes instead of months. They recommend a domain-by-domain approach for each business area being transformed, to rethink the business process and redesign the supporting technology simultaneously. Migrating technology in isolation, without aligning it to business transformation goals, wastes both time and resources. A key insight is that building a strong cloud foundation covering security policies, network configurations, and standardized deployment patterns that all teams can use can accelerate cloud migration by up to eight times and cut long-term costs by roughly 50%. The chapter also introduces FinOps, the discipline of managing cloud spending to ensure companies only pay for what they actually use. Because cloud costs can escalate quickly if unmanaged, leading organizations establish dedicated FinOps teams to track usage, forecast demand, and optimize spending, ensuring that cloud investments deliver maximum value.

Chapter 19: Engineering Practices for Speed and High-Quality Code

This chapter covers engineering practices that enable digital teams to move quickly without compromising quality. The key idea is that releasing software should no longer be a high-risk, infrequent event occurring every few months. Instead, it should be a routine, automated process that can happen daily or even multiple times a day. DevOps is the guiding philosophy, as development teams and operations teams (who maintain software in production) work together as a single, integrated unit rather than in separate silos. Developers are responsible not just for writing code but for ensuring it functions properly in production. Continuous Integration and Continuous Deployment is the technical realization of this philosophy. Every time a developer adds new code, automated tools run tests, check for security issues, and, if all checks pass, deploy the code directly to users. What used to take months can now be accomplished in minutes, allowing teams to iterate rapidly and deliver value continuously.

Chapter 20: The Tools to Make Your Developers Highly Productive

A highly skilled developer is limited by poor tools, like a master chef forced to cook without knives. The quality and availability of engineering tools directly impact both the speed and the quality of a team’s work. The authors recommend creating standardized “sandbox” environments for each pod. These are fully configured development environments that can be spun up in minutes, pre-loaded with all necessary tools, access to data, and connections to shared services. This ensures developers spend their time building value, not troubleshooting or configuring their environment. Standardization is essential. By agreeing on a common set of tools for version control, testing, packaging, and monitoring, all pods can work consistently, share code, and exchange knowledge efficiently, accelerating both development speed and organizational learning.

Chapter 21: Delivering Production-Grade Digital Solutions

Building a digital solution that works in a test environment is very different from creating one that is reliable, secure, and scalable for thousands or millions of real users. This chapter outlines the engineering practices that make production environments trustworthy and resilient. The core principles are clear, every action should be auditable so you can trace who did what and when, and the system should scale automatically to meet demand. It also should remain available even if a component fails, and it must be actively monitored with real-time dashboards that alert engineers to issues before users are affected. A simple example of monitoring is a live dashboard showing metrics such as page load speed, the percentage of failed requests, and cloud infrastructure costs. Like a car dashboard, these warning lights allow engineers to address problems proactively, preventing small issues from becoming major failures.

Chapter 22: Build Security in from the Start

Cybersecurity is one of the greatest risks in digital transformation. As companies move more systems to the cloud and build additional digital products, the potential attack surface for hackers expands. Traditional security approaches, where a separate team reviews code only at the end of development, are too slow to keep pace with rapid digital initiatives. The solution is to “shift left” on security, embedding security checks throughout the entire development process instead of treating them as a final gate. Automated tools scan code for vulnerabilities as it’s written, validate infrastructure configurations as they’re deployed, and continuously monitor production systems for suspicious activity. The authors describe DevSecOps as an evolution of DevOps as the framework for achieving this integration. In DevSecOps, development, security, and operations teams collaborate from the start, and security is automated within the CI/CD pipeline rather than applied manually at the end. This approach allows teams to move fast without compromising safety, ensuring that digital products are both innovative and secure.

Chapter 23: MLOps — So AI Can Scale

Building an AI model is just the beginning, it’s not a finished product. AI systems require constant care because the data they rely on changes, the environment shifts, and models can degrade or develop biases over time. MLOps (Machine Learning Operations) is the set of practices that enables companies to build, deploy, and continuously improve AI models at scale. The authors highlight that 90% of AI project failures aren’t due to poorly designed models, but rather the challenges of integrating models into real business systems and keeping them running reliably in production. A high-performing model is useless if it isn’t connected to the workflows where it can make decisions. MLOps manages the full lifecycle of AI, collecting and maintaining high-quality training data, experimenting with algorithms, automating deployment of updated models, and monitoring models in production to detect unexpected behavior. An illustrative example comes from the COVID-19 pandemic. AI models trained on pre-pandemic data, such as systems recommending customers visit restaurants, suddenly became ineffective when restaurants were closed. This underscores the importance of continuous monitoring and rapid retraining to keep AI models relevant and accurate as the world changes.

Chapter 24: Determine What Data Matters

Not all data is equally valuable. Before a company can address data challenges, it must first determine which data is most critical, specifically, the data required to deliver the digital solutions on its roadmap. The process begins by mapping the data domains relevant to priority initiatives, such as customer data, product data, transaction data, or sensor data. Within each domain, teams then identify the specific data elements that matter most. In practice, only about 10–15% of all available data elements are truly essential, so focusing on these first prevents teams from becoming overwhelmed. The chapter also introduces the concept of data readiness, which evaluates the quality of data across nine dimensions: accuracy, completeness, consistency, timeliness, uniqueness, validity, integrity, accessibility, and usability. Poor-quality data is a leading reason why AI models and other digital solutions fail to deliver expected results, making this assessment a crucial early step in any transformation.

Chapter 25: Data Products — The Reusable Building Blocks for Scaling

A data product is a curated, ready-to-use dataset that any team in the organization can access and apply immediately. It’s like a database that has been cleaned, organized, and packaged with a user-friendly interface, so a data scientist can start working with it right away without spending weeks figuring out what’s available or how to access it. Examples for this include a Customer 360, which consolidates all information a company has on each customer, a Network 360, which aggregates performance data from a telecommunications network, or an Employee 360, which combines data on employee performance, skills, and engagement. The authors use a simple analogy, and that is that data products are like grocery store produce, fresh, clean, clearly labeled, and ready to use, while raw data is like picking vegetables from a muddy field. The business case for data products is strong. New use cases can be developed up to 90% faster when built on top of high-quality data products, and overall data management costs can drop by roughly 30%, making them a key enabler of efficient, scalable digital transformation.

Chapter 26: Data Architecture — The System of Data ‘Pipes’

Data architecture is the system that moves data from where it’s created, whether in core systems, sensors, or customer interactions, to where it’s needed, such as AI models, business dashboards, or digital applications. The authors compare it to a network of water pipes, controlling how data flows through the organization. The chapter outlines five main approaches to data architecture. A data lake is flexible and storage-heavy, ideal for AI and data science work. A cloud data warehouse is optimized for business intelligence and reporting. A lakehouse combines the strengths of both lakes and warehouses, offering flexibility and structure. A data mesh is decentralized, giving each business domain ownership of its own data. Finally, a data fabric is an emerging approach that connects data across multiple cloud environments seamlessly. Choosing the right architecture depends on your digital roadmap. If your focus is primarily on AI applications, a data lake or lakehouse is preferable. If your main goal is management dashboards and reporting, a cloud data warehouse is usually the better choice.

Chapter 27: Organize to Get the Most from Your Data

Having strong data architecture and high-quality data products isn’t enough if no one is accountable for maintaining them. This chapter explains how to establish the organizational structures, roles, and governance processes needed to keep data reliable and usable over time. The authors recommend a federated model, where a central data office sets standards and provides oversight, while individual business units take day-to-day ownership of their data domains. This strikes a balance between the extremes of full centralization, which can slow progress, and total decentralization, which can lead to inconsistency. Key roles in this model include data domain stewards, business owners responsible for maintaining quality in specific data areas, data product owners, who manage individual data products like a Customer 360, data quality analysts, who continuously monitor and improve data quality, and data engineers, who build and maintain the pipelines that move data across the organization. Data governance, the rules around who can access data, how it can be used, and how quality is maintained, is more than a compliance exercise. When done well, it accelerates innovation by giving teams confidence to use data effectively without fear of errors or privacy violations.

Chapter 28: Nail User Adoption and Business Model Changes

Many digital transformation programs get stuck in what the authors call “pilot purgatory,” solutions that work in testing but never gain traction at scale. This happens for two main reasons, be it the solution itself may not be something users actually want, and the organization may fail to change behaviors and processes to take full advantage of it. To address adoption, the authors propose a four-part change management model. First, leadership engagement ensures that senior managers visibly use and champion the new solution. Second, a compelling change story explains why the solution matters to users, customers, and the company. Third, measurement tracks actual usage and rewards those who adopt the solution effectively. Fourth, role-based training equips people with the specific skills they need to use the solution successfully. Beyond adoption, deploying a digital solution often requires adjustments to the underlying business model. For example, an AI system recommending the best products to customers may necessitate changes in sales compensation, pricing, distribution, and performance metrics. Ignoring these downstream effects is one of the most common reasons digital initiatives fail to deliver their promised value. A practical rule of thumb is for every $1 spent building a digital solution, plan to spend at least another $1 on adoption, change management, and training. Without that investment, even the best solutions rarely achieve their full potential.

Chapter 29: Design Solutions for Easy Replication and Reuse

Scaling a digital solution means taking something that works in one context and deploying it across many more, yet scaling is often treated as an afterthought rather than a core design principle. The chapter explains how to build solutions so they can be replicated efficiently. The authors describe three main approaches to scaling. Linear waves involve deploying to one unit at a time, ideal for high-value but complex environments like mines or refineries. Exponential waves roll out in successively larger batches, 2, then 4, then 8 units suitable for networks of similar sites. Big bang deployment launches everywhere at once, appropriate for solutions that must be consistent across an entire system, such as airline scheduling platforms. The key to successful scaling is what the authors call assetization, which is designing digital solutions in modular components so that 60–90% of the code can be reused as-is, while only 10–40% needs to be customized for each new location or context. This approach dramatically reduces the time, cost, and risk of scaling digital initiatives.

Chapter 30: Ensuring Impact by Tracking What Matters

Many CEOs lack a clear view of how their digital transformation is performing, whether it’s delivering value, whether teams are healthy, and whether the organization is building the capabilities it needs. This chapter explains the performance management infrastructure required to answer those questions. The authors identify three families of metrics. Value creation metrics track whether the transformation is delivering promised outcomes, such as customer satisfaction improvements, cost reductions, or revenue growth. Pod health metrics assess whether teams are working effectively, releasing code regularly, and producing high-quality products. Change management metrics evaluate leadership engagement, talent development, and whether employees are growing the skills needed for the future. For pod health, the authors recommend using the four DORA metrics, widely adopted by elite technology organizations. They are, how frequently teams release new code to production, lead time from code being written to code being in users’ hands, time to recover when something goes wrong in production, and the percentage of releases that cause failures requiring rollback. The Transformation Office brings all of this together. Unlike a traditional program management office, the TO focuses on forward-looking oversight, tracking progress, removing obstacles, and anticipating problems before they occur so as to ensure the transformation maintains momentum and delivers lasting value.

Chapter 31: Managing Risk and Building Digital Trust

Digital transformation brings new, complex risks that traditional frameworks weren’t designed to handle, such as AI systems that produce biased decisions, sensitive customer data that can be stolen or misused, and software vulnerabilities that hackers can exploit. The authors emphasize that managing these risks isn’t about slowing innovation, it’s about building digital trust, defined as confidence that an organization protects consumer data, operates secure systems, delivers trustworthy AI products, and is transparent in its use of data. Companies with strong digital trust tend to perform better financially and are less likely to suffer reputational damage from security breaches or AI scandals. The practical approach involves three steps. First, triage risks upfront, identifying which digital solutions carry the highest risks before building them. Second, review and update policies around data use, AI governance, and cybersecurity. Third, operationalize those policies by embedding automated controls into the development process, rather than applying them manually at the end. The authors use an auto industry analogy from Mark Surman of the Mozilla Foundation. Early car manufacturers didn’t prioritize seatbelts because they were unreliable, but public demand eventually forced them to work 100% of the time. A similar pressure is now building on technology companies to ensure AI safety, data privacy, and algorithmic fairness are reliable and trustworthy.

Chapter 32: So, What About Culture?

“Culture” is the question executives ask most about digital transformation, yet it’s often the most abstract and hardest to define. The authors make it concrete, digital culture isn’t something you declare on a poster, it emerges from consistent actions. When you hire top digital talent, give them autonomy, set ambitious goals, invest in their development, and reward results, you create the culture you want. In other words, culture is what happens when you consistently do the right things. Being intentional about culture means emphasizing specific leadership behaviors: being customer-obsessed, understanding technology well enough to engage meaningfully, collaborating across functions, and embracing a learning mindset instead of a know-it-all attitude. The authors recommend three key investments to shape culture. First, leadership development programs that include visits to digital-native companies, classroom training on digital concepts, and coaching on how to lead differently in an agile environment. Second, broad skill-building initiatives that reach thousands of employees across the organization. Third, intensive reskilling programs for pivotal roles most impacted by digital—for example, merchandisers in retail who now need to leverage AI-driven recommendation tools. These investments ensure that both leaders and employees develop the behaviors and skills that reinforce a thriving digital culture.

Chapter 33: Freeport-McMoRan — Turning Data into Dollars

Freeport-McMoRan, one of the world’s largest copper mining companies with operations in Arizona, Peru, and Indonesia, and over 60,000 employees generating $22 billion annually, is far from a traditional technology company. Yet over a five-year journey, it used AI to unlock the equivalent of a whole new processing facility’s worth of copper production—without building a single new mine. Copper mining is highly capital-intensive. Constructing a new processing facility costs around $2 billion and takes 8–10 years. With mature mines, Freeport needed to increase output from existing assets. The solution: AI. Could machine learning optimize the operation of processing plants in real time? The journey began with a small pilot at the Bagdad, Arizona mine. A cross-functional team of metallurgists, plant operators, and data scientists collaborated over six months to build TROI (Throughput-Recovery-Optimization-Intelligence), an AI model that recommended optimal settings for the copper concentrator, which is the machine that extracts copper from ore. Success depended on adoption. The team worked closely with operators, reviewing recommendations every three hours, explaining reasoning, correcting mistakes, and building trust. This hands-on process was as crucial as the technology itself. The results were striking. In just one quarter, copper throughput exceeded 85,000 tons of ore per day—10% higher than the previous quarter, while the copper recovery rate improved by one percentage point. Leadership estimated that scaling TROI across all Americas mines could generate an additional 200 million pounds of copper per year, worth $350–500 million in annual EBITDA, all without new capital investment.

Scaling was not simply copying the pilot solution. Each mine has unique ore, equipment, and data conditions. Freeport assetized TROI, the core AI engine was reusable, while roughly 40% of the code was customized for each site. To build the necessary talent, the company used a buy, build, borrow strategy, hiring senior data scientists, upskilling internal engineers and metallurgists, and leveraging external partners for specialized skills. They migrated data infrastructure to the cloud and applied DevOps and MLOps practices to manage AI in production. Quarterly reviews, akin to QBRs, kept leadership aligned and enabled rapid resource reallocation to priority areas. The AI program eventually expanded beyond concentrators into maintenance, capital project management, and copper leaching, using the same playbook to drive value across multiple domains. Freeport’s example demonstrates how even a traditional, capital-intensive industry can achieve massive gains through disciplined AI adoption, careful scaling, and capability building.

Chapter 34: DBS Bank — From Traditional Bank to Digital Leader

DBS Group, headquartered in Singapore with operations in 19 countries and 36,000 employees, is Southeast Asia’s largest bank by assets. Over a decade-long transformation, DBS evolved from a traditional bank into a technology-driven financial institution, earning the title of World’s Best Bank five consecutive years (2018–2022). The transformation began with a bold vision from the CEO to stop benchmarking against other banks and start benchmarking against the world’s leading technology companies, such as Google, Amazon, Netflix, Apple, LinkedIn, and Facebook. Internally, this rallying cry became GANDALF, with each letter representing a tech giant and the D in the middle symbolizing DBS’s aspiration to join their league. The core vision was to “make banking joyful,” creating seamless, almost invisible experiences for customers. To achieve this, DBS reorganized around 33 platforms, each representing a major product area or customer segment. Each platform was co-led by a business leader and a technology leader in a “2-in-a-box” model, breaking down traditional silos between business and IT. They mapped 100 critical customer journeys from account opening to credit card origination and assigned a journey manager to each, leading cross-functional teams of 8–10 people. As a result, the credit card origination process was reduced from 21 days to just four.

Talent and technology were central to the transformation. DBS brought 70% of its technology talent in-house, up from 20%, and by 2021, 90% of technology services were insourced, and 99% of applications were cloud-based. Automation soared as one system administrator managed 1,200 virtual machines, work that previously required entire departments. Data and AI became core to the bank’s operations. Slide decks were replaced with data dashboards at every level, and AI was embedded across the business, marketing delivered over 50,000 personalized daily nudges to customers. HR predicted employee attrition, helping reduce turnover to 10%, half the industry average, and compliance used AI to detect money laundering and terrorism financing risks. DBS estimated that AI initiatives alone generated S$150 million in revenue and S$25 million in combined cost savings and fraud prevention in a single year. Culture and learning were equally critical. Through DigiFy, all 36,000 employees continuously updated their digital skills in agile ways of working, data literacy, and technology basics. The results speak for themselves as 65% of DBS customers now use digital tools, generating more than twice the income of traditional customers at half the cost-to-serve. The return on equity from digital customers reached 39%, 15 percentage points higher than that of traditional customers. DBS’s journey illustrates how a bank can become a digital leader by combining vision, operating model redesign, talent investment, data-driven decision-making, and a culture of continuous learning.

Chapter 35: The LEGO Group — Owning the Future of Play

The LEGO Group, the Danish toy company renowned for its interlocking bricks, employs over 25,000 people and generates $9.3 billion in revenue through stores, amusement parks, and digital products worldwide. Facing a digital era where children spend more time on screens and shopping and supply chain behaviors are increasingly digital, LEGO asked a fundamental question, such as how do you preserve the legacy of one of the world’s most-loved brands while becoming a digitally-enabled company? The transformation began with a concentrated effort from nearly 100 business leaders, who defined a five-year vision to become a truly digitally-enabled consumer goods company. To achieve this, LEGO adopted a product and platform operating model, organized around 10 business domains, including consumers, shoppers, customers, and colleagues. Each domain had a senior executive sponsor and a pair of leaders, one from business, one from technology, jointly accountable for results. Product owners led cross-functional pods of 8–10 people, sharing KPIs and incentives with technical colleagues, erasing the traditional divide between business and tech. LEGO invested heavily in technology and data modernization. About 80% of key workloads were migrated to the cloud, infrastructure operations were automated, and DevSecOps and CI/CD practices were implemented. Technical debt was reduced, and monolithic applications were replaced with modular, flexible systems. Data became a strategic asset, with each domain responsible for maintaining and sharing its data through standardized data products, ensuring clarity and a single source of truth across the organization.

The company also focused on building talent. Initially, fewer than 30% of engineers were on staff, with most code written by contractors. LEGO launched aggressive hiring campaigns, attended developer conferences, ran social media campaigns showcasing technical challenges, and opened digital studios in Shanghai (growing from 7 to 75 engineers) and Copenhagen (adding 200 engineers). Overall, systems and software engineering roles increased 2.5x. To scale globally, LEGO adopted a “global-first” design principle, which meant that every technology solution had to work across all markets from the outset, using standardized APIs and a consistent data taxonomy. The Chief Digital and Technology Officer enforced this approach and had the authority to veto local exceptions, allowing teams to work in parallel without creating incompatible systems. The results were significant. Revenue grew 17%, and operating profits rose 5% over the period. LEGO rebuilt its website to handle global scale, and downloads of the LEGO Builder app increased 42% year-over-year. The company is now expanding into gaming and the metaverse, partnering with Epic Games and building new capabilities in game engineering and design. LEGO’s story demonstrates how a legacy consumer brand can leverage technology, data, and talent to thrive in a digital-first world.