The Strategy Bottleneck

This is a draft excerpt from a book I’m working on, tentatively titled The Business Bottleneck. If you’re interested in the footnotes, leaving a comment, and the further evolution of the book, check out the Google Doc for it. Also, the previous excerpt, “The Finance Bottleneck.”

Digital transformation is a fancy term for customer innovation and operational excellence that drive financial results. John Rymer & Jeffrey Hammond, Forrester, Feb 2019.

The traditional approach to corporate strategy is a poor fit for this new type of digital-driven business and software development. Having worked in corporate strategy I find that fitting its function to an innovation-led business is difficult. If strategy is done on annual cycles, predicting and proscribing what the business should be doing over the next 12 months, it seems a poor match for the weekly learning you get from a small batch process. Traditionally, strategy defines where a company focuses: which market, which part of the market, what types of products, how products are sold, and therefore, how money should be allocated. The strategy group also suggests mergers and acquisitions, M&A, that can make their plans and the existing business better. If you think of a company as a portfolio of businesses, the strategy group is constantly asses that each business in that portfolio to figure out if it should buy, sell, or hold.

The dominant strategy we care about here goes under the name “digital transformation.” Sort of. The idea that you should use software as a way of doing business isn’t new. A strategy group might define new markets and channels where software can be used: all those retail omnichannel combinations, new partnerships in open banking APIs, and new products. They also might suggest businesses to shut down, or, more likely divest to other companies and private equity firms, but that’s one of the less spoken about parts of strategy: no one likes the hand that pulls the guillotine cord.

A moment of pedantry

First, pardon a bit of strategy-splaining. Having a model of what strategy is, however, is a helpful baseline to discuss how strategy needs to change to realize all these “digital transformation” dreams. Also, I find that few people have a good grasp of what strategy is, nor, what I think it should be.

I like to think of all “markets” as flows of cash, big tubes full of money going from point A to point B. For the most part, this is money from a buyer’s my wallet flowing to a merchant. A good strategy figures out how to grab as much of that cash as possible, either by being the end-point (the merchant), reducing costs (the buyer), or doing a person-in-the-middle attack to grab some of that cash. That cash grabbing is often called “participating in the market.”

When it comes to defining new directions companies can take, “payments” is a good example. We all participate in that market. Payments is one of the more precise names for a market: tools people use to, well, pay for things.

First, you need to wrap your head around the payments industry, this largely means looking at cashless transactions because using cash requires no payment tool. “Most transactions around the world are still conducted in cash,” The Economist explains, “However, its share is falling rapidly, from 89% in 2013 to 77% [in 2019].” There’s still a lot of cash used, oddly in the US, but that’s changing quickly, especially in Asia, for example in China, The Economist  goes on, “digital payments rose from 4% of all payments in 2012 to 34% in 2017.” That’s a lot of cash shifting and now shooting through the payments tube. So, let’s agree that “payments” is a growing, important market that we’d like to “participate” in.

There are two basic participants here:

  1. New companies enter the market by creating new ways of paying for things that compete with existing ways to pay for things. For example, new entrants are services like Alipay, Bunq, Apple Pay, and GrabPay. While this is the domain of startups in most people’s minds, large companies play this role often.
  2. Existing companies both defend their existing businesses and create new ways of paying for things. For example, Dutch banks launched iDEAL several years ago. Existing companies often partner with new entrants, for example: Goldman Sachs provides the backend for Apple Pay and Maybank partnered with GrabPay. Incumbents can also accomplish the second goal by just acquiring the new companies: in general banking, Goldman Sachs acquired Honest Dollar to help it get into consumer banking.

“Strategy,” then, is (1.) deciding to participate in these markets, and, (2.) the exact way these companies should participate, how they grab money from those tubes of cash. Defining and nailing strategy, then, is key to success and survival. For example, an estimated 3.3 trillion dollars flowed through the credit card tube of money in 2016. As new ways of processing payments gain share, they grab more and more from that huge tube of cash. Clearly, this threatens the existing credit card companies, all of whom are coming up with new ways to defend their existing businesses and new payment methods.

As an example of a general strategy for incumbents, a recent McKinsey report on payments concludes:

The pace of digital disruption is accelerating across all components of the GTB value chain, placing traditional business models at risk. If they fail to pursue these disruptive technologies, banks could become laggards servicing less lucrative portions of the value chain as digital attackers address the friction points. To avoid this fate, banks must embrace digitized transaction banking with a goal of eliminating discrepancies, simplifying payments reconciliation, and streamlining infrastructure to operate profitably at lower price points. They must take proactive strategic steps to leverage their current favorable market position, or watch new market entrants pass them by.

That is:

  1. New methods of payments will destroy your business, those pesky “tech companies.”
  2. So you should create some new (not credit card) payment methods 
  3. At the same time make your back-end systems more efficient so they can drive down costs for your existing credit card based business, increasing your profit margins despite overall revenue declining as “tech companies” grab more and more money out of your cash-tubes.
  4. Also, take advantage of your existing capabilities in security, fraud handling, and governance compliance to differentiate both your new, not credit card payment offerings and defend your existing credit card business.

That’s pretty good strategic direction and it comes, as you can see in the PDF, from a very deep analysis of market conditions, and trends – there’s even a Mekko chart!

McKinsey payments Mekko - Screen Shot 2019-08-08 at 2.27.28 PM.png
Source: “Global payments 2018: A dynamic industry continues to break new ground,” McKinsey, Oct 2018.

Now, how you actually put all that into practice is what strategy is. Each company and industry has its own peccadilloes. The reason McKinsey puts out all those fine charts is to do the pre-sales work of getting to invite them in and ask “yes, but how?” 

Getting over digital transformation fatigue

“Software is eating the world.” Pronouncements like this chestnut are by now obvious thanks to many Casandras have grown hoarse over the years. As one executive put it:

We came to the realization that, ultimately, we are a technology company operating in the financial-services business. So, we asked ourselves where we could learn about being a best-in-class technology company. The answer was not other banks, but real tech firms. 

This type of thinking has gone on for years, but change in large organizations has been glacial. If you search for the phrase “digital transformation” you’ll daily find sponsored posts on tech news sites preaching this, as they so often say, “imperative.” They’re long on blood curdling pronouncements and short on explaining what to actually do.

We’re all tired of this facile, digital genuflection. But maybe it’s still needed. 

If survey and sentiment are any indication, digital strategies are not being rolled out broadly across organizations as one survey, below, suggests. It shows that the part of the businesses that creates the actual thing being sold, product design and development, is being neglected:

Forrester digital transformation projects by department.png
Source: answers to the question “Which business processes are the focus of your firm’s most recent digital transformation?” Data from “Kick-Start Your Digital Business Strategy,” Forrester, June 2019.

As with all averages, this means that half of the firms are doing better…and half of them worse. Curiously, IT is getting most of the attention here: as I say, the IT bottleneck is fixed. My anecdotes-as-data studies match up with the attention customer service is getting: as many of my examples here show, like the Orange one, early digital transformation applications focus on moving people from call centers to apps. And, indeed, “improving customer experience” is one of the top goals of most app work I see.

But, it drops off after there. There’s plenty of room for improvement and much work to be done by strategy groups to direct and decide digital strategy. Let’s look at a two part toolkit for how they might could do it:

  1. Sensing your market – how to observe your market to time and plan changes.
  2. Validating strategy – a new method to safely and accurately define what your organization does.

Sensing your market

Changing enterprise strategy is costly and risky. Done too early, and you deliver perfectly on a vision but are unable to scale to more customers: the mainstream is not yet “ready.” Done too late, and you’re in a battle to win back customers, often with price cutting death spirals and comically disingenuous brand changes: you don’t have time for actual business innovation, so you put lipstick on discount pigs.

An innovation strategy relies on knowing the right time to enter the market. You need a strategy tool to continually sense and time the market. Like all useful strategy tools, it not only tells you when to change, but also when to stay the same, and how to prioritize funding and action. Based on our experience in the technology industry, we suggest starting with a simple model based on numerous tech market disruptions and market shifts. This model is Horace Dediu’s analysis of the post-2007 PC market. 2007, of course, is the year the iPhone was introduced. I’m not sure what to call it, but the lack of a label doesn’t detract from its utility. Let’s call it The Dediu Cliff:

The Dediu Cliff. Source: “The rise and fall of personal computing,” Jan 2012, Horace Dediu.

To detect when a market is shifting, Dediu’s model emphasizes looking beyond your current definition of your market. In the PC market, this meant looking at mobile devices in addition to desktops and laptops. Microsoft Windows and x86 manufacturers had long locked down the definition and structure of the PC market. Analyst firms like IDC tracked the market based on that definition and attempted disruptors like Linux desktop aspirants competed on those terms.

