Everyone is Busy: Who Has Time to Transform?

Stop me if you’ve heard this one. A company wants to transform to meet the future. The transformation is necessary; without it, they will be threatened by disruptive competitors or unable to serve their customers. But they can’t get started on the transformation because their employees are busy with their day-to-day jobs. Transforming requires effort. It also involves changing processes while simultaneously using those processes to run the business (the problem of “changing the tires while riding the bicycle”). Who will do the work of transformation—learn the new skills, prepare the new cloud environment, change business processes, reorganize the enterprise, or whatever else it is that needs to be done—while they’re busy with the same processes?

Fact: your employees are already busy. They have full-time jobs. They are not sitting around waiting for new tasks. You wouldn’t tolerate it if they were and you wouldn’t be paying so many salaries if employees were underutilized. You also can’t transform just by adding new employees to do the work of transformation. That wouldn’t be transformation—it would be more like creating a new company or business unit. Transformation means changing what already exists.

It follows that you have to find ways to make transformation part of the company’s everyday work. That might seem strange because we keep speaking of transformation as if it were a project with a well-defined start, endpoint, and series of steps. Digital transformation is a squishy term, as I pointed out in an earlier blog post. It helps to realize that digital transformation is a change to the way the company works, and the best way to get there is…to change the way the company works. It’s a change to everyday activities and ways of thinking.

Of course, major technical initiatives are involved (moving to the cloud, for example), but those initiatives are in the service of changing the way the company works. They are best driven by changes to everyday work; the two come together. A framework that I’ve found useful is Gojko Adzic’s Impact Mapping. In his framework, we start from a business objective and map out what behavioral changes will help accomplish that objective. We then figure out what technical changes will support those behavioral changes.

You’ll make the problem worse if you create a detailed five-year transformational roadmap as a project plan separate from daily activities. You’ll spend years getting everyone’s approval, and then there will be no one with free time to execute it.

Admittedly, there’s something a bit outlandish about how I’ve posed this question. I assumed at the beginning that you’ve decided transformation is critical to the company’s future, that the company will be at risk of not meeting its customers’ needs or being disrupted by a new competitor, perhaps a fast-moving startup. So it seems that the company’s employees don’t have enough time to do what is necessary for its survival. There is an obvious prioritization problem here. The company’s survival is the highest priority, so it must be at the top of the list (though see my earlier blog post on the problem with setting priorities). Something else has to go.

Nevertheless, this is what I hear from company leaders; having been a corporate leader, I understand where they are coming from.

Finding Time to Transform

How about reversing the way you think about the problem? Instead of building new technologies and using them to change the way employees work, change the way employees want to work and use that to drive changes to the technology. Here are a few ideas on how you might do so.

First, you must demonstrate commitment to the transformation. It’s not enough to tell employees to transform, write a plan, or make a slide deck. The message must be that transformation is not something extra to be engaged in when there’s spare time. It’s a top priority (a redundant term?): something the company is doing, not something it’s planning. Leaders are willing to make tradeoffs to see it happen.

An AWS customer executive recently told me about a knowledge-sharing community he created to advance their company’s transformation, including weekly sessions for sharing best practices and new knowledge. He held the meetings on Friday afternoons, which seemed wrong to me. It may be a small, but it demonstrated that leadership did not consider it vital. A meeting in prime time on Mondays covering how the new knowledge would be used in the upcoming week would be a stronger signal of its importance. That’s if a “knowledge-sharing” session is helpful at all. To strongly drive a transformation, you need much more “doing” than knowledge sharing.

Next, you must change incentives and role definitions. Since the goal of transformation is behavior change (new ways of working and thinking), you can best advance the transformation by incentivizing new behaviors and using them to drive requirements for technology change. If incentives are not changed, employees will continue doing what they’ve always done. I’m not necessarily talking about financial incentives, just changes in the employee’s job purpose or what success looks like for their role. Under the new incentives, “just doing their job” will lead to failure. To succeed, they’ll need to move along with the transformation vision.

