Chapter 4. The Leadership Bottleneck
Now, let’s take a look at the third bottleneck: leadership. “Leadership” is concerned with the success and sustainability of the organization. These are the people on the hook to meet corporate goals, increase shareholder value, deliver on their agency’s mission, or otherwise do the things the organization exists for. At most companies, this means growing revenue and profit and, at the very least, avoiding losing market share and money.
People in leadership roles, then, usually feel the need to transform the most because they’re intimately familiar with competition, customers, and their organization’s deficiencies. External stakeholders, customers, and armchair analysts constantly point out and ask leadership why the company hasn’t changed already, and point out competitive threats and lost opportunities. Individually, leadership’s compensation is often tied closely with company performance: the more money the company makes, the more their equity will be worth and the more reputation they’ll build up to jump to a new, bigger job.
It sounds like a dashing, bold adventure. Or, if you’re like me, a harrowing, exhausting existence. Fun or frightening, as the people most incented to transform, leadership is often the most powerless to change how people operate.
Leadership actually has a very small toolkit. Leaders can’t go to every single person in their organization and compel them to get better, let alone train and demonstrate how to think about software in a new, product-oriented way. The CIO can’t get really deep in your archaic ticketing system and speed up how servers are automated. Leadership certainly can’t go rewrite that 10-year outsourcing contract that predecessors put in place.
Let’s look at leadership’s tiny toolkit for transformation.
It’s little wonder that the notion of corporate vision is a much laughed-at concept. I’ve seen my share of lame vision statements. So many vision statements follow a basic format: “We endeavor to provide the best products to our customers, a rewarding work environment for our employees, and increasing shareholder returns.” Sometimes, there’s something about contributing back to the community, which is nice.
When you’re seeking to transform your organization to be more software-driven, your vision statement should be a tool, something the organization can come back to for direction in ambiguous situations. Your product teams will be working in ambiguous situations daily, needing to theorize solutions to problems, interpret how people are using their software, and decide what to do next according to business needs. They won’t have time to ask permission to make these changes, let alone set up meetings to get approval and “input” from senior management.
One of my favorite vision statements is from the Singapore bank DBS, as put by Siew Choo Soh:
We believe that we need to reimagine banking to make banking simple, seamless, as well as invisible to allow our customers to live more bank less.
Their vision can be even shorter: “live more, bank less.” What this means is that DBS’s customers (or the customer of any bank!) don’t want to spend time with their bank. When I finish writing this section, I’m not going to log in to my banking app, scroll through some recent transactions, and just sort of hang out with my bank for a good time. In fact, doing so is the opposite of a calming experience! I don’t want to chill with my bank, I want to go live my life.
DBS’s vision is a practical tool to guide staff’s day-to-day decisions. If there’s any doubt about how to implement a feature or how to run the business, employees can ask “will this let out customers spend less time worrying about banking?” In software design and product management, this means focusing on user productivity and simplicity. For example, enabling TouchID to log in instead of using a username and password, identifying recurring payments that people might want to cancel, or allowing customers to add accounts from other banks to get a quicker view of all their finances instead of having to login to each bank. This kind of thinking trickles down from those four words and you can see how DBS’s vision is a practical tool.
You likely won’t be lucky enough to have a perfect four-word vision. And here, I want to suggest breaking another vision definition taboo: maybe you should have a lengthy vision. Perhaps even bullet points!
In her excellent book on product management, Escaping the Build Trap, Melissa Perri creates a great vision for her fictional example company: “to make it easier and more convenient for mortgage applicants to apply (or for mortgage holders to access), their information anywhere.” Despite being long—and even using a parenthetical!—as with DBS’s vision, this vision of a mortgage product is an effective tool. Now, that vision might be for a division of the company, or even a single product. There’s really no problem trickling down visions like that, but strive to make the first one as practical as possible.
People in a leadership position are the ones who can define the corporate vision and they should spend time on it. They might need to change this vision as time passes, especially as their use of the small-batch cycle validates and invalidates the assumptions that drove their vision definitions. If you find yourself thinking, “Sure, that’s our vision, but we don’t actually do that,” it’s time to update the vision! Each time leadership needs to ask: can people use the vision as a tool to make decisions day to day?
Finally, I’ll be the first to admit that there are much more nuanced ideas of vision in the strategy canon. I’m just recommending making sure that the vision you create and come up with is useful. I’m also giving you permission to ignore those classic definitions if they result only in a poetic, yet inept, vision statement. And don’t worry, we know that your goal is to increase shareholder value and otherwise be awesome—no need to tell us.
Enshrine Urgency: Always Run in the Yellow
I was talking with a person from a large European retailer recently who was suffering from one of the first business bottlenecks leaders encounter: the company’s senior leadership, even owners, see no real need to change. They’re not sufficiently freaked out to expend the time and money to transform the monolithic organization. This is very counterintuitive to you, no doubt, who are reading this report to figure out how to transform your organization. No doubt you recognize the need to sustain and get better at innovating to compete and fend off competitors. Too often, as with the case of the European retailer, the C-suite and even the board is, well, asleep at the wheel.
Evidence of slumbering executives comes up frequently in surveys about digital transformation at the corporate level. One global survey asked people to self-evaluate their transformation efforts: only 20% said they were trying to be “disruptive and fundamentally new.” The rest were either doing nothing (just 8%, thankfully) or performing modestly (73%).
For all the table pounding about “existential” threats from “tech companies,” in the survey, organizations don’t have high ambitions to dramatically respond and change. When asked why they wanted to transform, their motivations were equally tepid. Accessing new markets comes in at 8%, operating model change at 9%, and business transformation at 8%. Driving revenue growth is the highest at 21%, followed by increasing agility and speed to market at 14%.
I read these responses as saying that organizations want to improve their existing businesses and capabilities, which is certainly needed when most organizations take a year or more to deliver applications to production. But, as it shows, transforming the business isn’t currently a major focus of digital transformation. Leaders are focused on incremental changes, not the dramatic changes needed to take advantage of new software techniques and fend off skilled knife-fighters like Amazon. Instead of digital transformation, perhaps we should call such efforts “digital tinkering.”
Leaders, then, have their work cut out for them when it comes to instilling a sense of urgency, not only “down” to staff, but sometimes “up” to their management chain and the board. The sensing and Casandra listening techniques discussed in the strategy bottleneck section can provide the raw data and analysis needed to instill this urgency.
A leader, however, needs to institutionalize this urgency, or, as it was famously described by Intel’s Andy Grove put it in the 1980s, paranoia. Making urgency part of the organization’s culture usually requires a crisis, an almost near-death experience.
Discussing how leadership institutionalized urgency, an executive at a large communications manufacturer said that until very recently (relative to the company’s 150-plus years age) the company had very little sense of urgency. History had proven again and again that it was one of the top companies in its field and as its age showed, it would survive. The company was smug! Although it knew about an emergent competitor in the industry at the time, this hubris left the company feeling comfortable. Needless to say, this old company all but lost in this key market to the new competitor. To its credit, however, the company learned the lesson and has since deeply enshrined market paranoia. Leadership no longer thinks the company is safe in any market and constantly seeks to improve, fend off competition, and be disruptive.
As with this example, in most cases, you’ll need a crisis to institutionalize urgency. For most companies this crisis is easily at hand. Still, you’ll need to rely on your newfound strategy tools to create freak-out charts to motivate people both up and down in your organization. Never pass on the chance to tell people that competitors are coming and you need to act quickly and decisively.
Sustaining this urgency relies on more rhetorical tricks. “Always run in the yellow,” as one CEO put it at a gathering of executives recently. “If you want to keep your job,” the CEO went on, “you don’t want to always run in the red. But it’s equally, perhaps even worse, to always run in the green.” As soon as the company feels that things are going well—running in the green—that hubris and complacency takes over. If all you have is a minor crisis, this CEO said, perhaps amplify that crisis into the red. Or, occasionally, you might even need to manufacture a crisis.
This all said, a word of caution. Sometimes a new executive will create or amplify a crisis to give them a heroic question to solve—and take credit for. This usually involves putting down their predecessor’s work and stopping any ongoing improvement program. If that program was bad, of course the new executives should change course. But stopping a multiyear program that’s working can be deadly in the short and long term. First, of course, it means that you must start over again with the Big Enterprise Change Fun-Fun Strategy. Long term, one side effect of this thrashing by new SVPs is that IT staff learns to ignore most change efforts and just go about their way. In a couple years when this current executive moves onto a new company (which, mysteriously, will also have a huge crisis to solve!) another change program will come in. And then another one, and another. There’ll be so much change that nothing will have time to actually change.
All the Feels: A Note on Positive Motivation
I’m a cynical person. I was raised to see the cutting humor and downside in everything. My superpower is the ability to deftly transform even the most delightful situation into a rainy day. This means I don’t pay as much attention to how to inspire and motivate people—beyond freaking them out. It’s one of the many things that makes me a super-fantastic manager when I’m cursed with that role.
Nonetheless, using optimism to motivate people seems to work better than just freaking them out with urgency and running in the yellow. Rather, positive motivation works hand-in-hand with grim motivation. If it’s only glum and mope, people will wear down and even become numb to the impending catastrophe. The best of them—the ones you really want to keep—will find new jobs.
Simply thanking people and rewarding them works well. Many people derive motivation by having autonomy in their work. Google’s Project Aristotle studied Google teams to find what makes team members effective, happy workers. They summarized five end-states that created a helpful, I’d say positive, motivation-driven environment. As Google analyst Julia Rozovsky says:
Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Dependability: Can we count on one another to do high-quality work on time?
Structure and clarity: Are goals, roles, and execution plans on our team clear?
Meaning of work: Are we working on something that is personally important for each of us?
Impact of work: Do we fundamentally believe that the work we’re doing matters?
A good vision and ongoing communication about the positive business impact of people’s work can contribute to many of these. Providing psychology safety is especially difficult in large, older organizations that have been through decades of outsourcing, acquisitions, and organizational churn.
As the Project Aristotle summary says, psychological safety is the most important attribute of well-performing teams. How do you achieve that feeling of safety, though? The report summarizes advice from Amy Edmondson of the Harvard Business School:
Frame the work as a learning problem, not an execution problem
Acknowledge your own fallibility
Model curiosity and ask lots of questions
Much of this is emphasizing that you’re a learning organization, not a perfect, omniscient, omnipotent one. The whole thrust of moving to a product approach to doing software is to put a learning process in place, to exploit individual and team’s curiosity to try new things, and use the resulting stream of innovation to be competitive. These aren’t easy to achieve, but even more difficult is building up room to succeed-by-failing; that is, to innovate. Indeed, although circular, putting a small-batch process in place also creates psychological safety as the authors of the Pivotal Design Guide point out: the ongoing “experiments have the added benefit of reducing the cost of failure. This creates an environment of increased psychological safety for the team in which trying out new innovative ideas is welcomed and not risky.”
You’ve likely heard of another Google tool, blameless post mortems, in which people document failures: what went wrong, what could have prevented it, and what can prevent it in the future. The goal is preventing failure in the future. It also encourages calculated, data-driven risk taking. I often call this “celebrating failure,” but that’s more dictional bravado. What you’re really celebrating is recovering from failure and improving the resilience of the overall system.1
If you’re switching to a product-driven approach to software and business design, you’re asking staff to be innovative and to learn new ways to do software and run the business. And this is just for product teams: think of how much we’re asking finance to change!
Being innovative requires taking risks. We’re always going on about how much we value “risk taking,” but usually what we value is “success.” Taking risks, though, usually results in more failure than success; otherwise, it wasn’t much of a risk. That “failure,” however, is a positive asset: it means that you’ve learned something that doesn’t work and can move on to finding something that does. It means you’ve at least tried, which is much more than your sleepy competitors will do. Also, you should keep in mind the risk of doing nothing, getting so trapped in analysis paralysis that you knowingly keep hurtling toward the edge of the cliff.
You need to make failing acceptable in your organization; otherwise nothing will happen. Many organizations that do so have what they commonly call “F-Up Fests,” a phrase I’ve heard many times in many organizations, so I’ll risk making you blush by using that word. These happen quarterly or twice a year and demonstrate that leadership is serious about supporting risk takers. And, it’s a good way to drive camaraderie and learning, all helping create psychological safety and that curiosity with which we’re looking to marble the culture.
That all sounds peachy, doesn’t it? Come over to the circle and sit criss-cross-apple-sauce and hear Gene tell us about the time they brought down production for 30 seconds and cost the company $10 million. When you ask your staff to embrace failure-as-learning, none of them are going to believe it. They won’t volunteer to celebrate failure and learning in public, let alone at the company-wide meetings that Google is said to use. Instead, you’ll have to lead by example—or, in this case, fail by example. Find ways to talk about how you, senior leadership, has failed and how the company was better for it. Or, just how you failed.
You and other leaders will likely need to fill the first few slots of your F-Up Fests before you find someone brave enough to share their own f-ups. When you do get more and more people sharing their failures, you’ll know you’re moving your culture in the right direction.
Organization Structure, or, Plato Never Worked at an Enterprise
Leadership often assumes that people will change when they’re told the better, more productive way of operating. That is, that people desire to improve. I think of this as the foundational error of Platonic ontology. If you recall The Allegory of the Cave, people start off looking at shadows of Truth, of the world, chained up to only look at false images and tricked about the true nature of things. Some kindly man in a loose toga unchains them and leads them out of the cave. They go through a series of epiphanies until they emerge from the cave and discover that there are some ultimate, almost physical Truths of which everything else is a reflection, a shadow, a corruption. And after you realize all this, you choose to live your life according to these Truths and the morals that follow. It’s like an enterprise architecture for ethics.
In my experience, people in enterprises rarely change after you show them the Truth. After all, Agile software development has existed for more than 25 years and yet, in many surveys, only about 50 or 60% of people say they follow the practices. Proving that there’s a better way to live and do software is the easy part. Everyone will nod their head and agree. Actually changing it is the hard part. There’s even a set of laws that describes how IT-driven bureaucracies resist change: Larman’s Laws:2
Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions and power structures.
As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
As a corollary to (1), any change initiative will be derided as “purist,” “theoretical,” “revolutionary,” “religion,” and “needing pragmatic customization for local concerns”—which deflects from addressing weaknesses and manager/specialist status quo.
As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3).
Culture follows structure.
Go read that one or two more times, and focus in on number two. You’re in that big conference room discussing this new, great way of operating—Agile, DevOps, doing product management, whatever you like—and you click to the last slide, asking for people’s thoughts. One of the middle-managers, will lean back in their chair; everyone’s been silent, and is now relieved that finally someone other than them is speaking. This reposed person will lightly cross their arms, sort of loudly breathe in as if they’re vacuuming this new knowledge, and starts, “Well, that sounds pretty good, actually.” You’re delighted! “This is what we’ve been doing, really, for the past 20 years. We just didn’t have a word for it!” It wasn’t understanding that what the manager was sucking up into their nose, it was gravitas.
This is the wicked power of humans in a bureaucracy: anything, even the clear need to change the bureaucracy and to an obviously different way of operating, can be used to justify the bureaucracy’s continued existence. Even though your organization hasn’t actually released software to production in the past 12 months, hasn’t actually spoken with customers...they’ve somehow been doing Agile and DevOps this whole time.
It’s important to be understanding and recall that, at one point, the processes and theories of the current bureaucracy were revolutionary and an improvement on whatever existed in the before times. However, the legacy bureaucracy you’re now seeking to change has calcified and slowed down. It’s taken on that magical property of Larman’s second law: it grows stronger, more calcified with each attempt to change it. Trying to change a bureaucracy by following existing processes is like putting out a fire by throwing more fuel on it.
Let’s look at some tools that leadership can use to actually change how people operate.
A Simple but Overly Cute Fix
In Monolithic Transformation, I prescribed a cute fix: don’t change the existing organization, create a new one. Most organizations and the bureaucracy that run them are immutable: after they’re set up and successful, they’re impossible to change. In response to this, many organizations have created brand new organizations, starting with just one or two teams and their applications. These new organizations start from scratch with new norms and processes (that is, “culture”), new technology stacks, and a new, product-minded approach to software. Because those teams are successful, more applications are moved to this new organization. Eventually, almost by accident, you’ve done some portfolio sorting: the applications that needed to and could move from a project approach to a product approach have been transformed. Meanwhile, those applications that weren’t worth improving are left to operate under the old model. And for these “old” apps, this is great! That’s where they belong, because the effort to modernize them is unprofitable.
Organizations like Allianz, The Home Depot, Allstate, Thales, Duke Energy, Daimler, and many others play off this immutable organization theory. I call this idea “cute” because it doesn’t actually fix the original problem. The immutable organization theory just gives up on trying to change the existing organization. In real life, things are messier. By all means, though, if you can just set up a new organization, do it! But, scaling change can bit more messy and slow.
Whether you can finagle setting up a new organization or you need to battle through changing an existing organization, you’ll face the same challenge as you scale beyond those initial teams.
As a leader, you’re one of the only people who can make large, organizational changes and manage how those changes scale to thousands, if not tens of thousands of developers. How do you ensure that your new teams follow the best practices that early teams have discovered and perfected?
The Best Ways to Spread the Improvement Virus
Thankfully, the 2019 DevOps Report gives us some new, numbers-driven insights into rolling out change from team to team. These finds match, more or less, the anecdotes and stories I’ve heard over the past six years, so despite not really understanding the science behind the DevOps Report, I’m certain these new findings are correct!
The report identifies nine tools and techniques to change an organization, quoted verbatim here:3
Training Center—Where people are taken out of their normal work routines to learn new tools or technologies, practices, and even culture for a period of time, and then put back into their normal work environment with the goal (hope?) that their new way of working will stick and possibly even spread out to others.
Center of Excellence—Where all expertise lives and then consults out to others.
Proof of Concept but stall—A Proof of Concept (PoC) project, where a central team is given the freedom to build in whatever way they feel is best, often by breaking organizational norms (and often formal rules). However, the effort stalls after the PoC.
Proof of Concept as a template—Starting with a small Proof of Concept (PoC) project (described above), and then replicating this pattern in other groups, using the first as a pattern.
Proof of Concept as a Seed—Starting with a small Proof of Concept (PoC), then spreading PoC knowledge to other groups. This is done by breaking up PoC (either the first PoC group or subsequent/parallel PoC groups) and sending them to other groups as a way to share the knowledge and practices learned. This may also be described as a rotation, where the PoC members are immersed in other teams to spread the new practices and culture and used as teachers. They may stay in this new group indefinitely or just long enough to ensure the new practices are sustainable.
Communities of Practice—Where groups that share common interests in tooling, language, or methodologies are fostered within an organization to share knowledge and expertise with each other, across teams, and around the organization.
Big Bang—Where the whole organization transforms to DevOps methodologies (however they choose to define it) all at once, often with top-down directive.
Bottom-up Grassroots—Where small teams close to the work pull together resources to transform and then informally share their success throughout the organization and scale without any formal organizational support or resources.
Mashup—Where the org implements several approaches described above, often only partially executed or with insufficient resources or prioritization to enable success.
These are good, comprehensive change strategies.4 What makes the report especially pertinent to the leadership bottleneck is the analysis of which of these strategies work best, and worst. To summarize the findings, the report finds that template and seed PoCs, communities of practice, and grassroots strategies correlate highly with successful organizations; centers of excellence and training centers much less so.
Clone and grow
Many organizations I’ve studied use templating and seeding to sustainably spread new methods of organizing and operating through the “legacy” organization. They follow a basic playbook:
An ideal team is formed. For many this means a team of 4 to 12 people comprised of developers, designers, and product managers who own the software they’re working on, treating it as a product—their product.
As these teams are successful over, say, two quarters, their methods of working, structure, and the tools they use are cloned for new teams.
New teams can certainly customize how they function if they find better methods, but they start with this template.
Often, a few individuals from these initial teams are moved to new teams to “seed” existing skills and knowledge. These seeds bring not only experience and expertise, but trust in the new system. They also know how to overcome previous organization hurdles. Some organizations use pair programming and pairing across other roles to further educate new people, relying on the viral spread of knowledge by rotating pairs daily on teams.
The bottoms-up approach certainly works at smaller organizations. But, relying on all of your staff to self-organize and choose the methods and tools of operating is rarely a good idea.
Instead, to change a large organization you should begin with a default template. You, as leadership, need to help define this template but by applying the small-batch process to experiment and learn how that template should evolve.
To be certainly, organizations give each team a high degree of freedom over those choices and how they function. For example, the organization behind MercedezBenz.io, which is made up of more than 350 people, uses the flat, holarchy model to give teams freedom to work as they please—at least, to make the case that they should use their own methods. However, you need at some point to decide that choices about how operating systems are patched and how load balancing is managed, for example, are beyond the scope of development teams. However, they still rely on best practices, standardized structures, and a common set of tools.
Introducing New Roles into the Team
Part of what makes a piece of software a product instead of just a project is the product manager. Product managers are, essentially, the general managers and “leaders” of the application. The egalitarian spirit of these teams tends to reword and emphasize the management aspects, but from a more traditional view of business, product managers own the product. They make decisions about application features, the roadmap for the product, and help resolve internal and external management problems. In a sense, the product manager is continually brokering the relationship between all of the parties involved: business, finance, IT, and often forgotten, the customer. The product management is trying to decide which features and which activities each release cycle will maximize business value for those stakeholders, negotiating between competing desires.
In that way, the product manager is in charge of making sure the business’s vision and strategy is realized, week to week, in the application. If a developer is responsible for the technical viability and performance of the application, the product manager is responsible for the business viability and effectiveness of the application.
To this end, one of the most important tasks a product manager does is sorting through and identifying the priorities for the application. Everyone in the organization from the line of business (LoB), to developers and designers, to the board will have ideas about what should be in the application. A new feature might help sell significant deals, or there might be a bug that’s slowing down releases each week. There might be a new type of machine learning that, if we just added it to the application, would optimize part ordering for car manufacturing. A product manager must synthesize choices based on their product’s strategy, the relative technical viability of the feature, and the potential to create a better business with each feature request.
Finding these people can be difficult, creating another bottleneck outside of IT. They might be people in the lines of business who have the eagerness, domain knowledge, and ability to focus. One of leadership’s first tasks is to find and recruit these people to become product managers. Ongoing, you’ll need to internally develop the role and begin hiring for that skill set.
A word of caution on finding product managers. Sometimes, product managers come from an IT background as IT people get more curious about how the business functions. Often, though, Agile coaches and Scrum Masters are thrust into the role of product management. The back of the can description of coaches and product managers seems similar. And, sure, these individuals might be great at the job. But more than likely they’re not equipped with all of the skills and relationships in the company to succeed as a product manager. More benignly, they might slide into Larman’s Bog and become stuck doing the same things, wrapped in different words. Be very careful about wholesale converting coaches and masters into product managers and checking off this box.
Strategy from the Nerds
For decades now, IT has been told that it’s in a servant relationship with The Business: IT takes requests and delivers on projects and services. Each of these services is metered and delivers to uptime and performance promises, as in the case of Service-Level Agreements (SLAs). What’s not too subtle here is the assumption that The Business knows all. IT has little to no role in defining how its organization works with customers, defining the products being sold, or driving any type of strategy. IT does what it’s told; it’s a servant! This is the “project” mindset that we’re trying to escape from: we want IT to be smarter than a computer that just does what it’s told and instead become a core part of how business is done at their organization.
Changing this relationship is another organizational tool that leadership has at its disposal. The way an enterprise is organized defines reporting structures and sources of truth. Typically, “The Business” means the departments of a company that are responsible for products and the associated revenue. IT is rarely, if ever, part of “The Business.” This unidirectional relationship, however, cuts the company off from very valuable insights and abilities. It means that any discovery IT makes or new idea the “developers” discover is largely ignored because IT’s job is to do what it’s told. All of that validated learning from the small-batch process rots, unused.
Making this relationship bidirectional is another powerful tool that leadership needs to use. Ideally, there is no “relationship” because “business” and “IT” are the same. As ever, getting to that strategic paradise will take time for most organizations. To move in the proper direction, leadership in the lines of business, and the company as a whole, needs to understand and value feedback that the small-batch loop gives to the business. The data that comes back from each experiment cycle isn’t only useful to define features in the software, but also to start defining how the actual business operates.
Let’s look at an example from the auto industry to understand how the business might profit from working with IT rather than just telling IT what to do.
Case Study: When Vans Are Cars
Daimler has shifted over to this new, product-minded way of building the software for its online storefront. By “storefront,” I mean the official website car buyers visit to not only browse which cars are available to purchase, but also create different configurations, research detailed performance characteristics, and schedule visits with dealers to test drive cars. Mercedes-Benz’s “storefront” is very much the beginning of the buying process for many customers. As you’d expect, this storefront has a search feature that allows customers to search for vehicles they’re interested in.
Daimler’s Sophie Seiwald told me a great story that illustrates how the product can inform how the business thinks of itself and operates.
In taking a product approach to the storefront software, the team proactively analyzed terms people searched for, trying to gain insights and inspiration into how to make the buying process better. The team noticed that people kept searching for work vans—those big, hardly sleek looking vans you’d see a plumber, electrician, or cabbie driving around. Searches for these vans didn’t turn up any results because the storefront was, of course, for personal cars. The LoB that sold work vans was an entirely different operation and had nothing to do with the storefront.
After looking into who was searching for vans and why, the storefront team came to an unexpected realization: individuals were actually interested in buying these work vans, not just plumbers. They might travel in these vans or just use them to, I don’t know, help friends move. And, of course, plumbers are people, too, so they also would search for vans through the storefront.
That this was some killer insight seems confusing if you don’t work at an auto company. As with most businesses the people searching for vans didn’t think about the auto company as a collection of different lines of businesses, each their own galaxy. Because of decades of successful brand marketing, these van buyers just thought of Mercedes-Benz as Big Car Company—they probably don’t even think of it as the actual name of the company, Daimler. Buyers had no idea they were supposed to go to FindPlumberVans.com to interact with Daimler’s professional-van LoB.
Using this newly found knowledge and, importantly, data to back up its claims, the storefront team began the arduous process of helping the van LoB reprogram one of its core business assumptions and, thus, operating strategies. The unidirectional command structure between business and IT reversed, in this instance. IT, very gently, suggested that The Business should consider rethinking a core assumption. The result is that searches for Mercedes-Benz vans now show up in the storefront: the software acts like customers would expect it to, but the businesses are also operating in a new way.
In my experience, in situations like this at any company, based on the historic give-and-take relationship between The Business and IT, taking advantage of the van insight would have been time consuming, if not impossible. The vans LoB would have missed out on new revenue—revenue which was, more or less, free and unexpected.
In most cases, leadership in both the LoB and the company as a whole are the ones who’ll have the power to the traditional IT-as-servant relationship. As we’ve been discussing, the idea isn’t to just listen to any cool but wacky idea from IT staff. Instead, the LoB trusts IT’s insights because IT demonstrates that it follows a disciplined, data-driven process. As the lines of business and leadership begin to trust those insights, the business bottleneck unclogs more and more.
Do You Still Need an IT Department?
At this point, it’s easy to ask, “Do I need an IT department? I mean, they seem to be kind of a hassle and grit in my magic innovation of rapid differentiation.” Famously, IT was predicted to cease mattering sometime in the 2000s. What this argument meant at the time was that previously complex, proprietary, and expensive infrastructure and software was set to be simplified, opened up, and made dramatically cheaper. An on-premises email server doesn’t “matter” because companies can get email cheaply, even for free. The same is the case for word processing and spreadsheets, and even the most complicated databases and programming models. Enterprise applications for enterprise resource planning (ERP) and customer relationship management (CRM) are a bit more secure in their “mattering,” but even the price of operating systems has effectively, or literally, gone to zero. IT is still needed, but large swaths of it are commoditized and should take up less time of your organization’s budget and attention.
Here, I like to distinguish between two types of IT.
The first bucket is what I jokingly refer to “desktop management and password resets.”5 These are all the tasks to provide the base level of computational and networking services needed: desktops, secure networking, email and calendering, collaboration software, file sharing, and other “utility” services. Someone has to manage how you use these services and roll out PC upgrades. Many of those services can be outsourced to Software as a Service (SaaS) providers, and others (like mobile management) can be shared with employees. Although this bucket needs to managed, it doesn’t “matter.” I mean, unless, just like electricity, you don’t have it, in which case, everything stops working. Most organizations spend about 70% of their budget on this type of IT, to “keep the lights on.”
The second bucket, as you can likely guess, is custom-written software. This is what we’ve been discussing this whole time. Budget wise, this bucket gets much less cash than keeping the lights on. From what I’ve seen, my rule of thumb is that new IT projects are about 20% or even just 15% of the overall IT budget.
Does IT need to “own” this function?
Until recently, the answer was yes because centralizing software building in IT was the only way to ensure sane costs, guaranteed levels of service, security, and compliance. The expertise in building datacenters to run software was in the IT department not in, say, the insurance risk-assessment group.
As IT began to “not matter,” the complexity of building and running datacenters changed the hold the IT department had on, well, IT. This was when the notion of “shadow IT” emerged, which is a delightfully wicked turns-out phenomena. Shadow IT meant using a SaaS or even building applications outside of the governance of IT. Sales groups starting employees using CRMs like Salesforce and marketing executives starting using agencies to build mobile applications. Or, more simply, individuals would use file-sharing services like Dropbox to finally be able to share files larger than the 25-megabyte limit on email attachments.
That is, the IT department couldn’t keep up with the business’ needs. The IT department was failing to be useful. In this case, IT was the real shadow IT!
Whatever clever take you might have on shadow IT, it’s a historic example that drives how you should think about where to put product teams and how to support them. For many organizations, keeping product teams will be the only viable option. This makes sense: most of those people and expertise will likely be in IT already. Few executives will want to be bold enough or spend enough political capital to pull apart the IT department. If you do place product teams in the IT department, at least follow the practice of creating a new suborganization, as discussed in the immutable organization section earlier in this report.
There are alternatives, however. You could embed product teams in their respective business units. This will ensure that product teams are the business. Finding product managers for each team will be easier, especially because their reporting lines won’t need to dramatically change.
Your LoB executives will need to understand what these teams do to make wise budget decisions and otherwise manage product teams. If those executives look at product teams as interchangeable parts, they’ll mismanage those “assets” when times are tough.
Another model is to create a new organization, often a product organization headed up by a chief product office or a feisty CTO-type. This organization might actually be in IT but that will just be a formality. Indeed, the immutable organization strategy above is essentially this scheme.
All of these schemes still require a high degree of governance and shared services. Historically, allowing lines of business and developer teams to come up with or even obey corporate standards and governance has been a risky, unrealistic proposition. Arguably, enterprise’s interest in DevOps and Google’s Site Reliability Engineering (SRE) practices are a response to how difficult it is to enforce governance across an enterprise’s software portfolio.
Contemporary DevOps- and SRE-think encourages using a standardized, centralized set of methodologies and platforms to focus developers on just coding their applications. These platforms logically belong in the IT department...if the IT department can change the way it builds and delivers these kinds of services.
Product Managing IT
Traditionally, IT thinks of what it does as providing a service. Indeed, “service delivery” is a common phrase in enterprise IT operations as well as “IT Service Management.” Oddly, hemming to the idea that IT doesn’t matter, IT sets itself up as a utility that provides computer stuff, almost willfully ignorant when it comes to the business value that it provides.
Just as we’re asking developers to focus on products, IT operations also needs to focus on providing a product. The first thing a product needs is a customer, which, in this case, are developers. This simple reorientation from providing a service to building a product has large and beneficial effects on how IT operates.
IT operations staff organizes around the product it’s providing—the shared infrastructure and development services product teams need not only to focus on just their applications, but also to automate the governance of policy and security.
Operation’s goal becomes making developers more successful, which largely means making them more productive. The products it builds, the platforms, seek to remove as many manual processes and as much waste as possible from developers’ daily lives. This platform team applies the same product management mentality as the product teams to study, theorize, and deliver new features and capabilities. This is the so-called “platform as product” approach, which I discuss in Monolithic Transformation.
In understanding what developers need, most IT departments realize that developers shouldn’t need to manage infrastructure, ensure security by hand, or even maintain common build tools. Instead, these organizations have followed in the steps of Netflix and Google by establishing centralized platforms to standardize how developers do these low-level, low-business-value tasks. These services provide the lower-level datacenter and cloud management tools, the middleware like databases and even machine learning, and the Continuous Integration (CI) and Continuous Delivery (CD) build tools.
Generally, anything “below” the app is waste from a customer’s perspective. Configuring production servers and patching operating systems might be necessary for happy customers, but they provide no value in the Lean sense of the word. And, here, remember that the customer is the developer! The platform operators need to identify these wasteful activities and automate them as much as possible.
This automation also improves governance and security because operations staff no longer need to depend on developers to follow such guidance, nor spend time patching operating systems and other components used in their applications. “When you use a Continuous Delivery pipeline, you can automatically test quality and check for security risks every time a developer modifies software,” as John Marcante, Vanguard’s CIO says, “Instead of the business and IT manually testing software, you can run all functional and regression tests automatically in minutes, not weeks.”
I’ve observed organizations like Daimler, Allstate, Thales, the US Air Force, and many others accomplishing this shift in IT-orientation by using modern cloud platforms like Pivotal Platform and other Kubernetes-based platforms. These are so-called “cloud native” platforms that use technologies perfected by the likes of Google and Amazon in recent years to run their own software.
Wherever you choose to put your product teams, ensure that IT is treating them as customers, not ticket queues.
Hopefully, it’s not insulting to suggest that there’s a...er, opportunity here, but if you want to be like a tech company, you, the executive, must understand technology, specifically software. After reading this book and my previous one, you’ll no doubt be at expert level when it comes to IT! But, you’ll still need to garden your ongoing technology education. Just as your product teams will be expected to know their customers, business, and its goals so that they can make snap decisions, you’ll need to understand the technology, the factory that’s used to create software so that you can make management decisions.
In returning to the idea of operating like a tech company, it’s worth looking at executives at tech companies. With very rare exception, executives at tech companies are incredibly familiar with technology. For example, VMware’s CEO, Pat Gelsinger, cowrote a book on the 80386 chip.6
Leaders need to employ an understanding of technology to gut-check attractive but risky strategies, especially acquisitions and multiyear strategies that target entering new markets. When executives understand how software is made and run, they can also change the way they oversee and manage it.
At the board level, this means having at least one member from the tech world. Hopefully this member will oversee and influence large initiatives like digital transformation, large IT purchases, and multiyear outsourcing contracts. Based on the preponderance of failures in those types of programs, there hasn’t been enough technical oversight from boards over the past few decades...rather, good oversight. More important, this board member can be an authoritative force for rallying belief in culture and organizational changes, not to mention the difficult finance changes like the ones I’ve suggested here. Most people recommend meeting with this board member at least quarterly to review technology decisions and programs.
Find yourself a secret nerd
If understanding technology and software better seems daunting to you, don’t worry. You’re a smart enough person that you’ve gotten to this point in your career, so you can certainly learn so long as you’re motivated, prioritize making the time, and...find a secret nerd.
A “secret nerd” is someone who can, usually weekly, spend an hour or so with you to go over trends and lessons in software. They can answer questions that you have and even come up with a curriculum. If you’re lucky, they’ll keep doing it indefinitely. They’re secret because, well, it’s often easier to learn out of the public eye in large organizations. For as optimistic as you might be, executive ignorance is often seen as a weakness in enterprises.
I first heard about this tactic many years ago. My friend was a senior technical staff member at one of the older, larger tech companies, of all places. They’d been asked to mentor a new executive and did so for an hour or more every Sunday. Although I would recommend a weekday, instead, this ensured that the executive was knowledgeable and, also, for this secret nerd, helped build a new trusted relationship with senior management.
However you achieve it, make sure you understand this new, core asset your organization relies on: software. The nature and potential of this “software” is evolving now more than ever. Just in recent years software has moved from a largely on-premises concern, for which you’re responsible for running and managing the data centers that run the software, to a SaaS model, which removes the need to run the software. Software is also what’s driving and running Internet of Things (IoT) and machine learning models that have the potential to unlock huge cost savings and new business models in previously analog businesses. If you can think of a new business model, the chances are that it’s made possible by software. Understanding software, then, for company leaders is as critical as understanding other core parts of your business.
Case in Point: Technical Debt
By far, the most frequent topic IT people wish The Business understood is technical debt. This concept is a catch-all phrase for shortcuts you take in software development and IT management to save costs or deliver features sooner. The metaphor “debt” is apt: you decide to take on future obligations for short-term gains.
In business, debt is usually helpful instead of to be feared. Getting more cash today helps you to build upon your existing assets and get to market quickly. Similarly, in software, taking on technical debt allows you to deliver faster and grow your business beyond your current means. In software, however, taking on “debt” is rarely this helpful. A better phrase might be “technical negligence.”
Software ages quickly: architectures are forgotten, the reasons you wrote code one way versus the other are forgotten, people with rare skills move on (or die!), and newer options are simply better than what you have. In theory, enterprise architects (EAs) keep an eye on refreshing your software, preventing coagulation and cementing—but this rarely works out. EAs tend to get caught up in other activities: formulating governance, holding review meetings to make sure governance is followed, or creating annual “trends” reports for senior executives (think blockchain!). These activities have the best intentions, but tend to keep EAs too far from the actual software and systems they’re trying to govern. It means that product teams and enterprise systems are denied the good parts of what EAs do: deep strategic knowledge and the ability to look forward to create agile enterprise architectures. This starvation manifests itself most deadly in technical debt.
Funding and time to work on behind-the-scenes fixes is always a problem. Simply rewriting the existing software seems like a waste if there’s no functional change, if the release doesn’t involve moving pixels on a screen. This, of course, is like thinking that time spent brushing your teeth is a waste because you could be eating more candy with that time. Long project cycles compound the problem, too: management doesn’t want to lose the chance to add new features to software.
Every large organization faces the challenges of technical debt. This is especially true of the largest and most successful, particularly those companies that can afford to acquire other companies. Over just a decade of acquiring other companies, your software portfolio can grow in number, but also incomprehensibility and complexity. With each acquisition and merger, you take on the legacy portfolio of another organization. And when M&A synergies are involved, people are often let go, shrinking the institutional memory and skills you’d need to update your legacy IT and reduce your technical debt. You likely double, or even triple, your technical debt.
Understanding technical debt is key for managing your digital strategy. If you let too much technical debt mount, your ability to innovate the business will come to a standstill. Leadership in large organizations needs to actively manage technical debt if it hopes to achieve any sort of business transformation sustainability. I don’t think it’s going too far to suggest that runaway technical debt is the number one reason for digital transformation failure.7
First, ask your secret nerd to go over what technical debt is and even report on how much debt your portfolio has. Then, study and track how long it takes to add in new features to core backends, or just to pull data from those systems. In banking and payments, for example, you could ask how long it would take to do the technical changes needed to support Apple Pay. You can also look at the time it takes to integrate the IT between identical businesses. In hotel and travel mergers, how long does it take to merge two loyalty programs into one? There are also code analysis tools that will tell you how tight of a spaghetti knot you have on your hands, but those are likely more useful after you understand and believe in the dangers of ignoring technical debt.
Metrics: Managing Like a Tech Company
Squishy as it might seem, product development is by no means immune from metrics. In fact, executives must rely on metrics to manage at scale, especially with hundreds of product teams, if not more. Let’s look at some metrics.
First, there are many metrics that are anything but quantifiable. They defy being reduced to a number. Of course, anything can be measured if you’re willing to make assumptions and compromises to create a model as Douglas Hubbard lays out How to Measure Anything (Wiley). That said, I wouldn’t try too hard for more qualitative questions. Despite being numerically slippery, qualitative “metrics” are incredibly helpful so long as company leaders have developed understanding and intuition about the mechanics of using software to innovate their businesses.
For example, one CEO at a large retailer began asking product teams what they’d learned in recent releases instead of just checking the status and budget of the projects.
There are many technical metrics to use, most of them characterizing how IT is performing. Even if you’re not in IT, understanding these metrics so that you can get a sense of IT’s overall health is important. Ideally, you can delegate constant monitoring of these metrics to the CIO and their team, but you should understand them if only to use when problems bubble up to you and to drive budgeting decisions based on good and poor performance.
For several years now, based on their studies of high-performing organizations, the DevOps Reports have recommended four key IT metrics. These are good metrics to start with and evolve as you learn more. I’ve listed them here along with my recommendations for the ideal, green state you should target and when to be concerned and investigate:
- Deployment frequency
This is how often software is deployed to production for people to actually use. Target weekly, be concerned when it’s monthly or longer.
- Lead time for changes
After the developers are done writing and verifying code, how long does it take to deploy to production? Target a week or less, be concerned when it’s two or more weeks.
- Time to restore service
When an error occurs in production, the length of time it takes to restore service. Target a day (an hour or less, eventually), be concerned if it’s three days or more.
- Change failure rate
The percentage of changes that result in errors or poor application performance that require rolling an immediate fix. Target zero to 15%, be concerned if it’s more than 20%.
There are many, many other IT metrics you could follow. Ask the product teams and operations staff what metrics they would like to share and think would be helpful for understanding overall IT health. Also, be wary of long lists of metrics or those that show only a single point in time instead of ongoing trends. Too many metrics create more confusion than clarity, and metrics without relation to historic trends can be assuring, yet baffling.
Finally, if IT can’t provide even these four, basic metrics for apps, you’ve spotted one of your initial problems to solve!
Business Value Metrics
The most useful metrics you can create and track are business value metrics: those metrics that measure the success and improvement to how your business is performing.8 Obviously, measuring revenue and profit is valuable, but those tend to be effects of other actions. Measuring those other actions are what business value metrics target.
For example, as cited by Jeffrey Hammond and Margo Visitacion in a Forrester report,9 the pharmacy “Walgreens, for instance, [uses] the time it takes customers to refill a prescription via mobile as a benchmark for convenience.” Thus, “convenience” might be a business value metric. As this length shortens, you know that the prescription refill team is doing a good job; if it stalls out, they’ve either reduced the refill time as much as possible or have hit a road-block; if it lengthens, something is going wrong and should be investigated.
Equally important to using such metrics to detect the status of product teams is using these metrics for financial and strategic planning. Rather than treating the refill app as simply software that was delivered to specification and treated as a cost, by continually tracking business metrics you can better appreciate how the software contributes to revenue, not just how it burns cash. This means that you can begin determining IT budget by usefulness instead of cheapness.
Your first business metrics will typically have to do with the rate of fulfillment, like the prescription refill metric or finishing an application. Insurance companies, for example, are currently obsessed with the time it takes to handle claims.
But, don’t focus just on speed, think through other metrics that might be attributes of whatever you think “success” is in your business. For example, the US Veterans Affairs (VA) department wanted to move more applicants to electronic forms. It, of course, measured the amount of forms submitted, but also measured the amount of forms started. This allowed the agency to monitor improvements to the software driving the application. As the software became better, the ratio between started and completed began to level out.10
Also, don’t be afraid to come up with useful vanity metrics. Something like “engagement” (the number of times someone likes a picture on Instagram, for example) might be difficult to tie to any real business value, but if it helps rally support for your transformation efforts, track it!
Automating these metrics is key, as well. I’ve witnessed too many organizations relying on manual collection of business metrics, right down to needing to know that one employee has accidentally forgotten access to a core ERP system and magic spreadsheets. Too much time spent generating these metrics will make them error-prone and out of date.
Here are some more broad and narrow example business value metrics to use when determining your own:
- New accounts and usage
New banking account sign-ups and how long it takes to open an account. With an average account deposit size, you can track the actual financial impact of software that streamlines signing up for new accounts. To be more advanced, also track how active those new accounts are.
- Time to respond to records request in government
When Congress asks to see your work, you’d better be able to respond quickly.
- Usage of new software, uptake, and engagement
One insurance company rewrote an application for encouraging healthy behavior that had very little use from customers. As it rewrote the application, it measured usage of the new app to gauge success and direct further development.
- Customer service
This is a vague category, and requires exploration. You could use NPS as a proxy, and you can also ask customers directly with surveys. But you can probably find other indicators of how happy customers are with you. For example, after introducing an AI-driven chatbot in its app, Comcast reduced call center volume by 40% and increased its Net Promoter Score (NPS).
- Cost savings in the business
Lower costs might actually be a key business goal. For example, if you know that your existing software is ancient and slowing down business efficiency, or if you’re still using an analog process that software could accelerate, lower costs to do business might indicate success. Just be sure to focus on the cost of doing business, not just the cost of the software. For example, one aerospace company replaced a call center for ordering airplane parts with an app, saving both time and money for customers and the company.
- Time to start a new business
Traditional IT typically takes a year or more to start a new business; for example, in a new geography. Tracking how long it takes to start in a new market and make your first scale can give you a sense for the business value IT provides. For instance, Liberty Mutual was able to start selling motorcycle insurance within six months, supported by new software for agents and buyers.
- Revenue growth
Clearly, the metric we’d all want. This can be difficult to convincingly correlate to IT changes, but if you can, do it!
Whatever you choose, try to limit your business value metrics to four or less. For example, in transforming the apps for the government of the United Kingdom, the UK Government Digital Services targeted four business value metrics: digital take-up, completion rate of forms and services requests, cost per transaction, and user satisfaction. As they explained in Digital Transformation at Scale, these metrics matched with their goals of “getting more people to use online government services, building services that worked first time, saving money and meeting user needs.”
As you transform your culture, you’ll want to somehow sense the direction of your progress. You might not be able to measure it exactly, but you can at least model it to get a sense for how transformation is going. Ongoing, these metrics will also allow you to detect when the organization is backsliding or when problems emerge in your organizations meatware. Culture metrics are primarily for you—the champion and manager of transformation—to monitor and guide how things are going. You might be able to use them to convince naysayers in your organization, or maybe not. Sadly, too often, for those types of conversation, only business results will be helpful.
The exact metrics you use will depend on your organization and the changes you’re making. Here is a short sampling to start you thinking:
- Employee NPS (eNPS)
This metric is similar to the usual NPS, but instead asks: “How likely is it that you would recommend your organization as a place to work to a friend or colleague?” Measuring this over time will give you a sense for how things are improving, or getting worse.
- Staff belief in leaders and mission
This measures people’s alignment with the company’s culture and plans, but also leaderships’ ability to communicate and work with staff. Of course, a negative rating could also show that the leadership and/or mission are bad.
- Interaction with customers
How often do product teams interact with customers? There’s certainly a limit of effectiveness, but a product team should be talking with actual customers regularly. Once a month is probably too little, daily way too much, so perhaps a few times a month.
- Staff retention and churn rate
As your culture improves, driving up psychological safety, people should want to stay in their jobs longer. This should reduce, or level off, churn rates. However, you don’t want 100% retention. Getting new people and ideas into the system is helpful, equally so, allowing others who don’t (want to) fit in to leave.
- Pathological, bureaucratic, or generative
In addition to quick metrics, the DevOps Report people recommend assessing where your organization is on the Westrum scale. This is a long series of questions and, perhaps, should just be done annually. However, in aggregate it will give you a (hopefully not alarming) deep sense of the type of organization you have.
2 Like all “laws” in software, these are not actually laws, like say, gravity, or even prohibitions against jaywalking. If you hear a software person call something a “law,” what they really mean is “rule of thumb.” At best, they mean, well-informed rule of thumb. But “Larman’s Well-Informed Rule of Thumb” doesn’t really sound, you know, authoritative.
3 All nine strategies quoted from Appendix B of the 2019 DevOps Report.
4 It’s fun to squint at the persnicketiness and propriety of some of these definitions. For example, would any strategy actually intend to “stall”? I especially like the parenthetical “hope?” in the training center definition as if to wink a sort of “you’ll never guess how this turns out!” snark. Wryness aside, they’re good models and tools.
5 I had to cover desktop management and, even more delightful, virtual desktop management at one of my analyst jobs. I’ve never forgiven that sector of IT for existing.
6 Often, sales people become CEO’s at tech companies, as well. In this case, by nature of being a good sales person who understands the product being sold and how companies evaluate and value software, they have a fair handle on tech, if not an excellent one.
7 Perhaps this can finally obliterate the tired construct “tech is not the problem, X is the problem”: “technology is not the problem, culture is the problem.” Actually, culture is not the problem, technical debt is the problem….
8 You can call these Key Performance Indicators (KPIs) if you like.
9 Forrester, The Agile Enterprise Emphasizes Practice Over Process, August 2019.
10 From “The Importance of Product Management in Government,” Chris Johnston and Kelly O’Connor, August 2018.