Use Internal Channels

There’s a little wizardry to communicating strategy. First, it must be compressible. But you already did that when you established your vision and strategy (see “Establishing a Vision and Strategy”...right? Next, you push it through all the mediums and channels at your disposal to tell people over and over again. Chances are, you have “town hall” meetings, email lists, and team meetings up and down your organization. Recording videos and podcasts of you explaining the vision and strategy is helpful. Include strategy overviews in your public speaking because staff often scrutinizes these recordings. Even though “Enterprise 2.0” fizzled out several years ago, Facebook has trained us all to follow activity streams and other social flotsam. Use those habits and the internal channels that you have to spread your communication.

Show Your Strategy in Action

You also need to include examples of the strategy in action: what worked and what didn’t work. As with any type of persuasion, getting people’s peers to tell their stories are the best. Google and others find that celebrating failure with company-wide post mortems is instructive, career-ending crazy as that might sound. Stories of success and failure are valuable because you can draw a direct line between high-level vision to fingers on keyboard. If you’re afraid of sharing too much failure, try just opening up status metrics to staff. Leadership usually underestimates the value of organization-wide information radiators, but staff usually wants that information to stop prairie dogging through their 9 to 5.²

Gather Feedback

As you’re progressing, getting feedback is key: do people understand it? Do people know what to do to help? If not, it’s time to tune your messages and mediums. Again, you can apply a small batch process to test out new methods of communicating. Although I find them tedious, staff surveys help: ask people whether they understand your strategy. Be sure to also ask whether they know how to help execute the strategy.

Create a Manifesto

Manifestos can help decompose a strategy into tangible goals and tactics. The insurance industry is on the cusp of a turbulent competitive landscape. To call it “disruptive” would be too narrow. To pick one sea of chop, autonomous vehicles are “changing everything about our personal auto line and we have to change ourselves,” says Liberty Mutual’s Chris Bartlow. New technologies are only one of many fronts in Liberty’s new competitive landscape. All existing insurance companies and cut-throat competitors like Amazon are using new technologies to optimize existing business models and introduce new ones.

“We have to think about what that’s going to mean to our products and services as we move forward,” Bartlow says. Getting there required reengineering Liberty’s software capabilities. Like most insurance companies, mainframes and monoliths drove its success over past decades. That approach worked in calmer times, but now Liberty is refocusing its software capability around innovation more than optimization. Liberty is using a stripped-down set of three goals to make this urgency and vision tangible.

“The idea was to really change how we’re developing software. To make that real for people we identified these bold, audacious moves, or ‘BAMS,’” says Liberty Mutual’s John Heveran:

• 60% of computing workloads to the cloud

• 75% of technology staff writing code

• 50% of code releasing to production in a day

These BAMs grounded Liberty’s strategy, giving staff very tangible, if audacious, goals. With these in mind, staff could begin thinking about how they’d achieve those goals. This kind of manifesto makes strategy actionable.

So far, it’s working. “We’re just about across the chasm on our DevOps and CI/CD journey,” says Liberty’s Miranda LeBlanc. “I can say that because we’re doing about 2,500 daily builds, with over 1,000 production deployments per day,” she adds. These numbers are tracers of putting a small-batch process in place that’s used to improve the business. They now support around 10,000 internal users at Liberty and are better provisioned for the long ship ride into insurance’s future.

Choosing the right language is important for managing IT transformation. For example, most change leaders suggest dumping the term “Agile.” At this point, near 25 years into “Agile,” everyone feels like they’re Agile experts. Whether that’s true is irrelevant. You’ll faceplam your way through transformation if you’re pitching switching to a methodology people believe they’ve long mastered.

It’s better to pick your own branding for this new methodology. If it works, steal the buzzwords du jour, such as “cloud native”, DevOps, or serverless. Creating your own brand is even better. As we discuss later, Allstate created a new name, CompoZed Labs, for its transformation effort. Using your own language and branding can help bring smug staff onboard and involved. “Oh, we’ve always done that, we just didn’t call it ‘Agile,’” sticks-in-the-mud are fond of saying as they go off to update their Gantt charts.

Make sure people understand why they’re going through all of this “digital transformation.” And make even more sure that they know how to implement the vision and strategy, or, as you start thinking, our strategy.

The Business Case

When you’re pitching a new idea, you need to show that the costs and benefits will be worth it, that it will be profitable and fit within budget. For innovation-driven businesses, “budget” can be nebulous. Often, there’s no exact budget specified, and the business case builds a rationale for how much money is needed. At the very least, it’s often good to ask for more, backed up with proof that it might be a good idea.

A digital transformation business case is a tool for getting cash, but also a tool for discovering the work to be done and educating the organization about the goals of transformation.

First, you want to show all the costs involved: staff salary, cloud hosting costs or private cloud build-out expenses, training and consulting, changes to facilities and other capital expenses like laptops and chairs, and even snacks for all those ping pong balls and foosball tournaments. This is the baseline; the “before” set of numbers.

The second set of numbers you create are savings estimates. These estimates are based on the expected productivity gains you’ll realize by improving staff productivity, replacing aged platforms and middleware, reducing time spent fixing bugs and addressing security issues, and the overall reduction of waste in your organization.

Where do these estimates come from, though?

• You can use industry norms for improvement, although finding trustworthy ones can be difficult. Every vendor and proponent of “The New Way” will have numbers at the ready; but they, of course, are biased to prove that their solution results in the best numbers. With that vendor disclaimer in your mind, you could start with a Forrester study that Pivotal commissioned to baseline before and after improvements.

There are the costs of software licensing (or “subscriptions,” to be technically correct, in most cases now) for platforms and tools as well as infrastructure costs. Some of these costs might seem high on their own, but compared to maintenance costs of older systems and lacking the savings from staff productivity, these new costs usually turn out to be worth it.

You need to account for the costs of transformation. This will be variable but should include things like training, consulting, initial services needed, and even facility changes.

With these numbers you have a comparison between doing nothing new and transforming. If the traditional way is cheaper, perhaps it’s more efficient and you should not actually change. But, it must be cheaper and get you the productivity, time to market, and software design improvements, as well, not just be cheaper than improving. More than likely, your transformation case will be better.

If you’re lucky enough to have business revenue projections, you can show how you contribute to revenue generation. Additionally, you should try to model some of the less tangible benefits. For example, because you’ll be delivering software faster and more frequently, your time-to-market will decrease. This means that your organization could begin earning money sooner, affecting time-based budgeting calculations like net present value (NPV) and cash flows.

The small-batch feedback loop, which quickly corrects for incorrect requirements, will improve your risk profile. Delivering weekly also means that you’ll begin putting value on the balance sheet sooner rather than, for example, delivering by batch in an annual release. These “value soon, not later” effects might be useful, for example, when comparing internal rate of return (IRR) calculations to other options: your budget might be higher, but it could be less risky than even lower budgeted programs.

There are many other fun and baroque budgeting dances to do with Agile-driven software. For example, you could do real options analysis to put a dollar figure around the agility you’ll gain. If you have the time and interest from finance to do such things, go ahead. For your initial business cases, however, that’ll likely be too much work for the payoff. The business case on sophisticated business cases is often poor.

The Ongoing Business Case

As soon as you get rolling, your ongoing business case will adjust, sometimes dramatically and sometimes just incrementally. Organizations often change how they do budgets—hopefully not every year. But new executives, boards, and regulations might require new budget models. A private equity firm will have different expectations than the public markets, both of which will be much different than operating in startup mode.

In addition to creating high-quality and well-designed software, when calibrated over several months, the small-batch process should result in more stability and predictability. A calibrated product team knows how many stories it can release each week and is familiar with its ongoing costs. As you create more product teams by slowly scaling up your product-centric approach, you’ll see similar calibrations which should, hopefully, be similar to the first few baselines.

This calibration can then be applied back to the budget to test the original assumptions behind the business case. Just as you can verify your theories about features with a small-batch approach, improving the software week to week, you can test your budgeting assumptions and correct them.

This means that feedback from each small-batch budgeting cycle adds more knowledge and gives finance more control. For finance, this is hopefully appealing because it adds more discipline into budgeting and addresses one of the primary responsibilities of the CFO: to ensure that money is spent wisely and responsibly. Even better, it puts a reliable process in place that ensures that money is well spent.

From the CFO’s perspective, a small-batch budgeting will be a refreshing take on traditional IT budgets. Rather than wrangling over a large sum of money and then being given just one chance per year to course correct, the CFO will have more accurate estimates, transparency throughout the process, and the ability to adjust budgets up or down throughout the year.

Finance teams can also use these new controls to stop projects that are obviously failing, reducing losses and reallocating unspent budget to new programs. This might seem bad for you—the one getting less budget—which arguably it is if you work at a company that punishes such failure. But don’t worry! There are always new organizations eager to hire ambitious, innovative people like yourself!

Gated Funding as a Defensive Tactic

Most people don’t like living with “gated funding.” This means that you’re not given a lump annual sum, but instead have to prove yourself many times during the course of the year. That lump sum might be allocated, at least in a spreadsheet, but you’re running the risk of not making it through the gates and increasing your chances of suffering from budget cuts.

But gated funding is often advantageous at first. In fact, it better matches the spirit of a small batch process. First, it’s easier to get the cash for just one or two teams to try out your transformation program. In the context of the entire corporate budget, the amount needed is likely a “rounding error,” allowing you to start the process of scaling up with a series of small projects and building up trust.

Rather than asking for a giant, multiyear bundle, asking for less might actually yield success—and that bigger budget—sooner. As Allstate’s Opal Perry explains, “By the time you got permission, ideas died.” But with a start-small approach, she contrasts, “A senior manager has $50,000 or $100,000 to do a minimum viable product,” allowing them to get started sooner and prove out the new approach.

You still need to prove that the new methods work, of course. This is why, as discussed elsewhere, it’s important to pick a small series of products to build up success and win over organizational trust with internal marketing.

Jon Osborn came across a second tactical benefit of gated funding: holding executive sappers at bay. Annual budgeting is a zero-sum game: there’s a fixed pool of cash to allocate.⁸ In the annual squabble for budgeting, most of your peers view your budget wins as budget they lost. Rolling over a bit by accepting gated funding can help muzzle some of your opponents in the budgeting dog fight.

Gardening the Organization

I like to think of the work EAs do as “gardening” the overall organization. This contrasts with the more top-down idea of defining and governing the organization, down to technologies and frameworks used by each team. Let’s look at some of an EAs gardening tasks.

The Shifting yet Never-Changing Role of the EA

I’ve highlighted just three areas EA contribute to in a cloud-native organization. There are more, many of which will depend on the peccadilloes of your organization; for example:

• Identifying and solving sticky cultural change issues is one such situational topic. EAs will often know individuals’ histories and motivations, giving them insight into how to deal with grumps that want to stall change.

• EA groups are well positioned to track, test, and recommend new technologies and methodologies. This can become an “enterprise astronaut” task of being too far afield of actual needs and not understanding what teams need day to day, of course. But, coupled with being a product manager for the organization’s platform, scouting out new technologies can be grounded in reality.

• EAs are well positioned to negotiate with external stakeholders and blockers. For example, as covered later, auditors often end up liking the new, small-batch and platform-driven approach to software because it affords more control and consistency. Someone needs to work with the auditors to demonstrate this and be prepared to attend endless meetings for which product team members are ill suited and ill tempered.

What I’ve found is that EAs do what they’ve always done. But, as with other roles, EAs are now equipped with better process and technology to do their jobs. They don’t need to be forever struggling eyes in the sky and can actually get to the job of designing, refactoring, and programming the enterprise architecture. Done well, this architecture becomes a key asset for the organization—often the key asset of IT.

Though he poses it in terms of the CIO’s responsibility, Mark Schwartz describes the goals of EAs well:

The CIO is the enterprise architect and arbitrates the quality of the IT systems in the sense that they promote agility in the future. The systems could be filled with technical debt but, at any given moment, the sum of all the IT systems is an asset and has value in what it enables the company to do in the future. The value is not just in the architecture but also in the people and the processes. It’s an intangible asset that determines the company’s future revenues and costs and the CIO is responsible for ensuring the performance of that asset in the future.

Hopefully the idea of designing and then actually creating and gardening that enterprise asset is attractive to EAs. In most cases, it is. Like all technical people, they pine for the days when they actually wrote software. This is their chance to get back to it.

Choosing Projects

Picking the right projects to begin with is key. Here are some key characteristics:

• They should be material to the business, but low risk.

• They should be small enough that you can quickly show success in the order of months.

• They need to be technically feasible for using cloud technologies.

These shouldn’t be science projects or automation of low-value office activities—no augmented reality experiments or conference room schedulers (unless those are core to your business). On the other hand, you don’t want to do something too big, like move the .com site. Christopher Tretina recounts Comcast’s initial cloud native ambitions:

We started out with a very grandiose vision... And it didn’t take us too long to realize we had bitten off a little more than we could chew. So around mid-year, last year, we pivoted and really tried to hone in and focus on what were just the main services we wanted to deploy that’ll get us the most benefit.

Your initial projects should also enable you to test out the entire software life cycle—all the way from conception to coding to deployment to running in production. Learning is a key goal of these initial projects, and you’ll do that only by going through the full cycle.

The Home Depot’s Anthony McCulley describes the applications his company chose in the first six or so months of its cloud-native roll-out. “They were real apps. I would just say that they were just, sort of, scoped in such a way that if there was something wrong, it wouldn’t impact an entire business line.” In the Home Depot’s case, the applications were projects like managing (and charging for!) late tool rental returns and running the in-store, custom paint desk.

Picking Projects by Portfolio Pondering

There are several ways to select your initial projects. Many Pivotal customers use a method perfected over the past 25 years by Pivotal Labs called discovery. In the abstract, it follows the usual Boston Consulting Group (BCG) matrix approach, flavored with some Eisenhower matrix. This method builds in intentional scrappiness to do a portfolio analysis with the limited time you can secure from all of the stakeholders. The goal is to get a ranked list of projects based on your organization’s priorities and the easiness of the projects.

First, gather all of the relevant stakeholders. This should include a mix of people from the business and IT sides as well as the actual team that will be doing the initial projects. A discovery session is typically led by a facilitator, preferably someone familiar with coaxing a room through this process.

The facilitator typically hands out stacks of sticky notes and markers, asking everyone to write down projects that they think are valuable. What “valuable” means will depend on each stakeholder. We’d hope that the more business minded of them would have a list of corporate initiatives and goals in their heads (or a more formal one they brought to the meeting). One approach used in Lean methodology is to ask management this question: “If we could do one thing better, what would it be?”¹⁰ Start from there, maybe with some five-whys spelunking.

After the stakeholders have listed projects on their sticky notes, the discovery process facilitator draws or tapes up a 2×2 matrix that looks like the one shown in Figure 2-2.

Participants then place their sticky notes in one of the quadrants; they’re not allowed to weasel out and put the notes on the lines. When everyone finishes, you get a good sense of projects that all stakeholders think are important, sorted by the criteria I mentioned, primarily that they’re material to the business (important) and low risk (easy). If all of the notes are clustered in one quadrant (usually, in the upper right, of course), the facilitator will redo the 2x2 lines to just that quadrant, forcing the decision of narrowing down to just projects to do now. The process might repeat itself over several rounds. To enforce project ranking, you might also use techniques like dot voting, which will force the participants to really think about how they would prioritize the projects, given limited resources.

Figure 2-2. A 2x2 decision-making matrix that can help you to sort through your portfolio when choosing projects.

At the end, you should have a list of projects, ranked by the consensus of the stakeholders in the room.¹¹

Planning Out the Initial Project

You might want to refine your list even more, but to get moving, pick the top project and start breaking down what to do next. How you proceed to do this is highly dependent on how your product teams breaks down tasks into stories,¹² iterations, and releases. More than likely, following the general idea of a small-batch process, you’ll do the following:

1. Create an understanding of the user(s) and the challenges they’re trying to solve with your software through personas and approaches like scenarios or Jobs to be Done.

2. Come up with several theories for how those problems could be solved.

3. Distill the work to code and test your theories into stories.

4. Add in more stories for nonfunctional requirements (like setting up build processes, CI/CD pipelines, testing automation, etc.).

5. Arrange stories into iteration-sized chunks without planning too far ahead (lest you’re not able to adapt your work to the user experience and productivity findings from each iteration).

Starting small ensures steady learning and helps to contain the risk of a fail-fast approach. But as you learn the cloud-native approach better and build up a series of successful projects, you should expect to ramp up quickly. Figure 2-3 shows the Home Depot’s ramp up in the first year.

The chart measures application instances in Pivotal Cloud Foundry, which does not map exactly to a single application. As of December 2016, the Home Depot had roughly 130 applications deployed in Pivotal Cloud Foundry. What’s important is the general shape and acceleration of the curve. By starting small, with real applications, the Home Depot gained experience with the new process and at the same time delivered meaningful results that helped it scale its transformation.

Figure 2-3. This chart shows the number of application instances, which is not 1:1 to applications. The end point represents about 130 applications, composed of about 900 services. (Sources: “From 0 to 1000 Apps: The First Year of Cloud Foundry at The Home Depot,” Anthony McCulley, The Home Depot, Aug 2016. “Cloud Native at The Home Depot, with Tony McCulley,” Pivotal Conversations #45.)

Volunteers

When possible, recruiting volunteers is the best option for your initial projects, probably for the first year. Forcing people to change how they work is a recipe for failure, especially at first. You’ll need motivated people who are interested in change or, at least, will go along with it instead of resisting it.

Osborn describes this tactic at Great American Insurance Company:

We used the volunteer model because we wanted excited people who wanted to change, who wanted to be there, and who wanted to do it. I was lucky that we could get people from all over the IT organization, operations included, on the team...it was a fantastic success for us.

This might be difficult at first, but as a leader of change, you need to start finding and cultivating these change-ready volunteers. Again, you don’t necessarily want rockstars so much as open-minded people who enjoy trying new things.

Sadly, some of your staff won’t make the transition. You can often find ways of motivating them to get genuinely excited, but some people resist change to the end. Over the years, executives I’ve talked with say that anywhere between 30 to 70% of staff will fall into this well of obstinacy. “You will lose people, not everybody’s gonna be on board,” Dick’s Sporting Good’s Jason Williams says. “You will have some attrition but one of the key things that’s happened to us recently, we’ve actually had engineers that have come back to us and rejoined our organization because they like the way we’re going.”

Of course, this problem isn’t confined to staff. Management and leadership can be just as resistant, as discussed in “Communicating the Vision and Strategy”.

Rotating Teams to Spread Digital Transformation

Few organizations have the time or budget-will to train their staff. Management seems to think that a moist bedding of O’Reilly books in a developer’s dark room will suddenly pop up genius skills like mushrooms. Rotating pairing in product teams addresses this problem in a minimally viable way within a team: team members learn from one another on a daily basis. Event better, staff is actually producing value as they learn instead of sitting in a neon-light buzzing conference room working on dummy applications.

To scale this change, you can selectively rotate staff out of a well-functioning team into newer teams. This seeds their expertise through the organization, and when you repeat this over and over, knowledge will spread faster. One person will work with another, becoming two skilled people, who each work with another person, become four skilled people, and then eight, and so on. Organizations like Synchrony go so far as the randomly shuffle desks every six months to ensure that people are moving around. Discover has institutionalized this practice with a dedicated group that works with a new team for six weeks to experience the new culture, sending them back into the organization to seed those new skills.

More than just skill transfer and on-the-job training, rotating other staff through your organization will help spread trust in the new process. People tend to trust their peers more than leaders throwing down change from high, and much more than external “consultants” and, worse, vendor shills like myself. As ever, building this trust through the organization is key to scaling change.

Orange France is one of the many examples of this strategy in practice. After the initial success revitalizing its server message block (SMB) customer service app, Orange began rotating developers to new teams. Developers who worked on the new mobile application pair with Orange developers from other teams, the website team. As ever with pairing, they both teach their peers how to apply Agile and improve the business with better software at the same time. Talking about his experience with rotating pairing, Orange’s Xavier Perret says that “it enabled more creativity in the end. Because then you have different angles, [a] different point of view. As staff work on new parts of the system, they get to know the big picture better and engage in in “more creative problem solving” to each new challenge, Perret adds.

Even though you might start with ninjas, you can take a cadre of volunteers and slowly but surely build up a squad of effective staff that can spread transformation throughout your organization. All with less throwing stars and trashed hotel rooms than those 10x rockstars leave in their wake.

A Note on Labs and Legacy Organizations

At this point, you might be thinking that changing a large, existing organization sounds difficult. Well, it is! People and processes are in place, and often no one wants to change themselves or revise those processes. To get around this, many organizations create new groups, usually called “labs.” Product by product, and team by team, new software and people are moved to the new group. Volunteers are accepted in the initial stages (remember: team composition matters), and only favorable products are picked. As news of teams’ successes spreads, this new organization is given corporate permission to take on new products and reluctant staff are more trusting that changing their work habits is a good idea.

The existing—now “legacy”—organization continues to operate as needed, but projects and people are slowly moved to the new organization. Service dependencies from new to old are mediated and hidden behind APIs and facades, trying to decouple the two into a sort of reverse-quarantine: the old organization is blocked off from infecting the new group.

The new organization follows all the new-fangled notions and norms, from the pedestrian practice of free lunches and massages to paired programming to fully automated build pipelines—all enabling the magic of small batches that result in better software.

Synchrony Financial, for example, used this approach to shift from a functional to a product organization. The trick here is to begin with a blank slate across the board, including organization structure, governance, culture, and tools used. Getting to that point takes high-level support; in Synchrony’s case, support came directly from the CEO. You don’t always need that high a level of support, but if things go well, it can be easier to climb up the authority ladder to ask for that support. What’s important is to somehow carve out the permission and space for a new organization, no matter how small, and put in place a strategy to grow that organization.

The magic of this method is that it avoids having to unfreeze the glacier, namely, the people who don’t want to work in a new way. Instead of doing the difficult work of changing the old organization, management slowly moves over willing people, reassembling them into new teams and reporting structures. The old organization, though perhaps de-peopled, is left to follow its Waterfall wont.

After some initial success, you might even consider naming and branding the new organization to give the people in it a sense of identity. Allstate did this with its CompoZed Labs, creating a new logo and name. As of 2017, CompoZed was handling 40% of Allstate’s software development, following the new, small-batch approach to software.

The important thing to remember is that even people and processes that seem immutable can be changed. It’s just going to take planning, patience, and finesse.

Beyond Newsletters

After you nail down some initial successful applications, start a program to tell the rest of the organization about these projects. This is beyond the usual email newsletter mention. Instead, your initial content-driven marketing should quickly evolve to internal “summits” with speakers from your organization going over lessons learned and advice for starting new cloud-native projects.

You have to promote your change, educate, and overall “sell” it to people who either don’t care, don’t know, or are resistant. These events can piggyback on whatever monthly “brown-bag” sessions you have and should be recorded for those who can’t attend. Somewhat early on, management should set aside time and budget to have more organized summits. You could, for example, do a half-day event with three to four talks by team members from successful projects, having them walk through the project’s history and provide advice on getting started.

My colleagues and I are often asked to speak at these events, and we of course delight in doing so. However, don’t be too reliant on external speakers: there’s only so much trust a smooth talking, self-deprecating vendor like me can instill in an organization. Make sure you have speakers who work at your company. Fellow employees, especially peers in the career hierarchy, are very powerful agents for change on the dais.

Fostering Trust

This internal marketing works hand in hand with starting small and building up a collection of successful projects. As you’re working on these initial projects, spend time to document the “case studies” of what worked and didn’t work, and track the actual business metrics to demonstrate how the software helped your organization. You don’t so much want to just show how fast you can now move, but you want to show how doing software in this new way is strategic for the business as well as individuals’ compensation, career, reputation, and personal happiness. You know: motivate them.

Content-wise, what’s key in this process is for staff to talk with one another about your organization’s own software, market, and challenges faced. This is a good chance to kick up that Kotterian “sense of urgency,” as well, if you think things have become too languid.

Also, you want to demonstrate that change is possible, despite how intractable people might think the status quo is. I find that organizations often think that they face unique challenges. Each organization does have unique hang-ups and capabilities, so people in those organizations tend to be most interested in how they can apply the wonders of cloud native to their jobs, regardless of whatever success they might hear about at conferences or, worse, vendors with an obvious bias (that would be me!). Hearing from one another often passes beyond this sentiment that “change can’t happen here.”

After your organization begins hearing about these successes, you’ll be able to break down some of the objections that stop the spread of positive change. As Amy Patton at SPS Commerce put it, “Having enough wins, like that, really helped us to keep the momentum going while we were having a culture change like DevOps.”

Winning Over Process Stakeholders

The IRS provides an example of using release meetings to slowly win over resistant middle-management staff and stakeholders. Stakeholders felt uncomfortable letting their usually detailed requirements evolve over each iteration. As with most people who are forced—er, “encouraged—to move from Waterfall to Agile, they were skeptical that the final software would have all the features they initially wanted.

While the team was, of course, verifying these evolving requirements with actual, in-production user testing, stakeholders were uncomfortable. These skeptics were used to comforting, thick upfront analysis and requirements, exactly spelling out which features would be implemented. To begin getting over this skepticism, the team used its release meetings to show off how well the process was working, demonstrating working code and lessons learned along the way. These meetings went from five skeptics to packed, standing-room-only meetings with more than 45 attendees. As success was built up and the organizational grapevine filled with tales of wins, interest grew as well as trust in the new system.

The Next Step: Training by Doing

As the organizations I’ve mentioned earlier and others like Verizon and Target demonstrate, internal marketing must be done “in the small,” like this IRS case and, eventually, “in the large” with internal summits.

Scaling up from marketing activities is often done with intensive, hands-on training workshops called dojos. These are highly structured, guided, but real release cycles that give participants the chance to learn the technologies and styles of development. And because they’re working on actual software, you’re delivering business value along the way: it’s training and doing.

These sessions also enable the organization to learn the new pace and patterns of cloud-native development, as well as set management expectations. As Verizon’s Ross Clanton put it recently:

The purpose of the dojo is learning, and we prioritize that over everything else. That means you have to slow down to speed up. Over the six weeks, they will not speed up. But they will get faster as an outcome of the process.

Scaling up any change to a large organization is mostly done by winning over the trust of people in that organization, from individual contributors, to middle-management, to leadership. Because IT has been so untrustworthy for so many decades—how often are projects not only late and over budget, but then anemic and lame when finally delivered?—the best way to win over that trust is to actually learn by doing and then market that success relentlessly.

Monitoring

In IT, most of the metrics you encounter are not actually business oriented and instead tell you about the health of your various IT systems and processes: how many nodes are left in a cluster, how much network traffic customers are bringing in, how many open bugs development has, or how many open tickets the help desk is dealing with on average.

All of these metrics can be valuable, just as all of them can be worthless in any given context. Most of these technical metrics, coupled with ample logs, are needed to diagnose problems as they come and go. In recent years, there have been many advances in end-to-end tracing thanks to tools like Zipkin and Spring Sleuth. Log management is well into its newest wave of improvements, and monitoring and IT management analytics are just ascending another cycle of innovation—they call it “observability” now; that way, you know it’s different this time!

Instead of looking at all of these technical metrics,¹⁴ I want to look at a few common metrics that come up over and over again in organizations that are improving their software capabilities.

Six Common Cloud-Native Metrics

Certain metrics come up consistently when measuring cloud-native organizations. Let’s take a look at each of them.

Lead time

Lead time is how long it takes to go from an idea to running code in production; it measures how long your small-batch loop takes. It includes everything in between, from specifying the idea, writing the code and testing it, passing any governance and compliance needs, planning for deployment and management, to getting it up and running in production, as shown in Figure 2-4.

Figure 2-4. This diagram shows the elements that you need to consider when calculating lead time.

If your lead time is consistent enough, you have a grip on IT’s capability to help the business by creating and deploying new software and features. As such, you want to monitor your lead closely. Ideally, it should be a week. Some organizations go longer, up to two weeks, and some are even shorter, like daily. Target and then track an interval that makes sense for you. If you see your lead time growing, you should stop everything, find the bottlenecks, and fix them. If the bottlenecks can’t be fixed, you probably need to do less each release.

Value-stream mapping is a common tool for measuring lead time. A value-stream map shows all of the activities needed, from thinking of a new feature to a person using that feature. Functional organizations often focus on just one group’s contribution to that overall task, which too often leads to locally optimizing each part of the value stream instead of the whole.

A value-stream map will also help you find wasted time in your release cycle, helping you to reduce lead time. “Waste” can be vague, but in general anything that the end user doesn’t value or care about is waste. You can’t always get rid of waste, but you should try to remove as much as possible. For example, using a value-stream map, one of Daimler’s product teams identified time spent ordering, configuring, and deploying servers as waste. People walking into a Mercedes-Benz dealership rarely started the conversation with, “Boy, I want to get a Mercedes because you provision servers so well!” After this was identified, the team prioritized automating this and other waste in its value stream and brought its lead time down from 30 days to 3 days.

Business Value

Of course, none of the metrics so far has measured the most valuable but difficult metric: value delivered. How do you measure your software’s contribution to your organization’s goals? Measuring how the process and tools you use contribute to those goals is usually more difficult.

Somehow, you need to come up with a scheme that shows and tracks how all this cloud-native stuff you’re spending time and money on is helping the business grow. You want to measure value delivered over time to do the following:

• Prove that you’re valuable and should keep living and get more funding.

• Recognize when you’re failing to deliver so that you can fix it.

There are a few prototypes of linking cloud-native activities to business value delivered. Let’s look at a few examples:

• As described in the earlier case study of when the IRS replaced call centers providing limited availability with software, IT delivered clear business value. Latency and error rates decreased dramatically (with phone banks, only 37% of calls made it through) and the design improvements it discovered led to increased usage of the software, pulling people away from the phones. The business value was clear: by the fall of 2017, this application had collected $440 million in back taxes.

• Running existing businesses more efficiently is a popular goal, especially for large organizations. In this case, the value you deliver with cloud native will usually be speeding up businesses’ processes, removing wasted time and effort, and increasing quality. Duke Energy’s line worker case is a good example here. Duke gave line workers a better, highly tuned application that queues and coordinates field work. The software increased line workers’ productivity and reduced waste, directly creating business value in efficiencies.

• The US Air Force’s tanker scheduling case study is another good example here: by improving its software capabilities, the US Air Force was able to ship the first version in 120 days and began saving $100,000’s in fuel costs each week. Accuracy and speed in scheduling delivered clear business value, as well.

• Then, of course, there comes raw competition. This most easily manifests itself as time-to-market, either to match competitors or get new features out before them. Liberty Mutual’s ability to enter the Australian motorcycle market from scratch in only six months is a good example. Others such as Comcast demonstrate competing with major disruptors like Netflix.

It’s easy to become very nuanced and detailed when you’re mapping IT to business value. To avoid spiraling into a nuance vortex, management needs to keep things as simple as possible, or, put another way, only as complex as needed. As with the previous example, clearly link your cloud-native efforts to straight forward business goals. Simply “delivering on our commitment to innovation” isn’t going to cut it. If you’re suffering under vague strategic goals, make them more concrete before you begin using them to measure yourself. On the other end, just lowering costs might be a bad goal to shoot for. I talk with many organizations who used outsourcing to deliver on the strategic goal of lowering costs and now find themselves incapable of creating software at the pace their business needs to compete.

Fleshing Out Metrics

The preceding sections provided a simplistic start at metrics. Each layer of your organization will want to add more detail to get better insights into itself. Creating a comprehensive, umbrella metrics system is impossible, but there are many good templates with which you can start. Platform operators, for example, should probably begin by learning how the Google SRE team measures and manages Google.

Metrics’ Utility

Whatever the case, make sure the metrics you choose are 1) targeting the end goal of putting in place a small-batch process to create better software, 2) reporting on your ongoing improvement toward that goal, and 3) alerting you that you’re slipping and need to begin addressing the problem before it becomes worse.

