“The goal is to continue building the engineering team to focus on building technology that allows restaurants to operate at a higher efficiency,” he said.
Most of the technology focuses on back-of-house operations, though Newlin declined to share details about that technology. On the front end, customers place orders using kiosks or its mobile app. A large screen then displays the customer’s name next to a countdown, which indicates exactly when an order will be ready.
“The general idea is figuring out how to run a restaurant based on statistics,” he said. “In the long term, we’re going to be running every piece of technology that touches on the customer and employee experience. We’re building a technology platform that will be the entire Birdcall ecosystem.”
“This allows an insurance broker to close and bind a product in real-time,” which also lowers the cost of onboarding new members, Fowler says.
Take-up was as we had expected – at peak times better than we’d expected – and it’s clear that not all our customers are ready for a totally till-free store. Some customers preferred to pay with cash and card, which sometimes meant they were queuing to use the helpdesk, particularly at peak times of day. This is why we’ve added a manned till and two self-checkouts back into the store so those looking to pay by cash and card can do so quickly and conveniently. We want to be the most inclusive retailer where people love to work and shop, so it’s really important to us that our customers can pay how they want to…. We’ll take the learnings from this experiment to develop our technology even further to help make shopping easier and more convenient for all our customers.
Daimler’s Thomas Müller, platform architect, spoke this morning at the summit about his company’s migration from IBM WebSphere to Pivotal Cloud Foundry (PCF) and illustrated another point, that the typical enterprise has more to worry about than K8s support.
His company began its transition from WebSphere in 2015 and it took until March 2019 to go live with 50 or so applications on PCF.
We saw a spike of over 70% points for our new monthly bill-pay option. In the past, we’ve said that monthly billing is not convenient for us, but our customers told us that’s what they want. When we gave it to them, they rewarded us with an auto bill-pay rate that spiked, which is important because autopay is a leading indicator of how long a customer will stay with us. We saw a 40% jump in ecommerce revenue almost overnight. We are now levering those learnings in our commercial markets.
For example, at Kessel Run, they tried different-sized teams before deciding that about eight people make up the ideal product team. They also learned not every big idea worked as planned.
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:
- 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.
- 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.
- New methods of payments will destroy your business, those pesky “tech companies.”
- So you should create some new (not credit card) payment methods
- 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.
- 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.
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
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:
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:
- Sensing your market – how to observe your market to time and plan changes.
- 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:
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:
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:
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:
- Know your customer – study their Jobs to be Done, maintain a good, “speaking” relationship with them.
- Consider Cassandras that use footnotes – track trend spotting, especially year over year (over year, over year).
- 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.
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.
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.
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
Many organizations using what we’ll call the small batch cycle. This is a feedback loop that relies on four simple steps:
- Identify a problem to solve.
- Create a theory of how to solve the problem.
- Validate this theory by trying it out in real life.
- 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.”
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.
Toyota is working to have 70% of new cars connected globally by 2020, with almost all of those in the U.S. and Japan. Automakers are already using the cloud to generate revenue through telematics insurance and car-sharing services.
Toyota also has talked about using data to alert dealers when cars need servicing, provide information about road and traffic conditions for smart city planning, and inform retailers where their customers are commuting from to allow more targeted marketing.
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.
The Business Bottleneck
All businesses have one core strategy: to stay alive. They do this by constantly offering new reasons for people to buy from them and, crucially, stay with them. Over the last decade, traditional businesses have been freaked by competitors that are figuring out better offerings and stealing those customers. The super-clever among these competitors innovate entirely new business models: hourly car rentals, next day delivery, short term insurance for jackets, paying for that jacket with your phone, banks with only your iPhone as a branch, incorporating real-time weather information into your reinsurance risk analysis.
In the majority (maybe all) of these cases, surviving and innovating is done well with small business and software development cycles. The two work hand-in-hand are ineffective without the other. I’d urge you think of them as the same thing. Instead of business development and strategy using PowerPoint and Machiavellian meeting tactics as their tool, they now use software.
You innovate by systematically failing weekly, over and over, until you find the thing people will buy and the best way to deliver it. We’ve known this for a long time and enshrined it in processes like The Lean Startup, Jobs to Be Done, agile development and DevOps, and disruption theory. While these processes are known and proven, they’ve hit several bottlenecks in the rest of the organization. In the past, we had IT bottlenecks. Now we have what I’ve been thinking of as The Business Bottleneck. There’s several of them. Let’s start by looking at the first, and, thus, most pressingly damaging one. The bottleneck that cuts off business health and innovation before it even starts: finance.
Most software development finance is done wrong and damages business. Finance seeks to be accurate, predictable, and works on annual cycles. This is not at all what business and software development is like.
Business & software development is chaos
Software development is a chaotic, unpredictable activity. We’ve known this for decades but we willfully ignore it like the advice to floss each day. Mark Schwartz has a clever take on the Standish software project failure reports. Since the numbers in these reports stay the same each year, basically, the chart below shows that that software is difficult and that we’re not getting much better at it:
What this implies, though, is something even more wickedly true: it’s not that these project failed, it was that we had false hopes. In fact, the red and yellow in the original chart actually shows that software is performs consistent to its true nature. Let me rework the chart to show this:
What this second version illustrates is that the time and budget it takes to get software software right can’t be predicted with any useful accuracy. The only useful accuracy is that you’ll be wrong in your predictions. We call it software engineering, and even more accurately “development” because it’s not scientific. Science seeks to describe reality, the be precise and correct – to discover truths that can be repeated. Software isn’t like that at all. There’s little science to what software organizations do, there’s just the engineering mentality of what works with what we have time and budget to do.
What’s more, business development is chaotic as well. Who knows what new business idea, what exact feature will work and be valuable to customers? Worse, there is no science behind business innovation – it’s all trial and error, constantly trying to both sense and shape what people and businesses will buy and at what price. Add in competitors doing the same, suppliers gasping for air in their own chaos quicksand, governments regulating, and culture changing people’s tastes, and it’s all a swirling cipher.
In each case, the only hope is rigorously using a system of exploration and refining. In business, you can study all the charts and McKinsey PDFs you want, but until you actually experiment by putting a product other there, seeing what demand and pricing is, and how your competitors will respond, you know nothing. The same is true for software.
Each domain has tools for this exploration. I’m less familiar with business development, and only know the Jobs to Be Done tool. This tool studies customer behaviors to discover what products they actually will spend money on, to find the “job” they hire your company to solve, and then change the business to profit from that knowledge.
The discovery cycle in software follows a simple recipe: you reduce your release cycle down to a week and use a theory-driven design process to constantly explore and react to customer preferences. You’re looking to find the best way to implement a specific feature in the UI to maximize revenue and customer satisfaction. That is, to achieve whatever “business value” you’re after. It has many names and diagrams, but I call this process the “small batch cycle.”
For example, Orange used this cycle when perfecting its customer billing app. Orange wanted to reduce traffic to call centers, thus lower costs but also driving up customer satisfaction (who wants to call a call center?). By following a small batch cycle, the company found that its customers only wanted to see the last two month’s worth of bills and their employees current data usage. That drove 50% of the customer base to use the app, helping remove their reliance on actual call centers, driving down costly and addressing customer satisfaction.
These business and software tools start with the actual customers, people, who are doing the buying and use these people as the raw materials and lab to run experiments. The results of these experiments are used to validate, more often invalidate theories of what the business should be and do. That’s a whole other story, and the subject of my previous book, Monolithic Transformation.
We were going to talk about finance, though, weren’t we?
The Finance Bottleneck
Finance likes certainly – forecasts, plans, commits, and smooth lines. But if you’re working in the chaos of business and software development, you can’t commit to much. The only certainty is that you’ll know something valuable once you get out there and experiment. At first all you’ll learn is that your idea was wrong. In this process, failure is as valuable as success. Knowing what doesn’t work, a failure, is the path to finding what does work, a success. You keep trying new things until you find success. To finish the absurd truth: failure creates success.
Software organizations can reliably deliver this type of learning each week. The same is true for business development. We’ve known this for decades, and many organizations have used it as their core differentiation engine.
But finance doesn’t work in these clever terms. “What they hell do you mean ‘failure creates success’? How do I put that in a spreadsheet?” we can hear the SVP of Finance saying, “Get the hell out of this conference room. You’re insane.”
Instead, when it comes to software development, finance focuses only on costs. These are easy to know: the costs of staff, the costs of their tools, and the costs of the data centers to run their software. Business development has similar easy to know costs: salary, tools, travel, etc.
When you’re developing new businesses and software, it’s impossible to know the most important number: revenue. Without that number, knowing if costs are good or bad is difficult. You can estimate revenue and, more likely, you can wish-timate it. You can declare that you’re going to have 10% of your total addressable market (TAM). You can just declare – ahem, assume – that you’re chasing a $9bn market opportunity. Over time, once you’ve discovered and developed your business, you can start to use models like consumer spending vs. GDP growth, or the effect of weather and political instability on the global reinsurance market. And, sure, that works as a static model so long as nothing ever changes in your industry.
For software development, things are even worse when it comes to revenue. No one really tells IT what the revenue targets are. When IT is asked to make budgets, they’re rarely involved in, nor given revenue targets. Of course, as laid out here, these targets in new businesses can’t be known with much precision. This pushes IT to just focus on costs. The problem here, as Mark Schwartz points out in all of his books, is that cost is meaningless if you don’t know the “value” you’re trying to achieve. You might try to do something “cheaply,” but without the context of revenue, you have no idea what “cheap” is. If the business ends up making $15m, is $1m cheap? If it ends up making $180m, is $5m cheap? Would it have been better to spend $10m if it meant $50m more in revenue?
IT is rarely involved in the strategic conversations that narrow down to a revenue. Nor are they in meetings about the more useful, but abstract notion of “business value.” So, IT is left with just one number to work with: cost. This means they focus on getting “a good buy” regardless of what’s being bought. Eventually, this just means cutting costs, building up a “debt” of work that should have been done but was “too expensive” at the time. This creates slow moving, or completely stalled out IT.
A rental car company can’t introduce hourly rentals because the back office systems are a mess and take 12 months to modify – but, boy, you sure got a good buy! A reinsurance company can’t integrate daily weather reports into its analytics to reassess its risk profile and adjust its portfolio because the connection between simple weather APIs and rock-solid mainframe processing is slow – but, sister, we sure did get a good buy on those MIPS! A bank can’t be the first in its market to add Apple Pay support because the payments processing system takes a year to integrate with, not to mention the governance changes needed to work with a new clearinghouse, and then there’s fraud detection – but, hoss, we reduced IT costs by $5m last year – another great buy!
Worse than shooting yourself in the foot is having someone else shoot you in the foot. 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. But, hey! Our software development processes cost a third less than the industry averages!
Business development is the same, just with different tools and people who wear wing-tips instead of toe-shoes. Hopefully you’re realizing that the distinction between business and software development is unhelpful – they’re the same thing.
The business case is wrong from the start
So, when finance tries to assign a revenue number, it will be wrong. When you’re innovating, you can’t know that number, and IT certainly isn’t going to know it. No one knows the business value that you’re going to create: you have to first discover it, and then figure out how to deliver it profitably.
As is well known, the problem here is the long cycle that finance follows: at least a year. At that scope, the prediction, discovery, and certainty cycle is sloppy. You learn only once a year, maybe with indicators each quarter of how it’s going. But, you don’t really adjust the finance numbers: they don’t get smarter, more accurate, as you learn more each week. It’s not like you can go get board approval each week for the new numbers. It takes two weeks just to get the colors and alignment of all those slides right. And all that pre-wiring – don’t even get me started!
In business and software development, each week when you release your software you get smarter. While we could tag shipping containers with RFID tags to track them more accurately, we learn that we can’t actually collect and use that data – instead, it’s more practical to have people just enter the tracking information at each port, which means the software needs to be really good. People don’t actually want to use those expensive to create and maintain infotainment screens in cars, they want to use their phones – cars are just really large iPhone accessories. When buying a dishwasher, customers actually want to come to your store to touch and feel them, but first they want to do all their research ahead of time, and then buy the dishwasher on an app in the store instead of talking with a clerk.
These kinds of results seem obvious in hindsight, but business development people failed their way to those success. And, as you can imagine, strategy and finance assumptions made 12 to 18 months ago that drove businesses cases often seem comical in hindsight.
A smaller cycle means you can fail faster, getting smarter each time. For finance, this means frequently adjusting the numbers instead of sticking to the annual estimates. Your numbers get better, more accurate over time. The goal is to make the numbers adjust to reality as you discover it, as you fail your way to success, getting a better idea of what customers want, what they’ll pay, and how you can defend against competition.
Small batch finance
Some companies are lucky to just ignore finance and business models. They burn venture capital funding as fuel to rocket towards stability and profitability. Uber is a big test of this model – will it become a viable business model (profitable), or will it turn out that all that VC money was just subsidizing a bad business model? Amazon is a positive example here, over the past 20 years cash-as-rocket-fuel launched them to boatloads of profit.
Most organizations prefer a less expensive, less risky methods. In these organizations, what I see are programs that institutionalize these failure driven cycles. They create new governance and financing models that enforce smaller business cycles, allowing business and software development to take work in small batches. Allianz, for example, used 100 day cycles discover and validate new businesses. Instead of one chance every 365 days to get it right, they have three, almost four. As each week goes by, they get smarter, there’s less waste and risk, and finance gets more accurate. If their business theory is validated, the new business is graduated from the lab and integrated back into the relevant line of business. The Home Depot, Thales, Allstate, and many others institutionalize similar practices.
Each of these cycles gives the business the chance to validate and invalidate assumptions. It gives finance more certainly, more precision, and, thus, less errors and risk when it comes to the numbers. Finance might even be able to come up with a revenue number that’s real. That understanding makes funding business and software development less risky: you have ongoing health checks on the viability of the financial investment. You know when to stop throwing good money after bad when you’ve invalidated your business idea. Or, you can change your assumptions and try again: maybe no one really wants to rent cars by the hour, maybe they want scooters, or maybe they just want a bus pass.
Business cases focused on growth, not costs
With a steady flow of business development learning, you can start making growth decisions. If validate that you can track a team of nuclear power plant workers better with RFID badges, thus directing them to new jobs more quickly and reducing costly downtime, you can then increase your confidence that spending millions of dollars to do it for all plant workers with payoff. You see similar small experiments leading to massive investments in omnichannel programs at places like Dick’s Sporting Goods and The Home Depot.
Finance has to get involved in this fail-to-success cycle. Otherwise, business and software development will constantly be driven to be the cheapest provider. We saw how this generally works out with the outsourcing craze of my youth. Seeking to be the cheapest, or the synonomic phrase, the “most cost effective,” option ends up saving money, but paralyzing present and future innovation.
The problem isn’t that IT is too expensive, or can’t prove out a business case. As the Gartner study above shows, the problem is that most financing models we use to gate and rate business and software development are a poor fit. That needs to be fixed, finance needs to innovate. I’ve seen some techniques here and there, but nothing that’s widely accepted and used. And, certainly, when I hear about finance pushing back on IT businesses cases, it’s symptomatic of a disconnect between IT investment and corporate finance.
Businesses can certainly survive and even thrive. The small, failure-to-success learning cycles used by business and software developers works, are well known, and can be done by any organization that wills it. Those bottlenecks are broken. Finance is the next bottleneck to solve for.
I don’t really know how to fix it. Maybe you do!
Crawl into the bottleneck
After finance, for another time, my old friends: corporate strategy. And if you peer past that blizzard of pre-wired slides and pivot tables, you can see just in past the edges of the next bottleneck, that mysterious cabal called “The C-Suite.” Let’s start with strategy first.
“According to research by Evercore Group L.L.C., Booking.com’s “testing drives conversions across the whole platform at 2–3 times the industry average.” That means massive increases to their revenue and bottom line.”
How Booking.com A/B Tests Ten Novenonagintillion Versions of its Site
This focus on the people behind the coffee beans could strengthen positive consumer sentiment around Starbucks’ brand and give it more of a human element as it continues to stretch its global reach. The move could also drive other coffee chains to make their supply chain journeys accessible to their customers. Investing in traceability isn’t unusual in the coffee space — Philz Coffee, for example, provides a breakdown of the steps of the coffee journey it has access to, but leveraging that information for interactive marketing purposes is still a ripe opportunity.
In terms of the best integration architecture, what seems to me the only long-term solution is something like the unified log architecture that Jay Kreps wrote about back in 2013. All incoming writes need to go into a centralized log, such as Kafka, and then from there the various databases can pull what they need, with each team making its own decisions about what it needs from that central log. However, SuperRentalCorp has retail outlets with POS (point of sale) systems which talk directly to specific databases, and the path of that write (straight from the POS to the database) is hardcoded in ways that will be difficult to change, so it will be a few years before the company can have a single write-point. For now, each database team needs to be accepting writes from multiple sources. But a unified log is the way to go in the long-term. And that represents a large change of process for every one of those 20 teams. Which helps explain why the company has spent 2 years and $25 million trying to build an API, and so far they have failed.
“When we moved to the cloud the first time, we cut down the lead time for an environment from 100 days to 85 days. This is self-inflicted lead time… processes that are keeping you from moving faster,” he said.
“We also had 30 people involved in a classic delivery, and we figured the cost was around €40,000 to provision an environment, in work time, handovers and meetings and what not.”
Source: Domino’s will start robot pizza deliveries in Houston this year
There’s a level of empathy needed for those on the frontline when making business decisions, especially decisions related to IT. Effective leaders are concerned with making the right call, said Gaffney. Ineffective leaders tend to implement practices and approaches that take small incremental de-risking steps, “led by dates and budgets and not happy humans.”
You’re basically breaking things down into smaller increments. I’m constantly getting in front of the customer. At the end of the day, you’re delivering really what the customer wants from you.
So you may be able to start giving value to your customer much quicker. Even though they’re not getting 100% of what they want, they get an MVP [minimum viable product] that they can start to utilize, they can start to realize value and give you feedback on that. That may influence the rest of what you’re building as well.
Most, if not all, teams I have worked with (in the capacity as the Agile Coach in The Lab) do not know what truly matters to their customers. Through numerous planning sessions with key stakeholders from ‘the business’, they gather requirements for their product development. These plans sound great until you start asking a few questions, for example: ‘What are the biggest problems facing your customers?’, ‘How have you validated the requirements with your customers?’, ‘Will the proposed solution actually work in their context?’. Upon asking these kinds of questions, they quickly understand that the proposed backlog of work is frequently what the business wants, not what their customers need. Using design thinking approach and applying techniques for user research and validation, the teams had the opportunities to understand the need of real customers. Talking to a real customer isn’t that hard, but the insights can be quite profound.
What all of those “unicorns” have in common are flat organizations with small teams that are responsible for a product or feature, including receiving feedback from their customers and guiding the future of the product. ING decided to transform its business to be more agile.
The cliché we all recite is that technology isn’t the problem, culture is. Put another way: if the hardware and software are fine and fresh, it must be the meatware that smells. Come hear several de-funking recipes from the world’s largest companies whose meat now smells proper.
I answered a few attendee questions in the webinar, and answered the rest in a Twitter thread afterwards.
On Sainsbury’s move and use of AWS, serverless, and DevOps:
“Our relationship with AWS really kicked off at the point we decided to take our groceries online business and rebuild it in the cloud. This was effectively taking a WebSphere e-commerce monolith with an Oracle RAC database, and moving it, and modularising it, and putting it into AWS,” Sainsbury’s CIO Phil Jordan told the audience.
“That movement of RAC to RDS and that big database migration was all done using AWS services, and now we have a fully fledged cloud-native-ish service that runs groceries online across all of our business. Today, we run about 80 per cent of our groceries online with EC2, and 20 per cent is serverless.”
In total, the company migrated more than 7TB of data into the cloud. As a result, or so Jordan claimed, the mart spends 30 per cent less on infrastructure, and regularly sees a 70-80 per cent improvement in performance of interactions on the website and batch processing. So far, there’s been no “major” outages, said the CIO, without defining “major”.
Moving to the cloud has also helped Sainsbury’s into the warm infinity-looped embrace of DevOps. The company has moved from five to six releases per year to multiple releases per day, said the CIO.
Check out their talk, scrub in to about 24:10.
Related, the Sainsbury’s tech blog is pretty good.
And, from elsewhere and unrelated to Sainsbury’s, some clearer notion that “serverless” forces an event-driven architecture:
So why can’t we just write an event-driven system for our corporate infrastructure? Our world, is event-driven, and generally, we reduce the complexity of our systems by just defining events. “When there’s an access to the FTP service of upload … do this …”, “When there’s an access on a column on a database … do this “. In an IoT world, with billions of disparate devices, it is the only way to go. And if we are to create truly citizen-focused systems, we need to define the events which trigger. How many organisations could crisply define the operation of their infrastructure and all the interactions that happen?
Rather than just defining a server running Exchange, we could have some code which triggers on “When Bob logs-in open up his mail box”, or “When Alice changes the marks for her students, send an update to the exams office”. This is a world where the complexity of servers moves us towards “The Cloud” as a computation resource. In this way we write rules based on events and enact them in the Cloud. There’s no concept of running Exchange or Web servers.
As a team, going serverless has given us a lot more velocity, we can rapidly release, we can test the same infrastructure we’re deploying in production, in a pull request environment, in a staging environment, we can rapidly retest ideas- and every developer can do that because we’re using Lambda to load test, so the power it gives you as a developer and engineering team is pretty amazing.
The power of focus. Before the crisis, each team worked on its own backlog and specialized in its domain. In the backlog, there were finely decomposed tasks, the team selected several tasks for a sprint. But during the crisis, we worked quite differently. The teams did not have specific tasks, they had a big challenging goal instead. For example, a mobile app and API must handle 300 orders per minute, no matter what. It is up to the team how to achieve the goal. The teams themselves formulate hypotheses, quickly check them in Production and throw away. And this is exactly what we wanted to continue doing. Teams do not want to be dumb coders, they want to solve problems.
The power of focus manifested itself in solving complex problems. For example, during the crisis, we created a set of performance tests in spite we had no expertise. We also made the logic of receiving an order asynchronous. We have long thought about it and talked, and it seemed to us that this is a very difficult and long task. But it turned out that the team is quite capable of doing it in 2 weeks, if it they are not distracted and completely focused on the problem.
There is an old-timey model in which the key elements of banking are, like, having a local branch, looking customers in the eye and giving them a hearty handshake, knowing their parents, etc. But in modern banking the importance of having a website and a payments app and, uh, “keeping track of customer deposits” is relatively higher, and the handshaking is relatively less important. For big banks, this means that they are increasingly and self-consciously becoming tech companies, building apps and hiring developers and blathering about blockchain. For small banks, it means that they are increasingly and unhappily becoming franchises of tech companies.
“There are a million solutions out there to your technical problems, but what we wanted was to solve the people and process problems,”
“It depends on Pivotal. If they add a common pattern in the future for deployment with Istio and Envoy through a cluster and platform-agnostic service mesh, then, yes, we will combine them,” said another senior engineer at the carrier.
“Don’t get excited about shipping a feature—get excited about when the feature turns into revenue and turns into profit.”
Chegg isn’t digital-only today. They still ship five million textbooks a year – but their mission has changed. And, as Narayan pointed out, they now need new metrics. Rosensweig said those metrics include subscriber growth, revenue growth, engagement, renewal, and conversion rates. But there’s an underlying metric: create something awesome.
What we learned was you not only have to get them to subscribe, you [also have to] lower your cost to customer acquisition, which at one point for us was 27 dollars. Now it’s $3.50. Our renewal rates were 63 percent; they’re now in the mid-80s for a monthly renewal.
One of the global leading banks created about 30 platforms. One such platform was payments, which consisted of more than 60 applications that previously had been managed independently from each other. The top team decided to bring the 300-plus IT people working on development and maintenance of payments together with the corresponding people on the business side. Under joint business/IT leadership, this entity was empowered to move quickly on priority business initiatives, to modernize the IT structure, and to allocate the resources to make that happen.
The team shifted its working model and started running the payments platform as an internal business that served all the different parts of the bank (think payments as a service). This approach made it clear where to focus specific tech interventions: removal of nonstrategic IT applications; modernization and accelerated shift of the target applications into the cloud; connectivity to enable swapping solutions in or out easily; and, most important, a major step-up in feature/solution development for the internal business clients. This platform-based way of running the business was then progressively rolled out across the group. Prioritization is set by the top team (because empowerment does not mean anarchy), and all IT interventions are run the same way, to ensure consistency and replicability.
Their notion of a platform is more like the old API economy thing:
A platform-based company will have 20 to 40 platforms, each big enough to provide an important and discrete service but small enough to be manageable. To simplify platform management, it helps to group them into three broad areas: customer journeys, business capabilities, and core IT capabilities (Exhibit 1).
For example, in personal banking, the customer-journey platforms cover the customer experiences of searching, opening an account, getting a mortgage, and so on. The business-capability platforms deliver the banking solutions, such as payments and credit analytics, and the support capabilities, such as employee-pension management, visual dashboarding, and management information systems (MIS). Finally, the core IT platforms provide the shared technology on which the journeys and business capabilities run, such as the cloud platform, the data analytics environment, and the set of IT connectivity solutions.
Inside this interview, there’s an excellent explanation of what product management means in an enterprise. By “enterprise,” I mean a company who’s product is not technology. That is, most every company and organization out there. To that end, there’s a great example of doing product management and design at a food services company: discovering the actual problem to solve to meet business needs, and solving it by experimenting with a small batch loop.
See also the original show notes.
To improve the way you do software, I recommend starting up a new organization. It’s not always the right tactic, but it probably is if you’re having problems changing the “culture” at your organization.
Duke Energy has had success with this approach over the years. In one of my recent Pivotal Conversations podcasts, I talked with John Mitchell, who’s been involved in their transformation over the years. They’d just opened a brand new (well, renovated from an old factory) office to host the existing teams (something like 4 or 5 if I recall) and the supporting teams.
Here’s a summary:
Duke Energy has been working on their software capabilities for some time now. They’ve recently reached a milestone by opening a brand new innovation center in Charlotte. Coté took a tour of it recently checking out the numerous product teams and their approach to exploring and building strategy, all the way from corporate strategy down to writing code. John also shares a couple of new examples of how lean product management and design in action. Also: gingham.
Few organizations have or rely on as much software the US Air Force. There’s plenty of it around and, thus, plenty to be improved. In recent years, one of the more spectacular digital transformation stories has come from the USAF’s work modernizing their Air Operations Control software. In this episode, USAF’s Bryon Kroger goes over how they’ve moved multi-year release cycles to just weeks in the Kessel Run projects. Much of the work is in the “fuzzy front” end of planning and procurement, but as Bryon says, an equally, hearty serving has to do with building up people’s skills, moral, and the overall culture.
One of my recent Pivotal Conversations episodes. There’s a play list collecting together other “customers” talking, rather than the usual of us Pivotal people just talking to ourselves.
An IoT use case, for tracking cows, that actually helps out the business (in addition to the customers, the ranchers):
Rabobank’s network and financial support helped mOOvement enormously, says Van de Ven. The bank has also benefited from the product. Van de Ven: “Nowadays, you can use satellite images to determine the condition of the grass. Combining that data with precipitation patterns and the GPS data from the cows generates interesting insights for both the farmer and the bank, such as the cows’ condition and what the ideal number of cattle is to graze on the land during a particular period. Using up-to-date information means the bank can make better decisions about financing requests than if it were to use the annual figures from the previous year. MOOvement enables us to serve not only the farmer, but also the bank.”
Wells Fargo, explains how the company is combating advanced persistent threats, as well as an onslaught of CVEs, by repaving its entire platform multiple times per week — with a goal of doing so every day by the end of 2019.
That is, they rebuild production three times a week, probably now more.
“it was not a question of replacing our experts but of increasing the skills of the group’s internal teams,” says Thierry Morcq.
(Translated with Google Translate.)
Original source: How Air France – KLM designed its PaaS Cloud Foundry
If you build it, you own it, big data ed.:
“We got some value out of that but to be honest we found it hard to keep on top of, just hard to build skills at the pace required to integrate new technologies,” Knott says.
“No matter how hard we ran there is always something new coming in that we wanted to get access to, but we couldn’t get there quite fast enough to have really finished deploying what we were deploying previously.
“So it was hard to manage, hard to keep on top of, and also hard to scale. We had reasonable success but we were having these challenges.””
Original source: HSBC chief architect: Why machine learning is accelerating cloud adoption
More coverage of the US Air Force going all in on digital XP, lean design, and cloud native to dramatically – almost unbelievably so – modernize their software.
The mission capabilities these war fighters received in 120 days or less span deliberate targeting, mission reporting, advanced target production, refueling operations and many more, saving over $6.4 million and 1,100 man-hours per month within the Air Force Central Command.
Embracing agile software development processes, the AOC leverages a highly disciplined approach to software engineering called Extreme Programming (XP), to gain the benefits of test-driven development, pair programming, continuous integration and continuous delivery (CI/CD).
Original source: Mission capability delivered at startup speed
There needs to be a place where you can fail and there’s no implication to your career. [The innovation lab] is a safety net. Anyone in the company can take a day in a week to work with the team [at the lab] and innovate together and talk through the idea.
Original source: Singapore Airlines employees urged to innovate, fail without fear
Signaling change with symbolic acts that embody the new culture is a good way to activate leadership characteristics quickly. For example, companies can designate meeting-free days to emphasize greater focus on action over planning, or they can give engineers a cash allowance to buy their own desktop equipment to demonstrate trust. Sometimes even a bold move, such as firing people whose behavior is antithetical to the new culture, is warranted. To signal change at Cisco, executives in certain divisions gave up their offices so the company could create team rooms; the company also started allowing employees to choose the workspace and tech tools that best fit their individual roles. The CEO of the North American software provider cited earlier began sending notes to employees who are praised by name in customer reviews. Such acknowledgment serves as an example of how company leaders can reinforce the customer-first mindset that’s central to the company culture.
And more leadership tactics from BCG.
Original source: It’s Not a Digital Transformation Without a Digital Culture
Owen covers CF Summit Basel:
“The users we spoke with didn’t just see it as a PaaS – it was the underlying philosophy of application delivery and management upon which future developments would be based. The Foundation claims Cloud Foundry saves, on average, 10 weeks of development time and $100,000 per app development cycle. In fact, in its own survey, 92% of users cite cross-platform flexibility as important. If these panelists are gaining such benefits, it’s easy to understand why they are so enamored with it.”
Original source: Cloud Foundry Cult
Any problems discovered in the software can be more easily corrected, a small failure being preferable to correcting the shortfalls of an entire software suite. Changes requested by the customer can sometimes be delivered in just a couple days.
Prior to Jigsaw, the tanker mission planners would use whiteboards to plot out their fueling rendezvous.
“Rather than taking hours to run the calculations by hand for the hundreds of sorties scheduled each day to find a feasible plan,” Tatro said. “The program logs events in order to detect and report errors in scheduling.”
It didn’t take long for the new software to start paying off.
“Before Jigsaw was delivered to the tanker planners, they would be spending 8 to 12 hours a day with a team of five planning a day of tanker missions,” Maung said. “Now they only need three people and it takes them 4 to 5 hours, usually done before lunch.”
Since the program was put into use in April 2017, Jigsaw has saved approximately $200,000 per day, just in fuel. There were other benefits as well.
Original source: Cyber Airmen fuel innovation
In 2011 Friedberg decided to sell exclusively to farmers, and WeatherBill changed its name to The Climate Corporation. “We needed to feel a little less Silicon Valley and less whimsical,” said Friedberg. For the next few years he would spend half his time on the road, explaining himself to people whose first step was toward mistrust. “Farmers don’t believe anything,” he said. “There’s always been some bullshit product for farmers. And the people selling it are usually from out of town.”
He’d sit down in some barn or wood shop, pull out his iPad, and open up a map of whatever Corn Belt state he happened to be in. He’d let the farmer click on his field. Up popped the odds of various unpleasant weather events—a freeze, a drought, a hailstorm—and his crops’ sensitivity to them. He’d show the farmer how much money he would have made in each of the previous thirty years if he had bought weather insurance. Then David Friedberg, Silicon Valley kid, would teach the farmer about his own fields. He’d show the farmer exactly how much moisture the field contained at any given moment—above a certain level, the field would be damaged if worked on. He’d show him the rainfall and temperature every day—which you might think the farmer would know, but then the farmer might be managing twenty or thirty different fields, spread over several counties. He’d show the farmer the precise stage of growth of his crop, the best moments to fertilize, the optimum eight-day window to plant his seeds, and the ideal harvest date.
From The Fifth Risk.
Original source: A useful big data story