I can explain it to you, but I can't comprehend it for you

I’ve given my share of presentations over the years. I am under no illusions that I am anything more than a marginal presenter. My presentations are information dense, a function of how I learn. Many years ago, I realized that I learn when I’m drinking from the fire hose, not when content is spoon fed to me. I am focused and engaged with the prior; I become disinterested and disengaged with the latter. Of all the recommended presentation styles I’ve been exposed to over the years, I find the “tell them what you’re going to tell them / tell them / tell them what you just told them” pattern intellectually insulting. I prefer to treat my audience with respect and assume they are intelligent, so I err on the side of content density.

For this style to be effective, the audience has to also want to drink from the fire hose. If they do not, you won’t get past the first couple of paragraphs. But in over 30 years in the tech business, I find tech audiences generally respond to high-content-density presentations.

As the person leading a briefing or presentation, it is your responsibility to connect with the audience. However, there are limitations. The content as prepared is only as good as the guidance you’ve received to shape the subject and depth of detail. A presenter with subject matter expertise isn’t (or at any rate, should not be) wed to the content and can generally shift gears to adjust when there is a fidelity mismatch between content and audience. But being asked, even demanded, to explain even a moderately advanced concept in a limited amount of time to an audience lacking in subject matter basics is going to fall flat every single time.

* * *

People buy things - large capital things - for which they have little or no qualifications to purchase other than the fact that they have money to spend. Few people who buy houses are carpenters, plumbers or electricians. Few people who buy used cars are mechanical engineers.

This expertise disconnect plagues the software business. There are, unfortunately, times when contracts for custom software development are awarded by individuals or committees who have (at best) limited understanding of the mechanics of software delivery. And there are times when contracts for software product licenses are awarded by individuals or committees who have (at best) limited understanding of the complexity of the domain into which the licensed product must work.

An egregious, although not atypical, example is an 8-figure custom software development contract with payouts indexed to “story points developed”. Not “delivered”, not “in production.” The delivery vendor tapped the contract for cash by aggressively moving high-point story cards to “dev complete”. Never mind that nothing had reached production, never mind that nothing had reached UAT. By the time I got a look at it (they were looking - hoping - for process improvements that would yield deployable software rather than deplorable software), every story had an average of 7 open defects with a nearly 100% reopen rate. And yes, smart reader, ignore the fact that the apparent currency was “story points,” because it was not. The currency was the cash value of the contract; story points were simply a proxy for extracting that cash. Ironically, the buyer thought the arrangement was shrewd because it tied cash to work. Sadly it failed to tie cash to outcomes. In the event, the vendor had the buyer hostage: there were no clawbacks, so the buyer would either have to abandon the investment or have to sign extension after extension in the hopes of making good on it.

Licensed software products are no different. I’ve seen too many occasions where a buyer entered into a license agreement for some product without first mapping out how to integrate that product into their back office processes. When the buyer doesn’t come to the table prepared with a detailed understanding of their as-is state, they default into allowing the vendor to take the lead in designing solution architecture for the to-be state based entirely on generic and simplistic use cases, with disastrous outcomes to the buyer. Licensed products tend not to be 100% metered cost, and the vendor sales rep has a quota to meet and a commission to earn, so the buyer commits to some minimum term-based subscription spend with metered usage piled on top of that. In practice this means the clock is ticking on the buyer to integrate the licensed product the second the ink is drying on the contract. Finding out after the contract is signed that intrinsic complexity of the buyer environment is many orders of magnitude beyond the vendor supplied architecture is the buyer’s problem, not the vendor’s.

To level this information asymmetry between buyer and seller, buyers have independent experts they can call on to give an opinion of the contract or product or vendor or process. But of course there are experts and there are people with certifications. An expert in construction can look beyond things like surface damage to drywall and trim and determine whether or not a building is structurally sound. Then there are the “certified building inspectors” who look closely at PVC pipe covered in black paint and call it “cast iron plumbing.” All the certification verifies is that once upon a time, the certificate bearer passed a test. What is true in building construction is equally true in software construction. Buyers have access to experts but that doesn’t do them a bit of good if they don’t know how to qualify their experts.

Of course there’s a little more to it than that. Buyers have to be able to qualify their experts, want their expertise, and be willing and able to act on it. I’ve advised on a number of acquisitions. No person mooting an acquisition wants to hear “it’s a bad acquisition at any price”, especially if their job is to identify and close acquisitions. Years ago, I was asked to evaluate a company that claimed to have a messaging technology that could be used to efficiently match buyers and sellers of digital advertising space. They had created a messaging technology that was different from JMS only in that (a) theirs was functionally inferior and (b) it was not free. Instead of expressing relief at avoiding a disastrous deployment of capital, the would-be investor was desperate for justification that would overshadow these… inconveniences. As the saying goes, “you cannot explain something to somebody whose job depends on not understanding it.”

* * *

I have been fortunate to have worked overwhelmingly with experts and professional decision makers over the years, people who have been thoughtful, insightful, willing to learn, and who in turn have stretched me as well. I sincerely hope I have done the same for them.

Unfortunately, I have had a few brushes with those who fell irreconcilably short. The CTO of a capital markets firm who requested an advanced briefing on the mechanics of how distributed ledger technology could change settlement of existing and open the door for new complex financial products, but had done nothing before the briefing to learn the basics of what “this blockchain thing” is. The mid-level VP leading a RFP process who derailed a vendor presentation because she simply could not fathom how value stream mapping of business operations exposes inefficiencies that have income statement ramifications.

When we fail to connect with an audience, we have to first internalize the failure and look for what we might have done differently: what did we hear but not process at the time, what question should we have asked to clarify the perspective of the person asking. What is spoken is less important than what is heard.

At a certain point, though, responsibility for understanding lies with the listener. The audience member adamantly demanding further explanation may be doing so for any number of reasons, ranging from simple neglect (a failure to have done homework on the basics) to a deliberate unwillingness to understand (i.e., cognitive dissonance).

Which is where the title of this blog comes in. It’s a comment Ed Koch, the 105th mayor of New York, made to a constituent who demanded to know why the mayor’s office was introducing policy to lighten taxes, some time after New York had financially imploded and was still hemorrhaging high-income earners and businesses. “I can explain it to you” he told this constituent, “but I can’t comprehend it for you.”

The era of ultra low interest rates is over. Tech has painful adjustments to make.

Interest rates have been climbing for two years now. The Wall Street Journal ran an article yesterday with the headline the days of ultra low interest rates are over. Tech will have to adjust. It’s going to be painful.

When capital is expensive, we measure investments against the hurdle rate: the rate of return an investment must satisfy to exceed to be a demonstrably good use of capital. When capital is ridiculously cheap, we no longer measure investment success against the hurdle rate. In practice, cheap capital makes financial returns no more and no less valuable than other forms of gain.

There are ramifications to this. As fiduciary measures lapse, so does investment performance. We go in pursuit of non-financial goals like "customer engagement rate". We get negligent in expenditure: payrolls bloated with tech employees, vendors stuffing contracts with junior staff. We get lax in our standard of excellence as employees are aggressively promoted without requisite experience. We get sloppy in execution: delivery as a function of time is simply not a thing, because the business is going to get whatever software we get done when we get it done.

Capital may not be 22% Jimmy Carter era expensive, but it ain’t cheap right now. Tech has to earn its keep. That means a return to once familiar practices, as well as change that orchestrates purge of tech largesse. Business cases with financial returns first, non-financial returns second. Contraction of labor spend: restructuring to offload the overpromoted, and consolidation of roles or lower compensation for specialization. Transparency of what we will deliver when for what cost, and what the mitigation is should we not. An end to vanity tech investments, because the income statement, much less the balance sheet, can no longer support them.

Some areas of the tech economy will be immune to this for as long as they are thematically relevant. AI and GenAI are TINA (there is no alternative) investments: a lot of firms have no choice but to spend on exploratory investments in AI, because Wall Street rewards imagination and will reward the remotest indication of successful conversion of that imagination that much more. Yet despite revolutionary implications, AI enthusiasm is tempered compared to frothy valuations for tech pursuits of previous generations, a function of investor preference for, as James Mackintosh put it, profits over moonshots.. Similarly, businesses where there is a tech arms race on because innovation offers competitive advantage, such as in-car software, it will be business as usual. But these arms races will end, so it will be tech business as usual until it isn’t. (In fact, in North America, this specific arms race may not materialize for a long, long time as EV demand has plateaued, but that’s another blog for another day.)

Tech has had the luxury of not being economically anchored for a long time now. If interest rates settle around 400 bps as the WSJ speculated yesterday, those days are over. The adjustment to a new reality will be long and painful because there’s a generation of people in tech who have not been exposed to economic constraints.

This is the Agile Manager blog, as it has been since I started it in 2006. Good news, this change doesn’t mean a return to the failed policies of waterfall. Agile had figured out how to cope with these economic conditions. Tech may not remember how to use those Agile tools, but it has them in the toolkit. Somewhere.