Metrics are not only useful for day-to-day operations. You can also start using them to demonstrate to the rest of the organization that your transformation strategy is working and can be trusted. Showing, for example, that your team’s velocity is reliable and stable will demonstrate a level of professionalism that’s usually not expected by teams that have historically delivered late and over budget. When it comes time to ask for more budget, reporting on business value delivered will be most helpful.

But First, What Exactly Is “Compliance”?

If you’re a large organization, the chances are that you’ll have a set of regulations with which you need to comply. These are both self- and government-imposed. In software, the point of regulations is often to govern the creation of software, how it’s managed and run in production, and how data is handled. The point of most compliance is risk management; for example, making sure developers deliver what was asked for, making sure they follow protocol for tracking changes and who made them, making sure the code and the infrastructure is secure, and making sure that people’s personal data is not needlessly exposed.¹⁵

Compliance often takes the form of a checklist of controls and verifications that must be passed. Auditors are staff that go through the process of establishing those lists, tracking down their status in your software, and also negotiating whether each control must be followed. The auditors are often involved before and after the process to establish the controls and then verify that they were followed. It’s rare that auditors are involved during the process, which unfortunately ends up creating more wasted time, it turns out. Getting auditors involved after your software has been created requires much compliance archaeology and, sadly, much cutting and pasting between emails and spreadsheets, paired with infinite meeting scheduling.