When the iPhone and Android were introduced in 2007, the definition of the PC market changed without much of anyone noticing. In a short 10 years, these “phones” came to dominate the “PC” market by all measures that mattered: time spent staring at the screen, profits, share increases, corporate stability and high growth, and customer joy. Meanwhile, traditional PCs were seen mostly as work horses, as commodities like pens and copy machines bought on refresh cycles with little regard to differentiation.

Making your own charts will often require some art. For example, another way to look at the PC market changing is to look at screen time per device, that is, how much time people spend on each device:

Screentime from Statcounter - Screen Shot 2019-08-08 at 2.49.37 PM.png
Screen time, or “engagement” as measured by web traffic. Notice that the analysis of the US market share has  iOS leading above Android. Source: Statcounter, queried 29 July 2019.

You have to find the type of data that fits your industry and the types of trends you’re looking to base strategy on. Those trends could be core assumptions that drive how your daily business functions. For example, many insurance businesses are still based on talking with an agent. So, in the insurance industry, you might chart online vs. offline browsing and buying:

Screen Shot 2019-08-07 at 3.28.14 PM
Source: Gartner L2, July 2019.

While more gradual than Deidu’s PC market chart, this slope will still allow you to track trends. Clearly, some companies aren’t paying attention to that cliff: as the Gartner L2 research goes on to say, once people look to go from quote to purchasing, only 38% of insurance companies allow for that purchase online.

Gaining this understanding of shifts in the very definition of your market is key. Ideally, you want to create the shift. If not, you want to enter the market once the shift is validated, as early as possible, even if the new entrant has single digit market share. Deploying your corporate resources (time, attention, and money) often takes multiple years despite the “overnight success” myths of startups. 

Timing is everything. Nailing that, per industry, is fraught, especially in highly regulated industries like banking, insurance, pharmaceuticals, and other markets that can use regulations to, uh, artificially bolster barriers to entry. Don’t think that high barriers to entry will save you though: Netflix managed to wreak havoc in the cable industry, pushing top telcoes even more into being dumb pipes, moving them to massive content acquisitions to compete.

I suggest the following general tactics to keep from falling off The Dediu Cliff:

  1. Know your customer – study their Jobs to be Done, maintain a good, “speaking” relationship with them.
  2. Consider Cassandras that use footnotes – track trend spotting, especially year over year (over year, over year).
  3. Try new things – experiment and incubate new ideas to continually test and participate in the market.

We’ll take a look at each of these, and then expand on how the third is generalized into your core innovation function.

Know your customer

Measuring what your customer things about you is difficult. Metrics like NPS and churn give you trailing indicators of satisfaction, but they won’t tell you when your customer’s expectations are changing, and, thus, the market.

You need to understand how your customer spends their time and money, and what “problems” they’re “solving” each day. For most strategy groups, getting this hands on is too expensive and not in their skill set. Frameworks like Jobs to Be Done and customer journey mapping can systemize this research, as we’ll see below, using a small batch process to implement your application allows you to direct strategy by observing what your customers actually interact with your business do day-to-day. 

Case Study: “The front door of the store is in your pocket,” Home Depot

In the ever challenging retail world, The Home Depot has managed to prosper by knowing their customer in detail. The company’s omnichannel strategy provides an example. Customers expect “omnichannel” options in retail, the ability to order products online, buy them in-store, order online but pick-up in-store, return items from online in-store…you get the idea. Accomplishing all of those tasks seems simple from the outside, but integrating all of those inventory, supply-chain, and payment systems is extremely difficult. Nonetheless, as Forrester has documented, The Home Depot’s concerted, hard fought work to get better at software is delivering on their omnichannel strategy: “[a]s of fiscal year 2018, The Home Depot customers pick up approximately 50% of all online orders in the store” and a 28% growth in online sales.

Advances in this business have been fueled by intimate knowledge of The Home Depot’s customers and in-store staff by actually observing and talking with them. “Every week, my product and design teams are in people’s homes or [at] customer job sites, where we are bringing in a lot of real-time insights from the customers,” Prat Vemana, The Home Depot’s Chief Digital Office said at the time.

The company focuses on customer journeys, the full, end-to-end process of customers thinking to, researching, browsing, acquiring, installing, and then using a product. For example, to hone in on improving the experience of buying appliances, the product team working on this application spent hours in stores studying how customers bought appliances. They also spent time with customers at home to see how they browsed appliance options. The team also traveled with delivery drivers to see how the appliances are installed.

Here, we see a company getting to know their customer and their problems intimately. This leads to new insights and opportunities to improve the buying experience. In the appliances example, the team learned that customers often wanted to see the actual appliance and would waste time trying to figure out how they could see it in person. So, the team added a feature to show which stores had the appliances they were interested in, thus keeping the customer engaged and moving them along the sales process. 

Spanning all these parts of the customer journey gives the team research-driven insights into how to deliver on The Home Depot’s omnichannel strategy. As customers increasingly start research on their phone, in social media, go instore to browse, order online, pick up instore, have items delivered, and so forth, many industries are figuring out their own types of omnichannel strategies. 

All of those different combinations and changing options will be a fog to strategy groups unless they start to get to know their customers better. As Allianz’s Firuzan Iscan puts it: “When we think from the customer perspective, most of our customers are hybrid customers. They are starting in online, and they prefer an offline purchasing experience. So that’s why when we consider the journey end to end, we need to always take care of online and offline moments of this journey. We cannot just focus on online or offline.”

Corporate strategy didn’t sign up for this

The level of study done at The Home Depot may seem absurd for the strategy team to do. Getting out of the office may seem like a lot of effort, but the days spent doing it will give you a deep, ongoing understanding of what your customers are doing, how you’re fulfilling their needs, and how you can better their overall journey with you to keep their loyalty and sell more to them. Also, it’s a good excuse to get out of beige cubicle farms and dreary conference rooms. Maybe you can even expense some lunches!

As we’ll see, when the product teams building these applications are put in place, strategy teams will have a rich source of this customer information. In the meantime, if you’re working on strategy, you’d be wise to fill that gap however you can. We’ll discuss one method next, listening to those people yelling and screaming doom and disruption.

Consider Cassandras

An early, ignored attempt to warn about that “book seller” in Seattle.

In Western mythos, Cassandra was cursed to always have 100% accurate prophecies but never be believed. For those of us in the tech industry, cloud computing birthed many Cassandras. Now, in 2019, the success of public cloud is indisputable. The on-premises market for hard and software is forever changed. Few believed that a “booker seller” would do much here or that Microsoft could reinvent itself as an infrastructure provider, turning around a company that was easily dismissed in the post-iPhone era.

Despite this, as far back as 2007, early Casandras were pointing out that software developers were using AWS in increasing numbers. Early on, RedMonk made the case that developers were the kingmakers of enterprise IT spend. And, if you tracked developer choice, you’d see that developers were choosing cloud. More Cassandras emerged over the years as cloud market share grew. Traditional companies heard these Cassandras, some eventually acting on the promises.

cloud spend.png
“Follow the CAPEX: Cloud Table Stakes 2018 Edition,” Charles Fitzgerald, February 2019.

Finally, traditional companies took the threat seriously, but as Charles Fitzgerald wickedly chronicled, it was too late. As his chart above shows, entering the public cloud market at this stage would cost $100’s of billions of dollars, each year, to catch up. The traditional companies in the infrastructure market failed to sense and act on The Cliff early enough – and these were tech companies, those outfits that are supposed to outmaneuver and outsmart the market!

Now, don’t take this to mean that these barriers to entry are insurmountable. Historically, almost every tech leader has been disrupted. That’s what happened in this market. There’s no reason to think that cloud providers are immune. We just don’t know when and how they’ll succumb to new competitors or, like Microsoft, have to reinvent themselves. What’s important, rather is for these companies to properly sense and respond to that threat.

There’s similar, though, rearview mirror oriented, stories in many industries. TK( listing or summarizing one in a non-tech company would sure be cool here ).

To consider Cassandras, you need a disciplined process that looks at year over year trends, primarily how your customers spend their time and money. Mary Meeker’s annual slide buffet is a good example: where are your customers spending their time? RedMonk’s analysis of developers is another example. A single point in time Cassandra is not helpful, but a Cassandra that reports at regular intervals gives you a good read on momentum and when your market shifts.

Finally, putting together your own Dediu Cliff can self-Cassandraize you. Doing this can be tricky as you need to imagine what your market will look like – or several scenarios. You’ll need to combine multiple market share numbers from industry analysts into a Cliff chart, updating it quarterly. Having managed such a chart, I can say it’s exhilarating (especially if someone else does the tedious work!) but can be disheartening when quarter by quarter you’re filed into an email inbox labeled “Cassandras.”

