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.

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.

The Ever Given is Not a Black Swan Event

By transporting a container more cheaply than any other vessel afloat, [Emma Maersk] and her six sister ships were expected to stimulate even faster growth in international trade, lowering the cost of moving goods through the supply chains that had reshaped the global economy…

An extremely large container ship - the Ever Given - has been in the news this past week for running aground and blocking traffic through the Suez Canal. This has caused considerable disruption to global supply chains. Some have incorrectly referred to the incident and the aftermath as a “black swan” event.

The disruption is not simply the result of a ship running aground and blocking traffic in a busy, narrow passageway. The disruption is a function of the scale of the container ships themselves. In the mid-2000s, with global trade growing by leaps and bounds every year, shipping companies opted for larger and larger vessels. The largest of these ships each carry the equivalent of over 10,000 truckloads of goods. With trade growing, the value proposition of ever-larger ships was self evident in 2007: “On a per-container basis, a larger vessel cost less to build and operate than a smaller one, allowing the owner to undercut competitors’ cargo rates and still earn a healthy profit.”

Such scale led to optimization among tightly-coupled participants in the global supply chain. “Operating on regular schedules - such that an identical vessel departs Shanghai every Wednesday, stops in Singapore nine days later and arrives in Antwerp five weeks hence, with tight connections to barges and freight trains - intermodal container transport gave manufacturers and retailers the confidence to plan tightly organized long-distance supply chains.”

But as Nassim Taleb pointed out well over a decade ago in his book The Black Swan, “Globalization [of financial markets] creates interlocking fragility, while reducing volatility and giving the appearance of stability. In other words it creates devastating Black Swans.”

And so it has happened with container shipping.

Though supremely efficient at sea, Emma and the even larger ships that followed in her wake became a nightmare. By making freight transportation slower and less reliable than it had been decades earlier, they helped to stifle the globalization of manufacturing…

Local optimization - in this case, minimizing the cost of transporting a container of goods over the sea - distorted the economies of scale of global shipping. Shippers, facing excessive capacity after the financial crisis of 2008, either went out of business, merged, or did deals to fill their ships to capacity. Optimization of the oceangoing containership fleet came at the cost of the efficiency of the rest of the supply chain into which it was integrated.

Discharging and reloading the vessel took longer as well, and not only because there were more boxes to put off and on. The new ships were much wider than their predecessors, so each of the giant shoreside cranes needed to reach a greater distance before picking up an inbound container and bringing it to the wharf, adding seconds to the average time required to move each box. Thousands more boxes multiplied by more handling time per box could add hours, or even days, to the average port call. Delays were legion.

Freight railroads staggered under the heavy flow of boxes into and out of the ports. Where once an entire shipload of imports might be on its way to inland destination within a day, now it could take two or three. Queues of diesel-belching trucks lined up at terminal gates, drivers unable to collect their loads because the ship lines had too few chassis on which to haul the arriving containers. And often enough, the partners in one of the four alliances that came to dominate ocean shipping didn’t use the same terminal in a particular port, requiring expensive truck trips just to transfer boxes from an inbound ship at one terminal to an outbound ship at another.

But the disruption to supply chains created by the beaching of the Ever Given is not a black swan event. First, the Ever Given was involved in an incident in 2019 in which it was caught in high winds while operating at slow speed and collided with a pleasure ferry in the Elbe River in Hamburg, Germany. The same conditions have been cited as contributing factors to the vessel’s recent beaching in the Suez, and it is fair to say those conditions are not exactly the stuff of “one hundred year events”. Second, the supply chain bedlam triggered by the Ever Given’s beaching exposed the asymmetric downside risk endemic to the systemic fragility - that is, the woefully inadequate robustness - in tightly-coupled supply chains. However, this asymmetric risk - as evidenced by the previous two paragraphs - was hidden in plain sight.

An incident is not a “black swan event” simply because some people could not fathom the possibility of it occurring. The triggering event had happened before. The systemic fragility was as plain as day. In fact, the article I’ve quoted throughout this post describing that fragility - titled, appropriately enough, The Megaships That Broke Global Trade - was not published in the wake of the Ever Given’s beaching: it appeared last October in the Wall Street Journal. This is not a black swan event. This was a fragile system operating on borrowed time.

I kept a copy of the October WSJ article intending to use it as a metaphor for large software development processes designed to optimize labor unit costs, specifically developer labor unit costs. The pattern is the same, the risks are the same, the consequences are the same. But with hindsight the article reads much better as a chronicle of one-way risk: a tightly-coupled system with highly concentrated activity in the value stream that, in turn, is locally optimized to a single variable is a powder keg that can be detonated by the most mundane of sparks.

As written, the October WSJ article about the Emma Maersk is a story of misplaced local optimization creating systemic inefficiency and undesirable outcomes. Ironically, the author laments the factors that do not “flatter the bottom line” resulting from local optimization of the oceangoing container fleet: the need for “keeping more inventory, shipping via multiple routings and producing in multiple factories rather than in giant sole-source plants”. While these measures certainly increase costs, they also make manufacturing and distribution far more robust (that is, less fragile). The Ever Given incident points out the benefits of doing so. Cheap insurance policies against one-way downside risk such as multiple facilities and alternative shipping routes are a far preferable price to pay than to have factors outside of your control - a beached container vessel in the Suez - make a mockery of fragile optimization.

While the Emma Maersk article is a compelling story of systemic distortions resulting from local optimization, it is really the story of a critical yet fragile system waiting for a simple, pedestrian event to realize asymmetric downside risk.

Legacy Modernization

I've worked with quite a few companies for which long-lived software assets remain critical to day-to-day operations, ranging from 20-year-old ERP systems to custom software products that first processed a transaction way back in the 1960s. In some cases, if only a very few, these assets continue to be used because they still work very well, were thoughtfully designed, and have been well cared for over the years. The vast majority of the time, though, they continue to be used because the cost to replace them is prohibitive. Decades of poor architecture guidelines and lax developer discipline resulted in the commercial-off-the-shelf components of an ERP becoming inseparable from the custom code built around it. Decades of upstream and downstream systems resulted in point-to-point and often database-level integrations to legacy systems. Several turns through the business cycle starved those legacy applications for investment at critical junctures, and the passage of time has left few people remaining with intimate knowledge of how they work. The assets are not current with business needs, it will require a long time to re-acquire the knowledge of how they work, and it will require a fair bit of investment if they are to be leveled up to meet current needs. Operations suffer an increased labor intensity needed to compensate for feature gaps and repetitive, systemic errors.

It may seem like common sense that this is an asset that must be replaced for the betterment of the business, but the economics don't necessarily justify doing so. It's cheaper to hire administrative labor to make up for systemic shortcomings than it is to replace all the features and functions of an asset that has been decades in development. Risk may be legitimate, but risk is a threat that merits cost for preparation and containment, not necessarily cost for elimination. Justifying a pricey legacy migration principally on an expectation of risk realization is a huge career gamble, especially if there is plausible deniability (e.g., annual independent audits that flag the exposure "high" but the probability "low") to the decision-maker should the risk actually materialize. By and large, until the asset fails in spectacular fashion, there's no real motivation for a business to invest in a replacement.

Enter the "legacy modernization" initiative. A basic premise is that there are alternatives to traditional "lift and shift" strategies by retiring legacy assets in a piecemeal fashion. Several things stand out about these initiatives.

The first and most obvious is that they are long on how to start, but short on how to finish. The exercise of assessing, modeling and dispositioning the landscape does offer valuable new ways of looking at legacy assets. Collectively mapping an ERP, CRM and a handful of custom applications to logical domains as opposed to traditional thinking that portrays them as closed systems with territorial control over data offers a different perspective on software capabilities. The suitability of the investment profile (sustain, evolve or upgrade) of underlying assets can also change when seen in the light of how those assets enable or impair the evolution of those domains in response to business need. Code translators (for example, from COBOL to J2EE) can make legacy code accessible to a new generation of developers to aid with reverse-engineering. All useful stuff, but it's still just assessment work. A lot has to be true for a piecemeal strategy to be viable, and that isn't knowable until coding begins in anger.

