After at least five years of struggling to transformation, IT knows how to deliver better software, how to do the process and use the new tools needed for “digital transformation.” They may not actually do all that, but they know what should be done. However, “The Business” is not involved enough nor knows what to do. This prevents achieving the full benefits of digital transformation. The Business just knows that Amazon is coming to eat their lunch and that their boards are demanding a strategic response, like, yesterday. There are a handful of educational exceptions: companies like The Home Depot that are figuring it out and thriving. But, there’s a lot more organizations that are stumbling than succeeding. IT isn’t the bottleneck anymore, it’s finance, strategy, and management.
And, here’s a talk on the topic:
It’s a sequel to my previous book, Monolithic Transformation. That book looks more inward at the IT department and how it should change, while this one is trying to look at the rest of the organization: how does (should?) “The Business” need to change?
Here are some draft excerpts and related things I’ve been working on:
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.”
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.
“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:
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.
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!
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?”
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:
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:
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:
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:
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.
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
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
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.
52.3556164.932718
Posted on
“With the rise of Lean Startup, we began to focus on outcomes, yes, but we also started to celebrate failure. I want to be clear here: it is not a success if you fail and do not learn. Learning should be at the core of every product-led organization. It should be what drives us as an organization. It is just better to fail in smaller ways, earlier, and to learn what will succeed, rather than spending all the time and money failing in a publicly large way. This is why we have problem and solution exploration in product management—to de-risk failing in the market.” from “Escaping the Build Trap: How Effective Product Management Creates Real Value” by Melissa Perri
When GDS started in 2011, mobile apps were that day’s special on the fad menu. Ministers all wanted their own. Top officials thought they sounded like a great idea. Delighted suppliers queued up to offer their services to government. We’ll talk about apps in more detail later. For now, all you need to know is that GDS blocked 99% of requests for them. Government wasn’t ready for apps, because the people asking for them didn’t really know what they were for. They just sounded good. The blogpost explaining the apps policy, written by Tom Loosemore in 2013, quickly became the digital team’s most widely read post. 16 We have seen too many chief executives and department heads proudly explain their organisation’s pioneering work on artificial intelligence, say, while in the same breath conceding their back office systems can’t reliably pay employees on time. Or running pilots with connected devices while thousands of their customers still post them cheques. This is not to say that preparing for the future isn’t right and good. Responsible leaders need to keep their eyes on the horizon. The successful leaders are those who can do this while remaining mindful their view will be ruined if they step in something disgusting lying on the floor.
from “Digital Transformation at Scale: Why the Strategy Is Delivery (Perspectives)” by Andrew Greenway, Ben Terrett, Mike Bracken, Tom Loosemore
Just as it is easy to misinterpret the reason for an icebreaker activity, it’s easy to mistake certain social customs of Americans that might suggest strong personal connections where none are intended. For example, Americans are more likely than those from many cultures to smile at strangers and to engage in personal discussions with people they hardly know. Others may interpret this “friendliness” as an offer of friendship. Later, when the Americans don’t follow through on their unintended offer, those other cultures often accuse them of being “fake” or “hypocritical.”
Also:
…[a] Russian saying “If we pass a stranger on the street who is smiling, we know with certainty that that person is crazy . . . or else American.”
I’ve collected together my columns from The Register and several other pieces into a book, Digital WTF. You can buy it! YAY, CAPITALISM.
There’s plenty of people telling you why digital transformation, DevOps, agile, and cloud are good. When you’re finished being inspired, this book is waiting for you, like a forgotten twenty dollar bill in that lambskin trucker jacket you haven’t worn in 16 years.
Can I write a blurb, or what?!
Sadly, as I’m putting it together myself, it has typos, and I’m sure I’ll come out with some dot releases modifying it and adding (or removing!) some of the content.
In the meantime, enjoy it! It’ll go all PDF, epub, mobi, or whatever. That means it’ll work in whatever ereader you have.
Here’s a longer description of the book:
The phrase “digital transformation” is stupid, but like all stupid tech trend phrases it actually means something precise and useful: creating better software. DevOps and agile are equally maligned yet useful. Coté has covered this topic for many years and has tried to describe each using common practices, pit-falls, and anecdotes, such as: the role of developers and managers in DevOps, small batch release cycles, dealing with finance, and burnout. The book also includes coverage of vendor sports, a select history of the software industry, and tactics for surviving the head-banging-on-a-brick wall life of working at a large organization. Since these topics are really boring, Coté writes in a darkly humorous, irreverent style that at least leaves you entertained by the end of each piece – so people tell him.
My old pal John Willis was very kind to write a forward for me. He’s a very kind man.
COWEN: When you translated the Odyssey — as a reader, I think of your approach as pretty clean and direct and very easy to read, but also with a lot of psychological depth, and I prefer that in the Odyssey. But when I read, say, the Hebrew Bible, I want something a little more, maybe stentorian in tone, or a little more baroque, actually. I think a lot of people feel the same way. Why that difference? Why do we want something different from a Bible translation often?
…
WILSON: ..I think it’s partly just about the source text, and it’s also about the cultural perception of the sourced text. Most people in contemporary society don’t believe in Athena, so we have a different idea about how should divinity be represented in this text versus in a text where there are people who still worship the God of the Hebrew Bible, right?
And, sure, people always disappear into new people, and no one can stop the way new versions of people overtake the old versions of people, but something about the new Linda was so menacing that it made me suspicious of what she’d done with the old Linda.
This book can hard to read through – it’s got that numb tone of people staring at their nihilistic existence. At least that’s my read. But, it’s full of the clarity that comes with that bleakness.
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.”
She never brought up Daniel again, but it didn’t really matter. I’d already made it a habit to consider the way my life could have been if I’d said yes when Daniel had asked the question I knew he didn’t even think was a question, just a rite of passage we had to go through. (You could see a marriage approach some couples in Texas the same way you could watch a summer storm churning on the plains, miles before it hit.) It was possible my life wouldn’t have been any more or less enjoyable had I turned from person to wife, wife to parent, had I stayed in White Deer and parceled my hours out to a family, turned my mother grand. (A life might comfortably disappear into a well-worn groove between house, school, and grocery store. (All lives disappear one way or another. (All hours get spent.))) But as pleasant as it might have been, that kind of life also seemed—somehow—elsewhere, like a dream I could only watch instead of do.
Usually we’re told that improving IT means changing the old organization. I’ve been re-reading The Art of Business Value, and re-came across this, to the contrary:
This way of thinking has always struck me as a little strange. Our goal is to deliver value, to figure out how to meet the needs that are determined by the organization, and yet we consider the organization to be the biggest impediment to doing so. The only explanation I can think of for this is that we are implicitly assuming that there is a stable, objective, preordained definition of business value, and we are determined to deliver on that definition despite the organization around us. In my experience, this arrogance is not warranted; in fact, the organization probably understands value in ways that the Agile team does not, and the obstacles to Agile adoption actually tell us something useful about business value in the organization.
Because, in fact, the organization knows the “business value,” the strategy, it’s in charge of reliving:
The organization has had to learn what business strategies, values, protocols, and behaviors work in its environment to support its ultimate aims, whether those are maximizing shareholder value or accomplishing mission objectives. That learning forms the basis of tacit assumptions and norms, the organization’s collected wisdom about what behaviors foster success. And if success means accomplishing the ultimate goals that serve as the sources of business value, then the Agile team must come to understand those values, strategies, goals, and operational modes that are embedded in the culture around it—that is, the business values that have been known to foster success.
Of course, there were countercurrents. Managers wanted to control activities. That impetus for control and management of potential risks led to the rise of bureaucracy, characterized by highly defined processes. Generations of executives micromanaged people all the way down the organization while fighting the growth of paperwork and “signoffs.” Such behavior also originated with Watson Sr., who exhibited such contradictory behavior. A vast number of decisions came to him, so many that when his son Tom took over the business in the mid-1950s, one of the first things he did was reorganize IBM to move decision making out of headquarters and into the broader organization.
Yet, simultaneously, the Old Man admonished employees to take individual responsibility for running their “piece of the business,” a phrase used frequently by executives with their staffs. Reflecting back on his first ten years at IBM in 1924, Watson Sr. told a class of the company’s executives that, “It is our policy not to burden any one man, or any group of men, with the responsibility of running this business.” 17 He gave thousands of talks to employees extolling these themes and a positive philosophy about IBM sales. By the early 1920s, this eternal optimist had begun telling salesmen that only 5 percent of all business information was handled by data processing, leaving 95 percent yet to be seized, a magnificent sales opportunity. He spent more time talking to his employees around the world than most future CEOs at IBM would. He met continuously with customers and public officials, far less so with the media.” from “IBM: The Rise and Fall and Reinvention of a Global Icon (History of Computing)” by James W. Cortada
From the history of IBM book I’ve been reading. See more…
The writing in this book is good, and I’m always a sucker for noir.
But it gets tiresome after awhile, all the balls-out crazy stuff and topics.
There’s a lot to study about fiction dynamics here though fueled by the picador plotting: lots of interesting characters, lots of mini-plots; paring characters; the weak male/strong female trope; unlimited budget; snarky, but weary direct address tone to the reader; maybe world building, but just as the back-story for the various characters you meet (the serial killer on the airplane, the Roanokes, but the Bob character is ignored/anemic in this respect); social commentary as asides (from Trix, often); sex for titilation.
If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.
You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”
A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”
Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)
But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.
Works as Designed
Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:
The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).
And then summarized as:
…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.
Which is to say: you wanted this, and so I am giving it to you.
The Agile Bureaucracy
The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:
While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.
These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.
Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.
Learning bureaucracies
The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:
Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.
And then an example of that principal in place to sell ads at CBS, early on:
“Here you have the advertiser’s ideal—the family group in its moments of relaxation [listening to the radio] awaiting your message,” said CBS. “Nothing equal to this has ever been dreamed of by the advertising man.” It is, as we shall see, one thing to sell access to the minds, quite another to predict reliably the audience’s frame of mind; and by dictating the moment of infiltration, radio claimed to do just that. At the time and place of CBS’s choosing, the audience would be “at leisure and their minds receptive.”
Any communication, Lippmann came to see, is potentially propagandistic, in the sense of propagating a view. For it presents one set of facts, or one perspective, fostering or weakening some “stereotype” held by the mind. It is fair to say, then, that any and all information that one consumes—pays attention to—will have some influence, even if just forcing a reaction. That idea, in turn, has a very radical implication, for it suggests that sometimes we overestimate our own capacity for truly independent thought. In most areas of life, we necessarily rely on others for the presentation of facts and ultimately choose between manufactured alternatives, whether it is our evaluation of a product or a political proposition. And if that is true, in the battle for our attention, there is a particular importance in who gets there first or most often. The only communications truly without influence are those that one learns to ignore or never hears at all; this is why Jacques Ellul argued that it is only the disconnected—rural dwellers or the urban poor—who are truly immune to propaganda, while intellectuals, who read everything, insist on having opinions, and think themselves immune to propaganda are, in fact, easy to manipulate.
These two books go well together because the first describes how automation is lowering the need for labor, leading, likely, to less jobs, while the second provides a compendium of examples of such software-driven labor change.
Vinnie’s book has the optimism of a technologist, while Avent’s is much more fraught. Both accurately describe how IT is optimizing and replacing “analog” labor and businesses, leaving the core problem of devaluing human labor, perhaps to the point of eliminating millions of jobs, permanently. Vinnie’s optimism is the usual believe that we can figure it out, mostly by being more humane in our politics and safety nets, but also in the belief that new problems and jobs will come about. Avent, on the other hand, offers little in the way of solace.
As the review in his magazine, The Economist, put it: “I found the virtuosity with which Mr Avent knocked down possible solutions disquieting.” Aside from actually reading the book, the lecture Avent gave at LSE is good stuff too.
Unsurprisingly, I liked both of them, esp. the second:
What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.
The premise of this book, for most anyone, is painfully boring: planning out and project managing the installation of COTS software. This is mostly lumbering, on-premises ERP applications: those huge, multi-year installs of software that run the back office and systems of record for organizations. While this market is huge, touches almost every company, and has software that is directly or indirectly touched by almost everyone each day (anytime you buy something or interact with a company)…it’s no iPhone.
If you’re in the business of selling enterprise software and services, however, Beaubouef’s book is a rare look inside the buyer’s mind and their resulting work-streams when they’re dealing with big ol’ enterprise IT. As a software marketer, I read it for exactly that. I was hoping to find some ROI models (a scourge of my research). It doesn’t really cover that at all, which is fine.
There’s a core cycle of ideas and advice flitting in and bout of the book that I like:
COTS software will do, you know, 80% of what you like. The rest is customizing it through configuration, your own code layered on-top, or getting the vendor to add in new features.
The more you customize the software, the harder it will be to change. But, the less you customize it, the less it creates differentiation for your business processes.
Most of the problems and challenges you’ll encounter, though, will be human based.
Much of these human problems are about managing the requirements process to make sure the software is matching the needs of the business.
Process-wise, to do this we like to take on a waterfall approach (try to specify everything up front, implement it all, then verify if it works). This results in a lot or risk of waiting for that final verification to see if it works and you were right about matching the COTS implementation to business needs.
Instead, and iterative approach that focuses on learning and honing the COTS/business match-up seems like a good idea.
Role-wise, getting someone(s) who have a tops-down view of the business process and enough technical understanding to map that to the COTS project is a really good idea, though hard to put in place.
While the book focuses on on-premises software, the overall thinking could easily apply to any implementation of a large IT-driven, vendor provided system: SaaS would work, and to an extent the kind of infrastructure software we sell at Pivotal. As the points above go over, the core thrust of the book is about managing how you make sure your IT is actually helping the business, not bogging down in its self.
If you’re pretty vague on what you should do in these large IT initiatives, you could do a lot worse than read this book.
…most of the time, prescribing an antidepressant is not about making somebody “better than well” but rather helping to relieve a patient’s acute suffering enough that she can resume a semblance of normal life.
Rounding out the “Bigend Trilogy,” Zero History is up to the standards you’d expect from William Gibson’s “in the present” stories. Reading through it, you can feel the mastery of his own style of that Gibson has: soulless, unsentimental, and over saturated with a sort of frenetic calm. As with most science fiction, the plot is more of a fixture, and characters are almost equally part of the set. The more pleasurable part is the atmosphere created, here, from places like a “private hotel” with ornate-weird interior decoration, fashion-fetishizing, London motorcycle couriers, and even a brief stint in blown-out rural America.
As with the previous books in the series – Pattern Recognition and Spook Country – the plot itself is the mystery of the book: trying to figure out why all these characters are being compelled to hunt down the secret “Gabriel’s Hounds” clothing maker. There’s some frenetic, tacked on action at the end (as usual) that makes for the major look into characters – what will they do when forced to make a “difficult choice” – but all of that is just background imagery for the more comfortable string of scenes Gibson paints in the rapid chapters.
My rating: 3 of 5 stars
Short and new enough to make you interested in reading some “new” fiction, but tedious like a low-budget indie film.
This collection of short stories has its ups and downs, and to read all the blurbs on it, many professionals liked it. Most of the characters are socially inept and haven’t seemed to discover happiness or how to perpetuate it in their short lives. They’re the kind of characters whose last words in a dialog are always “Oh.” And, of course, there’s no quotes around any dialog which gives it that extra bleakness.
Here’s a good example:
By the time I ran into Ed Borger at Trader Joe’s, Lyon was living at my house only half the week. Which is something Ed and I talked about with loaves of bread in our hands. He thouht this was great progress. I said we owed it all to him. He said his bread always got moldy before he could finish the loaf. I said he should freeze the bread to prevent this problem. He said, Won’t that ruin the bread? I said, No if you’re making toast with it. He said, You can toast it frozen? And I said, Yep.
Still, it’s kind of fun and calming to read, if only to see what kind of whacky thing happens next: mostly normal people doing non-mainstream (what’s the PC word for “perverted” or “abnormal”?) sex here and there. Sort of like a muted, calm Maury Povich show but all the guests were over-reflective, under-employed liberal arts types from boring 80’s childhoods who aren’t even funny enough to be like the 40 year old virgin.
My rating: 3 of 5 stars
As with most pattern books, this is one you flip through in an hour and then save it to refer back to. The strength of software management and development pattern books is describing problems that commonly occur, not really telling you how to fix them. Thus, hey tend to be frustrating because you’re left thinking, “how am I going to get this to work in my organization?” There is a certain level of detail in some of these patterns that’s refreshing, but most are just brief outlines of a software management or team-work problem.Still, they’re extremely helpful things to keep in mind which you may be forgetting (“The Empty Chair”) or no longer think applies to you (“Young Pups Old Dogs”), helpful advice if you must do it (“Offshore Follies”), to some that can be reduced to a clever quip, as in “War Room” where DeMarco says, “I’m beginning to think that a project not worth a war room may be a project not worth doing.”There’s solid advice in here, but the 0th pattern is “Be humble: never assume you have this shit figured out.” After that, many of them are extremely good advice.
I gave up reading this one because it never seemed to get to a plot. And, you know, it was like a “bad things can happen” book that got a bit repetitive and (given how cynical we all are now-a-days, without even thinking about it) unoriginal. I feel like a schmuck for not reading a book written by a Nobel Prize winner, but those episodes of Mad Men aren’t going to watch themselves.
and 
– the plot itself is the mystery of the book: trying to figure out why all these characters are being compelled to hunt down the secret “Gabriel’s Hounds” clothing maker. There’s some frenetic, tacked on action at the end (as usual) that makes for the major look into characters – what will they do when forced to make a “difficult choice” – but all of that is just background imagery for the more comfortable string of scenes Gibson paints in the rapid chapters.
.jpg){kind=link}