When you’re looking to transform your software capabilities, these traditional approaches to compliance, however, often end up hurting businesses more than helping them. As Liberty Mutual’s David Ehringer describes it:

The nature of the risk affecting the business is actually quite different: the nature of that risk is, kind of, the business disrupted, the business disappearing, the business not being able to react fast enough and change fast enough. So, this is not to say that some of those things aren’t still important, but the nature of that risk is changing.

Ehringer says that many compliance controls are still important, but there are better ways of handling them without worsening the largest risk: going out of business because innovation was too late.

Avoiding that risk requires tweaking your compliance processes. I’ve seen three approaches to dealing with compliance, often used together as a sort of maturity model: compliance unchained, minimum viable compliance, and transform compliance. Let’s take a look at each.

Compliance Unchained

Although it’s just a quick fix, engineering a way to avoid compliance is a common first approach. Early on, when you’re learning a new mindset for software and build up a series of small successes, you’ll likely work on applications that require little to no compliance. These kinds of applications often contain no customer data, don’t directly drive or modify core processes, or otherwise touch anything that’d need compliance scrutiny.

These might seem disconnected from anything that matters and thus not worth working on. Early on, though, the ability to get moving and prove that change is possible often trumps any business value concerns. You don’t want to eat these “empty calories” projects too much, but it’s better than being killed off at the start.