The one (and as near as I an tell, only) alternative pattern to "lift and shift" is strangulation in one form or another. Or perhaps more accurately, asset capture through strangulation. The preferred form is the gradual retirement of code through encapsulation, interception and substitution. When it is viable, it is pretty straightforward: isolate key functionality, decouple it from things like direct database calls, wrap it in an API, create a battery of automated tests around it, have old and new systems invoke the API, rewrite the functionality in a modern architecture using a modern language, and redirect the API to the new code from the old once ready. To truly incrementally retire the legacy code, however, requires that the legacy asset itself be both decomposable and (at least to some extent) recomposable. The integration of orchestration logic with functional logic common in legacy code makes decomposition very difficult. Tight coupling of code to data (think COBOL programs to VSAM files, or ABAP programs to customized tables in SAP) makes code difficult to recompose into new structures. Plus, both decomposition and recomposition require people fluent in the legacy code, with the skills to re-engineer it to do things such as redirect to an abstraction layer that enables functionality to be migrated, and with the confidence to do so without causing any damage. Of course, this can be side-stepped, at least to a degree, by building agnostic user interfaces that invoke APIs over robotic process automation, but the lack of malleability of the underlying code will preclude eclipsing a legacy asset at a finely-grained and highly tunable manner. It can only be strangled at a more coarsely-grained manner. By way of example, a credit-card processor supporting both house-branded cards and white-labeled third party cards that wants to replace its legacy transaction processing assets might be able to migrate volume brand-by-brand. This is preferable to migrating all-or-nothing, but it lacks the granularity of migrating function-by-function within the asset itself. Excluding any card-specific custom capabilities, 100% of the legacy codebase will remain in production until all transactions are redirected toward the replacement and all in-flight transactions are fully processed.

Something often overlooked is that the tight coupling of software assets is a mirror of the tight coupling of business functions. A company with a legacy procurement system integrated to a legacy ERP may find that it can modernize purchase orders but not purchase order receiving because of tight coupling of receiving to inventory, accounts payable, manufacturing and supply chain management. It is one thing to strangle purchase order functionality or migrate purchase order volume from legacy to modern systems, but it is entirely another to do so over core accounting functions that are, by their nature, tightly coupled capabilities regardless the fact those capabilities are the purview of different departments or functions. Integrated finance really does have its benefits.

Another challenge to modernization is finding relevant reference cases. The conditions surrounding one company's legacy assets - sophistication and quirks of the business model, erosion of asset and / or business process fluency, complications from prior modernizations that started but stalled, complications from acquisitions, complications from regulatory restrictions, and on and on - are not identical to those surrounding another. Finding a success story is great, but applicability of any methodology is a function of the similarity of conditions. As was written many decades ago by the great IT philosopher L. Tolstoy, "all IT organizations are dysfunctional in their own way." There isn't a legacy migration playbook. At best, there are individual plays, or more likely things to be learned from individual plays.

Perhaps the biggest challenge is that the value proposition for legacy modernization is thin. A quick survey of consulting firms pitching legacy modernization services reveals the primary benefits to be things like "reduce IT complexity and costs", "improve flexibility and collaboration", "increase data consistency." These are woolly statements, difficult to quantify, and not necessarily true. Replacing the long-since-paid-for on-prem mainframe with IaaS will bulge the expense line of the income statement as accountants treat IaaS as an annually-funded subscription, not an asset that can be bought and paid for and capitalized. While there may indeed be a step-by-step path to legacy modernization, the cost of not completing the journey is additional layers of code that need to be maintained, redundant production systems and infrastructure, and additional layers of transaction reconciliation. Reduction of IT costs requires legacy system retirement. Retirement requires feature parity of core cases and edge cases and a complete migration of volume. While any individual step of modernization may be inexpensive, the enterprise must still sign up for the entire journey if the justification is "reduce IT complexity and costs".

This makes the value case that much more important. Legacy modernization performed in pursuit of digital modernization - that is, in pursuit of changing the fundamental business model - can be a path to that value. My colleague Ranbir Chawla pointed out to me a couple of years ago that a company we were working with was steadfast in espousing technology paradigms abandoned a long time ago by the vendors who sold them. Those paradigms - even technological paradigms - are blinders that lock people's understanding of how their company transacts business. Re-imagine the business - goodness, it doesn't even have to be so ethereal, just look at what competitors are doing today - and it is possible to expose the opportunities those legacy paradigms self-select you out of doing.

However, recasting "legacy modernization" as "digital modernization" is no easy task. It's one thing to redefine an operation from linear batch processes performed in an on-premise mainframe to parallel event queues in an elastic cloud. There is bound to be lift in capacity, efficiency, and recoverable revenue for the architectural change, and this is easily projected against current state. Unfortunately, the benefits for digital modernization are harder to prove. For example, it sounds great that the company could pursue adjacent markets by exposing APIs to those event queues and selling subscriptions with variable pricing to 3rd party providers of ancillary services. There may even be a large addressable market of 3rd party providers of ancillary services. Potential is valueless without a plausible path to conversion. As it is highly resource- and labor-intensive to get hard evidence on the nature of those adjacent markets given the current state of the business, those opportunities are just conjecture. A CFO being asked to approve multi-million-dollar spend to modernize legacy assets is not a CFO who will do so based on somebody's conjecture.

Still, this does not negate the role that digital modernization has to play in making the case for legacy modernization. If the legacy modernization provides just enough lift to make a case on its own merits (and in the absence of a bloated cost base or significantly eroded revenue that can be won back quickly that is a best-case scenario) it is a cost-neutral to marginally cost-positive investment that opens the door to digital modernization and the multitude of potential benefits that lie beyond. Restated, it doesn't hurt the business to invest in modernization, and the odds are that it will be better off for it.

Most corporate IT departments would prefer not to start from the position they're currently in, so "legacy modernization" will find a willing audience. Unfortunately, there are no modern technological silver bullets that make legacy modernization any less onerous than it was the last 10 times IT proposed doing so. Not to mention, the financial analyses that dictate how capital is allocated in legacy firms are geared heavily toward "certainty" and not at all toward "speculative". What a legacy modernization initiative needs is a legitimate path to paying for itself. Provided that there is one, ceteris paribus, spending $100 today for $102.76 of value in two years leaves the firm no better off but also no worse off than had it spent $0. But no companies operate in a static world and every executive knows as much today. That means it's a pretty safe bet for the CFO that $100 on a cost neutral legacy modernization is a free call option on a lot of upside gain, if not outright survival of the business itself.

The Tortoise Strategy

Three years ago, I wrote that the unstoppable forces of Fintech were running into the immovable force of financial orthodoxy. Specifically, the technology cycle wasn't enough to overcome the credit cycle for peer-to-peer lending firms, which were resorting to selling their loan portfolios to traditional lenders, becoming buyers of last resort themselves when no buyers emerged, and offering deposit insurance for lenders.

Earlier this year, I wrote that incumbents had advantages - specifically, access to greater amounts of patient capital - which they can parlay in a multitude of ways to co-opt a would-be disruptors business: make the disruptor financially dependent by becoming one of their biggest customers buy buying their products (e.g., loan books originated by peer-to-peer lenders), licensing their technology, or investing in their business and getting board seats.

Last month, I wrote that being a late mover can be less financially ruinous than being an early mover. A fast-growth business with low barriers to entry attracts a lot of competitors who burn increasing amounts of capital chasing each other's customers more than new ones. Patience and playing to strengths is a better response than betting the balance sheet in an unfamiliar casino.

This week, the Financial Times ran an interesting article on the trials of peer-to-peer lenders. Finding lenders is hard, and finding borrowers is proving even harder. Incumbent banks have lower costs of capital, which allows them to lend at lower rates. In periods of economic uncertainty or downturn, banks offer safety to cash-holders in the form of insured deposits.

What does the FT article recommend? That the survivors will be those who follow a "tortoise" strategy:

That means working with investors with a low cost of capital [...], and avoiding yield-hungry hedge funds. It means not reaching too hard for high returns, which will become high losses in a recession. It means sticking to niches with good borrowers, who are too hard for big banks to serve. Finally, it means not spending excessively on marketing.

All this, of course, implies slow growth: hence the tortoise. But the hares are set for a very nasty couple of years.

'Tis better to arrive late than not to arrive at all.