That said, I also blog about economics and tech. If the Fed funds rate lands in the 400 bps range, tech is in for still more difficult adjustments. More specifically, the longer tech clings to hopes for a return to ultralow interest rates, the longer the adjustment will last, and the more painful it will be.

The ultralow rate party is over. It’s long past time for tech to sober up.

Don’t queue for the ski jump if you don’t know how to ski

I’ve mentioned before that one of my hobbies is lapidary work. I hunt for stone, cut it, shape it, sand it, polish it, and turn it into artistic things. I enjoy doing this work for a lot of reasons, not least of which being I approach it every day not with an expectation of “what am I going to complete” but “what am I going to learn.”

As a learning exercise, it is fantastic. I keep a record of what I do on individual stones, on how I configure machines and the maintenance I perform on them, and for the totality of activities I do in the workshop each day. I do this as a means of cataloging what I did (writing it down reinforces the experience) and reflecting on why I chose to do the things that I did. Sometimes it goes fantastically well. Sometimes it goes very poorly, often because I made a decision in the moment that misread a stone, misinterpreted how a tool was functioning, or misunderstood how a substance was reacting to the machining.

My mistakes can be helpful because, of course, we learn from mistakes. I learn to recognize patterns in stone, to recognize when there is insufficient coolant on a saw blade, to keep the torch a few more inches back to regulate the temperature of a metal surface.

But mistakes are expensive. That chunk of amethyst is unique, once-in-a-lifetime; cut it wrong and it’s never-in-a-lifetime. If there isn’t coolant splash over a stone you’re cutting, you’re melting an expensive diamond-encrusted saw blade. Overheat that stamping to a point where it warps, or cut that half hard wire to the wrong length, and you’ve just wasted a precious metal that costs (as of today’s writing) $25+ per ounce for silver, $2,240+ for gold.

Learning out of a video or website or a good old fashioned book is wonderful, but that’s theory. We learn through experience. Whether we like to admit it or not, a lot of experiential learning results in, “don’t do it that way.”

Learning is the human experience. Nobody is omnipotent.

But learning can be expensive.

* * *

A cash-gushing company that has been run on autopilot for decades gets a new CEO who determines they employ thousands doing the work of dozens, and since most of these people can’t explain why they do what they do, the CEO concludes there is no reason why, and spots an opportunity to squeeze operations to yield even better cash flows. Backoffice finance is one of those functions, and that’s just accounting, right? That seems like a great place to start. Deploy some fintech and get these people off the payroll already.

Only, nobody really understands why things are the way they are; they simply are. Decades of incremental accommodation and adjustment have rendered backoffice operations extremely complicated, with edge cases to edge cases. Call in the experts. Their arguments are compelling. Surely, we can we get rid of 17 price discounting mechanisms and only have 2? Surely, we can we have a dozen sales tax categories instead of 220? Surely, we can get customers to pay with a tender other than cash or check? All plausible, but nobody really knows (least of all Shirley). Nobody on the payroll can explain why the expert recommendations won’t work, so the only way to really find out is to try.

Out comes a new, streamlined customer experience with simplified terms, tax and payments. Only, we lose quite a lot of customers to the revised terms, either because (a) two discounting mechanisms don’t really cover 9x% of scenarios like we thought or (b) we’re really lousy at communicating how those two discounts work. We lost transactions beyond that because customers have trust issues sharing bank account information with us. And don’t get started on the sales tax remittance Hell we’re in now because we thought we could simplify indirect tax.

Ok, we tried change, and change didn’t quite work out as we anticipated. It took us tens of millions of dollars of labor and infrastructure costs to figure out if these changes would actually work in the first place. Bad news is, they didn’t. Good news is, we know what doesn’t work. Hollow victory, that. That’s a lot of money spent to figure out what won’t work. By itself, that doesn’t get us close to what will work. Oh and by the way, we spent all the money, can we please have more?

Let’s zoom out for a minute. How did we get here? Since the employees don’t really know why they do what they do, and since all this activity is so tightly coupled, what is v(iable) makes the m(inimum) pretty large, leaving us no choice but to run very coarsely grained tests to figure out how to change the business with regard to customer facing operations that translate into back office efficiencies. Those tests have limited information value: they either work or they do not work. Without a lot of post-test study, we don’t necessarily know why.

This is not to say these coarse tests are without information value. With more investment of labor hours, we learn that there are really four discounting mechanisms with a side order of optionality for three of them we need to offer because of nuances in the accounting treatment our customers have to deal with. That’s not two but still better than the nineteen we started with. And it turns out with two factor authentication we can build the trust with customers to share their banking details so we can get out of the physical cash business. Indirect tax? Well, that was a red herring: the 220 categories previously supported is more accurately 1,943 under the various provincial and state tax codes. Good news is, we have a plan to solve for scaling up (scenarios) and scaling down (we’ll not lose too much money on a sales tax scenario of one).

Of course, we’ll need more money to solve for these things, now that we know what “these things” are.

That isn’t a snarky comment. These are lessons learned after multiple rounds of experiments, each costing 7 or 8 figures, and most of them commercially disappointing. We built it and they didn’t come, they flat out rejected it. We got it less wrong the second, third, fourth, fifth time around and eventually we unwound decades of accidental complexity that had become the operating model of both backoffice and customer experience, but that nobody could explain. Given unlimited time and money, we can successfully steer the back office and customers through episodic bouts of change.

Given unlimited time and money. Maybe it took five times, or seven times, or only three. None was free, and each experiment cost seven to eight figures.

* * *

There are a few stones I’ve had on the shelf for many, many years. They are special stones with a lot of potential. Before I attempt to realize that potential, I want to achieve sufficient mastery, to develop the right hypothesis for what blade to use and what planes to cut, for what shape to pursue, for what natural characteristics to leave unaltered and what surfaces to machine. Inquisitiveness (beginner’s mind) twined with experience on similar if more ordinary stones have led me to start shaping some of those special ones, and I’m pleased with the results. But I didn’t start with those.

Knowledge is power as the saying goes, and “learn” is the verb associated with acquiring knowledge. But not all learning is the same. The business that doesn’t know why it does what it does is in a crisis requiring remedial education. There is no shame in admitting this, but of course there is: that middle manager unable to explain why they do the things they do will feel vulnerable because their career has peaked as the “king of the how in the here and now.” Lessons learned from being enrolled in the master class - e.g., being one of the leads in changing the business - will be lost on this person. And when the surrogate for expertise is experimentation, those lessons are expensive indeed.

Leading change requires mastery and inquisitiveness. The prior without the latter is dogma. The latter without the prior is a dog looking at a chalkboard with quantum physics equations: it’s cute, as Gary Larson pointed out in The Far Side, but that’s the best that can be said for it. When setting out to do something different, map out the learning agenda that will put you in the position of “freely exercising authority”. But first, run some evaluations to ascertain how much “(re-)acquisition of tribal knowledge” needs to be done. There is nothing to prevent you from enrolling in the master class without fluency in the basics, but it is a waste of time and money to do so.

Patterns of Poor Governance

As I mentioned last month, many years ago I was toying around with a governance maturity model. Hold your groans, please. Turns out there are such things. I’m sure they’re valuable. I’m equally sure we don’t need another. But as I wrote last month there seemed to be something in my scribbles. Over time, I’ve come to recognize it not as maturity, but more as different patterns of bad governance.

The worst case is wanton neglect, where people function without any governance whatsoever. The organizational priority is on results (the what) rather than the means (the how). This condition can exist for a number of reasons: because management assumes competency and integrity of employees and contractors; because results are exceedingly good and management does not wish to question them; because management does not know the first thing to look for. Bad things aren’t guaranteed to happen in the absence of governance, but very bad things can indeed (Spygate at McLaren F1; rogue traders at Société Générale and UBS). Worse still, the absence of governance opens the door to moral hazard, where individuals gain from risk borne by others. We see this in IT when a manager receives quid pro quo - anything from a conference pass to a promise of future employment - from a vendor for having signed or influenced the signing of a contract.

Wanton neglect may not be entirely a function of a lack of will, of course: turning a blind eye equals complicity in bad actions when the prevailing culture is “don’t get caught.”

Distinct from wanton neglect is misplaced faith in models, be they plans or rules or guidelines. While the presence of things like plans and guidelines may communicate expectations, they offer no guarantee that reality is consistent with those guidelines. By way of example, IT managers across all industries have a terrible habit of reporting performance consistent with plans: the “everything is green for months until suddenly it’s a very deep shade of red” phenomenon. Governance in the form of guidelines is often treated as “recommendations” rather than “expectations” (e.g., “we didn’t do it that way because it seemed like too much work”). A colleague of mine, on reading the previous post in this series, offered up that there is a well established definition of data governance (DAMA). Yes there is. The point is that governance is both a noun and a verb; governance “as defined” and “as practiced” are not guaranteed to be the same thing. Pointing to a model and pointing to the implementation of that model in situ are entirely different things. The key defining characteristic here is that governance goes little beyond having a model communicating expectations for how things get done.