Employees must have a clear sense of where the transformation is headed. A vision of the transformed enterprise’s new state and how it will be different—not a detailed roadmap— is important. The vision should clarify how the future state will better accomplish business goals or the organization’s mission. It can’t be vague or generic because it must paint a clear picture in employees’ minds of what they’re shooting for and why it’s important. Remember, the goal is to have everyone working toward the transformational vision in their everyday activities, not as a side project.

Come to think of it, even calling it “transformation” makes it sound like a separate—and very large—project. And who has time for that? It feels irresponsible to proceed on a major commitment without a detailed roadmap. But the commitment should be to the vision, not the implementation details.

Instead of a long-term roadmap, you might try converting your big transformation effort into a series of business goals, the sum of which is the transformational vision. Maybe the first goal is to remove 20% from the company’s operating cost structure. A second goal might be to roll out a particular business line extension. A third goal might be to build resilience into your operations so you can cope with pandemics and ransomware attacks. These goals are specific and more easily integrated into everyday company activities.

You might worry that breaking things down into individual goals will fragment the transformation and result in a poorly thought-out technical architecture—not so if it’s done with a bit of artistry. The high-level vision will guide it, and the architecture can be molded and refined iteratively.

My role at USCIS involved a huge transformation project. Our initial mistake was to think of it as a monolithic effort; we were going to make all the agency’s paper processes into digital processes. It would have been better to clarify the business outcomes, which were achievable. We knew we wanted to reduce the amount of paper that moved between our offices; that let us prioritize addressing the parts of the business that moved the most paper. We knew we wanted to be better at detecting fraudulent applications; that clarity let us focus on the types of immigration benefits most susceptible to fraud. And so on for our other goals. With this clarity, we tied the transformation to everyday activities rather than going off and building technical infrastructure as a sideline project.

CIOs often ask me how they can find time to remediate legacy technical debt when they are already overloaded with requirements for business functionality. What doesn’t work is to stop all new development and spend years just modernizing systems. The company will not sit still for years. Instead I often recommend continuing the new development work but adopting a very high standard for the delivered work’s quality, including that it be secure, resilient, maintainable, and automatically deployable and testable. To deliver to this standard, any work on legacy systems requires resolving legacy technical debt—but only to the extent that it supports developing new features. The transformational work thus becomes part of the everyday work.

A Few Additional Considerations

Although carving out time for training employees is important, it cannot be the entire strategy for developing new skills. You can’t hold off on transforming until employees have all the right skills; technologists learn best through doing hands-on work and pairing with other technologists to deliver work. Think of new skills as an output of transformation, not a prerequisite.

Organizations sometimes appoint a head of transformation, what we call a single-threaded leader here at AWS. Having someone fully dedicated to transformation in a leadership role can be powerful. But if this person does not have direct management authority over the employees who will conduct the transformation, there is still a problem. How will employees make time for transformational activities? And since transformation requires transforming employees’ jobs, how will the head of transformation cause that change?

Having a single-threaded leader is not at all a bad idea, but it must be combined with commitment across the organization’s leadership so that busy employees become part of the effort. It’s not enough to say that transformation is important, and it’s not enough to communicate its importance by appointing a senior leader with “transformation” in their title. Commitment means making transformation a part of everyone’s daily activities and incentives.

Transforming by incentivizing new behaviors might sound slow, but it isn’t if you do it with determination. It is certain to be faster than if you wait until employees have spare time.

Working Backward and Working Forward

You can’t find time to transform if transformation is too distant from everyday activities. To make it part of everyday activities, change behavior at the same time as you evolve your technology. Employees will spend time accomplishing their assigned goals—whatever they are incentivized to do or told they will be measured against. If their incentives are not changed, there will be no transformation. On the other hand, incentivizing them for the new behaviors you want will engage them in driving the transformation. Sometimes we get things backward!