Minimal Viable Compliance

Part of what makes compliance seem like toil is that many of the controls seem irrelevant. Over the years, compliance builds up like plaque in your steak-loving arteries. The various controls might have made sense at some time—often responding to some crisis that occurred because this new control wasn’t followed. At other times, the controls simply might not be relevant to the way you’re doing software. If that’s the case, you’ll have some work to do to determine and fulfill minimum viable compliance.

Transform Compliance

Although you might be able to avoid compliance or eliminate some controls, regulations are more likely unavoidable. Speeding up the compliance bottleneck, then, requires changing how compliance is done. Thankfully, using a build pipeline and cloud platforms provides a deep set of tools to speed up compliance. Even better, you’ll find cloud-native tools and processes improve the actual quality and accuracy of compliance.

Improving Compliance

Compliance is easier with automation because it is repeatable and I can let the compliance people do self-service. They can stop scheduling meetings to look at information they now have access to.

Jon Osborn, Great American Insurance Company.

The net result of all of these efforts to speed up compliance often improves the quality of compliance itself:

• Understanding and working with auditors gives the product team the chance to write software that more genuinely matches compliance needs.

• The traceability of requirements, authorization, and automated test reports gives auditors much more of the raw materials needed to verify compliance.

• Automating compliance reporting and baking controls into the platform create much more accurate audits and can give so called “controls” actual programmatic control to enforce regulations.