Still another pattern of bad governance is governance theater, where there are governance models and people engaged in oversight, but those people do not know how to effectively interrogate what is actually taking place. In governance theater, some governing body convenes and either has the wool pulled over their eyes or simply lacks the will to thoroughly investigate. In regulated industries, we see this when regulators lack the will to investigate despite strong evidence that something is amiss (Madoff). In corporate governance, this happens when a board relies almost exclusively on data supplied by management (Hollinger International). In technology, we see this when a “steering committee” fails to obtain data of its own or lacks the experience to ask pertinent questions of management. Governance theater opens the door to regulatory capture, where the regulated (those subject to governance) dictate the terms and conditions of regulation to the regulators. When governance is co-opted, governance is at best a false positive that controls are exercised effectively.

I’m sure there are more patterns of bad governance, and even these patterns can be further decomposed, but these cover the most common cases of bad governance I’ve seen.

Back to the question of governance “maturity”: while there is an implied maturity to these - no controls, aspirational controls, pretend controls - the point is NOT to suggest that there is a progression: i.e., aspirational controls are not a precursor to pretend controls. The point is to identify the characteristics of governance as practiced to get some indication of the path to good governance. Where there is governance theater, the gap is a reform of existing institutions and practices. Misplaced faith requires creation of institutions and practices, entirely new muscle memories for the organization. Each represents a different class of problem.

The actions required to get into a state of good governance are not, however, an indication of the degree of resistance to change. Headstrong management may put up a lot of resistance to reform of existing institutions, while inexperienced management may welcome creation of governance institutions as filling a leadership void. Just because the governance gap is wide does not inherently mean the resistance to change will be as well.

If you’re serious about governance and you’re aware it’s lacking as practiced today, it is useful to know where you’re starting from and what needs to be done. If you do go down that path, always remember that it’s a lot easier for everybody in an organization - from the most senior executive management to the most junior member of the rank and file - to reject governance reform than to come face to face with how bad things might actually be.

Governance Without Benefit

I’ve been writing about IT governance for many years now. At the time I started writing about governance, the subject did not attract much attention in IT, particularly in software development. This was a bit surprising given the poor track record of software delivery: year after year the Standish CHAOS reports drew attention to the fact that the majority of IT software development investments wildly exceeded spend estimates, fell short of functional expectations, were plagued with poor quality, and as a result quite a lot of them were canceled outright. Drawing attention to such poor results gave a boost to the Agile community who were pursuing better engineering and better management practices. Each is clearly important to improving software delivery outcomes, but neither addresses contextual or existential factors to investments in software. To wit: somebody has to hold management accountable for keeping delivery and operations performing within investment parameters and, if it is not, either fix the performance with or without that management or negotiate a change in parameters with investors. Governance, not engineering or management, is what addresses this class of problem.

If IT governance was a fringe activity twenty years ago, it is everywhere today: we have API governance and data governance and AI governance and on and on. Thing is, there is no agreement as to what governance is. Depending on who you ask, governance is “the practice” of defining policies, or it “helps ensure” things are built as expected, or it “promotes” availability, quality and security of things built, or it is the actual management of availability, quality and security. None of these definitions are correct, though. Governance is not just policy definition. Terms like “promote” and “helps ensure” are weasel words that imply “governance” is not a function held accountable for outcomes. And governance intrinsically cannot be management because governance is a set of actions with concomitant accountability that are specifically independent of management.

That governance is still largely a sideline activity in IT is no surprise. For years, ITIL was the go-to standard for IT governance. ITIL defines consistent, repeatable processes rooted in “best practices”. The net effect is that ITIL defines governance as “compliance”. As long as IT staff follow ITIL consistent processes, IT can’t be blamed for any outcome that resulted from its activity: they were, after all, following established “best practices.” As there is not a natural path from self-referential CYA function to essential organizational competency, it is unrealistic to expect that IT governance would have found one by now.

I’ve long preferred applying the definition of corporate governance to IT governance. Corporate governance boils down to three activities: set expectations, hire managers to pursue those expectations, and verify results. When expectations aren’t met, management is called to task by the board and obliged to fix things. If expectations aren’t met for a long period of time, the managers hired to deliver them have to go or the expectations have to go. And if expectations aren’t met after that, the board goes. Before it gets to anything so drastic, governance has that third obligation, to “verify results.” Good governance sources data independently of management by looking directly at artifacts and constructing analyses on that data. In this way, good governance has early warning as to whether expectations are in jeopardy or not, and can assess management’s performance independently of management’s self-reporting. Governance is not “defining policies” or “helping to ensure” outcomes; governance is actively involved in scrutinizing and steering and has the authority to act on what it has learned.

Governance is concerned with two questions: are we getting value for money, and are we receiving things in accordance with expectations. Multiple APIs that do the same thing, duplicative data sources that don’t reconcile, IT investments that steamroll their business cases, all make a mockery of IT governance. We’ve got more IT “governance” than we’ve ever had, yet all too often it just doesn’t do what it’s supposed to do.

I’m picking up the topic of IT governance again because it does not appear to me that the state of IT governance is materially better than it was two decades ago, and this deserves attention. Soon after I started down this path, I thought it would be helpful to have a governance “maturity model.” No, the world does not need another maturity model, let alone one for an activity that is largely invisible and only conspicuous when it fails or simply isn’t present. It doesn’t help that good governance does not guarantee a better outcome, nor that poor governance does not guarantee a bad outcome. Governance is a little too abstract, difficult to describe in simple and concrete terms, and subsequently difficult for people to wrap their heads around. That, in turn, renders any “maturity model” an academic exercise at best.

Still, there is room for something that characterizes all this governance on an IT estate and frames it as an agent for good or bad. That is, in the as practiced state, is governance of this activity (say, API or appdev) materially reducing or increasing exposure to a bad outcome. That’s a start.

* * *

Dear readers,

I took extended leave from work last year, and decided to also take a break from writing the blog. I’m back.

Also, I do want to apologize that I’ve been unable all of these years to get this site to support https. It’s supposed to be a simple toggle in the Google admin panel to enable https, but for whatever reason it has never worked, which I suspect has to do with the migration of the blog from Blogger into Google. Despite admittedly tepid efforts on my part, I've not found a human who can sort this out at Google. I appreciate your tolerance.

Resistance

Organizational change, whether digital transformation or simple process improvement, spawns resistance; this is a natural human reaction. Middle managers are the agents of change, the people through whom change is operationalized. The larger the organization, the larger the ranks of middle management. It has become commonplace among management consultants to target middle management as the cradle of resistance to change. The popular term is “the frozen middle”.

There is no single definition of what a frozen middle is, and in fact there is quite a lot of variation among those definitions. Depending on the source, the frozen middle is:

• an entrenched bureaucracy of post-technical people with no marketable skills who only engage in bossing, negotiating, and manipulating organizational politics - change is impossible with the middle managers in situ today
• an incentives and / or skills deficiency among middle managers - middle managers can be effective change agents, but their management techniques are out of date and their compensation and performance targets are out of alignment with transformation goals
• a corporate culture problem - it’s safer for middle managers to do nothing than to take risks, so working groups of middle managers respond to change with “why this can’t be done” rather than “how we can do this”
• not a middle management problem at all, but a leadership problem: poor communication, unrealistic timelines, thin plans - any resistance to change is a direct result of executive action, not middle management

The frozen middle is one of these, or several of these, or just to cover all the bases, a little bit of each. Of course, in any given enterprise they’re all true to one extent or another.

Plenty of people have spent plenty of photons on this subject, specifically articulating various techniques for (how clever) “thawing” the frozen middle. Suggestions like “upskilling”, “empowerment”, “champion influencers of change”, “communicate constantly”, and “align incentives” are all great, if more than a little bit naive. Their collective shortcoming is that they deal with the frozen middle as a problem of the mechanics of change. They ignore the organizational dynamics that create resistance to change among middle management in the first place.

Sometimes resistance is a top-down social phenomenon. Consider what happens when an executive management team is grafted onto an organization. That transplanted executive team has an agenda to change, to modernize, to shake up a sleepy business and make it into an industry leader. It isn’t difficult to see this creates tensions between newcomers and long-timers, who see one another as interlopers and underperformers. Nor is it difficult to see how this quickly spirals out of control: executive management that is out of touch with ground truths; middle management that fights the wrong battles. No amount of “upskilling” and “communication” with a side order of “empowerment” is going to fix a dystopian social dynamic like this.

One thing that is interesting is that the advice of the management consultant is to align middle management’s performance metrics and compensation with achievement of the to-be state goals. What the consultants never draw attention to is executive management receiving outsized compensation for as-is state performance; compensation isn’t deferred until the to-be state goals are demonstrably realized. Plenty of management consultants admonish executives for not “leading by example”; I’ve yet to read any member of the chattering classes admonish executive to be “compensated by example”.