Thus far, our methods for sensing the market have been a research, even “assume no friction” methods. Let’s look at the final method that relies on actually doing work, and then how it expands into the core of the new type of strategy and breaking The Business Bottleneck.

Try new things

The best way to understand and call market shifts is to actually be in the market, both as a customer and a producer. Being a customer might be difficult if you’re, for example, manufacturing tractors, but for many businesses being a customer is possible. It means more than trying your competitor’s products. To the point of tracking market redefinition, you want to focus on the Jobs to Be Done, problems customers are solving, and try new ways of solving those problems. If this sounds like it’s getting close to the end goal of innovation, it’s because it is: but doing it in a smaller, lower cost and lower risk way.

For example, if you’re in the utility business, become a customer of in-home IoT devices, and how that technology can be used to steal your customer relationship, further pushing your business into a commodity position. In the PC market, some executives at PC companies made it a point of pride to never have tried, or “understood” the appeal of small screens – that kind of willful, proud ignorance isn’t helpful when you’re trying to be innovative. 

You need to know the benefits of new technologies, but also the suffering your products cause. There’s a story that management at US car manufacturers were typically given a company car and free mechanical service during the day while their car was parked at the company parking lot. As a consequence, they didn’t know first hand how low quality affected the cars. As Nassem Talab would put, they didn’t have any skin in the game…and they lost the game. Regularly put your skin in the game: rent a car, file an insurance claim, fill out your own expenses, travel in coach, and eat at your in-store delis.

Ket to trying new things is to be curious, not only in finding these things, but in thinking up new products to improve and solve the problems you are, now, experiencing first hand.

The goal of trying new things is to experiment with new products, using them to direct your strategy and way of doing business. If you have the capability to test new products, you can systematically sense changes in market definition. Tech companies regularly gloat new ideas as test products to sense customer appetite and, thus, market redefinitions. If you’ve ever used an alpha or beta app, or an invite only app, you’ve played a part in this process. These are experiments, ways the company tries new things. We laud companies like Google for their innovation successes, but we easily forget the long list of failed experiments. The website killedbygoogle.com catalogs 171 products that Google killed. Not all of these are “experiments,” some were long-running products that were killed off. Nonetheless, once Google sensed that an experiment wasn’t viable or a product no longer valid, they killed it, moving on.

When it comes to trying things, we must be very careful about the semantics of “failure.” Usually, “failure” is bad, but when it comes to trying new things, “failure” is better thought of as “learning.” When you fail at something, you’ve learned something that doesn’t work. When you’re feeling your way through foggy, frenetic market shifts requires tireless learning. So, in fact, “failing” is often the fastest way to success. You just need a safe, disciplined system to continually learn.

Validating strategy

Innovation requires failure. There are few guarantees that all that failure will lead to success, but without trying new things, you’ll never succeed at creating new businesses and preventing disruption. Historically, the problems with strategy has been the long feedback cycles required to tell you if your strategy “worked.”

First, budgets are allocated annually, meaning your strategy cycle is annual as well.Worse, to front-load the budget cycle, you need to figure out your strategy even earlier. Most of the time, this means the genesis of your current strategy was two, even three years ago. The innovation and business rollout cycles at most organizations are huge. TK( some long roll out figure). It can be even worse: five years, if not ten years in many military projects. Clearly, in “fast moving markets,” to use the cliché, that kind of idea-to-market timespan is damaging. Competing against companies that have shorter loops is key for organizations now. As one pharmacy executive put it, taking six months to release competitive features isn’t much use if Amazon can release them in two months.

Your first instinct might be the start trying many new things, creating an incubation program as a type of beta-factory of your own. The intention is good, but the risks and costs are too high for most large organizations. Learning-as-failure is expensive and can look downright stupid and irresponsible to share holders. Instead, you need a less costly, lower risk way to fail than throwing a bunch of things at the wall and seeing what sticks.

The small batch cycle

small batch doodle - Screen Shot 2019-08-08 at 3.04.20 PM.png
The small batch cycle.

Many organizations using what we’ll call the small batch cycle. This is a feedback loop that relies on four simple steps:

  1. Identify a problem to solve.
  2. Create a theory of how to solve the problem.
  3. Validate this theory by trying it out in real life.
  4. Analyze the results to see if the theory is valid or not.

This is, essentially, the scientific method. The lean startup method and, later, lean design has adapted this model to software development. This same loop can be applied “above the code” to strategy. This is how you can use failure-as-learning to create validated strategy and, then, start innovating like a tech company. 

As described above, due to long cycles, most corporate strategy is theoretical, at worse, PowerPoint arts and crafts with cut-and-pasting from a few web searches. The implementation details can become dicey and then there’s seeing if customers will actually buy and use the product. In short, until the first customer buys and uses the “strategy,” you’re carrying the risk of wasting all your budget and time on this strategy, often a year or more.

That risk might pay off, or it might not. Not knowing either way is why it’s a risk. A type of corporate “double up to catch up” mentality adds to the risk as well. Because the timeline is so long, the budget so high, and the risk of failure so large, managers will often seek the biggest bang possible to make the business case’s ROI “work.” Taking on a year’s time and $10m budget must have a significant pay off. But with such high expectations, the risk increases because more must be done, and done well. And yet, the potential downside is even higher as well.

This risky mentality has been unavoidable in business for the most part – building factories, laying phone lines, manufacturing, etc. require all sorts of up-front spending and planning. Now, however, when your business relies on software, you can avoid these constraints and better control the risks. Done well, software costs relatively little and is incredibly malleable. It’s, as they say, “agile.” You just need to connect the agile nature of software to strategy. Let’s look at an example.

Case Study: Most viable strategy: Duke Energy validates RFID strategy

As an energy company, Duke Energy has plenty of strategizing to do around issues like: disintermediation from IoT devices, deregulation, power needs for electric vehicles, and improving customer experience and energy conservation. Duke has a couple years of experience being cloud-native, getting far enough along to open up an 83,000-square- foot labs building housing 400 employees working in product teams.

They’re applying the mechanics of small batches and agile software to their strategy creation. “Journey teams” are used to test out strategies before going through the full-blown, annual planning process. “They’re small product-type teams led by design thinkers that help them really map out that new [strategic] journey and then identify [what] are the big assumptions,” Duke’s John Mitchell explained. Once identified, the journey teams test those assumptions, quickly proving or disproving the strategy’s viability.

Mitchell gives a recent example: labor is a huge part of the operating costs for a nuclear power plant, so optimizing how employees spend their time can increase profits and the time it takes to address issues. For safety and compliance reasons, employees work in teams of five on each job in the plant, typically scheduled in hour-long blocks. Often, the teams finish in much less than an hour, creating spare capacity that could be used on another job.

If Duke could more quickly, in near real-time, move those teams to new jobs they could optimize each person’s time. “So the idea was, ‘How can we use technology?’” Mitchell explains. “What if we had an RFID chip on all of our workers? Not to ‘Big Brother’ check in on them,” he quickly clarifies, but to better allocate the spare capacity of thousands of people. Sounds promising, for sure.

Not so fast though, Mitchell says: “You need to validate, will that [approach] work? Will RFID actually work in the plant?” In a traditional strategy cycle, he goes on, “[You’d] order a thousand of these things, assuming the idea was good.” Instead, Duke took a validated strategy approach. As Mitchell says, they instead thought, “let’s order one, let’s take it out there and see if it actually works in plant environment.” And, more importantly, can you actually put in place the networking and software needed: “Can we get the data back in real time? What do we do with data?” The journey team tested out the core strategic theories before the company invested time and money into a longer-term project and set of risks.

Key to all this, of course, is putting these journey teams in place and making sure they have the tools needed to safely and realistically test out these prototypes. “[T]he journey team would have enough, you know, a very small amount of support from a software engineer and designer to do a prototype,” Mitchell explains. “[H]opefully, a lot of the assumptions can be validated by going out and talking to people,” he goes on, “and, in some cases there’s a prototype to be taken out and validated. And, again, it’s not a paper prototype—unless you can get away with it—[it’s] working software.”