As with any discussion that includes the word “automation,” some people take all of this to mean that auditors are no longer needed. That is, we can get rid of their jobs. This sentiment then gets stacked up into the eternal “they” antipattern: “well, they won’t change, so we can’t improve anything around here.

But, also as with any discussion that includes the word “automation,” things are not so clear. What all of these compliance optimizations point to is how much waste and extra work there is in the current approach to compliance.

This often means auditors working overtime, on the weekend, and over holidays. If you can improve the tools auditors use, you don’t need to get rid of them. Instead, as we can do with previously overworked developers, you end up getting more value out of each auditor and, at the same time, they can go home on time. As with developers, happy auditors mean a happier business.

The Build Pipeline

Your build pipeline is one of your most important software delivery tools. It’s the connection between a developer committing code and adding new functionality to the application in production. Between these two points, the code is built into software, verified with multiple types of tests, checked against audit and security controls, prepared for deployment, and, in some cases, even automatically deployed to production. You’ll likely hear the pipeline referred to as “CI/CD”; that is, continuous integration and continuous delivery.

Getting a build pipeline in place is key. If you don’t have one already—let alone just continuous integration—drop everything and put a pipeline in place. Gary Gruver summarizes how critical a pipeline is in his short, excellent book Start and Scaling Devops in the Enterprise (BookBaby):