Late Mover Advantage

Many years ago, I worked with a company that helped big pharma companies distribute free medical samples to doctors. Having pharma products on-hand is a convenience for doctors and patients alike, mainly because a doctor can initiate immediate treatment for a patient. Having pharma products on-hand is also good for big pharma, as starting somebody on a medication is highly likely to lead to a prescription. So pharma manufacturers were motivated to avail free samples of medicines to doctors.

It's a regulated activity. Doctors can only get medicines appropriate for their practice (e.g., a pediatrician cannot get free samples of Cialis) in limited quantities for specific lengths of time (usually every x number of days). Pharma companies keep track of which doctor got what product on what date. Because doctors exhaust their supply of free product within the allocation time frame, doctors create standing re-order requests. The pharma company decides whether or not to fulfill a doctor's reorder request primarily based on when the last order was fulfilled and the quantity supplied. A pharma manufacturer would not supply more free product to a doctor who had received the maximum volume just a week ago if the reorder window is 21 days.

Because doctors obtain pharma samples from multiple manufacturers, a lot of intermediaries popped up to provide a consolidated service. The value prop of the intermediary was that a doctor need only visit one site to replenish samples from multiple drug manufacturers. Again, because doctors exhaust their supply of free product every few weeks, they were encouraged to set up recurring orders through the intermediary, so a doctor might request multiple products from multiple manufacturers with different replenishment rules. The intermediary made money by charging the pharma company for each free sample request they fulfilled. The pharma company treated it as a marketing expense, effectively treating these intermediaries as a channel partner and paying them a commission. The volume aspect made every doctor acquired very valuable indeed.

The theoretical market numbers were eye-popping. Just one of the big pharma firms measured the total product value they gave away in the form of samples, coupons and vouchers to be nearly $2 billion through all channels of distribution. At the time there were about a dozen or so bulge bracket pharma firms. The free pharma product business was big business indeed.