Once the strategic assumptions are validated (or invalidated, the entire company has a lot more confidence in the corporate strategy. “Once they … validate [the strategy],” Mitchell explains, “you’ve convinced me—the leader, board, whatever—that you know you’re talking about.”

It’s software

With software, as I laid out in Monolithic Transformation, the key ways to execute the loop are short release cycles, smaller amounts of code in each release, and the infrastructure capabilities to reliably reverse changes and maintain stability if things go wrong. 

These IT changes lead directly to positive business outcomes. Using a small batch cycle increases the design quality and cost savings of application design, directly improving your business. First, the shorter, more empirical, customer-centered cycles mean you better match what your customers actually want to do with your software. Second, because your software’s features are driven by what customers actually do, you avoid overspending on your software by putting in more features than are actually needed. 

For example, The Home Depot kept close to customers and “found that by testing with users early in the first two months, it could save six months of development time on features and functionality that customers wouldn’t use.” That’s 4 months time and money saved, but also functionality in the software that better matches what customers want.

As you mature, these capabilities lead to even wider abilities to experiment with new features like A/B testing, further honing down the best way to match what your software does to how your customers want to use it, and, thus, engage with your business. TK( quick example would be nice here ).

Software is the reason we call tech companies tech companies. They rely on software to run, even define their business. Thus, it’s TK( maybe? ) software strategy where we need to look at next.

An unused executive dinner speech

An empty table, set for fun.

I hosted an executive dinner a few weeks ago. I’d put together this opening talk, introducing the customer who was kind enough to come go through their story. I didn’t really get a chance to give it, which was probably for the best. Maybe next time

Thanks for coming – we’re glad y’all took the time. I know it’s hard.

My favorite thing about Pivotal is that I get to meet new people, computer people. My wife is always befuddled that I’m a wallflower in most company, but then, turn into an extrovert around computer people. So, it’s nice to meet more people like myself.

I’ve been at Pivotal almost five years and I’ve seen people like yourselves go through all sorts of transformations. They’re getting better at doing software. That’s setting them up to change how they run their business, to change what their business is, even. You can call it innovation, or whatever. Anyhow, I collect these stories – especially the parts where things go wrong – and in the Pivotal spirit of being kind and doing the right thing, try to help people who’re getting started by telling them the lessons learned.

Tonight, I’m hoping we can just get to know each other, especially amongst yourselves – us Pivotal people know each other well already!.

Most organizations feel like they’re the only ones suffering. They think their problems are unique. I get to talk with a lot of organizations, so I see the opposite. In general, everyone has the same problems and usually the same solutions.

Given that, I’d encourage you to talk with each other about what you’re planning, or going through. Chances are someone right next to you is in the same spot, or, if you’re lucky, has gotten past it.

As an example of that, we’re lucky that [customer who’s here] wanted share what’s been going on at [enterprise]. There’s lots of great stories in there…

So, let’s hear them…then let’s eat!

Speed, Accuracy, and Flexibility, IBM circa 1920

IBM punched card machine.

The purpose of a sales force is to bring a company’s value proposition—its “deal”—to customers. That value proposition results in the development of a company’s “go-to-market” strategy, how it will implement that plan. Central to that activity can be a direct sales force, people who meet face-to-face with customers, a typical approach with complex and expensive equipment. For simple products, a catalog or store can suffice, and today even a simple website will do. In 1914, ITR’s and Hollerith’s products were complicated, and so one had to make a clear case about why customers should buy them.

There was considerable consistency across the decades about IBM’s value proposition. Watson explained to a new batch of executives that, “We are furnishing merchants, manufacturers and other businessmen with highly efficient machines which save them money.” For the larger IBM community, he followed with, “That is why we are going to make more money for this business.” He spoke about how IBM created value. By 1920, Watson was preaching that the way to accomplish C-T-R’s goals was “to serve better industry’s vital requirements—the need to conserve time, motions and money.” He introduced a signature for IBM sales literature, too, that delivered a sound-bite value proposition used for decades: “Speed, Accuracy, and Flexibility.”

From IBM: The Rise and Fall and Reinvention of a Global Icon.

So what exactly should IBM do, and have done?

Now that IBM has ended its revenue losing streak, we’re ready to stick a halo on it:

There is no doubt, though, that there are signs of progress at IBM, which would not comment on its financial picture before the release of the earning report. So much attention is focused on the company’s top line because revenue is the broadest measure of the headway IBM is making in a difficult transformation toward cloud computing, data handling and A.I. offerings for corporate customers.

The new businesses — “strategic imperatives,” IBM calls them — now account for 45 percent of the company’s revenue. And though it still has a ways to go, IBM has steadily built up those operations — and gained converts.

Over all those quarters, there hasn’t been that much good analysis of “what went wrong” at IBM in so much as I haven’t really read much about what IBM should have been doing. What did we expect from them? What should they be doing now and in the future? I don’t know the answers, but I’m damn curious.

“State your deal.”

Since the mid-2000’s, all tech companies have been shit on for not getting to and dominating public cloud faster (there are exceptions like Adobe that get lost in the splurty noise of said shitting on). Huge changes have happened at companies HP/HPE and Dell/EMC/VMware (where I work happily at Pivotal, thank you very much), and you can see Oracle quarterly dance-adapting to the new realities of enterprise IT spending.

For the past 8 or 10 years I’ve had a rocky handle on what it is that IBM sell exactly, and in recent years their marketing around it has been fuzzy.  Try to answer the question “so what is it, exactly, that IBM sells?” A good companion is, “why do customers choose IBM over other options?”

You can’t say “solutions” or “digital transformation.” (I’m aware of some black kettle over here, but I and any Pivotal person could tell you exactly the SKUs, tools, and consulting we sell, probably on an index card). I’m pretty sure some people in IBM know, but the press certainly doesn’t know how the fuck to answer that question (with some exception at The Register and from TPM, grand sage of all IBM coverage).

I’ve been a life-long follower of IBM: my dad worked at the Austin campus, it was a major focus at RedMonk, and, you know, just being in the enterprise tech industry gets your face placed facing Armonk frequently. I feel like I know the company pretty well and have enough of an unnatural fascination to put up with spelunking through them when I get the chance; IBMers seem pleasantly bewildered when the first thing I ask them to do is explain the current IBM hierarchy and brand structure.

But I couldn’t really explain what their deal is now. I mean, I get it: enterprise outsourcing, BPaaS (or did they sell all that off?), some enterprise private cloud and the left over public cloud stuff, mainframe, a bunch of branded middleware (MQ, WebSphere, DB2, etc.) that they seem forbidden to mention by name, and “Watson.”

There are clear products & services (right?)

 

When I’ve been involved in competitive situations with IBM over the years, what they’re selling is very, very straight forward: outsourcing, software, and a sense of dependability. But the way they’re talked about in the press is all buzzwordy weirdness. I’m sure blockchain and AI could be a big deal, but their on and off success at doing something everyday, practical with it is weird.

Or, it could just be the difficulty of covering it, explaining it, productizing, and then marketing it. “Enterprise solutions” often amounts to individually customized strategy, programs, and implementations for companies (as it should, most of the time), so you can’t really wrap a clear-cut SKU around that. It’s probably equally hard to explain it to financial analysts.

So, what’s their deal?

Cumulative capex spend by Google, Amazon, and Microsoft since 2001.
How much is that public cloud in the window?

Anyhow, I don’t come here to whatnot IBM (genuinely, I’ve always liked the company and still hope they figure it out), but more out of actual curiosity to hear what they should have been doing and what they should do now. Here’s some options:

  1. The first option is always “stay on target, stay on target,” which is to say we just need to be patient and they’ll actually become some sort of “the business of AI/ML, blockchain, and the same old, useful stuff of improving how companies run IT.” I mean, sure. In that case, going private is probably a good idea. The coda to this is always “things are actually fine, so shut the fuck up with your negativity. Don’t kill my vibe!” And if this it true, IBM just needs some new comms/PR strategies and programs.
  2. You could say they should have done public cloud better and (like all the other incumbent tech companies except Microsoft), just ate it. What people leave out of this argument is that they would have had to spend billions (and billions) of dollars to build that up over the past 10 years. Talk about a string of revenue loosing quarters.
  3. As I’m fiddling around with, they could just explain themselves better.
  4. They should have gotten into actual enterprise applications, SaaS. Done something like bought Salesforce, merged with SAP, who knows. IBM people hated it when you suggested this.
  5. The always ambiguous “management sucks.” Another dumb answer that has to be backed up not with missed opportunities and failures (like public cloud), but also proving that IBM could have been successful there in the first place (e.g., with public cloud, would Wall Street have put up with them loosing billions for years to build up a cloud?)

I’m sure there’s other options. Thinking through all this would be illustrative of how the technology industry works (and not the so called tech industry, the real tech industry).

(Obviously, I’m in a weird position working at Pivotal who sells against IBM frequently. So, feel free to dismiss all this if you’re thinking that, now that you’ve read this swill, you need to go put on a new tin-foil hat because your current one is getting a tad ripe.)

More on “grim” automation – Notebook

A few weeks back my book review of two “the robots are taking over” came out over on The New Stack. Here’s some responses, and also some highlights from a McKinsey piece on automation.

Don’t call it “automation”

From John Allspaw:

There is much more to this topic. Nick Carr’s book, The Glass Cage, has a different perspective. The ramifications of new technology (don’t call it automation) are notoriously difficult to predict, and what we think are forgone conclusions (unemployment of truck drivers even though the tech for self-driving cars needs to see much more diversity of conditions before it can get to the 99%+ accuracy) are not.

Lisanne Bainbridge in her seminal 1983 paper outlines what is still true today.

From that paper:

This paper suggests that the increased interest in human factors among engineers reflects the irony that the more advanced a control system is, so the more crucial may be the contribution of the human operator.

When things go wrong, humans are needed:

To take over and stabilize the process requires manual control skills, to diagnose the fault as a basis for shut down or recovery requires cognitive skills.

But their skills may have deteriorated:

Unfortunately, physical skills deteriorate when they are not used, particularly the refinements of gain and timing. This means that a formerly experienced operator who has been monitoring an automated process may now be an inexperienced one. If he takes over he may set the process into oscillation. He may have to wait for feedback, rather than controlling by open-loop, and it will be difficult for him to interpret whether the feedback shows that there is something wrong with the system or more simply that he has misjudged his control action.

There’s a good case made for not only the need for humans, but to keep humans fully trained and involved in the process to handle errors states.

Hiring not abating

Vinnie, the author of one of the books I reviewed, left a comment on the review, noting:

For the book, I interviewed practitioners in 50 different work settings – accounting, advertising, manufacturing, garbage collection, wineries etc. Each one of them told me where automation is maturing, where it is not, how expensive it is etc. The litmus test to me is are they stopping the hiring of human talent – and I heard NO over and over again even for jobs for which automation tech has been available for decades – UPC scanners in groceries, ATMs in banking, kiosks and bunch of other tech in postal service. So, instead of panicking about catastrophic job losses we should be taking a more gradualist approach and moving people who do repeated tasks all day long and move them into more creative, dexterous work or moving them to other jobs.

I think Avent’s worry is that the approach won’t be gradual and that, as a society, we won’t be able to change norms, laws, and “work” over fast enough.

McKinsey

As more context, check out this overview of their own study and analysis from a 2015 McKinsey Quarterly article:

The jobs don’t disappear, they change:

Our results to date suggest, first and foremost, that a focus on occupations is misleading. Very few occupations will be automated in their entirety in the near or medium term. Rather, certain activities are more likely to be automated, requiring entire business processes to be transformed, and jobs performed by people to be redefined, much like the bank teller’s job was redefined with the advent of ATMs.

Further:

our research suggests that as many as 45 percent of the activities individuals are paid to perform can be automated by adapting currently demonstrated technologies… fewer than 5 percent of occupations can be entirely automated using current technology. However, about 60 percent of occupations could have 30 percent or more of their constituent activities automated.

Most work is boring:

Capabilities such as creativity and sensing emotions are core to the human experience and also difficult to automate. The amount of time that workers spend on activities requiring these capabilities, though, appears to be surprisingly low. Just 4 percent of the work activities across the US economy require creativity at a median human level of performance. Similarly, only 29 percent of work activities require a median human level of performance in sensing emotion.

So, as Vinnie also suggests, you can automate all that stuff and have people focus on the “creative” things, e.g.:

Financial advisors, for example, might spend less time analyzing clients’ financial situations, and more time understanding their needs and explaining creative options. Interior designers could spend less time taking measurements, developing illustrations, and ordering materials, and more time developing innovative design concepts based on clients’ desires.

Companies want more from offshore IT, likely leading to more on-shore IT growth

The most recent offshoring survey from Horses for Sources suggests that companies will have less use for traditional IT outsourcing.

When it comes to IT services and BPO, it’s no longer about “location, location, location”, it’s now all about “skills, skills, skills”.

Instead of “commodity” capabilities (things like password resets, routine programming changes, etc.), companies want more highly-skilled, innovative capabilities. Either offshorers need to provide this, or companies will in-source those skills.

Because offshorers typically don’t focus on such “open ended” roles, analysis of the survey suggests offshorers will have less business, at least new business:

aspirations for offshore use between the 2014 and 2017 State of the Industry studies, we see a significant drop, right across the board, with plans to offshore services.

And:

an increasing majority of customers of traditional shared services and outsourcing feel they have wrung most of the juice offshore has to offer from their existing operations, and aren’t looking to increase offshore investments.

What with the large volume of IT offshorers companies do, and how this outsourcing tends to control/limit IT capabilities, paying attention to these trends can help you predict what the ongoing “nature of IT” is in large offshorers.

This fits the offshoring and outsourcing complaining I hear from most all software teams in large organizations.

To me this read as “yes, we need to refocus IT to help us create and refine new business models.” You know, “digital transformation,” “cloud native,” and all that.

Source: “Offshore has become Walmartas Outsourcing becomes more like Amazon”

Linux killed Sun?

For the Sun: WTF? files:

Gerstner questioned whether three or four years from now any proprietary version of Unix, such as Sun’s Solaris, will have a leading market position.

One of the more popular theories for the decline of Sun is that they accepted Linux way, way too late. As a counter-example, there’s IBM saying that somewhere around 2006 you’d see the steep decline of the Unix market, including Solaris, of course.

If I ever get around to writing that book on Sun, a chart showing server OS market-share from 2000 to 2016 would pair well with that quote.

If you’ve read Stephen’s fine book, The New Kingmakers, you may recall this relevant passage:

In 2001, IBM publicly committed to spending $1 billion on Linux. To put this in context, that figure represented 1.2% of the company’s revenue that year and a fifth of its entire 2001 R&D spend. Between porting its own applications to Linux and porting Linux to its hardware platforms, IBM, one of the largest commercial technology vendors on the planet, was pouring a billion dollars into the ecosystem around an operating system originally written by a Finnish graduate student that no single entity — not even IBM — could ever own. By the time IBM invested in the technology, Linux was already the product of years of contributions from individual developers and businesses all over the world.

How did this investment pan out? A year later, Bill Zeitler, head of IBM’s server group, claimed that they’d made almost all of that money back. “We’ve recouped most of it in the first year in sales of software and systems. We think it was money well spent. Almost all of it, we got back.”

Source: IBM to spend $1 billion on Linux in 2001 – CNET

Talend IPO’s

The open source based data integration (basically, evolved ETL) company Talend IPO’ed this week. It’s a ten year old company, based on open source, with a huge French tie-in. Interesting all around. Here’s some details on them:

  • “1,300 customers include Air France, Citi, and General Electric.” That’s way up from 400 back in 2009, seven years ago.
  • In 2015 “Talend generated a total revenue of $76 million. Its subscription revenue grew 39% year over year, representing $62.7 million of the total. The company isn’t profitable: it reported a net loss of $22 million for 2015.”
  • “…much of that [loss] thanks to the $49 million it spent on sales and marketing,” according yo Julie Bort.
  • “Subscription revenue rose 27% to $63m while service fees stayed flat at $13m,” according to Matt Aslett.
  • It looks like the IPO performed well, up ~50% from the opening price.

TAM Time

By this point, I’m sure Talend messes around in other TAMs, but way back when I used to follow the business intelligence and big data market more closely, I recall that much of the growth – though small in TAM – was in ETL. People always like the gussy it up as “data integration”: sure thing, hoss.

That seems still be the case as spelled out a recent magic quadrant of the space (courtesy of the big dog in the space, Informatica):

Gartner estimates that the data integration tool market was worth approximately $2.4 billion in constant currency at the end of 2014, an increase of 6.9% from 2013. The growth rate is above the average for the enterprise software market as a whole, as data integration capability continues to be considered of critical importance for addressing the diversity of problems and emerging requirements. A projected five-year compound annual growth rate of approximately 7.7% will bring the total to more than $3.4 billion by 2019

In comparison, here’s the same from the 2011 MQ:

Gartner estimates that the data integration tools market amounted to $1.63 billion at the end of 2010, an increase of 20.5% from 2009. The market continues to demonstrate healthy growth, and we expect a year-on-year increase of approximately 15% in 2011. A projected five-year compound annual growth rate of approximately 11.4% will bring the total to $2.79 billion by 2015.

Meanwhile check out Carl Lehmann’s recent overview of Informatica and the general data integration market and Matt Aslett’s coverage of IPO plans back in June for a good overview of Talend.

Eventually, to do a developer strategy your execs have to take a leap of faith

A kingmaker in the making.

I’ve talked with an old colleague about pitching a developer-based strategy recently. They’re trying to convince their management chain to pay attention to developers to move their infrastructure sales. There’s a huge amount of “proof” an arguments you can make to do this, but my experience in these kinds of projects has taught me that, eventually, the executive in charge just has to take a leap of faith. There’s no perfect slide that proves developers matter. As with all great strategies, there’s a stack of work, but the final call has to be pure judgement, a leap of faith.

“Why are they using Amazon instead of our multi-billion dollar suite?”

You know the story. Many of the folks in the IT vendor world have had a great, multi-decade run in selling infrastructure (hardware and software). All the sudden (well, starting about ten years ago), this cloud stuff comes along, and then things look weird. Why aren’t they just using our products? To cap it off, you have Apple in mobile just screwing the crap out of the analogous incumbents there.

But, in cloud, if you’re not the leaders, you’re obsessed with appealing to developers and operators. You know you can have a “go up the elevator” sale (sell to executives who mandate the use of technology), but you also see “down the elevator” people helping or hindering here. People complain about that SOAP interface, for some reason they like Docker before it’s even GA’ed, and they keep using these free tools instead of buying yours.

It’s not always the case that appealing to the “coal-facers” (developers and operators) is helpful, but chances are high that if you’re in the infrastructure part of the IT vendor world, you should think about it.

So, you have The Big Meeting. You lay out some charts, probably reference RedMonk here and there. And then the executive(s) still isn’t convinced. “Meh,” as one systems management vendor exec said to me most recently, “everyone knows developers don’t pay for anything.” And then, that’s the end.

There is no smoking gun

If you can’t use Microsoft, IBM, Apple, and open source itself (developers like it not just because it’s free, but because they actually like the tools!) as historic proof, you’re sort of lost. Perhaps someone has worked out a good, management consultant strategy-toned “lessons learned” from those companies, but I’ve never seen it. And believe me, I’ve spent months looking when I was at Dell working on strategy. Stephen O’Grady’s The New Kingmakers is great and has all the material, but it’s not in that much needed management consulting tone/style. (I’m ashamed to admit I haven’t read his most recent book yet, maybe there’s some in there.)

Of course, if Microsoft and Apple don’t work out as examples of “leaders,” don’t even think of deploying all the whacky consumer-space folks out like Twitter and Facebook, or something as detailed as Hudson/Jenkins or Oracle DB/MySQL/MariaDB.

I think SolarWinds might be an interesting example, and if Dell can figure out applying that model to their Software Group, it’d make a good case study. Both of these are not “developer” stories, but “operator” ones; same structural strategy.

Eventually, they just have to “get it”

All of this has lead me to believe that, eventually, the executives have to just take a leap of faith and “get it.” There’s only so much work you can do — slides and meetings — before you’re wasting your time if that epiphany doesn’t happen.

The transformation is complete.

If this is your bag, come check out a panel on the developer relations at the OpenStack Summit on April 28th, in Austin — I’ll be moderating it!

So you want to become a software company? 7 tips to not screw it up.

Hey, I’ve not only seen this movie before, I did some script treatments:

Chief Executive Officer John Chambers is aggressively pursuing software takeovers as he seeks to turn a company once known for Internet plumbing products such as routers into the world’s No. 1 information-technology company.

Cisco is primarily targeting developers of security, data-analysis and collaboration tools, as well as cloud-related technology, Chambers said in an interview last month.

Good for them. Cisco has consistently done a good job to fill out its portfolio and is far from the one-trick pony people think it is (last I checked, they do well with converged infrastructure, or integrated systems, or whatever we’re supposed to call it now). They actually have a (clearly from lack of mention in this piece) little known-about software portfolio already.

In case anyone’s interested, here’s some tips:

1.) Don’t buy already successful companies, they’ll soon be old tired companies