[Deployment pipelines] address the biggest opportunity for improvement that does exist in more large traditional organizations which is coordinating the work across teams. In these cases, the working code in the deployment pipeline is the forcing function used to coordinate work and ensure alignment across the organization. If the code from different teams won’t work together or it won’t work in production, the organization is forced to fix those issues immediately before too much code is written that will not work together in a production environment. Addressing these issues early and often in a deployment pipeline is one of the most important things large traditional organizations can and should be doing to improve the effectiveness of their development and deployment processes.

Now, let’s briefly look at each component of a build pipeline.

Continuous deployment

After your release is built, tested, and properly logged for compliance and security checks, you need to somehow get it to production. One of the key insights of DevOps is that the tested, certified build is only half of the work. Releasing to production is the other half, and it’s just as much the team’s responsibility as writing and building the code. You’re not done until your code is running in production.

Here, CD works hand-in-hand with your cloud platform. As illustrated in Figure 2-5, the pipeline takes the packaged build through a series of tests on staging and, ideally, production environments. To do this, the pipeline relies on another DevOps principal: treating infrastructure as code. All of the configuration and processes needed to deploy the release to production are managed as if they were application code: checked into version control, tested, and tracked as they should be, as part of the release.

Your pipeline takes this production configuration and bundles it with the release. It is then ready for your platform’s automated deployment capabilities to do the final release. This entire process should take minutes. Great American Insurance Company, as reported by Jon Osborn, can do pipeline releases in about 10 minutes. Sometimes, the cycle is longer due to complexity or compliance concerns, but it should take less than a day; otherwise, your small-batch process will dramatically slow down.

