What Is a Digital Transformation—For Real?

Mar 1

Recently a senior manager said to me,

“What does digital transformation mean? What is it made up of?”

I think a lot of people are confused by the term. It sounds cool—after all, today’s products are digital. But what exactly is a digital transformation?

Well here is what digital transformation means—or should mean—to be effective:

The company begins to view itself as a technology company.
Tech is becoming a business partner—not a service.
The company begins to apply operations research and Lean approaches to optimize the business outcomes of entire value streams, rather than having functional silos and optimizing the separate cost performance of each.
The company’s culture becomes more collaborative and discussion oriented, and is not dominated by internal competition.
Thoughtful decision changes become seen as routine—not as mistakes.
The company becomes more concerned with effectiveness than efficiency.

“We’re a Technology Company”

Some years ago the CEO of a major fintech company in my area said, “We are a financial services company. We are not a software company.”

He wanted to remind people that software was, in his view, only a tool, and that the company was fundamentally about financial services.

Except that almost all of that company’s business, at that time, was already occurring through digital processes. And those digital processes were the differentiators and enablers of future opportunities for growth—and even survival.

If a company is a tech company that operates in certain markets, then tech is strategic, and is not just a service: it is a market maker.

The world had changed around him, and he could not yet see it.

He is gone from the company now, and today that same company today describes itself as a tech company that provides financial services.

This shift in viewpoint matters because senior executives focus on the things that they think are central to their business. If they think that technology is peripheral or is just “a tool” then they will not focus on it, and will miss the opportunities of today and tomorrow. And their priorities will be such that technology is treated as a commodity, which it is not: today it is the great enabler of everything. Nicholas Carr could not have been more wrong.

And gone with that attitude that tech is just a tool is the idea of IT as a service. The idea that business stakeholders bring their needs to the tech group and the tech group merely implements it is arrogant in that it assumes that tech has no business ideas of its own. And yet most innovation today, and therefore most business opportunities, is technical in nature. If a company is a tech company that operates in certain markets, then tech is strategic, and is not just a service: it is a market maker.

“We Organize Around End-to-End Flows”

Regardless of how an organization is structured, rapid decisionmaking needs to occur around the natural flows of value, from the organization’s capabilities to the customer.

The reality today is that product issues often cut across hierarchy. That is not an anomaly—it is a common occurrence. Consider for example a core microservice that is used by five different products. Now consider what must happen when one product requires changes to that core microservice. The old approach of escalating that issue to an architecture review board and redesigning all the affected products is way, way too slow for today.

What must happen instead is that someone in leadership must observe or be made aware of the issue right away, and the affected product leads need to gather and quickly talk through the situation and reach an intelligent and timely decision about what to do. We’re talking hours, days, or weeks—not months. In other words, leadership needs to follow issues and see them through, in a collaborative and non-competitive way that puts the organization’s goals first with minimal concern for one’s turf.

That kind of just-in-time cross-cutting collaboration and decisionmaking needs to be a behavioral norm. It needs to be the natural response of everyone involved, especially those in leadership roles. People need to be focused on the end-to-end flow of activities that deliver the various products—not just on their job function.

We also need to focus on end-to-end performance, and use metrics such as lead time, cycle time, and quality as our primary indicators of our performance. Forget utilization; forget productivity. The market does not care. (More on that in a moment.) Focus on how fast you get the product out and how good the product actually is, and everything else will take care of itself.

Another thing to realize is that you have internal products—things that are used in many separate customer-facing products. (See the figure.) The shared microservice is an example of that. Those internal products need to be maintained well, as if they were customer facing. Otherwise, they will be a chronic source of trouble that affects multiple customer-facing products.

“We Know How to Talk Things Through Well”

To achieve rapid identification and resolution of cross-cutting issues requires behavioral changes at multiple levels, but the one I want to call attention to here is the attitude about what is relevant to each of us. Instead of saying “that’s tech, so I don’t need to know that” or “that’s about the customer and I am in tech, so I don’t need to know that”, we all need to be interested in every issue along the value delivery stream.

One must have a non-competitive internal culture in which people know the basics of every aspect of their products and how those products are built.

How can you have cross-cutting discussions about things, with a focus on the entire end-to-end flow, unless you understand every step in that flow?

That does not mean that we all need to be experts in everything; but we need to know enough so that we can have intelligent conversations with experts about all issues.

Being able to identify issues as soon as they arise, assemble just the right people, efficiently collaborate about those issues in a productive manner, and then reach a timely decision is crucial. It requires a non-competitive internal culture and it requires that people know the basics of every aspect of their products and how those products are built.

It means that the skills and behaviors needed for effective discussion of complex issues are natural and deeply internalized. In short, people need to know how to have effective dialectic discussions and must be accustomed to balancing their respective interests for the best overall outcome.

“We Treat Change as Normal”

The more complex that products are, the more frequently changes are needed in the course of development. In an internally competitive culture, one’s internal adversaries will use every change of direction that you make as a mistake and as a way to gain standing at your expense. Thus, for complex products one will have countless opportunities to be criticized for mistakes and lose standing.

The result of that is that people will become very risk averse—and yet for complex cutting-edge products exactly the opposite behavior is needed. People need to push the envelope and make decisions without being certain. That requires a culture in which people are not internally competitive, but instead everyone is focused on the organization’s overall success.

Thoughtful change needs to be seen as routine and part of the endeavor of creating new and sophisticated products. People need to view the failure of prototypes as par for the course in the natural path of a product that eventually becomes a great success.