Software follows a strange loop. Unlike hardware where (more or less) we keep making the same products better, in software we like to re-write the same old things every five years or so, throwing out any “winners” from the previous regime. Examples here are APM, middleware, analytics, CRM, web browsers…well…every category except maybe Microsoft Office (even that is going bonkers in the email and calendaring space, and you can see Microsoft “re-writing” there as well [at last, thankfully]). You want to buy, likely, mid-stage startups that have proven that their product works and is needed in the market. They’ve found the new job to be done (or the old one and are re-writing the code for it!) and have a solid code-base, go-to-market, and essentially just need access to your massive resources (money, people, access to customers, and time) to grow revenue. Buy new things (which implies you can spot old vs. new things).

2.) Get ready to pay a huge multiple

When you identify a “new thing” you’re going to pay a huge multiple of 5x, 10x, 20x, even more. You’re going to think that’s absurd and that you can find a better deal (TIBCO, Magic, Actuate, etc.). Trust me, in software there are no “good deals” (except once in a lifetime buys like the firesale fro Remedy). You don’t walk into Tiffany’s and think you’re going to get a good deal, you think you’re going to make your spouse happy.

3.) “Drag” and “Synergies” are Christmas ponies

That is, they’re not gonna happen on any scale that helps make the business case, move on. The effort it takes to “integrate” products and, more importantly, strategy and go-to-market, together to enabled these dreams of a “portfolio” is massive and often doesn’t pan out. Are the products written in the exactly the same programming language, using exactly the same frameworks and runtimes? Unless you’re Microsoft buying a .Net-based company, the answer is usually “hell no!” Any business “synergies” are equally troublesome: unless they already exist (IBM is good at buying small and mid-companies who have proven out synergies by being long-time partners), it’s a long-shot that you’re going to create any synergies. Evaluate software assets on their own, stand-alone, not as fitting into a portfolio. You’ve been warned.