There are also bottom-up organizational dynamics at work. “Change fatigue” - apathy resulting from a constant barrage of corporate change initiatives - is treated as a problem created by management that management can solve through listening, engagement, patience and adjustments to plans. “Change skepticism” - doubts expressed by the rank-and-file - is treated as an attitude problem among the rank-and-file that is best dealt with by management through co-opting or crowding out the space for it. That is unfortunate, because it ignores the fact that change skepticism is a practical response: the long timers have seen the change programs come and seen the change programs go. The latest change program is just another that, if history is any guide, isn’t going be any different than the last. Or the dozen that came and went before the last.

The problematic bottom up dynamic to be concerned with isn’t skepticism, but passivity. The leader stands in front of a town hall and announces a program of change. Perhaps 25% will say, this is the best thing we’ve ever done. Perhaps another 25% will say, this is the worst thing we’ve ever done. The rest - 50% plus - will ask, “how can I not do this and still get paid?” The skeptic takes the time and trouble to voice their doubts; management can meet them somewhere specific. It is the passengers - the ones who don’t speak up - who represent the threat to change. The management consultants don’t have a lot to say on this subject either, perhaps because there is no clever platitude to cure the apathy that forms what amounts to a frozen foundation.

Is middle management a source of friction in organizational change? Yes, of course it can be. But before addressing that friction as a mechanical problem, think first about the social dynamics that create it. Start with those.

How Agile Management Self Destructs

I’ve been writing about Agile Management for over 15 years. Along the way, I’ve written (as have many others) how to get Agile practices into a business, how to scale them, how to overcome obstacles to them, and so forth. I’ve also written about how Agile gets co-opted, and a few months ago I wrote about how Agile erodes through workforce attrition and lowered expectations. I’ve never written about how Agile management can self-destruct.

The first thing to go are results-based requirements. Stories are at the very core of Agile management because they are units of result, not effort. When we manage in units of result, we align investment with delivery: we can mark the underlying software asset to market, we can make objective risk assessment and quantify not only mitigation but the value of mitigation. Agile management traffics in objective facts, not subjective opinion.

The discipline to capture requirements as Stories fades for all kinds of reasons. OKRs become soft measures. “So that” justification become tautologies. Labor specialization means that no developer pair, let alone a single person, can complete a Story. Team boundaries become so narrow they’re solving technical rather than business problems. And, you know what, it takes discipline to write requirements in this way.

Whatever the reason, when requirements no longer have fidelity to an outcome, management is back to measuring effort rather than results. And effort is a lousy proxy for results.

The next thing to go is engineering excellence. Agile management implicitly assumes excellence in engineering: in encapsulation, abstraction, simplicity, build, automated testing, and so forth. Once managers stop showing an active interest in engineering discipline, the symbiotic relationship between development and management is severed.

The erosion of engineering discipline is a function - directly or indirectly - of a lapse of management discipline. Whereas a highly-disciplined team decides where code should reside, an undisciplined team negotiates who has to do what work - or more accurately, which team doesn’t have to do what work. This is how architectures get compromised, code ends up in the wrong place, and abstraction layers create more complexity than simplicity.

The loss of engineering excellence is traumatic to management effectiveness. How something is built is a good indicator of the outcomes we can expect. Is the software brittle in production? Expensive to maintain? Does it take forever to get features released? Management has to reinforce expectations, verify that things are being built in the way they’re expecting them to be built, and make changes if they are not. When excellence in engineering is gone, management is no longer able to direct delivery; it is instead at the mercy of engineering.

The third thing to go is active, collaborative management. I’ve previously described what Agile management is and is not, so I’ll not repeat it here. The short version is, Agile management is a very active practice of advancing the understanding of the problem (and solution), protecting the team’s execution, and adjusting the team as a social system for maximum effectiveness. Now, management can check-out and just be scorekeepers even when there is engineering excellence and results-based requirements. But suffice to say, when saddled with crap requirements and becoming a vassal to engineering, management is reduced to the role of passenger. There is no adaptability, no responding to change, beyond adding more tasks to the list as the team surfaces them. Management is reduced to administration.

Agile requires discipline. It also requires tenacity. If management is going to lead, it has to set the expectations for how requirements are defined and how software is created and accept nothing less.

Give us autonomy - but first you've gotta tell us what to do

The ultimate state for any team is self-determination: they lead their own discovery of work, self-prioritize that work, self-organize their roles and self-direct the delivery.

Self-determination requires meta awareness. The team knows the problem space - the motivations of different actors (buyers, users, influencers), the guiding policies (regulatory and commercial preference), the tech in place, and so forth. Conversely, they are not whipsawed by external forces. They do not operate at the whim of customers because they evolve their products across the body of need and opportunity. They do not operate at the mercy of regulation because they know the applicable regulation and how it applies to them. They know their integrated technology’s features and foibles and know what to code with and code around. They know where the bodies are buried in their own code. And the members of the team might not be friends or even friendly to one another, but they know that no member of the team will let them down.

In the early 1990s, a Chief Technology officer I knew once replied to a member of his customer community during the Q&A at their annual tech meetup thusly: “there is nothing you can suggest that we’ve not already thought of.” Arrogance incarnate. But he and his entire team knew the product they were trying to build and they product they were not trying to build. They were comfortable with the tech trends they were latching onto and those they were not. They had not only customer intimacy but intimacy with prospective customers. They sold what they made; they did not make what they sold. Best of all, they’re still in business today, over 30 years later. They achieved a state of sustainable economic autonomy.

Freedom is most often associated with financial independence. There is a certain amount of truth to this. Financial independence means you can reach as far as “esteem” in Maslow’s hierarchy without doing much more than lavish spending. Unfortunately, money only buys autonomy for as long as the money lasts. History is littered with case studies where it did not. Sustained economic performance - through business cycles and tech cycles - yields the cash flow that makes self-determination possible. That requires evolution and adaptability, and those are functions of meta awareness.

Which brings us to the software development team that insists on autonomy. The team wants the freedom to tell their paymasters how a problem or opportunity space is defined, what to prioritize, how to staff, how much funding they need, and when to expect solution delivery will begin. That’s a great way to work. And, for decades now, management consultants have advised devolving authority to the people closest to the need or opportunity. But that proximity is only as valuable as the team’s comprehension of the problem space, familiarity with the domain, experience with similar engineering challenges, and the ability to think abstractly and concretely. When a team lacks in these things, devolving authority will simply yield a long and expensive path of discovery while the team acquires this knowledge. The less a priori knowledge the team has, the less structured and more haphazard the learning journey; so when the problem space is complex, this becomes a very long and very expensive discovery path indeed - and one that sometimes never actually succeeds.

Autonomy increasingly became the norm in tech as a result of the shortage of capable tech people, driven by the combination of cheap capital and COVID fueling tech investments. Under those conditions, a long learning journey was the price of admission; meta awareness was no longer a requirement for autonomy. With capital a lot more expensive today, tech spending has cooled and returns on tech investments are under much tighter scrutiny, and the longer the learning journey the less viable the tech investment. This is having the effect of exposing friction between how tech expects to operate and how business buyers expect for it to operate. Business buyers financing tech investments want tighter business cases that define returns and provide controls for capital spend. Tech employees want the space to figure out the domain, increasing expense spend and lengthening the time (and therefore cost) to deliver. With capital now having the upper hand, it is not uncommon for tech to be dichotomously demanding both autonomy and to be told exactly what to do.

While autonomy is the ultimate state of evolution for any team, the prerequisites to achieve it are extraordinarily high. It doesn’t require omnipotence, but it does require sufficient fluency with the tech and the domain to know the question to ask, to make appropriate assumptions, to anticipate the likely risks, and to know the sensible defaults to make in design. Devolved authority is a fantastic way to work, but autonomy must be earned, never granted.

Measured Response

Eighteen months ago, I wrote that there is a good case to be made that the tech cycle is more economically significant than the credit cycle. By way of example, customer-facing tech and corporate collaboration technology contributed far more to robust S&P 500 earnings during the pandemic than the Fed’s bond buying and money supply expansion. Having access to capital is great; it doesn’t do a bit of good unless it can be productively channeled.

Twelve months ago, I wrote a piece titled The Credit Cycle Strikes Back. This time last year, rising interest rates and inflation reminiscent of the 1970s cast a pall over the tech sector, most obviously with tech firms laying off tens of thousands. Arguably, it cast a pall over the tech cycle in its entirety, from households forced to consolidate their streaming service subscriptions to employers increasingly requiring their workforce to return to office. Winter had come to tech, courtesy the credit cycle.

Silicon Valley Bank collapsed last month. The balance sheet, risk management, and regulatory reasons for its collapse are well documented. The Fed responded to SVB’s collapse by providing unprecedented liquidity in the form of 100% guarantees on money deposited at SVB. The headline rationale for unlimited deposit insurance - economic policy, political exigence - are also well documented elsewhere. Still, it is an economic event worth looking into.