Figure 2-5. An illustration showing the elements of your build pipeline. (From “Speed Thrills,” Ben Kamysz and Jared Ruckle, Aug 2017.)

With a fully automated build pipeline, the only human fingers involved are in that first commit. The pipeline does everything else. This amount of automation isn’t practical for some organization’s compliance policies. In such cases, that button gets moved down the pipeline. The release pauses right before deploying to production when a human gets the chance to approve the deploy.¹⁷

Properly done, a pipeline will automate the vast majority of the work required to get a build in production, including compliance and security checks. When you can be ready to deploy to production in minutes, you’ll rely on a fully automated cloud platform like Pivotal Cloud Foundry at the end of the pipeline. The two together will have you speeding up your software development life cycle and quickly improving how your organization functions. As Pivotal’s Matthew Parker puts it “[a] team that can’t ship, can’t learn. And the longer you’re not learning, the greater the risk that you’re wasting time and money building the wrong thing.”

You’re Gonna Need a Platform

The amount of automation, standardization, and controls required to deploy on a weekly, let alone daily, basis requires a degree of automation that’s completely foreign, and even fantastical, to most IT organizations. You’ll need a cloud platform to meet those needs. To prove this out, a common first parlor trick is to chart out all of the activities, approvals, and time that it takes to deploy just one line of code to production. Even better, assume that there’s no new code and you’re just deploying the current version from scratch. This is the simplest value-stream map a software-driven organization could make.