4.) Educate your sales force. No, really. REALLY!

You’re thinking your sales force is going to help you sell these new products. They “go up the elevator” instead of down so will easily move these new SKUs. Yeah, good luck, buddy. Sales people aren’t that quick to learn (not because they’re dumb, at all, but because that’s not what you pay and train them for). You’ll need to spend a lot of time educating them and also your field engineers. Your sales force will be one of your biggest assets (something the acquired company didn’t have) so baby them and treat them well. Train them.

5.) Start working, now, on creating a software culture, not acquiring one

The business and processes (“culture”) of software is very different and particular. Do you have free coffee? Better get it. (And if that seems absurd to you, my point is proven.) Do you get excited about ideas like “fail fast”? Study and understand how software businesses run and what they do to attract and retain talent. We still don’t really understand how it all works after all these years and that’s the point: it’s weird. There are great people (like my friend Israel Gat) who can help you, there’s good philosophy too: go read all of Joel’s early writing of Joel’s as a start, don’t let yourself get too distracted by Paul Graham (his is more about software culture for startups, who you are not — Graham-think is about creating large valuations, not extracting large profits), and just keep learning. I still don’t know how it works or I’d be pointing you to the right URL. Just like with the software itself, we completely forget and re-write the culture of software canon about every five years. Good on us. Andrew has a good check-point from a few years ago that’s worth watching a few times.

6.) Read and understand Escape Velocity

This is the only book I’ve ever read that describes what it’s like to be an “old” technology company and actually has practical advice on how to survive. Understand how the cash-cow cycle works and, more importantly for software, how to get senior leadership to support a cycle/culture of business renewal, not just customer renewal.

7.) There’s more, of course, but that’s a good start

Finally, I spotted a reference to Stall Points in one of Chambers’ talks the other day which is encouraging. Here’s one of the better charts you can print out and put on your wall to look at while you’re taking a pee-break between meetings:

That charts all types of companies. It’s hard to renew yourself, it’s not going to be easy. Good luck!

The Problem with PaaS Market-sizing

Figuring out the market for PaaS has always been difficult. At the moment, I tend to estimate it at $20–25bn sometime in the future (5–10 years from now?) based on the model of converting the existing middleware and application development market. Sizing this market has been something of an annual bug-bear for me across my time at Dell doing cloud strategy, at 451 Research covering cloud, and now at Pivotal.

A bias against private PaaS

This number is in contrast to numbers you usually see in the single digit billions from analysts. Most analysts think of PaaS only as public PaaS, tracking just Force.com, Heroku, parts of AWS, Azure, and Google, and bunch of “Other.” This is mostly due, I think, to historical reasons: several years ago “private cloud” was seen as goofy and made-up, and I’ve found that many analysts still view it as such. Thus, their models started off being just public PaaS and have largely remained as so.

I was once a “public cloud bigot” myself, but having worked more closely with large organizations over the past five years, I now see that much of the spending on PaaS is on private PaaS. Indeed, if you look at the history of Pivotal Cloud Foundry, we didn’t start making major money until we gave customers what they wanted to buy: a private PaaS platform. The current product/market fit, then, for PaaS for large organizations seems to be private PaaS

(Of course, I’d suggest a wording change: when you end-up running your own PaaS you actually end-up running your own cloud and, thus, end up with a cloud platform. Also, things are getting even more ambiguous at the infrastructure layer all the time — perhaps “private PaaS” means more “owning” the PaaS layer, regardless of who “owns” the IaaS layer.)

How much do you have budgeted?