The company I was working with had a division that was one such intermediary. It was supposed to be a growth business in the portfolio: as mentioned above, pharma samples were a big business and the order volume had plenty of room to grow. But the performance was never all that impressive. When intermediaries made enough mistakes (e.g., process the reorder too early or not at all and doctors don't replenish their sample stock in a timely fashion), and the doctors will sign up with another intermediary. Since the pharma companies were the ones managing the replenishment data (what doctor received what product in what quantity on what date) and enforcing the replenishment rules, and since the pharma companies had no exclusive distribution agreements with any intermediary, a doctor could set up the same reorder profile with a dozen different intermediaries. The first intermediary to process the reorder successfully won the business that day. And, not only were there lots of intermediaries competing for the same business, the pharma companies operated their own direct-to-doctor channels as well - and distributed the bulk of the product that way.

Being a crowded field, intermediaries had no pricing power with the pharma companies. By way of example, at the time the internet travel booking business had a take rate of somewhere between 5 and 10% of the value of the travel services they were selling; intermediaries had a take rate of a tiny fraction of a percent of the value of the product order they were submitting.

In short, there was no customer loyalty, no vendor exclusivity, and no pricing power in this business. There was a market, but no obvious winning strategy. Infrequent site visits meant that user experience wasn't going to provide an edge. Orders duplicated across multiple intermediaries meant that even the smartest algorithms and the fastest technology would provide only a fleeting edge as competitors would quickly catch up. Acquisition wasn't an option as every seller would demand too high a price for little value in the form of assets or cash flow. Industry consolidation would simply formalize the value destruction that had already taken place but not been accounted for.

An intermediary couldn't crush the competition with customer love, innovation, tech firepower, or scale. They were in a state of mutually assured destruction. The only strategy was to hope that your competitors ran out of cash before you did.

Recent analyses in the financial press on the ride sharing, home meal kits and food delivery industries got me thinking about that company again. They compete in crowded fields amid the challenges of low switching costs, low margins, little differentiation, and no customer loyalty. As the Wall Street Journal put it, these companies are now engaged in "a land grab for overlapping customer bases". Every ride from Lyft and Uber is still subsidized by investor capital. There wasn't enough of a market for home meal kits to support the number of firms competing for it.

The Journal makes the point that the would-be disruptors in home meal kits have done more to disrupt one another than they have to established players in retail food, and that's an important point. That these firms are "disrupting" in a different competitive landscape to their technological forebears: building a business at the expense of sleepy competitors in legacy industries (as firms such as Amazon and Expedia benefited from in the 1990s) is much different than trying to do so with evenly-matched competitors.

This casts doubt on the investment case. The long play for all of these companies is winner-take-all: all the chips go to the last player standing. Reuters Breakingviews estimates that the total current market cap of food delivery firms prices in optimistic growth, profitability and value multipliers. Breakingviews goes on to point out that an "... optimistic ending would be one firm knocking out rivals and boosting its pricing power. A more likely one may be that valuations, far from getting hotter and rewarding venture capitalists, grow cold." And what if it isn't a contest worth winning? Groupon won the online coupon competition. It didn't work out too well on a total-return-on-capital basis.

As mentioned above, I've seen this movie before. The Journal article was titled "Mutually Assured Destruction in Silicon Valley." That's apt.

The chattering classes and management consultants advocate for incumbents get into the disruption game themselves. It's certainly good for the pontificators and suits if the incumbents do, because it generates clicks on articles and contracts for services. But doing so asks established firms to enter into very expensive gambles that don't play to any of their strengths, and may offer no payoff whatsoever. Pundits and consultants are very good at spending other people's money - on themselves. Incumbents need to concentrate on their strengths, not their weaknesses.

The incumbent's response to disruption in financial services offers some insights. Clearly, Fintech has had an impact: things like loan origination are far more efficient at banks today than they were just a few years ago. But the disruption storyline in finance is far more muted, in large part because of the way the incumbents responded to it. Incumbent financial services firms didn't try to enter as competitors to the startups, but employed a combination of tactics including infiltration (experienced bankers dominate FinTech boards), co-option (licensing and integrating new technology), and economic might (buying loan books). It should come as no surprise that today, FinTech lenders look more like banks than banks look like FinTech lenders.

Rather than taking a high-risk position well outside of a firm's comfort zone and competencies, patience can be a better strategy. Enter into non-exclusive partnerships and licensing deals and lightly finance the entrants to encourage competition, penetrate their boards to influence their strategy, and alter their book of business to make them economic dependents, all while cleaning up your balance sheet to have more equity and less debt. The incumbent that can do that will have a stronger risk footing when the time is right to strike in changing market dynamics.

Come On and Take a Free (Regulatory) Ride

Within 24 hours of last month's post on regulation of technology firms, new anti-trust probes into Google and Apple were reported by the Wall Street Journal. Around the same time, Renault stirred up a hornets nest of regulatory furore over its proposed (and subsequently withdrawn) merger with Fiat Chrysler. It's worth examining the prior in the context of the latter to understand why the regulatory free ride Big Tech Media firms enjoy will continue for quite some time to come.

Instead of thinking about companies as financial entities that reward investors, think of them as agencies that fulfill public policy. Let's start by looking at the automotive industry. Economies benefit from the physical mobility of their citizens: the more affordably they can get around, the more flexible they are as a labor force, the more likely they are to get out and spend, etc. To be competitive in the transportation business, a company needs scale; that means transportation companies are large direct employers. The complexity and sophistication of modern cars means that automakers have expansive supply chains, making them large indirect employers as well. Transportation is an industry of great national importance: jobs create middle-class households that spend money, pay taxes, and vote.

But transportation creates a lot of other problems such as energy consumption and pollution, so cars are regulated for their safety equipment, the types and quantities of energy they use, and the amount of pollution they generate. In this way, government can get its citizenry mobile with fewer negative consequences. It isn't a stretch to say that automakers are executors of public policy on the combination of transportation (mobility is good), labor (jobs are good), energy (fuel efficiency is good), and environment (clean air is good).

It takes quite a while for a society to figure out the consequences of its innovations and the price it is paying directly or indirectly for the benefits it enjoys, hence regulation lags commercial innovation for a very long time. For example, corporate financial disclosures were not regulated with the first stock sale or even the first equity market crash: the Philadelphia Stock Exchange was established in 1790, but the Securities and Exchange Commission didn't come into being until the 1930s. Similarly, cars were not subject to emissions regulations with the sale of the first car; delays in emissions regulation stemmed from the fact that the good of affordable mobility outweighed the bad of pollution in the minds (and perhaps the wallets) of policy makers for a very long time.

Let's look at the aborted Renault-FCA merger in this light. Aside from the tantalizing potential for the best buffet cuisine ever in the history of annual general meetings of shareholders, in financial terms this appeared to be a rational merger. A combined Fiat Chrysler Renault with a side order of Nissan and Mitsubishi would have girth in all of the numbers automakers have been traditionally measured on: production volume (third largest, globally); market access (full-scale distribution networks in every major car-buying market including the US, Europe and China); and margin (Dodge and Jeep light trucks.) In short, the proposed merger would have yielded everything except for the specific electronic vehicle technology that governments are adamant that auto manufacturers must deliver. Even there, the combined R&D spend would effectively double, reducing wasteful redundancies: US$8b goes a lot further than US$4b twice over. Given the fact that for the time being EVs are doing more damage to automaker P&Ls than being a source of industry disruption, that combined R&D spend would go a long way to charting a course for a successful future of the two companies.

Unfortunately, the tie-up of the two firms quickly ran afowl of labor policy. Part of the sales pitch of the merger was that Renault would gain access to the US market through Fiat Chrysler dealerships. But it doesn't make sense for a dealer to be selling a Renault Clio side-by-side a Fiat 500, with a Mits Mirage in the showroom just through that door over there and the Nissan Versa in a showroom across the parking lot. It makes even less sense given both dealer and manufacturer are losing money on the wholegoods sale of the small car. There is a stronger argument to be made that these products on nearby showroom floors will simply cannibalize sales from one another, much as the Jaguar F-PACE did to the Land Rover product lineup. If that proves to be the case, than the combined companies will stage their own private fight clubs of their products. Sooner or later, the rationalized product portfolios will result in rationalized production capacity. By way of example, look at the lineup of Fiat Chrysler products: the Chrysler and Dodge brands have no small cars; FCA meets US CAFE requirements with the small Fiats. And, of course, Kraft made similar assurances about maintaining production facilities before acquiring Cadbury only to abandoned them one week after the completion of the merger. The leaders of Renault and FCA said they anticipated no plant closures, but it was difficult to take those assurances very seriously.

In financial terms, consolidation made sense because a consolidated manufacturer can produce just enough small cars (which are by and large unprofitable) to offset their production of light trucks (Chrysler, Nissan pick-up trucks), designer vehicles (Alfa Romeo), performance vehicles (Nissan GT-R, Alpine A110) and exotic vehicles (Ferrari), all categories where automakers make money. But in political terms the merger did not make sense, because it is easier to ramp up production of the facility producing (currently) money-losing small cars to offset any gain in money-making larger cars than it is to perpetuate a lot of factories producing small cars. Gains for a factory producing small Fiats in Italy really would translate into reductions at a factory producing small Renaults in France if the consolidated automotive fight club rewards the Fiat model over the Renault model. While the combination would make financial sense and make it more likely that the two companies would survive the transition to electric cars, the loss of jobs was too great a risk for either the Italian or French governments to bear.

What does this tell us of the ramp-up of anti-trust probes into Apple and Google?

Google is a big media firm which it monetizes through advertising. Google did not invent advertising, mass advertising, or targeted advertising; it found ways to provide a scale of advertising at a level of reach greater than any outlet had ever created before, which it can sell to advertisers at a price lower than what traditional media could offer, with more accurate targeting to boot. Google provides this ad space in media outlets that did not exist previously, ranging from browser-based search, to geographic search (maps), to in-home search (Google Home), to in-car (Android Auto), to many other media outlets. Google's imagination for the possibility of monetizable moments is many decades in front of that of any government.

In the process of becoming Big Media, companies like Google have become Big Surveillance, both directly (the data they capture and analyze) and indirectly (the multitude of 3rd party firms in the analytics chain). Cross-analyzing data creates infinitely targeted opportunities to pitch a consumer transaction: by capturing payments (Google Pay), Google knows you have an affinity for Mediterranean cuisine; by capturing your location, Google knows you travel to San Antonio and stay in the same hotel every week; by capturing your boarding pass info, Google knows your flight is running a bit late. It might be a great convenience - in fact, it might even delight you - if Google Express not only suggested a Mediterranean restaurant, but built an order based on your previous menu choices and scheduled the order to be delivered to your hotel in time for your late arrival.

Consumers are not the only ones who stand to benefit from such analysis. The accelerometer in the phone and the spacial-temporal data captured by maps mean that Google know whether you drive the rental car you get in San Antonio every week in an aggressive manner. The rental car company and your auto insurer would like to know that, as they could price in the risk of accident based on characteristics of your actual driving patterns as well as the responses by the drivers around you to how you drive. (Yes, Progressive Insurance has offered something like this for years, but with Progressive the insured is making an explicit decision to expose driving data; Google could choose to collect that data and provide it to insurers and rental car companies and law enforcement agencies without consumer consent). The contract between insured and insurer has traditionally been based on reported events, specifically moving violations and accidents. The insured had a great deal of leeway in deciding how to behave as long as the what happened showed no indication of trouble to the insurer.

Western societies. and the United States in particular, are based on the rights of the individual, the wellspring of personal freedom. Individual anonymity is a contributing factor to protecting those rights, as the individual is free to make decisions - what to do, how to drive, what to eat, what to invest in, what to read, how to be entertained - without fear of repercussion for the choices they make. Continuous surveillance all but eliminates the anonymity of the individual, exposing not only what people do but providing potential clues as to why they do them because a person's decisions and actions expose their own preferences, beliefs and values. Plus, any one person's decisions erode the anonymity of the people around them: the data collected on one person may indicate an ailing parent or struggling child. Continuous surveillance raises some thorny questions for western societies. What are the consequences when the individual effectively loses decision rights over how they do things to the companies they do business with? What is to stop a company from predatorily monetizing a condition that a person wishes to keep discreet? What prevents an individual from being targeted for the values they are perceived to hold through the decisions they make? What if the algorithms conclude the wrong things about an individual based on the data that it has?

Western governments have historically intervened (ostensibly) on behalf of the individual to level the playing field with large companies. The rise of the American middle class in the first three decades of the 20th century created a large new category of individual investor, enabling legal but ethically questionable (that is, exploitative) financial reporting practices by corporations; with middle-class investors wiped out by the market crash and confidence in public markets all but non-existent, the US government created the SEC. The shift of the American economy from agrarian to industrial in the 19th century allowed for legal but ethically questionable labor practices by industrial firms; as labor unions arose, government eventually supported (and in many cases, enabled) worker organization. The plot is no different this time around, with Big Media engaging in legal but ethically questionable consumer practices. The scale is much different, though: 20th century Big Industry was large in economic might but still human in scale; Big Surveillance is large in economic might and machine in scale.

The anti-trust probes revealed earlier this month target the commercial activities of Google and Apple. These are regulatory probes within the constructs of established policy stemming from the industrial era. The question any probe has yet to ask is one of public policy: if and how to protect individual freedom against constant surveillance and activity derived from that surveillance at machine scale. Before it can answer that question, government must be able to frame the problem in that light, define what rights individuals really have, can conscionably waive and under what circumstances they can be waived, and what rights the individual has no right whatsoever to expect.

Labor policy is well established, so it wasn't difficult for either the French or Italian governments to conclude the risk of combining state champion companies was too great. Data and information policy is not well established and it will take time for the US government to define it in such a way that companies that rely on Big Surveillance do so in a manner that advances desirable, multi-faceted public policy, and not simply exploit its absence. The scale and complexity of forming that policy, in what is new regulatory territory for every government, means that the regulatory free ride will continue for quite a long time.

The Safe Haven of Regulation

Big tech has historically been lightly regulated. True, both IBM and Microsoft were subject to regulation in 1956 and 2001, respectively, to limit their monopolistic powers. But neither suffered dents in their financial returns as a result (attorney fees notwithstanding), and the tech industry innovated in ways that made their respective monopolistic states very short lived. Today's cash-gushing tech companies such as Oracle, SAP, and ironically the most valuable of them all, Microsoft, are all utility providers that enjoy light regulation. The light-touch regulation party will not end for them any time soon.

Facebook is not big tech, it is big media. Facebook enjoys - for now, anyway - the status of being a lightly regulated cash gushing media utility. Although it has become ubiquitous, it makes money in ways that national regulators of media are still years away from catching up with. That regulatory lag means Facebook is effectively regulated by national and trans-national governmental bodies such as the US Congress, UK Parliament, and European Commission. That has been a boon to Facebook as national legislatures have many more things to concern themselves with than a media outlet.

While the threat of regulation creates uncertainty, the bigger challenge facing Facebook isn't regulation but the threat of being both a tool and political beach ball for many, many more election cycles to come. To the average citizen of any country, it may stand to reason that the nature of media outlet that Facebook has become needs codified regulation spanning everything from what gets published to who has decision and economic rights over user data. But to the political classes, Facebook is heads-I-win-tails-I-win. If people are easily manipulated through Facebook in the actions they take from how they vote to how they immunize their offspring, Facebook is a channel to be exploited. If there is evidence that political opponents have used disreputable tactics to manipulate people through Facebook for their own purposes, Facebook is a convenient punching bag. The downside risk to Facebook is that while it may enjoy light formal regulation for some time to come, it will be continuously on trial in the court of public opinion. That isn't a fun problem for marketing to solve, or for their lobbyists to navigate. Investors get tired of this.

Facebook are evidently considering going into the payments business. By entering into payments, Facebook would be choosing to become a regulated business. Facebook would be regulated by bodies such as the US Fed and the UK's Payment Systems Regulator and their equivalents in every jurisdiction where they offer payment services. That introduces technical jargon that is more specific than political jargon, which is easier for the regulated to succeed under. Where there is regulation by rule the burden is on the regulator to prove non-compliance, whereas today Facebook is regulated by principle, and as a result must argue it is neither out of compliance with societal norms nor complicit in acts by those who use it in ways that are.

Entering into payments is a logical first step into the four functions of finance that John Kay identifies in Other People's Money: facilitate payments, match lenders with borrowers, manage personal finances across lifetimes and generations, and manage risks associated with everyday life. Once in payments, it isn't difficult to imagine Facebook creating a credit function to provide microloans that facilitate purchases. Over a span of a few years, it isn't difficult to imagine Facebook leveraging their trove of data to offer algorithmic solutions to manage personal finance and manage risks. Financial services would offer a lot of growth runway: WeChat derives 60% of its revenue from payments and only 30% from advertising, and payment processors like PayPal and Square write a lot of loans to merchants.

It will not be easy to change from being an unregulated to regulated company (it's a bad idea to break things where people's money is concerned), costs will go up (compliance isn't cheap), and the potential for bad headlines - money laundering, robbed wallets - will only increase. But these are comparatively benign problems for a company with a product that has been used in the commission of numerous felonies.

Facebook has largely escaped regulation to date. However, its enormous size and influence, its economic power, and its existence as a lightly-regulated multi-jurisdictional entity all suggest that regulation is coming. The regulatory lag between old media (print and television) and social media make it clear that governments are not prepared for the task. By redefining its business as a commerce platform rather than a media platform, Facebook would be able to choose its regulators rather than wait for legislatures to pick one - or worse still, create one - for them. It would then have the pick of mature regulators, agencies that are less likely to be politically charged than an upstart chartered specifically for the purpose of regulating social media. A mature regulatory agency would also bring an imprimatur that carries weight with consumers and politicians worldwide.

As a move designed to defend their greatest asset - data - regulating key aspects of the business under the auspices of financial services would be pretty shrewd indeed.

Counterfactuals

Earlier this year, my house should have burned to the ground.  A CR2032 battery exploded and caught fire in a confined place dense with flammable objects.  But my house didn't burn down: at the moment the battery exploded, I was sitting a few feet away from it. I heard a loud bang, investigated, and stamped out the fire within a few seconds.

I wasn't planning to be there at the time. A series of minor reschedules and reprioritizations had me sitting in my home office at the moment the battery exploded. I happened to be in the right place at the right time to prevent something from happening.  It was business as usual for the rest of the day.

There is no law or reason governing why I was there at the moment the battery exploded, or for the battery to have exploded at precisely that moment.  What if my schedule isn't rearranged and I'm not home when the battery explodes? What if it happens hours earlier or later when everybody is asleep in the house? I can't help but think that there are more quantum realities where something bad happened than there are where something bad did not happen.

But that isn't necessarily true.  The battery could have exploded at a time when nobody was around to put out the fire, but the ensuing fire may have simply died out causing no damage.  And maybe the chemical processes that triggered the explosion was itself an anomaly of circumstances set in motion by my presence in the room at that particular moment.  I have to be content with the only certainty I have, which is that a battery exploded and nothing bad happened.

Counterfactuals are messy because they're not provable.  Strategy and investing, execution and operations are loaded with counterfactuals.  They're each similarly messy because we don't really know what would have happened had we chosen another course of action.  Conventional wisdom says that Kodak should have bet on the digital technology they invented, and not dithered around with its legacy analogue business. But what if Kodak were to have invested heavily in digital and their distribution partners made good on their threats to shift the lucrative film processing business to Fuji?  Would Kodak's bet on the future have imploded for being starved of cash flow?  Hindsight isn't 20/20, it's narrative fallacy.

Just as it's difficult to have retrospective strategic certainty, it's next to impossible to forecast the outcomes of alternative paths, decisions or circumstances.  It sounds simple enough: invest in the highest-return opportunities, and consistently assess the performance of and the risks to delivery.  But we're forced to interpret and project from incomplete and imperfect information. Our plans and forecasts are just as likely to be narrative fallacy as fact-based assessments.  Microsoft paid dearly for Skype, but we can't know what might have been had it been acquired by Google or Facebook - and the possibilities may very well have justified the premium Microsoft paid.

The landscape of strategic software investing and governance is riddled with speculation.  As much as we would like to think we've made the best decision available to us, or dodged a bullet, we rarely know with certainty.  No matter how formulaic we're told that portfolio management or delivery operations can be, they will never be as optimal or predictable as promised, because business is imprecise and untidy.

The Fine Line Between "Stretch Role" and "Unqualified", Part II: The Growth Mask

When a business or a profession grows faster than the labor market it draws from, it suffers a capability deficiency: there simply aren't enough experienced people to go round. It also suffers a leadership deficiency: there aren't enough people with cross-discipline experience to make competent business decisions. When there are more leadership jobs than there are qualified leaders to fill them, people will be given responsibilities they would not otherwise have. Even though hiring decisions are made independently, macro forces can be responsible for people landing in stretch roles.

Volume Cures All Ills

Growth - be it a function of runaway demand or insatiable investor appetite - increases a business' tolerance for leaders who are coming to terms with their responsibilities. In no small part, this is because the performance of a rapidly growing businesses can be difficult to measure, while its business decisions - most importantly, where they concern cash - are blatantly obvious.

For example, early stage tech businesses tend to lack revenue and profitability but attract increasing numbers of users. They are measured on indicators such as total number of user accounts and number of active users. These are non-financial measures that are calculated differently across firms (e.g., a single person may have multiple accounts, while "active" is a relative term), making comparisons difficult. Because there is little history of tracking these types of metrics in business, it isn't clear how they truly relate to the long-term valuation of a business. Although the performance measures of a growth firm in an emergent industry are a bit foggy, the business decisions are crystal clear. The most important decision - what to do with cash - is cut and dried: plow it back into the business to fuel growth.

By comparison, well established businesses in industries like air travel or retail banking are expected to be predictable. They are meticulously measured on established accounting metrics such as earnings and cash flow, measures that are easy to understand and comparable within and across industries. But their business decisions - again, particularly those to do with cash distribution - are more complex: do we invest in the core for efficiency, diversify for growth, or distribute cash to shareholders? Stakeholders - employees, investors, customers - in a growing business will be tolerant of novice leadership; stakeholders in a mature one will not.

By way of example, social media firms had the benefit of time to adjust their products to be mobile centric rather than desktop centric. Although the chattering classes raised concerns, the total growth of social media prevented a sense of crisis from cratering equity values or inciting mass employee exodus. In contrast, retail firms haven't been so fortunate: ecommerce cannibalizes existing retail sales more than it increase them (to wit: Amazon's growth in retail has come substantially to the detriment of traditional retailers). Retail firms are not seeing their businesses grow rapidly because of technology, they're seeing their businesses change underneath them because of it. These firms don't have an abundance of time because their core businesses are vulnerable to rapid erosion. They are far less tolerant to leaders learning their trade.

Growth Makes Everybody Look Good

Although growth make it safer for people in stretch roles, they also make everybody look good, deservedly or not. The greater the success achieved by multiple businesses in the same sector, the less clear the contribution of the leadership to any firm's success. A rising tide simply lifts all boats. As Jeff Immelt famously quipped about commercial conditions during the 1990s: "A dog could have run a business".

Too often, we never really know the difference between a savvy business leader and person who simply got lucky. Many years ago, I sat on a panel with a renoun dot-com investor who had retained his fortune post-bubble by getting out just in time. Prima facie, he appeared to be the sage of Silicon Valley. On interrogation, it turned out that he'd cashed out several investments to free capital for a new round of leveraged bets on internet businesses, just as the bottom fell out of dot-com equities. He happened to be out of the market at precisely the right moment because he hadn't finished negotiating his new placements. It wasn't deep market insight that enabled him to call the market peak: he intended to be long the entire time, and was short only because dumb luck that had him cash out and head to the sidelines at just the right moment. The only sage advice he was qualified to give was to "be in the right place at the right time".

What If Everybody is Stretching?

In overheated sectors, we can easily end up with leadership teams who are reaching beyond their capability. The more the froth on the business, the more concern there is with fast action and the less concern there is with meaningful qualification of the people running it. We end up with an explosion of title inflation (a rise in the number of people with double-barreled titles beginning with words like "chief", "strategic" or "senior") without the concomitant increase in the number of experienced board members and executives to mentor these freshly minted leaders. It isn't uncommon for a high growth firm to build an entire leadership chain of stretchies - people in the wrong weight class, from the most senior executives right down to management on the line. This renders mentoring relationships irrelevant, and potentially damaging.

Explosive business growth can yield a new class of leaders. But in the absence of a strong foundation, it is just as likely to foment destructive organizational pathologies of paranoia and denial. The pinnacle of organizational absurdity is when employees, clients and investors are told quarter after quarter that every leader is "awesome", yet mysteriously, the overall business performance is disappointing. This isn't a business on the rise, it's a well funded frat party.

Where's your business?

The Fine Line Between "Stretch Role" and "Unqualified", part I

Everybody wins when somebody is put in a stretch role. Whoever does the hiring - a manager naming a first time tech lead or a board hiring a first time CEO - has propelled somebody's career. The investment in that person's success implies a commitment to a very active mentoring relationship. The person being asked to stretch is being given the opportunity to learn and mature, with a tacit expectation that they have freedom to try and fail while they are honing new skills.

We like seeing people in stretch roles, we like what it says about us as leaders that we put people in them, and we like the possibility that one day we, too will be given an opportunity to stretch.

A stretch role creates a halo effect for the person doing the hiring and the person being hired. For the management doing the hiring, it's a sign that the company is investing in the next generation of leaders, and that the firm demonstrably offers opportunity for advancement. For the individual being hired, it signals satisfaction of performance and expectations for great things. And, because everybody is taking a chance, it communicates an element of "risk", even in otherwise risk-averse corporate cultures.

But the halo reflects little brilliance. Stretch roles are too often made because there aren't any other viable choices. We rarely get to hire our ideal candidate, so we're going to have to settle in one way or another. Scarcity is a factor: in tight labor markets, availability becomes a skill. Plus, the longer a position goes without being filled, the worse the manager responsible for filling it looks - and the more likely that somebody higher up will conclude the position isn't all that necessary and will remove it from the budget. The decision to put somebody in a stretch role is very often simply that we can't think of any reason not to put you in this job. This is easily rationalized: emotionally, the benevolence of offering somebody a stretch role more than compensates for the risk that the person will not work out.

In the right circumstances, stretch roles grow people and businesses. They give a person license to test his or her boundaries, the freedom to experiment, and the opportunity to develop a unique style at something. But success depends on the circumstances: a short honeymoon period, being kept on a short leash by management, pressure to underwrite risks they don't completely understand, a "we never fail" corporate culture, no critical assessment of the person's areas of weakness, an absentee mentor or, worse, an incapable mentor, each stack the deck against the stretch candidate. A newbie in the job will not recognize the factors working against their success.

Throwing somebody into the deep end of the pool in their first swim lesson isn't enabling, it's overwhelming. Having somebody claw their way into a state where they can perform at a rudimentary level isn't professional development: it risks developing the wrong "muscle memories" for the job, and denies them the opportunity to achieve the meta-awareness they need to master their new role. It's also short-term career fatal: perpetually chasing responsibilities, constant drama and few successes alter the perception of the person from "aspirant stretchie" to "unqualified leader".

There is also the potential for long-term career damage. Over-promote somebody into a leadership role and they'll forever think they're leadership material. It may be that they simply aren't, but the stretch candidate is not likely to recognize this before or after being asked to take a stretch role; once invited, they've made the grade. The person who was on a stable career path ends up making frequent job-hops across firms just to maintain the same level of seniority.

Teams and departments suffer, too, not only from weak leadership at the helm but from the damage done to the confidence and trust among everybody else in the business. Plus, it sews seeds of doubt with the management who put the person in that role in the first place, often with damaging consequences (recall that Bill Ackman was ousted from the JC Penney board for having hired Ron Johnson as CEO).

Worse, the time spent with the wrong person in the role is time the business prolongs its people problems. Some years ago, I worked with a firm that had a strong tech culture but a weak sales one. There was high turnover of salespeople, and frequent vacancies in the sales team. A manager in the tech organization asked for a position in business development. Because of his credibility in tech delivery twined with an extrovert personality, management saw no reason not to give him the job. His lack of knowledge of business development, his lack of empathy for non-technical business buyers, and the absence of any strong sales leaders to mentor the new hire contributed to a disappointing year, culminating with his being asked to leave the sales organization and return to tech. Tainted by this failure, the would-be BDM left the company soon after. The company had not only engineered the loss of a respected member of the tech organization, it was no further along solving it's sales problem one year on.

(As to the person in question, his resume ticked technology, management and sales boxes, he already had a general management position at another tech firm in hand at the time he left. It was a short-lived gig as it became obvious very quickly that his capability did not live up to his resume.)

There's a simple litmus test we can apply to any organizational leader: would this person hold a comparable position in a comparable organization? An established leader capable of redefining and reshaping role clearly passes this test. An emerging leader who quickly takes to their new role while also disrupting conventional understanding of it will also pass this test. An aspirant leader being chased by demands and relegated to rote execution under constant direction of his or her superiors will not.

Every business has people in stretch roles. What are you doing with yours?

Deflation and Technical Debt

Technical debt is a useful metaphor for explaining why some code is faster to complete but more expensive to maintain. It is also helpful in explaining design decisions made for sake of expediency, or because of an outright lack of knowledge. Tech debt can be a real burden on development, particularly as it takes away time that would otherwise be directed toward productive investment in new feature development. This makes it tempting to interpret tech debt as a quantifiable economic or financial phenomenon. It is not. If we respect the accounting treatment of it as indirect, and extend the metaphor toward team dynamics and away from financial statements, it also helps us understand our ongoing ability to service tech debt.

Debt and Deflation

Edward Hadas argues that debt is an antiquated form of finance, "unnecessarily distant from economic reality". Fixed interest rates, maturity mismatches (banks borrow short and lend long) and variability in borrower's cash flows create unnecessary risks to borrower and lender alike. Financial institutions create all kinds of provisions and capital structures to underwrite uncertainty and absorb losses. If we set out to create finance today, we wouldn't use such a rigid structure as a primary investment vehicle.

Debt is a wager on future interest rates. The debtor is making an income backwardation play: that inflation will rise faster than the rate reflected in the interest rate, or that their real wages rise over the life of the loan. For example, in simple housing finance, a wage earner takes out a loan to buy a house. If inflation rises faster than expected (per the interest rate on the loan) and their wages keep pace with that higher inflation rate, the debt is easier to service because their income is higher. In this case, they've been inflated out of their debt. In addition, the debtor's wages can rise faster than inflation through salary increases (e.g., due to job promotions). This makes the debtor's real income higher, which also makes it easier to service the debt. The backwardation is that the projected future income at the time of the loan is less than what the spot income turns out to be in the future.

The lender is not entirely betting on the opposite. It is true that the lender comes out ahead if inflation rises more slowly than the rate reflected in the interest rate. But they also stand to gain from the debtor's ability to service a loan. An increase in real wages increases the debtor's ability to service the debt; this is reflected in the borrower's credit worthiness (rating or score). Lower credit risk increases the value of the debt instrument. A lender can sell the loan to somebody else for a higher price, which is their reward for underwriting the risk of the borrower at the time of origination.

For the borrower, deflation increases the real cost of debt. The less money a household earns, the harder it is for that household to service its debt. This is why central banks in highly indebted economies will pull out all the stops to fight deflation. Falling consumer prices reduce revenues. Falling asset prices reduce people's perception of their wealth, which reduces their willingness to spend. Deflation increases the burden of debt and intensifies contractionary forces on an economy. Mature economies - Europe, Japan, US - are debt-financed more than they are equity financed, and there are far more borrowers than lenders. It comes as no surprise that European Central Bank chief Mario Draghi committed to fight low inflation, Shinzo Abe's government in Japan expanded money supply to juice asset prices, and former US Fed Chairman Ben Bernanke committed to Quantitative Easing.

Technical Debt is an Indirect Economic Phenomenon, not a Direct One

In finance, the person using debt to finance an asset purchase is the person who is responsible for the debt. This makes sense in the business of software, because the person paying to acquire and operate software may be "borrowing" against future cash flows in the form of costs to service technical debt. The buyer of a software asset is the person footing the bill for people to service that debt.

But technical debt is an indirect economic phenomenon, not a direct one. That is, technical debt does not necessarily finance a software asset. Technical debt only has economic impact if costs required to service that debt are realized. For example, an asset with a lot of tech debt may not be subject to much maintenance activity, or suffer production instability requiring a lot of attention, or suffer performance problems (directly resulting from that tech debt) requiring additional investment to scale. In each of these cases, a tech-debt-heavy asset may have the potential to be high cost, but those costs may never be realized. If a cost is not realized, it is not a real economic cost. It only becomes an economic phenomenon if excess labor or infrastructure is needed to compensate for its presence.

This brings us to the limits of the tech debt metaphor. There is no bank offering technical debt loans: tech debt is conjured by people during moments of development. One can argue that tech debt borrows against the equity of the asset, but that does not hold up in accounting terms. With or without tech debt, we still carry the asset on the balance sheet at the same economic value: the total capital outlay less accumulated depreciation. The cost of servicing technical debt is a function of people's time, which is an operating cost. The expectation of future payroll costs that may be incurred to service technical debt is not a balance sheet liability that reduces an asset's equity, it's reported in the future period when it is incurred as an operating expense on our income statement and a drag on cash flow. Tech debt may or may not lead to reduced current and future profitability and cash flows; it does not intrinsically reduce the accounting value of an asset.

Only if the software itself is truly impaired - for example, owing to poor design decisions, our software doesn't scale beyond a single user and a significant portion of the asset is written off - is technical debt a direct economic phenomenon. However, in that case, "debt" is the wrong moniker: the asset is well and truly impaired, not merely leveraged by debt. If a business takes out a usurious loan to buy a truck, the truck isn't impaired by the loan or the high interest payments. If the truck is severely damaged in an accident, it is impaired and written down. Because of the optics, impaired software is more likely to receive additional investment than it is to be written off.

Since tech debt is an indirect economic phenomenon, we have to look at our principal actors differently. In technology, the people who are responsible for servicing the asset (e.g., the code) are the people who are responsible for tech debt. Remember, in finance, we don't borrow against an asset. We borrow against future cash flows of a household or company, using an asset as collateral should the borrower not have the cash to service the debt. In tech, our code may be the asset against which we have borrowed, but we're really borrowing against the time of the team (e.g analogous to future cash flows) responsible for it to service that debt. Tech debt is a call option on people's time at some point in the future, not the asset itself.

Thinking about it this way allows us to extend the debt metaphor a bit further.

Capability Deflation Increases The Cost of Servicing Technical Debt

We saw earlier that deflation impairs people's ability to service debt. The same applies to tech debt. The inflationary or deflationary forces that impact our ability to service tech debt are related to our capability. We "inflate" our capability - and thus reduce our burden of servicing tech debt - through skill development and productivity enhancement. Our skills improve through study and experience. Our productivity improves with knowledge, tools and process. Holding our tech debt static - that is, assuming our tech debt merely rolls over - our ability to service that debt improves with the inflation of our skills and productivity. Capability "inflation" is the same as a household seeing real wages increase. The stronger our capability, the less impact that tech debt has on a team, the more "value" it can produce.

The converse is also true: capability deflation increases the real cost of servicing tech debt. An erosion of skills, loss of situational knowledge, and reduction in productivity all contribute to capability deflation which increases the burden of technical debt. Again, holding our technical debt static, our ability to service it declines with the deflation of our skills and productivity. Just as deflation intensifies contractionary forces on an economy, so, too, does deflation intensify contractionary forces on a team: the greater the deflation, the greater the burden of servicing tech debt, the less "value" produced by a team (the equivalent of economic contraction). In extreme cases, as happens in financial markets, debt servicing "crowds out" our ability to invest in our business through software creation.

Whip Deflation Now?

In 1974, fighting what would become runaway inflation in the post-Bretton-Woods currency world, the United States launched a grassroots campaign encouraging all citizens to curtail consumption - and share their ideas for doing so - as a way to contain inflation. The campaign was entitled "Whip Inflation Now", or "WIN". In the immortal words of Alan Greenspan, "this [campaign] is unbelievably stupid".

Leaders of any tech organization are in a constant battle against capability deflation. People will quit and work somewhere else, taking their skills and situational knowledge with them. People's skills will erode as they become content maintaining a "software annuity" that pays them a high salary for low-effort maintenance work. Organizational memory erodes as people leave, and those who remain forget why specific design decisions were made. Demand outpaces supply for skilled software engineers, forcing firms to hire less skilled developers if they are to have developers at all. New technology obsoletes old technology, and old software becomes trapped in legacy infrastructure. As evolution gives rise to pure maintenance, the work becomes less and less engaging and attractive. All of these things are deflationary forces on team capability.

To keep capability deflation in check, we have to burn the candle from both ends: refresh skills, and refresh assets. Have "refactoring" hack nights to attack tech debt, run spikes to introduce new technologies into legacy code, and rotate people through different teams to disseminate situational knowledge. We can also make investment cases to retire legacy software assets, which we can help by drawing attention to the "tech currency" of the software assets in our production portfolio. We can also use the strangler pattern to incrementally retire legacy systems, reducing the economic cost - and uncertainty - of replacement.

There will always be tech debt, if for no other reason than one person's engineering masterpiece is another's code hairball. And there will always be the threat of capability deflation. We can fight capability deflation - we have no choice, we have to fight it - but we'll never defeat it. To keep it in check, have a corporate culture that values knowledge acquisition and collaboration, and an investment strategy that constantly reinvents the software that runs the business.

Self-Insuring Software Assets

When we buy a house, we also buy insurance on the house. Catastrophic events can not only leave the homeowner without shelter, they can be financially ruinous. In the event of a catastrophe, the homeowner has to be able to respond quickly to contain any problems, and be able to either enact repairs herself, or mobilize people and materials to fix the damage. Repairs require building materials and a wide variety of skills (electrician, mason, carpenter, decorator). Most homeowners don't have the construction skills necessary to perform their own repairs, so they would have to set aside large capital reserves as a "rainy day fund" to pay for such repairs. But homeowners don't have to do this, because we have homeowner's insurance. In exchange for a little bit of cash flow, insurance companies make policyholders whole in the event of a catastrophe by providing temporary shelter, and providing the capital and even the expertise to make repairs in a reasonable period of time.

When we build software, we don't always buy insurance on the software. For software we build, we underwrite the responsibility for the fact that it will be technically sound and functionally fit, secure and reliable, and will work in the client and server environments where it needs to operate. As builder-owners, we have responsibility for these things during the entire useful life of the software. This obligation extends to all usage scenarios we will encounter, and all environmental changes that could impair the asset. If regulation changes and we need to capture additional data, if a nightly data import process chokes on a value we hadn't anticipated, if our stored procedures mysteriously fail after a database upgrade, if the latest release of FireFox doesn't like the Javascript generated by one of our helper classes, it's our problem to sort out. There is nobody else.

In effect, we self-insure software assets that we create. When we build software, we underwrite the responsibility for all eventualities that may befall it. Self-insuring requires us to retain people who have the knowledge of the technology, configuration and code; of the integration points and functionality; of the data and its structures; and of the business and rules. It also requires us to keep sufficient numbers of people so that we are resilient to staff turnover and loss, and also so that we can be responsive during periods of peak need (the technology equivalent of a bad weather outbreak). Things may be benign for most of the time, but in the event of multiple problems, we must have a sufficient number of knowledgeable people to provide timely responses so that the business continues to operate.

The degree of coverage that we take out is a function of our willingness to invest in the asset to make it less susceptible to risk (preventative measures), and our willingness to spend on retaining people who know the code and the business to perpetuate the asset and to do nothing else (responsiveness measures). This determines the premium that we are willing to pay to self-insure.

In practice, this premium is a function of our willingness to pay, not of the degree of risk exposure that we are explicitly willing to accept. This is an important distinction because this is often an economic decision made in ignorance of actual risk. Tech organizations are not particularly good at assessing risks, and usually take an optimistic line: software works until it doesn't. If we're thorough, previously unforeseen circumstances are codified as automated tests to protect against a repeat occurrence. If we're not, we fix the problem and assume we'll never have to deal with it again. Even when we are good at categorizing our risks, we don't have much in the way of data to shed light on our actual exposure since most firms don't formally catalogue system failures. We also have spurious reference data: just as a driver's accident history excludes near-miss accidents, our assessments will also tend to be highly selective. Similarly, just as an expert can miss conditions that will result in water in the basement, our experts will misjudge a probable combination of events that will lead to software impairment (who in 2006 predicted the rise in popularity of the Safari browser on small screens?) And on top of it all, we can live in a high risk world but lead highly fortunate lives where risks never materialize. Good fortune dulls our risk sensitivity.

The result is that the insurance premium we choose to pay in the end is based largely on conjecture and feeling rather than being derived from any objective assessment of our vulnerability. Most people in tech (and outside of tech) are not really cognizant of the fact that we're self-insuring, what we're self-insuring against, the responsibility that entails, and the potential catastrophic risks that it poses. Any success at self-insuring software assets has little to do with thoughtful decision making, and more to do with luck. If operating conditions are benign and risks never manifest themselves, our premium looks appropriate, and even like a luxury. On the other hand, if we hit the jackpot and dozens of impairments affect the asset and we haven't paid a premium for protection, our self-insurance decision looks reckless.

Insuring against operating failures is difficult to conceptualize, more difficult to quantify and an even more difficult to pay for. We struggle to define future operating conditions, and the most sophisticated spreadsheet modeling in the world won't shed useful light on our real risk exposure. Willingness to pay a premium typically comes down to a narrative-based decision: how few people are we willing to keep to fix things? This minimal cost approach is risk ignorant. A better first step in self-insuring is to change to an outcome-based narrative: what are the catastrophes we must insure against and what is the income-statement impact should those happen? This measures our degree of self-insurance against outcomes, not on costs.

Investing in Software Through Experts, Analysis or Discovery

Whether investing in equities or in software, there are three distinct approaches to how we make an investment decision: based on our intuition or experience, based on our analysis of an opportunity, or based on our ability to rapidly discover and respond to market feedback. Let's look at each in turn.

When we invest based on experience, our decisions are rooted in the expertise we've gained from things we've done before. When based on intuition, our decisions are based on strongly held convictions. An equity investor familiar with retail might recognize demographic changes in specific geographic areas (e.g., migration of families with young children to Florida and Texas) and intuitively invest in firms exposed to those changes (such as commercial construction businesses operating in those areas). In the same way, somebody who has first hand experience can invest in developing a technology solution: the inspiration for Square, Inc. came from a small firm that couldn't close a sale because it couldn't accept credit cards. Although expert investing will likely involve a little bit of analysis, for the most part the investor relies on gut. Because we invest primarily on the courage of our convictions, capital controls on intuitive investments tend not to be very strict. In absolute terms, the capital commitment is generally small, although in relative terms the committed capital may be quite large especially if it is a private placement. As a result, the capital tends to be impatient: trust in an expert lasts only so long; investors will get cold feet quickly if there aren't quick results.

We can invest based on research and analysis. Value investors in equities study company fundamentals looking for firms with share prices that undervalue the assets or the durability of cash flows. In the same way, we can look for value gaps in business operations or market opportunities and identify ways that technology can deliver value to fill those voids. The foundation of the analysis are things such as value-stream mapping, or competitive analyses of solutions developed by sector and non-sector peers. From this, we can produce a financial model and, ultimately, a business case. We need expertise to develop a solution, but by and large we make our investment decision based on the strength of our analysis. In absolute terms, the amount of committed capital can be quite large. But, having rationalized our way to making an investment, the capital controls tend to be strict, and the capital tends to be patient.

Finally, we can invest based on our ability to discover and adjust based on market or user feedback. Traders move in and out of positions, adjusting with changes in the market and hedging based on how the market might change. Over a long period of time, the trader hopes to end up with large total returns even if any given position is held for only a short period of time. We can do something similar with software, using approaches like Continuous Delivery and Lean Startup. In this approach, we aren't just continuously releasing, but rapidly and aggressively acquiring and interpreting feedback on what we've released. We can also use things like A/B testing to hedge investments in specific features. When we invest this way, we do so based not so much on our expertise or analysis, but based on our willingness and ability to explore for opportunities. Capital controls are strict because we have to explain what features we're spending money on and how we're protecting against downside risk of making a mistake. The capital backing a voyage of discovery will be impatient, wanting frequent assurances of positive feedback and results. But at any given time, the amount of committed capital is small, because investors continually evaluate whether to make further investment in the pursuit.

Each of these approaches makes it easy to answer "why" we are making a particular investment. Why should we part with cash for this particular feature? Go ask the expert, or see how it fits in the business case, or go get user feedback on it. "Why" should drive every decision and action made in pursuit of an investment. Without the "why" there is no context for the "what". In its absence, the "what" will suffer.

No approach is universally superior to another. The approach we take has to play to our strengths and capabilities. Either we have people with expertise or we don't. Either we have people with analytic minds and access to data or we don't. Either we have the ability to rapidly deliver and interpret feedback or we don't. The approach we take must also be suitable to the nature of the investment we're making. A voyage of discovery is well suited for developing a product for a new market, but not for an upgrade to a core transactional system. The business case for investing in a customer self-service solution is going to be much more compelling than a business case for developing a product for an emerging market segment.

Just because we take one of these approaches is no guarantee of success. Not all investments are going to pay off: our experts may turn out to have esoteric tastes that aren't appealing to a mass audience. Our thoroughly researched market analysis might very well miss the market entirely. We might deliver lots of features but not find anybody compelled to use them.

Worse still, each of these approaches can be little more than a veneer of competency to unprofessional investing. A hired-in expert may be a charlatan. Many a manager has commissioned a model that inflates benefits to flatter an investment - only for those benefits to never be realized. Just because we can get continuous feedback from users does not mean that we can correctly interpret what that feedback really means.

Most of the time, of course, we take a hybrid approach to how we invest. We supplement expertise with a business case, or we charter an investment with a business case but use Continuous Delivery to get feedback. However we go about it, we need to get the essential elements of the approach right if we're to have any chance of success. Otherwise, we're just unprofessional investors: investing without experience, thoughtful analysis or an ability to respond quickly is reckless use of capital.

Entirely too much software investing fits this bill.