In this exercise, you can’t cheat...er, rather, optimize and go against existing policy, bringing in your own infrastructure and SCP’ing a PHP file to a server with some purloined credentials. The goal is to see how long it takes to deploy one line of code following all of the official procedures for starting a new project, getting the necessary infrastructure, doing the proper documentation and policy reviews, and so forth all the way up to running the line of code in production.

The results, as you can imagine, are often shocking. It usually takes at least a month, or even years for some government organizations. Some organizations find that just gathering together all the activities and wait times to put a value-stream map together is interminable.

The ability to deploy code on a small-batch loop requires a platform that takes care of most all of the infrastructure needs—across servers, storage, networking, middleware, and security—removing the time drag associated with provisioning and caring for infrastructure. Gaining the trust of auditors, security experts, and other third-party gatekeepers requires building up trust in a repeatable, standardized stack of software.

It gets worse! These are just the day one problems of getting the first version of your software out the door into production. After that come the day 2+n problems of managing that application in production, updating all your applications weekly, and then updating the platform itself.

Cloud platform reference architecture

When you put together a reference architecture of all of the capabilities needed to support all of the days of your cloud-native life, you quickly realize how much the platform does. Figure 2-6 shows one reference architecture based on conversations my company, Pivotal, has had with organizations executing their cloud-native transformations.

Any good cloud platform has deep capabilities in these five domains (taken directly from the Pivotal whitepaper referenced in Figure 2-6).

Infrastructure

Infrastructure is provided as a service, commonly thought of as IaaS, whether public or private. The platform requests, manipulates, and manages the health of this infrastructure via APIs and programmatic automation on behalf of the developers and their applications. In addition, the platform should provide a consistent way to address these APIs across providers. This ensures that the platform and its applications can be run on and even moved across any provider.

Operations

Metrics and data are the lifeblood of a successful operations team. They provide the insights required to assess the health of the platform and applications running on it. When issues arise, operational systems help troubleshoot the problem. Log files, metrics, alerts, and other types of data guide the day-to-day management of the platform.

Deployment

Deployment tooling enables continuous building, testing, integration, and packaging of both application and platform source code into approved, versioned releases. It provides a consistent and durable means to store build artifacts from these processes. Lastly, it coordinates releasing new versions of applications and services into production in a way that is automated, nondisruptive, and doesn’t create downtime for consumers during the process.

Figure 2-6. An example of what cloud platform reference architecture can look like. (From “The Upside-Down Economics of Building Your Own Platform,” Jared Ruckle, Bryan Friedman, and Matt Walburn, 2018 ed.)

Runtime, middleware, and data

The components of the stack interact with custom code directly. This includes application runtimes and development frameworks, in addition to commercial and open source versions of databases, HTTP proxies, caching, and messaging solutions. Both closed and open source stacks must have highly standardized and automated components. Developers must access these features via self-service, eschewing cumbersome, manual ticketing procedures. These services must also consume API-driven infrastructure, operations tooling for ongoing health assessment, and CD tooling.

Security

The notions of enterprise security compliance and rapid velocity have historically been at odds, but that no longer needs to be the case. The cloud-native era requires their coexistence. Platform security components ensure frictionless access to systems, according to the user’s role in the company. Regulators might require certain security provisions to support specific compliance standards.