With this premise — that people want private PaaS — I then look at existing middleware and application development market-sizes. Recently, I’ve collected some figures for that:

  • IDC’s Application Development forecast puts the application development market (which includes ALM tools and platforms) at $24bn in 2015, growing to $30bn in 2019. The commentary notes that the influence of PaaS will drive much growth here.
  • Recently from Ovum: “Ovum forecasts the global spend on middleware software is expected to grow at a compound annual growth rate (CAGR) of 8.8 percent between 2014 and 2019, amounting to $US22.8 billion by end of 2019.”
  • And there’s my old pull from a Goldman Sachs report that pulled from Gartner, where middleware is $24bn in 2015 (that’s from a Dec 2014 forecast).

When dealing with large numbers like this and so much speculation, I prefer ranges. Thus, the PaaS TAM I tent to use now-a-days is something like “it’s going after a $20–25bn market, you know, over the next 5 to 10 years.” That is, the pot of current money PaaS is looking to convert is somewhere in that range. That’s the amount of money organizations are currently willing to spend on this type of thing (middleware and application development) so it’s a good estimate of how much they’ll spend on a new type of this thing (PaaS) to help solve the same problems.

Things get slightly dicey depending on including databases, ALM tools, and the underlying virtualization and infrastructure software: some PaaSes include some, none, or all of these in their products. Databases are a huge market (~$40bn), as is virtualization (~$4.5bn). The other ancillary buckets are pretty small, relatively. I don’t think “PaaS” eats too much database, but probably some “virtualization.”

So, if you accept that PaaS is both public and private PaaS and that it’s going after the middleware and appdev market, it’s a lot more than a few billion dollars.

(Ironic-clipart from my favorite source, geralt.)

OpenStack Summit 2016 Talks

The OpenStack Summit is in Austin this year, finally! So, I of course submitted several talks. Go over and vote for them – I think that does something helpful, who the hell knows?

Here’s the talks:

I’ll be at the Summit regardless, but it’d sure be dandy to do some of the above too.

New DevOps Column at The Register

I started a new column at The Register, on the topic of DevOps. I used the first column to layout the case that DevOps is a thing, and baseline for how much adoption there currently is (enough, but not a lot – a “glass almost half full” type of situation). I was surprised by how many comments it kicked up!

Next up, I’ll try to pick key concepts and explain them, along with best and worst practices for adoption of those concepts. Or whatever else pops up to fill 800 words. Tell me if you have any ideas!

(You may recall had a brief column at The Register back when I was at 451 Research.)

The Problem with PaaS Market-sizing

Figuring out the market for PaaS has always been difficult. At the moment, I tend to estimate it at $20-25bn sometime in the future (5-10 years from now?) based on the model of converting the existing middleware and application development market. Sizing this market has been something of an annual bug-bear for me across my time at Dell doing cloud strategy, at 451 Research covering cloud, and now at Pivotal.

A bias against private PaaS

This number is contrast to numbers you usually see in the single digit billions from analysts. Most analysts think of PaaS only as public PaaS, tracking just Force.com, Heroku, and parts of AWS, Azure, and Google. This is mostly due, I think, to historical reasons: several years ago “private cloud” was seen as goofy and made-up, and I’ve found that many analysts still view it as such. Thus, their models started off being just public PaaS and have largely remained as so.

I was once a “public cloud bigot” myself, but having worked more closely with large organizations over the past five years, I now see that much of the spending on PaaS is on private PaaS. Indeed, if you look at the history of Pivotal Cloud Foundry, we didn’t start making major money until we gave customers what they wanted to buy: a private PaaS platform. The current product/market fit, then, PaaS for large organizations seems to be private PaaS

(Of course, I’d suggest a wording change: when you end-up running your own PaaS you actually end-up running your own cloud and, thus, end up with a cloud platform.)

How much do you have budgeted?

With this premise – that people want private PaaS – I then look at existing middleware and application development market-sizes. Recently, I’ve collected some figures for that:

  • IDC’s Application Development forecast puts the application development market (which includes ALM tools and platforms) at $24bn in 2015, growing to $30bn in 2019. The commentary notes that the influence of PaaS will drive much growth here.
  • Recently from Ovum: “Ovum forecasts the global spend on middleware software is expected to grow at a compound annual growth rate (CAGR) of 8.8 percent between 2014 and 2019, amounting to $US22.8 billion by end of 2019.”
  • And there’s my old pull from a Goldman Sachs report that pulled from Gartner, where middleware is $24bn in 2015 (that’s from a Dec 2014 forecast).

When dealing with large numbers like this and so much speculation, I prefer ranges. Thus, the PaaS TAM I tent to use now-a-days is something like “it’s going after a $20-25bn market, you know, over the next 5 to 10 years.” That is, the pot of current money PaaS is looking to convert is somewhere in that range. That’s the amount of money organizations are currently willing to spend on this type of thing (middleware and application development) so it’s a good estimate of how much they’ll spend on a new type of this thing (PaaS) to help solve the same problems.

Things get slightly dicey depending on including databases, ALM tools, and the underlying virtualization and infrastructure software: some PaaSes include some, none, or all of these in their products. Databases are a huge market (~$40bn), as is virtualization (~$4.5bn). The other ancillary buckets are pretty small, relatively. I don’t think “PaaS” eats too much database, but probably some “virtualization.”

So, if you accept that PaaS is both public and private PaaS and that it’s going after the middleware and appdev market, it’s a lot more than a few billion dollars.

(Ironic-clipart from my favorite source, geralt.)

IBM Software Group no longer a formal entity?

But what we had not fully processed – and perhaps no one else did, either – is that at that moment Software Group, for all intents and purposes, was gone except as an amalgamated category for financial reporting to Wall Street.

So suggests TPM in his coverage of Steve Mills retiring.

The media doesn’t know what they’re talking about w/r/t Yahoo, a study in i-banker rhetoric

The notion that some in the media – who usually have no specific knowledge about Yahoo – have recklessly put forward that Yahoo is “unfixable” and that it should be simply “chopped up” and handed over for nothing to private equity or strategies is insulting to all long-term public shareholders.

This presentation is an example of many things we discuss on Software Defined Talk around large, struggling companies and the way they’re covered. Among other rhetorical highlights:

  • Check out how they make their case
  • Use visuals and charts
  • The informal nature of their language, e.g., they use the word “stuff” frequently
  • Their citations, e.g., citing themselves (I always love a good “Source: Me!”) and citing “Google Images”

These things, in my view, are neither good or bad: I’m more interested in the study of the rhetoric which I find fascinating for investment banker documents/presentations like this.

Not only that, it’s a classic “Word doc accidentally printed in landscape.” The investment community can’t help themselves.

As another note, no need to be such a parenthetical dick, below, to prove the point of a poor M&A history, just let the outcomes speak for themselves, not the people who do them.

img_4051

They actually do a better job in the very next slide, but that kind to pettiness doesn’t really help their argument. (Their argument is: she’s acquiring her friends.)

This is a type of reverse halo effect: we assume that tree standing goofiness has something to do with the business: an ad hominem attack. But, I think most billionaires probably have picture of themselves in trees, wearing those silly glove shoes, roasting their own coffee, only eating meat they kill themselves, or any number of other affectations that have nothing to do with profit-making, good or bad.

Solving the conundrums of our father’s strategies

So here we are, as of this writing a good twenty-nine years after the “hatchet job,” and Kodak has declared bankruptcy. The once-humming factories are literally being blown up, and the company’s brand, which Interbrand had valued at $14.8 billion in 2001, fell off its list of the top one hundred brands in 2008, with a value of only $3.3 billion. 6 It really bothered me that the future was so visible in 1980 at Kodak, and yet the will to do anything about it did not seem to be there. I asked Gunther recently why, when he saw the shifts coming so clearly, he did not battle harder to convince the company to take more forceful action. He looked at me with some surprise. “He asked me my opinion,” he said, “and I gave it to him. What he did beyond that point was up to him.” Which is entirely characteristic of scientists like Gunther. They may see the future clearly, but are often not interested in or empowered to lead the charge for change. Why do I know this story so well? He happens to be my father. —The End of Competitive Advantage, Rita McGrath.

You don’t get a sudden, personal turn like that in business books much. It evoked one of the latent ideas in my head: much of my interest in “business” and “strategy” comes from dad’s all too typical career at IBM in the 80s and 90s.

Sometime in the early 80s – or even late 70s? – my dad started working at IBM in Austin on the factory floor, printed circuit boards I believe. He’d tell me that he’d work the late shift, third shift and at 6am in the morning, stop by 7-11 with his buddies to get a six pack and wait in the parking lot of the Poodle Dog bar for it to open at 8.