An interesting aspect to the collapse of SVB is the role that social media played in the run on the bank. A recent paper presents prima facie evidence that the run on SVB was exacerbated by Twitter users. In a pre-social media era, SVB’s capital call to plug a risk management lapse may very well have been a business as usual event; that is, at least, what it appears SVB’s investment banking advisors anticipated. Instead, that capital call was a spark that ignited catastrophic capital flight.

If the link between Tweets and capital flight from SVB is real, the Fed’s decision looks less like a backstop for bank failures caused by poor risk management decisions, and more a pledge to contain the impact of a technology cycle phenomenon on the financial system. As the WSJ put it this week, “… Twit­ter’s role in the saga of Sil­i­con Val­ley Bank re­it­er­ated that the dy­nam­ics of fi­nan­cial con­ta­gion have been for­ever changed by so­cial me­dia.” Most banks had paid attention to the fact that Treasurys had declined in value and took appropriate hedge positions to protect their core business of maturity transformation. Based on fundamentals it wasn’t immediately obvious there was a systemic crisis at hand. Yet the rapidity with which SVB had collapsed was unprecedented. The Fed’s response to that rapidity was equivalent to Mario Draghi’s “whatever it takes” moment.

Social media-fueled events aren’t new in the financial system; by way of example: meme stock inflation. And assuming SVB’s collapse truly was a social media phenomenon, the threat was still at human scale: even if those messengers had a more powerful megaphone than the newspaper reporter of yore observing a queue of people outside a bank branch, it was a message propagated, consumed and acted upon by humans. Thing is, the next (or more accurately, the next after the next) threat will be AI driven, the modern equivalent to program trading that contributed to Black Monday in 1987. Imagine a deepfake providing the spark fueling adjustments by like-minded algorithms spanning every asset class imaginable.

As tech has become an increasingly potent economic force, it represents a bigger and bigger challenge to the financial system. To wit: eventually there will be a machine scale threat to the financial system, and human regulators don’t have machine scale. As the saying goes, regulation exists to protect us from the last crisis - as in, regulations are codified well after the fact; the scale mismatch we’re likely to face implies a low tolerance for delay. The last line of defense are kill switches, and given the tightly coupled, interconnected, and digital nature of the modern financial system, orchestrating kill switches presents a machine scale problem itself. The Fed, the Department of the Treasury, the OCC, the FDIC, the European Central Bank, and all the rest need new tools.

Let’s hope they don't build HAL.

Competency Lost

The captive corporate IT department was a relatively early adopter of Agile management practices, largely out of desperation. Years of expensive overshoots, canceled projects, and poor quality solutions gave IT not just a bad reputation, but a confrontational relationship with its host business. The bet on Agile was successful and, within a few years, the IT organization had transformed itself into a strong, reliable partner: transparency into spend, visibility into delivery, high-quality software, value for money.

Somewhere along the way, the “products not projects” mantra took root and, seeing this as a logical evolution, the captive IT function decided to transform itself again. The applications on the tech estate were redefined as products, assigned delivery teams responsible for them with Product Owners in the pivotal position of defining requirements and setting priorities. Product Owners were recruited from the ranks of the existing Business Analysts and Project Managers. Less senior BAs became Product Managers, while those Project Managers who did not become part of the Product organization were either staffed outside of IT or coached out of the accompany. The Program Management Office was disbanded in favor of a Product Portfolio Management Office with a Chief Product Officer (reporting to the CIO) recruited from the business. Iterations were abandoned in favor of Kanban and continuous deployment. Delivery management was devolved, with teams given the freedom to choose their own product and requirements management practices and tools. With capital cheap and cashflows strong, there was little pressure for cost containment across the business, although there was a large appetite for experimentation and exploration.

As job titles with "Product" became increasingly popular, people with work experience in the role became attractive hires - and deep pocketed companies were willing to pay up for that experience. The first wave of Product Owners and Managers were lured away within a couple of years. Their replacements weren't quite as capable: what they possessed in knowledge of the mechanical process of product management they lacked in fundamentals of Agile requirements definition. These new recruits also had an aversion to getting deeply intimate with the domain, preferring to work on "product strategy" rather than the details of product requirements. In practice, product teams were "long lived" in structure only, not in institutional memory and capability that matter most.

It wasn't just the product team that suffered from depletion.

During the project management years of iterative delivery, something was delivered every two weeks by every team. In the product era, the assertion that "we deploy any time and all the time" masked the fact that little of substance ever got deployed. The logs indicated software was getting pushed, but more features remained toggled off than on. Products evolved, but only slowly.

Engineering discipline also waned. In the project management era, technical and functional quality were reported alongside burn-up charts. In the product regime, these all but disappeared. The assumption was, they had solved their quality problems with Agile development practices, quality was an internal concern of the team, and primarily the responsibility of developers.

The hard-learned software delivery management practices simply evaporated. Backlog management, burn-up charts, financial (software investment) analysis and Agile governance practices had all been abandoned. Again, with money not being a limiting factor, research and learning were prioritized over financial returns.

There were other changes taking place. The host business had settled into a comfortable, slow-growth phase: provided it threw off enough cash flow to mollify investors, the executive team was under no real pressure. IT had decoupled itself from justifying every dollar of spend based on returns to being a provider of development capacity for an annual rate of spend. The definition of IT success had become self-referential: the number and frequency of product deployments and features developed, with occasional verbatim anecdotes that highlighted positive customer experiences. IT's self-directed OKRs were indicators of activity - increased engagement, less customer friction - but not rooted in business outcomes or business results.

The day came when an ambitious new President / COO won board approval to rationalize the family of legacy of products into a single platform to fuel growth and squeeze out inefficiency. The board signed up provided they stayed within a capital budget, could be in market in less than 18 months, and could fully retire legacy products within 24 months, with bonuses indexed to every month they were early.

About a year in, it became clear delivery was well short of where it needed to be. Assurances that everything was on track were not backed up by facts. Lightweight analysis led to analysis work being borne by developers; lax engineering standards resulted in a codebase that required frequent, near-complete refactoring to respond to change; inconsistency in requirements management meant there was no way to measure progress, or change in scope, or total spend versus results; self-defined measures of success meant teams narrowed the definition of "complete", prioritizing the M at the expense of the V to meet a delivery date.

* * *

The sharp rise of interest rates has made capital scarce again. Capital intensive activities like IT are under increased scrutiny. There is less appetite for IT engaging in research and discovery and a much greater emphasis on spend efficiency, delivery consistency, operating transparency and economic outcomes.

The tech organization that was once purpose built for these operating conditions may or may not be prepared to respond to these challenges again. The Agile practices geared for discovery and experimentation are not necessarily the Agile practices geared for consistency and financial management. Pursuing proficiency of new practices may also have come at the cost of proficiency of those previously mastered. Engineering excellence evaporates when it is deemed the exclusive purview of developers. Quality lapses when it is taken for granted. Delivery management skills disappear when tech's feet aren't held to the fire of cost, time and, above all, value. Domain knowledge disappears when it walks out the door; rebuilding it is next to impossible when requirements analysis skills are deprioritized or outright devalued.

The financial crisis of 2008 exposed a lot of companies as structurally misaligned for the new economic reality. As companies restructured in the wake of recession, so did their IT departments. Costly capital has tech in recession today. The longer this condition prevails, the more tech captives and tech companies will need to restructure to align to this new reality.

As most tech organizations have been down this path in recent memory, restructure should be less of a challenge this time. In 2008, the tech playbook for the new reality was emerging and incomplete. The tech organization not only had to master unfamiliar fundamentals like continuous build, unit testing, cloud infrastructure and requirements expressed as Stories, but improvise to fill in the gaps the fundamentals of the time didn't cover, things like vendor management and large program management. Fifteen years on, tech finds itself in similar circumstances. Mastering the playbook this time round is regaining competency lost.

Shadow Work

Last month, Rana Foroohar argued in the FT that worker productivity is declining in no small part because of shadow work. Shadow work is unpaid work done in an economy. Historically, this referred to things like parenting and cleaning the house. The definition has expanded in recent years to include tasks that used to be done by other people that most of us now do for ourselves, largely through self-service technology, like banking and travel booking. There are no objective measures of how much shadow work there is in an economy, but the allegation in the FT article is that it is on the rise, largely because of all the fixing and correcting that the individual now must do on their own behalf.

There is a lot of truth to this. Some of the incremental shadow work is trivial, such as having to update profile information when an employer changes travel app provider. Some is tedious, such as when people must patiently hurdle through the unhelpful layers of primitive chat bots to finally reach a knowledge worker to speak to. Some is time consuming, such as when caught in an irrops travel situation and needing to rebook travel. And some is truly absurd, such as spending months navigating insurance companies and health care providers to get a medical claim paid. Although customer self-service flatters a service provider’s income statement, it wreaks havoc on the customer’s productivity and personal time.