SpaceX has a rule that if they are 51% certain that a choice is correct, then that is good enough to move forward. They then build based on that approach, and try it to see what happens. And when it fails, as it often does, they measure and adjust and redesign and try again. And again. And again. And after it finally works, they keep measuring, and adjusting, refining, and improving.

The key is to find the right balance between the cost in time, effort, and materials of a failed trial and the benefits of what you learn from that trial.

The key is to find the right balance between the cost in time, effort, the materials of a failed trial, and the benefits of what you learn from that trial, and also recognizing that trying things when you are partially certain is often a lot faster than designing them to be completely perfect. Speed of development is their goal—not efficiency.

If you have development partners, then instead of trying to precisely define their requirements, instead treat them as true partners, and trade requirements back and forth in the interest of the overall objective. Actively manage the flow: don’t sit back and manage by administering reports and numbers. Instead, manage issues. And make them put some of their own funds at risk, so that they are in it to succeed—not just to bill you.

For example, if one contractor is having trouble meeting a requirement, visit their lab. Talk to their experts. See if another contractor can adjust things to make up for the shortfall, so that the overall system achieves its goal. Don’t “hold their feet to the fire” on a low-level requirement. The ultimate best integrated solution is often not exactly how you defined all the pieces: allow the pieces to evolve toward the best overall solution. And don’t mire the change process in paperwork and approvals.

“We Are More Concerned With Effectiveness than Efficiency”

This is a big one.

Earlier I said to forget utilization and forget productivity, because the market does not care.

Organizations traditionally obsessed over efficiency metrics like utilization. The theory was that if every element of a process is maximally efficient, then the whole will be as efficient as possible.

Except that if you are competing based on quality or the effectiveness of your product, efficiency is not the goal. The goal is usually market share, and showing that your product is the best. Of course if your business is a commodity, then yes, efficiency is paramount. But if you differentiate your product based on its ability to help someone get their job done, then your efficiency needs to take a back seat to the customer’s results. And if you can’t do that and be profitable, then you are in the wrong business.

Trying to be efficient on a task level or item level basis incentivizes locking in all detail-level requirements, which is not in the best interests of the overall system’s performance. Requirements need to be allowed to change easily and fluidly, always with maximum system performance in mind.

Here is an example from the IT domain: Suppose that one has software being built and one is measuring the utilization of all of the development staff: that is, whether they are all busy all the time. Now suppose that someone figures out how to automate some of the testing. The result is that some of the testers can shift to the task of writing automated tests. Their utilization might drop slightly, due to the fact that they are sometimes waiting for test specs. However, the software can now be tested many times a day, due to the automation. Quality improves dramatically, and the time to release new features is reduced significantly, but staff utilization has dropped. Which would you prefer? Higher utilization or higher quality and shorter lead time for new features?

If you are building something that is a commodity, you might prefer higher utilization: your focus would be on the overall ROI of your product. But if you are in a cutting edge market where people choose based on quality or effectiveness of the product, then today’s cost does not matter as long as you are profitable: what matters is market share and growth.

The Confounding Role of Agile

Digital transformation is when the members of the organization shift their viewpoints to the above new perspectives so that they can take full advantage of the incredible flexibility of digital technologies. People must change their behaviors to work in these new ways. It requires that these changes occur throughout, constituting a cultural shift within the organization.

It is not just a matter of defining new processes and procedures. For people to behave this way, they have to operate in a supportive climate that incentivizes cooperation rather than internal competitiveness.

Digital transformation is ultimately an agility transformation. It means using the flexibility, speed, and extensibility of digital technologies to continuously and nimbly invent and fine-tune products so that you can lead in your markets.

Unfortunately, the approaches to “agile transformation” that are most commonly advocated by self-proclaimed experts in “Agile” often fail to deliver the promised agility, let alone market leadership. The creators and proponents of those methods will never blame their methods, but instead will tell you that “you did it it wrong” when in fact their core ideas are wrong, and the “Agile industrial complex” that consists of trainers and consultancies represents a huge amount of dysfunction.

That is why it is essential to select agility consultants whose approaches are informed by research and validated theories in behavioral science (for how people work well with others), leadership theory (for what kinds of leadership are effective in different situations), cognitive science (for how people collaborate, think, and create), organizational culture (for understanding how ideas and behaviors persist but can change in an organization), operations research (for understanding Lean flow), and other fields, rather than cooking up a framework and then hawking training for it, or—even worse—hawking amateur consultants who are merely certified in someone else’s framework as if that is a credential for competency, which is what some large consultancies often do.

What you need instead is true business+tech agility consultants who have deep and broad experience, including having had P&L accountability, product development experience, leadership experience, ideally some sales experience so that they understand the revenue generation perspective, and who also have a conceptual foundation in leadership theory, organizational change, and the technical aspects so that they know the vocabulary and tradeoffs in today’s tech platforms. You need real experts—not “Agile coaches” who merely attended a training seminar in some cockeyed “Agile” framework.

Conclusion

A digital transformation is more than a shift in one’s methods. It is a shift in behavior and organizational culture—as well as one’s methods. It is the same order of shift for an organization as occurs at a personal level when you realize that the ways of your youth will not serve you in your adult professional life: you must not only change what you do, but how you do it, how you perceive yourself, and how you react to the world.

It really is that deep a change. It has to be, because the world has changed. Technology has become as important as business relationships and market position, perhaps moreso. Product issues are so intertwined that decisionmakers cannot compartmentalize themselves—they have to participate in decisionmaking that considers the entire value delivery stream. And things move at a pace that would make yesterday’s executives’ head spin.

It is not a process change. It is not a new set of rules. Digital is a new way of being.

Clifford Berg