He moved up to management, and eventually into planning and forecasting. All for hardware. I remember he got really excited in the late 80s when he got a plotter at home so he could work on foils, that is, transparencies. We call these “slides” now: you can still get a that battlefield-twinkle out of old IBM’ers eyes if you say “foils.”

Eventually, he lived the dictum of “I’ve Been Moved” and went up to the research triangle for a few years, right before IBM divested of his part of the company selling it to Multek (at least he got to return to Austin).

As you can guess, his job changed from a long-term one where his company had baseball fields and family fun days (where we have an outdoor mall, The Domain now) to the usual transient, productivity harvesting job. He moved over to Polycom eventually where he spent the rest of his career helping manage planning and shipping, on late night phone calls to Thailand manufacturers.

In addition to always having computers around – IBM PCs of course! – there was always this thing of how a large tech company evolves and operates. At the time, I don’t think I paid much attention to it, but it’s a handy reference now that I spend most of my time focused on the business of tech.

Two very different estimates of cloud email usage and forecasts

A while back I posted a quick quote from recent Gartner prognosticating about cloud email. The up-shot was that right now, it’s just about 8% for all types of companies, globally (except India and China for some reason). Someone from SpiceWorks left a comment that arecent survey of theirs indicated something much different, at least across the more SMB focused demographics they asked (out of 539 respondents, 46% were in companies of 10-99 employees, 23% were from companies of 100-249). Gartner, no doubt, covers a broader market, perhaps even weighted to larger companies (I don’t have access to the report, so I can’t look up the demographics).

For your entertainment, here are the two charts:

Email Moving to Cloud Estimates

Email Moving to Cloud Estimates

(The SpiceWorks 2014 estimate is a bit of fuzz-work on my part based on people’s claims to migrate in six months. If that bothers you, just assume it’s flat and the fun still stands.)

Building a Great Team (Dell buys Enstratius)

With the Enstratius acquisition, Dell is getting a group of people with deep influence in the community. Founder George Reese is an O’Reilly author and a cloud pioneer. He is supported by James Urquhart, Bernard Golden and John Willis, all recognized as influencers in the cloud community.
Alex Williams, TechCruch

This is the part I’m most excited about. I’ve worked with and known the team at Enstratius for many years, esp. John Willis who you may recall from the salad days of The IT Management & Cloud Podcast. The talent at Enstratius up and down the org is phenomenal and I can’t wait to start working with them in continuing to build Dell’s cloud portfolio. I’ve had a great time being part of the industry heavy-weights at Dell, and it’ll be a privilege to be part of the combined team.

In a coincidental note, check out Barton’s interview with John Willis on culture and DevOps, from last week’s DevOpsDays Austin.

Project Fast PaaS and Dell Cloud Labs

A couple of developers in our Dublin cloud labs started working on Cloud Foundry and set it up to run on our Dell cloud. You can check out more info and sign up for a invite to it.

Moving Beyond The PaaS Paradox

In my strategy role I’ve been looking at PaaS for awhile now. In doing that, I keep hitting upon what I call “The PaaS Paradox.” If you take any given analysts forecasts for PaaS, the overall market looks “bad” compared to IaaS and SaaS: $2.9B by 2016 by a recent Gartner estimate – or about 3% of the ~$110B public cloud market in 2016 (I subtracted out that annoying “advertising” segment that Gartner tracks).

And then you have some real gorillas already moving in there: Microsoft, Salesforce, Google, IBM, Oracle, and so on. While several billion may seem amazing to individuals, in the IT industry, it’s not much…esp. if you’re competing with those guys. (As another data point along the PaaS road: EngineYard helpfully reports its revenue from time-to-time, $28M back in July, 2011.)

And yet, everyone is always going on about how PaaS is mega important. Each year it’s going to be “the year of PaaS,” and analyst survey data always indicates high interest in PaaS.

My theory has been that when most people, esp. all those gleeful survey respondents, think of PaaS they’re not thinking of “pure PaaS” (or 1st and even 2nd generation PaaS). Instead, they just are thinking “doing software development with cloud technologies and practices.” Once you re-calibrate your whiz-bang charts to include all of software development, “PaaS” seems a lot more attractive.

I ran this by Jeffery Hammond and James Staten in a conversation the other day and they framed it in another, interesting way: people want the ability to run, and target different frameworks in a cloud context. Heroku is the classic of example of this. While Heroku is a PaaS, it’s more about being able to run rails (and plenty of other languages and frameworks now). This flexiblity fixes that unsettling feeling that 1st generation PaaS had: you were using, essentially, a propriety framework that was limiting your choice.

Or, as Stephen puts it: PaaS is the new middleware.

With that framing, you can escape the PaaS Paradox, and PaaS is a lot more interesting. So far, Cloud Foundry has seemed one of the better architectural fits for this “PaaS as middleware” think.” As we move “Project Fast” through (the new) Dell Cloud Labs, I’ll be eager to see how that architecture plays out and even more excited to see how the Dell community reacts to and participates in the project. As with Project Sputnik, a huge part of what we’re doing is engaging with developers, which sounds like a pretty good way to spend time to me.

Also: check out some demo videos of Project Fast PaaS.

Down on the Guadalupe River

Despite an estimated net worth of $1.2 billion, Mr. Weston, 48, lives modestly with his wife and three children in a 2,300-square-foot double-wide trailer on the banks of the Guadalupe River just outside of San Antonio. In addition to being a successful dot-com and real estate investor, he descends from British nobility on his mother’s side and Canadian grocery magnates on his father’s side, whose holdings include Twinings tea, Karo syrup, Fleishmann’s yeast, Fortnum & Mason and Selfridges.

via Rackspace Revitalizes a Defunct Mall Into an Unorthodox Tech Campus 

Things analysts forecasts won’t tell you

“These old technologies are holding us back. They’re anchors on where we want to go,” he said. “We find the things that have outlived their useful purpose. Our competitors are afraid to remove them. We try to find better solutions – our customers have given us a lot of trust. In general, it’s a good idea to remove these rotating medias from our computers and other devices. They have inherent issues — they’re mechanical and sometimes break, they use power and are large. We can create products that are smaller, lighter and consume less power.”

Ain’t no 5 year bar graph that says that

Integration is gonna be a problem for cloud

Enterprise software integration is hard and risky. Once you’ve invested in integrating your enterprise applications with one another (and/or with your partners’ applications), that integration becomes the #1 reason why you don’t want to change your applications. Or even upgrade them. That’s because the integration is an extension of the application being integrated. You can’t change the app and keep the integration. SOA didn’t change that.

Integration is lockin

Some Kind of Hybrid Cloud

Our customers are asking for two interrelated items: federation to public clouds and a choice of public cloud APIs. It’s been very consistent. Customers are all deploying some kind of hybrid solution. Some times they start in public and want to move some workloads back to private, like Zynga. Some times they start in private and want to move some workloads back to public. Regardless, it’s clear they want to run mixed mode for the forseeable future: some capacity in private and some in public. The challenge, then is for them have private clouds that are compatible with public clouds

Randy Bias on adding Google Cloud compatibility to OpenStack

Cloud is just computers

I get the big data part of the PureData announcements, but after analyzing the announcements and getting briefed by Big Blue, I still don’t get the cloud part. And I don’t get why the names on all of this stuff need to be so complicated.

TPM opening on PureData

Disruption

In other words, an upgrade to an over-serving product will be deferred at the slightest excuse while an installation of an under-serving product that attacks an unsolved problem will be rationalized no matter the circumstances

asymco

On Oracle Strategy

What I’ve come to realise is this. Oracle’s strategy hinges on one simple argument: investing in a complete integrated stack of Oracle technology (from server and storage hardware up through middleware to enterprise apps) will deliver you more value than investing in technology from a variety of suppliers.

The integration strategy

Enterprise vs. Consumer Bid’ness

Workday was founded seven years ago by two guys with the best imaginable pedigrees, deep pockets, and networks to call on to get stuff done quickly. Duffield and Bhusri raised a reported $250 million to get the company humming and grew steadily to reach $134 million in annual sales as of last January. That’s impressive, but by contrast consumer-focused file-sharing site Dropbox was founded two years after Workday and in that shorter stretch also raised $250 million and reached $240 million in sales.

Workday’s IPO

Dell Software

I’ve been working with the team standing up the Dell Software Group since I joined Dell in August, in the role of a corporate strategy guy. Back in March, we launched the group, which is very exciting. People often ask me what areas Dell will focus on in software. In today’s financial analyst meeting presentation, you can find this slide:

Dell's software focus areas

So there you go: security, systems management, business intelligence, and applications. When I was still at RedMonk, I started to see the assemblage of a software group at last year’s industry analyst conference, so it’s been fun to see – and help! – the sausage getting made.