But it is unfair to say that automated customer service has been a boon to business and a burden to the customer. Banking was more laborious and inconvenient for the customer when it could only be performed at a branch on the bank’s time. And it could take several rounds - and days - to get every last detail of one’s travel itinerary right when booking a business trip through a travel agent. Self-service has made things not just better, but far less labor intensive for the ultimate customer.

It is more accurate to say that any increase in shadow work borne by the customer is not really a phenomenon of the shift to customer self-service as much as it lays bare the shortcomings of providers that a large staff of knowledgable customer service agents were able to gloss over.

First, a lot of companies force their customers to do business with them in the way the company operates, not in the way the customer prefers to do business. A retailer that requires its customers to put an order on a specific location rather than algorithmically routing the order for optimal fulfillment to the customer - e.g., for best availability, shortest time to arrival, lowest cost of transportation - forces the customer to navigate the company’s complexity in order to do business. Companies do this kind of thing all the time because they simply can’t imagine any other way of working.

Second, edge cases defy automation. Businesses with exposure to a lot of edge cases or an intolerance to them will shift burden to customers when they arise. The travel industry is highly vulnerable to weather and suffers greatly with extreme weather events. Airline apps have come a long way since they made their debut 15 years ago, but when weather disrupts air travel, the queues at customer service desks and phone lines get congested because there is a limit to the solutions that can be offered through an app.

Third, even the simplest of businesses in the most routine of industries frequently manage customer service as a cost to be avoided, if not outright blocked. A call center that is managed to minimize average call time as opposed to time to resolution is incentivized to direct the caller somewhere else or deflect them entirely rather than resolve the customer problem. No amount of self-service technology will compensate for a company ethos that treats the customer as the problem.

There is no doubt that shadow work has increased, but that increase has less to do with the proliferation of customer self-service and more to do with the limitations of its implementation and the provider’s attitude toward their customer.

Perhaps more important is what a company loses when it reduces the customer service it provides through its people: the inability to immediately respond humanely to a customer in need; the aggregate loss of customer empathy through a loss of contact. This makes it far more difficult for a company to nurture its next generation of knowledge workers to troubleshoot and resolve increasingly complex customer service situations.

But of greater concern is that as useful as automation is from a convenience and scale perspective, its proliferation drives home the point that customers are increasingly something to be harvested, not people with whom to establish relationships. Society loses something when services are proctored at machine rather than human scale. In this light, the erosion of individual productivity is relatively minor.

Relics

I recently came across a box of very old technology tucked away in my basement: PDAs, mobile phones, digital cameras and even a couple of old laptops, all over two decades old. It was an interesting find, if slightly disturbing to think this stuff has moved house a couple of times. Before disposing of something, I try to repurpose it if I can. That's hard to do with electronics once they're orphaned by their manufacturers. Still, electronics recycling wasn't as easy to do twenty years ago, so perhaps just as well that I held onto them until long after it was.

In addition to bringing back fond memories, finding this trove got me thinking about about how rapidly mobile computing evolved. In the box from the basement were a couple of PDAs, one each by HP and Compaq; phones by Motorola, Nokia (including a 9210 Communicator) and Ericcson; and a digital video recorder by Canon. The Compaq brand has all but disappeared; the makers of two of the three phones exited the mobile phone business years ago; the Mini-DV technology of the camcorder was obsolete within a few years of its manufacture.

There were also a couple of laptops in the box, one each made by Compaq and Sony. The interesting thing about the laptops is how little the form factor has changed. My first laptop was a Zenith SuperSport 286. The basic design of the laptop computer hasn't changed much since the late 1980s (although mercifully they weigh less than 17 lbs). The Compaq and Sony laptops in that box from the basement are not physically different from the laptops of today: the Sony had a square screen and lots of different ports, where a modern laptop has a rectangular screen and a few USB ports.

The laptop, of course, replaced the luggable computer of the 1970s and early 1980s made by the likes of Osborne and Kaypro and Compaq. The luggable was a statement for the era: what compels a person to haul around disk drives, CPU, keyboard and a small CRT? Maybe it was the free upper-body workout. The laptop was a quantum improvement in mobile computing.

But once that quantum improvement happened, the laptop became decidedly less exciting. As the rate of change of capabilities in the laptop slowed, getting a new laptop became less of an event and more of a pain in the ass. Not to mention that, just like the PDA and phone manufacturers mentioned above, the pioneers and early innovators didn’t survive long enough to reap the full benefits of the space maturing.

And the same phenomenon happened in the PDA/Phone/camera space. The quantum leap was when these converged with the original iPhone. Since then, a new phone has become less and less of an event. Yes, just like laptops, they get incrementally better. Fortunately, migration via cloud makes upgrading less of a pain in the ass.

The transition from exciting to ordinary correlates to the utility value of technology in our lives: in personal productivity, entertainment, and increasingly as the primary (if not only) channel for doing things. There are, of course, several transformative technologies in their nascent stages. Somehow, I don’t think any are spawning the Zenith Data Systems and Compaqs making a future relic that somebody someday will be slightly amused to find in a box in their basement.

Reinvention Risk Trade

Southwest Airlines has made headlines in recent days for all the wrong reasons: bad weather impacted air travel, which required Southwest to adjust plane and crew schedules. Those adjusted schedules were often logistically flawed because the planes and crews matched at a specific place and time didn’t make sense in the real world. Making matters worse, those adjusted schedules had to be re-(and re- and re-)adjusted every time either the weather changed or operations changed (ie., more flight cancellations), and both the weather and operations were changing throughout Southwest's route network. The culprit, according to people at Southwest quoted by the Wall Street Journal, was scheduling technology that could not sufficiently scale and is nearing end-of-life. Whether a problem of rapid growth or neglected investment, everybody seems to agree that Southwest has been living on borrowed time.

The neglect of core technology is an all too common a practice by virtually every company: the technology becomes more complex than its foundational architecture was ever intended to support, the team familiar with the technology erodes through layoff and attrition, and as a result a technology become more vulnerable to failure. But it still works day in and day out, so there is no incentive to invest in repair or replacement.

Unfortunately, vulnerability of an aging technology isn't a financial statement phenomenon; it is at best one risk mentioned among many in the 10-K. However, money spent on the labor to reduce that vulnerability is a financial statement phenomenon. Add to that the opportunity cost: every dollar spent on risk mitigation is a dollar that doesn't go toward a net new investment in the business, or a dollar that can't be returned to investors. While it doesn’t cost anything for a technology to fall into a state of disrepair, it sure costs a lot to rehabilitate it. Conversely, neglect is not only free, it’s cash flow positive: i.e., the company can claim victory for streamlining tech spend.

But as mentioned above, neglect creates business risk. And risk is a peculiar thing.

There have been dozens of massive macroeconomic risks realized in the past 25 years - acts of terror, acts of war, financial crises, environmental disasters, viral pandemics - that have made a mockery of the most sophisticated of corporate risk models. Yet risk is still no better an investment proposition than it was a quarter of a century ago: investing to be prepared for "black swan" events (i.e., robustness) is still an uncommon practice (n.b. perhaps inventory build-up and multiple sourcing practices in response to supply chain disruption in recent years will change this, but it remains to be seen how durable this turns out to be). And anyway, dilapidated internal systems are self-inflicted exposures: even if they can talk about such risks publicly, CEOs aren't paid for their acumen at developing and executing remediation strategies. Plus, just about every company will accept exposure to technology risk as business as usual. Business is risk. If a company spent to mitigate every last risk, it would be wildly unprofitable. There's an amount the company budgets annually for maintaining the status quo and every now and again the company will try staffing some up-and-coming manager or hire some hotshot consultants to figure out a way to make things a little less bad. This is great, but it amounts to pennies spent mitigating very large dollar amounts of exposure. In other words, hope is all too often the insurance policy against having a huge hole blown in the income statement by the failure of a high-risk technology.

While risk is generally not an investible proposition for technology (unless business operations are being wildly disrupted because of it, such as is happening to Southwest this week), sometimes there is a golden ticket that promises to make the risk simply go away, such as when a company has a legitimate case to make that it can reposition itself as an ecosystem if only it were built on a cloud-based platform. With consistent cash flows and an existing - and under-leveraged - network of partners, the right leader can motivate investors to pony up to make a wholesale replacement of existing technology. It's a growth story with a side order of risk mitigation through modernization. And with the appropriate supporting data, this is an attractive proposition to risk capital.

Investible, yes, especially since it is more than just an investment that makes the business less bad than it need be. But the headline doesn't tell the whole story. Switching from one technology to another is not a trade of one set of business parameters (the company's current business and operating model) for another (the company's future business and operating model). It is more accurately a trade of risk profiles: exposure to a current technology (the tech and operations supporting current cash flows) versus exposure to aspirational technology (the tech and operations supporting aspirational cash flows).

The magnitude of the technology risk between the two is really no different. It is, optimistically, an exchange of current system sustainability risk for the combination of development risk and future system sustainability risk. System fragility and key person risk may make the status quo highly unattractive, but software development has long track record of cost overruns and failure. In practice, of course, development risk and current system sustainability risk are carried at the same time, and current system risk may be carried for a very long time if it proves difficult to fully retire some legacy components. The true exposure is therefore far more complex than current versus future technology. In practical terms, this means is that just because “reinventing the business” makes legacy modernization more palatable to investors doesn’t mean it offers the business a safe way out of technology risk.

It bears mentioning that a business electing to mitigate existing technology risk through reinvention is taking on a new set of challenges, especially if that company has not made such an investment in recent years. It must be ready to deal with contemporary software delivery patterns and practices that are much different from those of even a decade ago. It must know how to avoid the common mistakes that plague replatforming initiatives. It must be prepared to deal with knowledge asymmetry vis-a-vis vendor partners. It must know how to set the expectation for transparency in the form of working software, not progress against plans. And it must be prepared to practice an activist form of governance - not the bullshit spewed by vendors passed off as governance - to make those investments a success.

Reinvention promises freedom from the shackles of the status quo, but while going about that reinvention, exposure to technology risk vastly increases and stays at an elevated level for a long period of time. The future awaits the replatformed business, but do be careful what you get investors to agree to let you sign up to deliver.

You should...

Our favorite craft brewer has a tap room. They never have more than a dozen beers on tap. They only serve their own brewed beers, never anything sourced from another producer. They have only marginal amounts of product distribution; for all intents and purposes, they sell only through their tap room. While they’ll fill a growler or crowler, they do not keep inventory in cans, only kegs. They turn over 2/3rds - maybe it’s 3/4ths, maybe it’s 7/8ths - of their taps seasonally, where a season might be as short as a month or as long as half a year, depending on the beer. They have a flat screen but never broadcast sports or politics, only streamed images of nature or trains or the like. They stream their own custom audio playlist to provide ambient noise.

They run the business this way because this is the business they want to run. They have direct access to 99.9% of their customers (not 100% as once it leaves the premises, the contents of a crowler could end up in anybody’s stomach…) They’re not committed to provide beer to other businesses on any kind of a product mix by volume, let alone date delivery schedule. They get to experiment with product, constantly. They don’t make what they sell, they sell what they make.

On any given day in the taproom, a customer will give them advice, a sentence that always begins with the words “you should.” Such as, “you should distribute this and that beer to these bars in Madison and Milwaukee - you’d sell 20x as much as you do in a single tap room.” Or, “you should have a small electric oven and sell food.” Or “you should have dozens of TVs with football and this place would be packed on weekends.”

They are every bit as good at customer interaction as they are with making and serving beer. They listen patiently, smile, and reply with “thank you, we’ll think about that.”

* * *

The software business has long been intertwined with management consulting to one degree or another. Decades ago, tech automated tasks that changed long standing business processes; management was fascinated as this made businesses more efficient. The dot-com era (followed by mobile, and shortly thereafter by social media) ushered in changes in corporate <— —> customer and —> employee interactions. The contemporary tech landscape (cloud, AI, distributed ledger tech) - and not for the first time in the history of tech - promises to “reinvent the business.” ‘Twas ever thus: tech has long been, and sought out as, a source of business advice.

On the whole, tech is not a source of bad advice. When tech gets close to a problem space, it brings a different and generally value generative solution. Why do that work manually when we can easily automate and orchestrate that? Why have this customer talk to that salesperson when the customer can do that for themselves 99% of the time? Why have people churn through that data when a machine can learn the patterns?

But sometimes, advice from tech is truly value destructive.

I wrote about this some years ago, but standing next to me in the queue for a flight out of Dallas were a couple of logistics consultants lamenting the fact that a client had taken a tech consultancy’s advice and prioritized flexibility over volume in their distribution strategy. It sounds great in a windowless conference room: why let restaurants (who are 80% of the clientele) run out of branzino before the night is over? You should run a fleet of small delivery trucks to top up their stock of branzino for the night in near real time. Except, the distribution cost for a few branzino to that restaurant - even if we put it in a small truck with a few packages of great northern beans to the restaurant down the street and some basmati to a restaurant a few blocks away - is bloody expensive. The economics of distribution are based on volume, not flexibility. That restaurant will have to put a lot of adjectives in front of the noun to justify the cost of limited-supplied branzino on a Tuesday in November. ’tis far more economically efficient for the waitstaff to push the red snapper when the branzino runs out.

Another time, I was working with a manufacturer of very large equipment. The manufacturer sold through a dealer network. Dealers are given guidance from the manufacturer’s sales forecasting division as to the volume of each type of machine they should expect to sell in the next two years, by quarter. Dealers order machines with that guidance as an input (their balance sheet being another input), and over the course of time dealer orders get routed to a manufacturing plant to the dealer sales lot. The tech people couldn’t grok this. Manufacturing something without a specific end customer? You should have just-in-time manufacturing, so a customer order goes directly to a manufacturing facility. That way there is no finished goods inventory collecting dust on a dealer lot and the component supply chain can be somehow further optimized. Except, that exposes the manufacturer to demand swings. As it is, the manufacturer has hundreds of dealer P&Ls to which it can export its own P&L. They’ll build give or take 250,000 units of this model, and give or take 160,000 units of that model, and give or take 90,000 units of that other model, and 000,000s of all those other models, year in and year out, with minor modifications in major product cycles in an industry regulated by, among other things, emission standards. That’s a lot of machine volume, especially when there are dozens and dozens of models of tens of thousands of unit volume. The manufacturer has a captive dealer network that will buy 100% of what the manufacturer produces. The dealer network acts as a buffer on the manufacturer’s P&L: while the good years may not be maximally great for the manufacturer, the bad years aren’t too terribly bad, let alone event horizons on the income statement. That, in turn, creates consistency of cash flows for the manufacturer, which investors reward with a high credit rating, which makes debt more easily serviceable, which leaves money to reward equity holders. Just-in-time manufacturing exposes the manufacturer to end-customer market volatility, which would require a substantial change in capital structure, which would penalize both equity and debt holders. Markets go up, but markets also go down: minimizing the downside was of more value than maximizing the upside. Tech has known these swings (anyone remember the home computer revolution?), but the commercial landscape is so destructive, there is a lack of instititional memory.

There was the insurance company implementing a workflow management system for automating policy renewal. Although insurance data is highly structured, there are a lot of rules and conditions on the rules governing renewal, spanning the micro (e.g., geographic location in a city and number of employees) and macro (discounting and payout rules in the event a customer has a property & casualty policy as well as an umbrella policy, as opposed to just a property & casualty policy). There are a lot of policy renewal rules that go very deep into the very edge cases of the edge cases (e.g., a policy that renews on February 29). Well, the boss wants this policy automation thing done quickly, because we have a great story to share with investors that we’ve reduced the labor intensity of policy renewal. Along comes a tech vendor with a compelling suggestion: insurance company, you should incentivize your process automation vendor by rewarding them for the shortest time to development of each codified rule. (The operative word here is development, which is not the same as production delivery: delivery was deemed out of the control of the development partner.) Except, the contract the insurance company signed indexed cash payable to the vendor for development complete of each rule. Within three months, the vendor had tapped out over 80% of the cash for software development, yet each rule that was dev complete had on average over five severity-1 defects associated with it and was therefore unsuitable for deployment. Worse still, one third of those defects were blocking, meaning there were countless other defects to discover once the blocking defect was removed.

Then there is the purely speculative pontification. I wrote three years ago that management consultants love to advise customers to get into the disruption game. Consider what was happening in home meals and transportation and the like 5 years ago: this is coming for your industry, so you better get in the game. To wit: hey financial services firm, you should invest in developing your own line of disruptive fintech. Except, in practice it turned out to be far more prudent for incumbents to colonize startup firms by placing people on startup firms boards and then co-opt them to the credit cycle through greenmail policies. The latter strategy was a hell of a lot cheaper than the former. And those home-meal- and food-delivery tech firms who were the reference implementation for disruption? They ended up disrupting one another, more than they disrupted the incumbents. Come to think of it, the winning strategy was that of the wise fighting fish in the movie From Russia, With Love: the stupid ones fight; the exhausted winner of that fight is easy prey for the smart fighting fish who sat out the fight and waited patiently. (Note to self: this is two consecutive months that I’ve used FRWL as an analogy, I really need to diversify my analogies. That said, Eric Pohlmann’s voiceover is truly underrated in cinematic history.)

This is, arguably, playing out today as auto manufacturers pull back from autonomous vehicle investments. Hey automotive firm, you should invest in autonomous vehicle delivery because it will totally disrupt the industry. Except, it’s proving to be much further away from reality than thought. It was great as long as delivery expectations were low and valuations were high. It isn’t so lucrative now.

Obviously, all advice has to meet a company where it’s at. Generic assertions of impending tech disruption in a well established industry crater instantly (even faster than crypto during a bank run) when they meet incumbent economic dynamics. People (especially long term employees) resist operational change; debt cycles outright crush those changes. Not meeting a company where it’s at renders the advisor a curious (and at best mildly amusing) pontificator.

At the same time, advice also has to meet the industry that consumer is in where it’s at. That’s not so easy when the advisor can only think transactionally. “Digital disruption” and “omnichannel” are, thankfully, out of favor now. They were ignorant of the industry dynamics at play, as mentioned earlier: co-opt the disruptor to the prevailing industry trends and the aspirant tech cycle is subservient to the credit cycle. It is (if ironically in evolutionary terms) well captured by Opus the penguin’s response to the allegedly inevitable.

* * *

One thing about being in the advisory space is that at a micro level, just about every firm has something - many somethings - unique to offer. (The caveat “just about” is intentional: it’s just about, but not all: as Mojo Nixon pointed out, Elvis is everywhere, but not in everyone.) “You should” advice that does not reflect that uniqueness - the expression of the company itself - is bound to fall flat. Yes, macro trends matter, but start with the business itself. If the people in that business know who they are and who they are not, you’ve got a great place to start. And if they don’t, the most Hyde Park Corner prophet of “disruption” isn’t going to hold an audience for long.

* * *

In the interest of full disclosure, we have, as you might well expect, been sources of what we deem brilliant “you should” advice to the aforementioned craft brewer. You should:

1. Have a beer that incorporates cough syrup as an ingredient, a beer version of a Flaming Moe.
2. Let me put my head underneath the taps like Barney Gumble when Moe isn’t around.
3. Have drone delivery of your beer. Because drones.
4. Have a trap door you can open that drops egregious “you should” pontificators into a pool of hungry alligators.

We’ve been assured that the proprietors are giving serious thought to every one of these.

Strategy

A few months ago I was asked to review a product strategy a team had put together. I had to give them the unfortunate feedback that what they had created was a document with a lot of words, but those words did not articulate a strategy.

There is a formula for articulating strategy. In his book Good Strategy, Bad Strategy, Richard Rumelt puts forward the three essential elements of a strategy. It must:

1. Identify a need or opportunity (the why)
2. Offer a guiding policy for responding to the need or opportunity (the what)
3. Define concrete actions for executing the policy (the how)

There’s more to it, of course. The need or opportunity has to be well structured and specific. The guiding policy must be focused on the leverage that a company can uniquely bring to bear (this is effectively the who that a company is) as well as anticipate the reaction of other market participants. The actions must be, well, actionable.

What we see too often passed off as strategy are goals (“grow the business by xx% in the next y years” is a goal, not a strategy); vision statements (“we want to be the premier provider of aquatic taxidermy products” is a lofty if vain ambition); or statements that are effectively guiding policies (“to be the one stop shop for all of our customer’s aquatic taxidermy needs”) without the need (why) articulated or actions (how) defined.

I’ve seen the aftermath of a number of failed strategic planning initiatives. Each time, the initiatives failed to articulate at least two, and sometimes all three, of the aforementioned elements that compose a strategy. The postmortems to understand why these initiatives failed exposed a few consistent patterns.

One pattern is that the people involved in the strategic thinking did not truly come to grips with what is actually going on in a company’s environment. To understand “what’s going on” requires collating the relevant facts (internal and external) into a cohesive analysis. That, in turn, requires a great deal of situational awareness: an honest assessment of a company’s capabilities, a high degree of customer empathy, and a fair bit of macroeconomic understanding. It also requires a sense of timeliness: not too immediate so as to be just a tactical assessment (your competitors are easier to do business with through digital channels than you are), not too far in the future to be purely speculative (ambient computing). All too often, the definition of the opportunity is derived - in many cases, copied verbatim - from some other source, such as an analyst report, somebody else’s PowerPoint making the rounds inside the company, the company’s most recent annual report. Or it is a truism (the world of aquatic taxidermy is going digital). Or worse still, it is a tautology (customers will buy aquatic taxidermy products through digital channels and from physical store locations from specialist retailers and general merchandisers).

Defining the opportunity through a thorough understanding what’s going on is hard. It’s also awkward, an exercise of the blindfolded people describing the pachyderm. And that’s ok. It takes several iterations, it requires diversity of participants, and while there will be many moments when the activity feels like churn (and not the kind of churn that yields butter or ice cream), it is worth the investment of time. The “what’s going on” is, arguably, the most important thing in formulating a strategy. If the “what’s going on” is wrong, the opportunity isn’t clear, and as a result the most eloquent guiding policy and the most definitive of actions will not solve the right problem. By way of analogy, directional North stars are great, but in the field we still largely navigate by compass. A compass is low tech. It works throgh attraction to a magnetic field that serves as a close enough proxy to true north, which we correct with declination. As Dr. John Kay showed, the most successful companies navigate by muddling through.

Another pattern: whereas the would-be strategic thinkers spend comparatively little time defining the opportunity, they are obsessed with formulating the equivalent of the guiding policies. Some of this is likely a function of professional programming: if, for the totality of your career, the boss has supplied you with the reason why you do the things that you do, it isn’t natural to start a new initiative by asking “why”. Just the opposite. But the biggest reason for focusing on the guiding policies is that the strategic thinkers believe they are being paid to come up with clever statements of what a company should do. No surprise that strategic planning exercises tend to produce a lot of “what to do” options, which they present as a portfolio of strategic opportunities. Yes, the portfolio passes the volume test applied to any strategic planning initiative: too few slides suggests the team just faffed about for several weeks. So what we get is a shotgun blast of strategy: dozens of “what to do” options, only some (not many, let alone all) of which are complimentary to one another. Plenty of things to try, but they’re just that: things to try. They don’t converge at cohesive interim states where the company is poised to engage in a next level of exploitation of an opportunity or need, exploitation that is amplified through development of the unique capabilities the company brought to the table in the first place. This is not a strategy as much as it is a task list of very coarsely grained things to maybe do, at some point, and see what happens.

The fear of not having a sufficient quantity of clever “whats” is understandable, but misplaced. ‘Tis better to have a few very powerful statements of “why” that tell the executive leadership team and the board very concrete things they do not know about their company or market, with very strong statements of “what” to do about them.

The third pattern contributing to strategic planning failure is the aversion to defining the concrete actions necessary to operationalize a strategy. As damaging as getting the why wrong is to the validity of the what, glossing over or ignoring the how renders a guiding policy into a fairy tale. Figuring out the how is, for a lot of people, the least attractive part of strategy formulation: it requires coming face to face with the organizational headwinds such as the learned helplessness, the dearth of domain knowledge, the resistance to change that characterize legacy organizations. Operationalization - especially in an environment with decades old legacy systems compounded on top of one another - is where great ideas go to die: we could never do that here, you don’t know the history, it doesn’t work like that, and so forth. Yet a strategy without a clear path of execution is just a theory. No company has the luxury of not starting from where it is today. Strategy has to meet a company where it is at. This isn't big up-front design; it's just the first iteration of the end-to-end to establish that execution is in fact plausible, supplemented with a now / next / later to define a plausible path of evolution.

The aversion to defining execution of a proposed strategy stems from at least two sources. One is the tedium of deep diving into operational systems to figure out what is possible and what is not, and to then delve into the details to turn tables to interrogate in detail the things we can do, changing the question from "why we can't" into “why we can”. But the more compelling reason that strategic thinkers avoid detailing execution that I’ve observed is the fear that a single ground truth could undo the brilliance of a strategy. Strategy is immutably perfect in the vacuum of a windowless conference room. It doesn’t do so well once it makes first contact with reality. And that is the real world problem to the person academically defining strategy in the absence of execution: when given a choice, a company will always choose as Ernst Stavro Blofeld did in the movie version of From Russia With Love: although Kronsteen’s plan may very well have been perfect, it was Klebb who, despite execution failure (engineered through improvisation by James Bond), was the only person who could achieve the intended objective. Strategy doesn't achieve outcomes. Delivery does.

I’ve worked with a number of people who insist they no longer wish to work in execution or delivery roles, only strategy. Living in an abstract world detached from operational constraints is great, but abstract worlds don’t generate cash flow for operating companies. The division of strategy and delivery is a professional paradox: if you do not wish to work in delivery, by definition you cannot work in strategy.

Strategy is genuinely hard. It isn’t hard because it bridges the gap between what a company is today and what it hopes to be in the future (the what). It’s hard because good strategy clearly defines what a company is and is not today (the who), what the opportunities are and are not for it in the future (the why), and the actionable steps it can take to making that future a reality (the how), orchestrated via compelling guiding policies (the what).

Successful business execution is difficult. Successful business strategy is even more difficult. If you want to work in strategy, you better know what it is you're signing up for.