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.

Corporate Middle Management as an Autopoietic System

[T]he aim of such systems is ultimately to produce themselves: their own organization and identity is their most important product.

-- Gareth Morgan, Images of Organization, p. 236.

In the early 1970s, biologists Humberto Maturana and Francisco Varela coined the term autopoiesis to define the self-maintaining nature of living cells: biological cells produce the components that maintain the structure that creates more components (in this case, more cells). This is in contrast to allopoietic systems, which use components (raw materials such as silicon and plastic) to generate something (mobile phones and computers) which are distinct from the thing that created it (the factory where they are made).

In the mid-1980s, Gareth Morgan applied the concept of autopoiesis to organizational study.

They do so by engaging in circular patterns of interaction whereby change in one element of the system is coupled with changes elsewhere, setting up continuous patterns of interaction that are always self-referential. They are self-referential because a system cannot enter into interactions that are not specified in the pattern of relations that define its organization.

-- Ibid, p. 236

A few months ago, I described the organizational pathologies that we see in slow-growth, (mostly) equity funded firms: because it faces no real pressure (no credit rating to support, no competitive threats to revenue) it will suffer from operations bloat. A significant source of that bloat will be a large middle management.

Left unchecked, tech organizations will grow vertically around line activities (software products that support business functions) and horizontally around shared services (testing, infrastructure). They will also establish one or more program management offices to navigate delivery of complex business initiatives across the fractured organizational landscape. For every management expansion, there is an equal and opposite hiring spree. The host business will mirror tech's management structures, creating business product managers opposite technology line managers, and a business PMO responsible for business change management functions opposite the tech PMO responsible for delivery of tech assets. This management sprawl happens for a variety of reasons: people are promoted into management for fear they might quit, IT gets burned by a delivery failure and creates new hierarchy in response, a senior business manager doesn't want to be seen as mapping to a low level of the tech organization, a new boss prefers to delegate rather than get his hands dirty with the details, there is a low level of trust between tech and business and matching staff is how it maintains equilibrium, and so forth.

Middle management is not a value-generative function. Because they are not engineers or analysts, middle managers don't directly contribute to solution development. Instead, they negotiate on behalf of their sphere of responsibility with other middle managers. They create documentation templates, project control forms, release and implementation workflows, and program checklists to create contracts among other managers to secure the time and attention of the people who do contribute to solution development. These contracts implicitly protect every middle manager by sharing responsibility (my work was dependent on somebody else who failed to deliver) and deflecting responsibility (another initiative took priority so we had no choice but to let this other deadline slip). The web of contracts allows middle management to self-perpetuate.

[W]e can describe autopoietic systems as those producing more of their own complexity than the one produced by their environment.

-- Carlos Gershenson, Requisite Variety, Autopoiesis, and Self-Organization.

It also serves as the fuel for growth: perpetual negotiation spurs middle management to expand its library of templates, forms, workflows and checklists. That, in turn, adds to the structure, because it requires more middle managers to fill out more program documentation. For example, a few years ago, the logical database storage for a legacy asset was overwhelmed when a new type of transaction was implemented; since then, the infrastructure department requires every new initiative to complete a "long-term storage analysis forecast". But, some initiatives don't generate many transactions at all and will have little impact on storage allocated to any asset. The managers in those initiatives don't have to fill out a "long-term storage analysis forecast", but must still fill out a "storage analysis forecast exemption" form to document why management concluded the forecast document wasn't necessary.

In this way, middle management is autopoietic: based on a flow of documentation, it creates components (middle managers) that maintains the structure (the bloated middle management) that creates new components (more middle managers).

* * *

[T]he brain does not process information from an environment, and does not represent the environment in memory. Rather, it establishes and assigns patterns of variation and points of reference as expressions of its own mode of organization. The system thus organizes its environment as part of itself. If one thinks about it, the idea that the brain can make representations of its environment presumes some external point of reference from which it is possible to judge the degree of correspondence between the representation and the reality. This implicitly presumes that the brain must have a capacity to see and understand its world from a point of reference outside itself. Clearly this cannot be so[.]

-- Morgan, pages 237-8.

Suppose we want to introduce Agile into an organization because we want delivery to be more efficient and effective, and we want a better relationship between business and technology. One way we think we can do that is by simplifying our management processes and making them more collaborative, and Agile appears to offer us a means of doing that.

If we have a large middle management function, we can't expect that Agile will simplify our requirements, development, release, or change management activities. What we should expect is that Agile will get co-opted by the very structures that it is there to disrupt. A middle manager cannot comprehend Agile as a different means to an end, because the only end a middle manager is pursuing is successful contract negotiation with other middle managers. A release plan becomes a closed-ended project plan, Stories in an iteration become a commitment, tasks per each Story become the coin of negotiation with other managers for their "resources". Adopting Agile - everything from adaptive planning to continuous delivery - requires a level of abstract thinking about why we do the things we do and how they lead to a delivery outcome that will be well beyond that of an incumbent middle management. Any middle manager capable of abstract thinking will have left the organization long ago: survival requires concrete thinking within a very narrow scope of self-referential activity.

When we recognize that identity involves the maintenance of a recurring set of relations, we quickly see that the problem of change hinges on the way systems deal with variations that influence their current mode of operation. Our attention is thus drawn to system processes that try to maintain identity by ignoring or counteracting threatening fluctuations, and to the way variations can lead to the emergence of new modes of organization.

-- Ibid, p 239.

For a large middle management, Agile is not a welcome change. If we have business and tech people working together daily rather than having a temporally shifted conversation through documentation, if we have technology generalists rather than specialists, if we capture knowledge in automated tests and ops scripts, we need far less intermediation in the delivery process. This obviates the need for an expansive middle management function.

An autopoietic system is capable of autoimmune responses. Co-opting, described above, is one. Ignoring is another: enough people refusing to change can force management to re-think its commitment to that change. Subverting is a third: creating obstacles and impediments to change to sow uncertainty and doubt on its effectiveness are behaviors intended to reinforce middle management's identity. Autoimmune forces are powerful: a function that exists solely for its own perpetuation - even when not by charter, but as a matter of social contract among its members - will become shrill in its own defense.

The policeman is not here to create disorder. The policeman is here to preserve disorder.

-- Richard J. Daley, 48th Mayor of Chicago

What does change look like under these circumstances?

Clearly, it isn't willing acceptance by the incumbents. We can't expect actors in a system to accept change that results in the destruction of that system. As Upton Sinclair famously wrote, "it is difficult to get a man to understand something, when his salary depends upon his not understanding it."

By definition, change of an autopoietic system must be triggered internally, and happen as a result of randomness. Morgan argues that "random variation provides the seed of possibility that allows the emergence and evolution of new system identities." Random changes create the possibility of new relations, which, if they're not absorbed or stifled by other parts of the system, can lead to new identities. Morgan argues that "Human ideas and practices seem to develop in a similar manner, exerting a major transformational effect once they acquire a critical level of support." Nassim Taleb makes the same argument in his book, Fooled by Randomness.

The corporate change leader doesn't have the luxury of time for the forces of randomness to reform an entrenched middle management. There are two policies that can accelerate structural change: disallowing self-referential justification for middle management practices (that is, expanding its scope of reference so that every action must be justified by a delivery outcome, not a middle management negotiation), and aggressive dismantling of the middle management structures themselves. The prior, if not compromised, puts an incumbent invested in the status quo on the defensive and robs it of it's raison d'être. It also helps to identify people in middle management who are reformable and coachable. The latter reduces the need for the prior.

Bad events in organisations are generally the product of bad systems rather than bad people ... [W]e need to go on and ask what it is about modern corporate life that has made such misbehavior not only possible but appear increasingly common.

-- John Kay, Organisations advance by asking "what went wrong" rather than "who is to blame

It's hopeful to believe that an incumbent middle management will "see the light" once introduced to a different set of practices, mechanics and tools. But the broader corporate reality tells us otherwise. When we introduce change, we quickly come into direct conflict with a self-referential ecosystem that, despite obvious internal contradictions and shortcomings, has an extraordinarily strong survival instinct. We also discover latent, institutionalized corporate misanthropy directed at users, customers, suppliers and business partners. A change toward Agile, and the value system it represents, is less enabling, and more threatening, than we'd like to think. To be successful as change agents, we have to dismantle the structures, processes and people behind the status quo while simultaneously replacing them with a new normal.

Potential and Motivation

When a management with a reputation for brilliance tackles a business with a reputation for bad economics, it is the reputation of the business that remains intact.

-- Warren Buffett

For a business to have "potential", it needs opportunity, money, willingness, talent, and aptitude. Yes, a business without all of these things still has potential: it might be poorly funded but have knowledge-acquisitive people and a clear opportunity; it may have weak capability but good cash flow. But somebody agreeing to lead or acquire a business because of its "potential" still needs to compensate for deficiencies in any of these areas.

Potential needs a wake up call if it is to be realized. Sometimes, our source of motivation is external: new competitors, or a threat to our business model. It can be internal: an activist investor on the board forces the CEO to accept new operating targets.

Potential and motivation are both the purview of leadership. A good leader creates potential where there is none: putting someone in a stretch role, freeing capital for reinvestment through a restructuring, diversifying the product line by acquiring a business, hiring a strong product team to engineer and market new offerings. A good leader motivates with incentives and rewards, culture and risk-taking: define business objectives that require cleverness and innovation and not just operational efficiency; flatten and simplify the organization, distribute authority and responsibility; recognize team behaviors over individual heroism.

The intersection of motivation and potential is never as far down each axis as we hope because they're constrained by our ambition (or lack thereof), and by fear. We can't imagine things any different so we fail to define an opportunity. We see competitive threats developing but we lack the will to act. We are reluctant to make difficult staff cuts to free up money. We don't recognize the outdated skills of our people, the absence of abstract thinking, the dearth of current technologies and practices, so we do nothing to upgrade our talent base. We're afraid of offending our current employees by changing the compensation structure. We are more comfortable micromanaging, demanding commitment, and promoting people through hierarchy than we are giving people autonomy and rewarding them for innovation.

Worst of all is when we simply talk ourselves down: of course we want to get to such-and-such state someday, but we can't possibly make so much change so quickly. This amounts to regulatory capture of a leader's ambition - and by extension, of a business' potential - by the business itself.

The difference between a change leader and a caretaker isn't lofty vision or inspiring words, it's the ability to create maximum potential within the organization, and the motivatiors that drive people's behaviors and actions to realize it.

Capitalizing Tech in a Cloud / SaaS / Continuous Delivery World

Around 2010, when US companies could count on a recovering domestic economy, a weak US dollar, and growing emerging market economies, CFOs didn't need to work that hard to flatter the income statement. This has changed: the US recovery has been inconsistent, emerging markets are performing poorly and the US dollar is strong (taking the edge off overseas revenue). Plus, firms are carrying more debt than they were a few years ago, making the optics of the P&L that much more important.

One result of this is that tech capitalization is back. It never really disappeared, of course, it just wasn't as common. But while tech capitalization was dormant, tech has changed a lot - quite a lot, in fact.

First, Cloud, SaaS and BYOD change software and infrastructure from capital investments to rent expenses. Renting is an economic convenience more than it is a cost efficiency. Renting is no less expensive than owning (the person who rents a house has to cover the landlord's mortgage, capital improvements, taxes, etc. in the rent payment), so technology costs represent a larger - and discreetly measurable - operating expense. As an expense, it's increasingly being indexed to payroll (that is, headcount), which makes it more like a tax (I need one ERP user license for every employee in sales, so if my sales force grows, I need more licenses).

Second, Continuous Delivery - deploying software hourly or daily instead of monthly or quarterly - blurs the lines among traditional development stages. It makes our packages of deployable work far more atomic than the more traditionally coarse "release" or "project" level deployment. Plus, if we're experimenting through software to see whether there's a need (much less a solution) - something uniquely enabled by Continuous Delivery - our development can't be capitalized at all. It's R&D, which has to be expensed.

What does it mean? Well, we don't know. For one thing, we're not really there yet. We know that this echoes the supercycle of businesses separating into asset-light operating companies (e.g., retailers) and asset-heavy finance companies (e.g., REITs). But we also know that a lot of firms still license captive ERP systems (no SaaS), operate captive data centers (no Cloud), and issue hardware to employees (no BYOD). In development, Continuous Delivery is still more idea than implemented among firms predisposed to capitalize rather than expense their software development costs. The execution trend toward tech asset light matches - but lags - the financial trend.

For another, specifically with regard to capitalizing development, we fit Agile under FASB 350-40 without violating the intent of the original AICPA policy (SOP 98-1), but we never explicitly formulated policy to reflect how work got done in an Agile world. For as much as we made Agile perform better than Waterfall under capitalization policies (e.g., better opex/capex ratio), it's always been an ill-fitting Waterfall suit around an Agile body. Fast forward, an today we have Continuous Delivery, which takes Agile concepts of frequent delivery and Lean development practices to the next degree. This extends the already long tail: accounting policy (treatment) lags tech execution (Continuous Delivery is still wishful thinking in most firms) lags financial expectation (asset light).

But some things we do know, and point to what we should be paying attention to.

The CFOs interpretation of tech as a capital investment is not the same as tech as an operating expense or tech as a tax. The more tech becomes an expense or a tax, the more downward price pressure there will be on tech. This is great for a business, but it could portend the next collapse in tech pricing buoyancy.

Similarly, software development as an R&D expense does the CFO no favors on the income statement. Development labor has commanded a premium price for many years now - it's been counter-cyclical since 2009, rising while labor costs in the broader economy stagnated or sank. CFOs don't have a high tolerance for this. Importing a high cost of labor onto your statement of cash flows because you're investing in an asset that you expect will generate future cash flows is one thing. Importing a high cost of labor onto your statement of cash flows for an R&D experiment is entirely another. As CFO, you're more comfortable paying a premium for labor if you see a path to getting it back; you're less comfortable if you're spending on some "ideation" boondoggle. Labor scarcity, cheap capital, easy profits, and a growth-through-tech-frenzy make boondoggles less onerous; a change in those conditions will make them far less tolerable.

The prevailing business conditions are changing, bringing capitalization back with them. Or, at least, tech is being asked to bring capitalization back. Tech is less well prepared to answer: while tech has evolved beyond fixed assets in data centers and long-cycle Waterfall delivery, it never truly matured how it accounts for its costs in the context of the host or consuming business. If anything, it's thumbed its nose at finance, allowing labor scarcity to afford it the freedom to drive itself more toward a no-strings-attached expense.

If the capital cycle still matters, this is bad for tech. If the tech cycle trumps the capital cycle, it doesn't. We'll look into that a bit more closely next month.

Capital Structures and Organizational Pathologies: Tech Investments in Slow Growth Equity Funded Companies

The volatile nature of tech companies makes them better suited to equity funding as opposed to debt. Equity is high-risk capital: owners are exposed to the upside of growth (you stand to make a lot of money), but also the downside of failure (you stand to lose everything you put in). Debt is not: how much risk is there to the lender when the borrower guarantees a return? Plus, in the event of a liquidation, creditors are first in line to be made whole.

Of course, there is risk with debt finance: if the borrower gets in trouble and has difficulty servicing the debt, the value of the debt falls. And there is high-risk debt: junk debt gives high-risk borrowers access to debt finance and debt investors more risk exposure than debt usually permits. Also, tech companies that become utilities - think Oracle or Microsoft - do lend themselves to debt finance. But that's because they are utilities more akin to electricity and water than volatile, shoot-for-the-moon tech firms. We don't equate investing in Microsoft with investing in King Digital Entertainment.

On the whole, tech investors want exposure to runaway upside, not steady returns. We get this exposure through equity capital.

Portrait of a slow-growth (non-technology) firm. Less than 10% of it's Enterprise Value is debt. It has a strong market share position and slow annual growth that allows it to pay a slightly increasing dividend year on year. As technology starts to become more prominent in their industry, they appear to be well prepared to take it on.

But are they?

This is a firm under no real pressure. Because it doesn't have a credit rating to support, this firm will be sloppy in operations. Being slow growth, they'll feel no threats to revenue, and likely can't conceive of any, possibly even believing they are uniquely immune to competitive threats. Mollifying investors every year with a slightly increasing dividend will attract capital satisfied with steady returns, not agitating for growth.

Their strong market position and simple balance sheet will give them the patina of being a "tech ready" firm, positioned to be leaders of tech innovation that can further improve their grip on the market. The board might go so far as to insist on the CIO bringing tech investments up for consideration, and the CEO may bring attention to these during earnings calls.

But the culture is fundamentally risk averse: why mess with the good thing we have going? Bloat in their cost of operations will crowd out cash for investment. The nature of tech investing - burning through a lot of cash on development and marketing to grow a user base - will be unpalatable. What they have in the appearance of readiness to be tech investors quickly evaporates in the lack of will to follow through.

Which is not to say they don't invest in tech, but it is a "me, too" firm that invests in low-risk technologies in response to what competitors have done. It is not an industry disrupter looking to change the competitive landscape through tech. They'll see investments in tech that drive a bit more efficiency out of their existing way of doing things (such as manufacturing or supply chain technology) far easier to conceptualize and pursue than high-risk, exploratory investments or acquisitions.

It might seem that new leadership or a few quarters of revenue contraction could break the company out of its slumber. But for fundamental change to happen, a CEO has to sell the board on a vision for how the competitive landscape is changing and what the company needs to do to lead it; cut overheads and perks; get line managers to tighten operations; and convince shareholders that the money saved is best redirected toward the pursuit of the new vision. And that's just the start: follow-through execution to make the vision a reality requires a change in the culture.

Changing the culture from "coast" to "hustle" challenges the company's willingness to act, all the way to the board. Sadly, if the stock price gets a lift simply by basking in the reflected glory of actual tech innovators, the board is more likely to interpret it as a validation of its decisions to date than it is willing to depart from them. The firm may be tech ready, but it is change averse.

Capital Structures and Organizational Pathologies: Tech Investments in Debt-Fuelled Capital Intensive Companies

Portrait of a growing company: a corporate parent with two-thirds of its enterprise value in debt, running two separate but interdependent divisions: a capital intensive asset heavy business, and a cash generative consumer-focused operating firm.

If you're the CFO, your primary concern is the debt capital that's financing your growth. You want to keep your credit rating strong to minimize the cost of rolling over debt (to finance existing assets) and the cost of raising new debt (to fund expansion). Every extra dollar paid to service the debt is a dollar less yield the business generates for its own use.

The CFO keeps the credit rating strong by having consistently strong cash flow from operations.  Even if it doesn't generate enough cash flow to cover investing activities, strong and consistent cash flows show financial discipline in running the business, and potential for financial reward at greater scale; this encourages more investment and suggests only modest risk.

The two divisions have decidedly different cash needs.  The asset-heavy business consumes capital, while the asset-light operating company generates it.  There isn't much you can do to squeeze operating cash flow efficiency from the asset-heavy business, aside from minimizing overhead costs associated with investing activity.  But you can squeeze the operating company for efficiencies, reducing total labor costs with things such as customer self-service.  The more cash hungry the asset-heavy business is for investment, the more ruthless the operating business will be squeezed for efficiencies.

The P&L is also a source of trouble for the CFO. The expanding asset-heavy division will have more expenses than income.  It isn't a problem for a growing business to post losses, but the volatility of investing activity in the asset-heavy side of the business will put downward pressure on the credit rating.  That will lead the CFO to be creative with the income statement, through things like capitalization.

What does all of this have to do with software?  The asset-heavy division isn't going to be very software intensive.  The operating company is, though.  Suppose that the operating company is in a firefight for market share, where the primary weapons are customer-facing technology (as is happening in retail, entertainment, and, to a lesser extent, airlines - all of which have capital intensive asset-cos side-by-side with cash generative op-cos.).  With labor demand outpacing supply in tech, engineers and designers are expensive. They have to be compensated in cash, since the capital structure makes it difficult to compensate them in equity.  Plus, not being an engineering firm, the company will be slugging it out to find and retain qualified engineers.  From the CFO's point of view, software development - just some part of the operating company - has a spiraling cost of labor, and it's high-maintenance (e.g., requires a lot of care and attention to get and keep people) to boot.

This is where the "we have a software company within" myth starts to fall apart.

The economics of running a competive software business don't matter a damn to a CFO who is trying to sweat every penny out of an operating company.  True, having the patina of a tech business could juice the valuation, but only in terms of the equity, not the debt - primarily because tech firms just aren't financed with debt.  If you're going to debt markets, you need financial operating cred more than you need to show tech characteristics.  Plus, the growth that mollifies the credit raters enough to turn a blind eye to the saggy P&L will have been priced into the equity; in an asset-heavy business, tech will be priced in as a necessary cost of the operating company, not as an option call on the potential for explosive growth.

Another way to look at it is, any increase in the equity value that results from the appearance of being a budding tech business is a nice-to-have for management (who have equity & options). Otherwise, with such a large debt overhang, any tech patina isn't likely to have any real economic value, e.g., the creation of an inflated currency (the company's own stock) with which it can favorably engage as an acquirer of other companies.

The opco may need tech to be competitive, but that won't be the first priority.  No matter how important tech may be, financing the debt will always trump it.  For the CFO, the priority is cost discipline.  In execution, the CFO will keep tech leadership on a short budgetary leash, forcing it to choose between hiring a lot of people but not paying competitive wages / contractor costs (and, on average, have a lower skilled engineering staff), or hiring / contracting at market rates but not being able to hire nearly the number of engineers it needs.  Either way, software development is starved for investment, crowded out by the demands of debt finance.

Accounting treatment of the software will also have its effect.  Its penchant for large capital investments on the asset-heavy side of the house will lead the company to make large capital investments in software.  Because the CFO capitalizes software development costs, the company can't afford for those investments to fail, because a failure requires the entire cost to be written off in the current accounting period, which puts a dent in the P&L.  This means that the company isn't predisposed to R&D through software (making a lot of little, experimental investments); it's predisposed to making large, debt-fueled asset acquisitions and making good on the convenants that go along with them.  In practice, the company will inject more capital into distressed software projects rather than let them fail.

The portrait of a growing, debt-fueled, capital intensive business is the antithesis of a modern software company.  Software companies are high-risk businesses: investors wager that the people in the firm can not only create interesting technologies, but can find users for them, and ways to monetize them.  The predictability and stability demanded by debt service obligations don't give rise to innovation and disruption; they create stagnation and sclerosis.  That puts paid to any suggestion that a debt-fueled, capital intensive business is really a software company in disguise.

Next month, we'll look at other operating pathologies driven by the capital structure.

Without the Right Capital Structure, There is no Software Company Within

Is every company destined to be a software company? From a production perspective, there's reason to believe so: relatively minor things that were once the domain of hardware (configuration set by switches on a circuit board), operations (merchandise re-ordering based on sales and quantities) or subscription (license fees paid for usage) have become things that are now the domain of software (configuration is set through a browser interacting with Java code running in a Linux variant deployed on a hardware device; algorithms that automatically re-order merchandise based on seasonal, demand & promotional variables; advertising-sponsored or use-metered interaction). Virtual data centers, real-time algorithmic pricing, and new media are simply larger versions of that same phenomenon.

Production isn't what it used to be. A century ago, production was king: demand outstripped supply in economies with emerging consumer classes, which gave power to producers. That has long since changed. Today, production has few sustainable advantages: it is over-built (e.g., automakers have far more capacity than demand), highly flexible (lower labor intensity and cheap capital means production can shift quickly in response to economic or political demands, but by extension means there is no intrinsic strength derived from a "highly skilled labor force"), and subject to constant innovation in inputs (look at the progress in materials science in the last two decades). Producers can only counteract deflationary forces at their core with ruthless cost control and brand allure. A producer does this with a combination of efficiency (squeeze every penny from raw materials sourcing to distribution) and by appealing to or outright fueling user vanity (engender customer identity in every facet of its business).

Software is the means through which both of these things are done: we can use software to gather data, analyze performance and adjust operations in near real-time; we can also use software to reinforce identity, influence attitudes and drive behavior of consumers. No software, no chance.

So producers have to become software companies. But what does that mean exactly?

To somebody running a business, it means realigning internal operations. We have to look at skills and capabilities: we're not going to be much of a software company if we don't employ any software engineers. There are process and cultural considerations, too: an "optimized" business might squeeze more performance out of operations through software, but is less likely to be capable of capitalizing on external data that allows it to "re-invent" its industry through software.

But skills, capabilities, processes and culture all wilt in the face of an overbearing capital structure. A company financed to produce long-term stable cash flows from operations isn't a company that is prepared to respond to threat of competitive innovation via software or anything else, let alone one that will be a source of competitive disruption. It might consume a lot of software. It might even create a lot of that software. But software intensity in what we do doesn't make us a software company, any differently than walking for miles every day makes us athletic. Operations and execution matter to the bottom line, but ultimately dance to the tune called by finance.

Next month, we'll look at the organizational pathologies created by different capital structures and how those make a firm that innovates and competes through software as opposed to a firm that ingests and consumes software.

Would Uber be so intriguing if we thought of it as the next American Airlines?

Suppose for a minute that self-driving cars become commercially available. Obviously, a lot has to happen before we get to that point, but suppose that it does. What happens to the economics of ground transportation?

Today, cars are owned or leased by individuals (households) or fleet operators (delivery firms or rental car companies). Auto manufacturers sell to dealers, who sell to individuals and firms; finance companies from universal banks to specialist lenders finance the trade. The buyer trades cash for utility (you have the car that suits your lifestyle), convenience (you have the car that you want any time you want it), and vanity (your car is a projection of who you want people to think you are). The rise in popularity of leasing hasn't changed things all that much because lessees make payments in exchange for possession that guarantees the same utility, convenience and vanity enjoyed by an owner-operator. Because there are millions of owners (and lessees), ownership is fragmented. Fleet operators have some buying power, but large fleets don't represent a very big portion of the total auto market.

Cars are underutilized: the average car sits unused about 95% of the time. This creates an opportunity to squeeze more efficiency out of the fleet. Enter firms such as Uber and Lyft: an idle person can take their idle car and give someone a ride. Of course, it isn't the car that's being shared, it's the labor: an UberX customer rents the driver, not the car. Uber brings new sources of labor into the market for personal transportation (competing against car ownership, car rental, taxi, limo, etc.), makes it conveniently accessible to passengers, and algorithmically optimizes pricing (the financially lucrative if socially unpalatable "surge pricing"). In a labor-intensive market prone to chronic shortages at the point of consumption (there never is a taxi when you need one in Manhattan...), this gives Uber and Lyft a price advantage over incumbents and attractive growth potential.

Enter the self-driving car. Suppose that we get autonomous self-driving cars that don't require a human operator backup. A self-driving car could deliver itself to a consumer and return itself to a vehicle pool. A vehicle that arrives when it's needed, and disappears when it isn't, changes vehicle consumption into an on-demand, short duration rental transaction. Companies that operate fleets of cars will initially compete on algorithms that maximize fleet utilization, plus inventory management that optimizes the mix of vehicles available in specific geographies at specific times (fuel efficient sedans for trips from home to the airport on weekdays, and light trucks for weekend DIY projects). The more efficient the dispatch and the more comprehensive the fleet, the easier it is for an on-demand service to satisfy an individual's need for utility, convenience and vanity in their choice of transportation.

In a world of self-driving cars, however, the service operator isn't optimizing labor, it's optimizing asset utilization. The economics of ground transportation will change to reflect this. A self driving car changes the current owner-operator (that is, the individual driver) into an on-demand renter-passenger. Rental transactions become simple debit or credit transactions between an individual and a fleet operator.

In this world, the users aren't the owners, but neither are the operators. Auto transportation will come to resemble the air travel business, where there are companies that own fleets of airplanes and rent them to companies that operate them to deliver passengers and packages. The fleet owners - firms like International Lease Finance - are asset-heavy companies that buy and insure aircraft from manufacturers (Boeing, Bombardier, Airbus) and lease them to airlines who operate them to deliver people and parcels. Being large buyers and large suppliers, the lessors concentrate ownership of the assets, which gives them negotiating power with both manufacturers and lessees. They are finance firms that throw off fixed-income-like returns to their investors.

The fleet operators are asset-light, leasing the aircraft (an operating expense) and slugging it out with one another for consumer market share. They throw off equity-like returns because they follow the ups and downs of the consumer economic cycle, facing the simple economic threats of substitution (videoconferencing has culled some demand for in-person meetings) and competition from start-ups siphoning off revenue of the most profitable routes (it isn't hard to start an airline, but it is hard to make money at it for any sustainable period of time, as the list of defunct carriers attests. It will be no less difficult to start an auto operating business).

The auto fleet operator - now an "asset sharing" company of assets it doesn't own, but rents - cannot compete for long solely on efficient dispatching and high asset utilization. Being operating companies of utility services, they compete on price, so they need to be merciless about increasing operating revenues and decreasing operating costs. They will develop complex pricing structures, just as airlines have done to charge premiums for better seats and extra bags. They will segment their market into a small premium segment that rents luxury vehicles and a mass segment that rents more humble rides. They will develop loyalty programs that rewards individuals for transaction volume and revenue contribution. And although it's tempting to think about fuel consumption as an individual responsibility as it is in the owner-operator model, the fleet operator will quickly realize that energy is a major cost component, and will hedge fuel costs as a way to lower their operating cost - or be able to offer lower operating prices vis-a-vis competitors.

We have cars that can drive themselves today. But a lot has to change before a significant number of the cars on the road drive themselves - and not just because of the equipment, infrastructure and policy needed to make it happen. Cars are vanity purchases. Suburban transportation and lifestyles are bound to automobiles. The convenience factor, particularly in periods of high demand, will compel many to continue to own or lease. The individual ownership or lessee model won't change any time soon, so this future is still a long way out.

Still, it suggests that the future of the dial-a-car business will be an exciting one, but for a different set of reasons than anybody is projecting today: intense competition, race-to-the-bottom pricing, volatile earnings, and the occasional trip through bankruptcy. Not exactly the kind of future that captures the imagination.

Matrix IT Organizations, Part II: The Inmates Are Running the Asylum

A few months ago, we took a look at the pathologies of matrixed organizations: no focus, amateur management, and people waging turf wars to secure power that they can exercise without consequence. The result is stationary organizational inertia, the portrait of a seized-up business.

When non-executives enjoy power without responsibility, the corollary is that executives suffer responsibility without power. The organisation cannot pursue a consistent or coherent strategy, and may find it difficult to take any decisions at all.

-- John Kay, How a proud corporate history can lead to poor governance

Matrices empower petty bosses but disenfranchise organizational leaders. The owner of a product P&L doesn't "own" the people who produce it: executors report to managers in other parts of the organization, are shared with other teams, and may be so over-subscribed they have little time to devote to any one of them. Non-technical product leaders will struggle to navigate business goals to completion through the sea of technical tasks their teams force them to sail in. Knowing their skills and institutional knowledge are in short supply, individual executors and their supervisors get to pick and choose what they work on. The product leader ends up negotiating in all directions - with the people nominally on their team, those people's managers, and their peers struggling with the same organizational dynamic - to secure the time, attention and cooperation of labor. This isn't leadership, this is perpetual pleading, often just to complete the most marginal of tasks.

The chaotic process is vigorously defended by claims of democratic legitimacy, and by reference to the traditions and distinctive values of the organisation. But the democracy is a sham, and the values and traditions [...] encourage a tendency to self-congratulation immune to deficiencies in current performance.

-- Ibid.

Although power rests with people in execution, few will derive any joy from the situation. Whether they have power or not, executors are constantly pulled in multiple directions at the same time. In an organization over-run with demands, people will resort to coping mechanisms. One is process: if they can't control demand they can control the means by which people making demands interact with them, giving them some semblance of "control" over their universe. Another is denial: as Dr. Kay points out, they've lost the ability to recognize that the business context itself is idiotic, yet will take triumph at how well they cope. To wit: revenue is declining, infrastructure is decrepit, quality is poor and we can't make even the most simple of decisions, but my goodness we are so much better at communication since we adopted Scrum. High five!

This is organizational madness, and the inmates are running the asylum.

Companies don't set out to be organized as matrices. They resort to it when revenues fail to keep pace with the costs of doing business. When they do, it suggests that the business is trying to do too many things at the same time. It also suggests that many of the things the business is trying to do don't generate much revenue. Put more simply, the business is distracted by a lot of bad ideas. This isn't a problem of organization or of operations leadership, it's an executive leadership problem twined with weak corporate governance that has failed to keep that executive on a short leash.

I once worked with a private equity-backed firm that had a portfolio of four very different digital media products in different stages of maturity, with limited cross-product synergies. Two were past their peak and in unarrestable decline, one was ex-growth, one was growing. The technology organization - including software development - was shared across all products, with tech costs subsidized by the entire business. The company was unprofitable, dependent on life support from private equity injections. To justify those, the corporate headline was growth, although they tried to make the case that there was a profitability story in some of the lines.

We calculated product-specific P&Ls. These revealed that no product was operationally profitable if it had to carry the burden of its actual tech costs. This was due to product customizations given away by sales as a way of luring in new clients to replace lost ones. The slipshod software that resulted from those freebie customizations came with high running costs; company and customer alike got what was paid for in that unfunded customization.

We also did a revenue analysis. It revealed significant client churn across the lines, and that pricing of the growth business was so anemic that it would never achieve sufficient organic growth to provide the revenue the firm expected. Worse still, this sole growing market was maturing rapidly, creating downward price pressures they could do nothing to combat.

Operations and technology were as described in this and the prior blog: unable to focus, fiefdoms without responsibility, and so forth. Being unable to put a floor under the declining businesses' revenues plus a permanent pricing impairment on the "growth" business meant operations and technology would always be starved for cash. There is no wizardry that would turn this around; it was simply a collection of bad businesses.

The sane alternative was to simplify and focus: dispose of the declining and ex-growth businesses or run them for cash; sell the growth business or acquire competitors to consolidate the industry to achieve scale; and invest in organic development of a new media property. Unfortunately, the CEO saw a portfolio of properties that had thousands of visitors and just enough revenue that he could convince the board to keep the funding taps open, because there had to be a pony in there somewhere.

The options aren't all that great in this situation, which is why professionals aren't attracted to them in the first place. If you're brought in as Chief Executive or part of an executive team with an explicit mandate from the board to make sweeping change, you have a chance. But if you have a weak board overseeing a delusional CEO and a sales force for whom every dollar of revenue is the same, all producing initiatives that require tech and operations to compromise to compensate for a lack of revenue, you're wasting your time: you're in the asylum, and there's no one to hear you scream.

Activist Investing in Strategic Software Chapter 1 Excerpt - Why Governance Matters

I've published drafts of the introduction and first 4 chapters of my book, Activist Investing in Strategic Software. I still have some citations to finalize, several visuals to integrate and a lot of editing to do. But the foundation is there. A sample of the book (currently, just the introduction) is available on from the site.

Here's an excerpt from Chapter 1, Why Governance Matters.

* * *

That there are abundant examples of bad governance but few examples of good ones comes as no surprise. What passes for "good" in governance is not all that remarkable. Boards, being the representatives of investors, are expected to be independent, diligent, and uncorruptable. Independent members of corporate boards are assumed to be people of capability and integrity. People in governance roles are expected to discharge their duties competently; meeting expectation is not exceptional. Hence we have few examples of good governance but many examples of bad.

This doesn't help us understand why governance is important.

Poor governance, such as in the cases of Olympus, Hollinger, Madoff, or the United Nation's Oil for Food program, can lead to devastating outcomes that are plain as day after the fact. Yet as we established in the prior section, there are objective characteristics of good governance: set expectations, invest authority, and validate results. And there is research to suggest that the presence of these have a significant impact on bottom-line results.

In a study of 1,500 companies by Harvard professor Paul Gompers, well governed organizations outperformed poorly governed ones by 8.5% annually. “Well governed companies face the same kind of market and competitor risks as everybody else, but the chance of an implosion … by ineffective management is way less.”

-- Gavin Anderson, Chairman, Governance Metrics International

Good governance reduces risk of bad things happening, and there is reason to believe it is a contributing factor to superior performance

Just as a corporation is an investment of capital, so, too, is strategic software. What is true for a company at a macro level should be true at a micro level. The characteristics of good corporate governance should be present in IT governance: an independent board that sets expectations, chooses and changes leadership as necessary, and validates results reported by that leadership.

Activist Investing in Strategic Software

A few years ago, I felt I had enough experience - and had put enough thought into the subject - to write a book on governance in software development. I had observed that most tech firms and captive IT organizations are largely left to self-govern, and both are pretty light touch about it. I had also observed that governance is widely misunderstood and the term is used in technology in a lot of different ways, almost universally incorrectly. With more ambitious investments being made in software and the success rate of large projects not getting all that much better, the need for better governance was there. Plus, it seemed to me that if IT didn't get its act together soon enough, the CFOs of the world were going to get IT's act together for it, so it also made sense to write it from a bit more of a financial rather than an operations perspective.

The timing was good, too, because the prior decade had given us some very well documented examples of egregiously bad corporate governance, ranging from isolated cases of accounting fraud (Worldcom and Parmalat) to the near-collapse of the banking industry that resulted from so many firms taking too much risk onto their balance sheets, their boards having absolutely no idea they had done so. There was some nascent research suggesting that good governance has a measurably positive impact on business outcomes, and also that "activist investors" - people who force their way onto the board of a company to agitate for change - were by and large net positive to a business. All together, we had great examples of how not to govern as well as behaviors we could use as a standard to define what governance really means - practiced or otherwise - in software development.

Within a couple of years, I had written enough material to compose a draft. Then I took a hiatus from it.

In the years since I wrote the first draft, a tension has developed between advocates of "innovation" and champions of "scale" in software development. In one corner are the enterprise development people who say control over operations yields predictable results. In the other are the lean startup people who say that discipline in execution twined with feedback loops is control enough, so just let people go on voyages of discovery and you'll have far better business results. The control camp claims that innovation is possible in their way because it embraces Agile (evidently, all you need are "innovation sprints"). The lean camp claims they can scale to the size of a large business (which may be true, but they're light on practical details). Both say they can revolutionize business itself.

But both camps take an execution (that is, operations) perspective. Execution is important, but if we're going to make organizational impact, we have to do it from a financial, not an operational, perspective. Operations are cost. Investments are value. To change the business of software, we have to speak the language and act the part of the latter. It doesn't matter how revolutionary or how beneficial a different way of delivering software can be to a company: nothing that comes out of either camp is going to cause the authors of Fundamental Accounting Principles to overhaul their text.

I am once again writing the book. I will publish it iteratively. It is still early days - no cover art, not much of a landing page.

But today, the first draft of the first chapters of my book, Activist Investing in Strategic Software, is available on Leanpub.

Matrix IT Organizations, Part I: Turtles all the way Down

Multiple layers of authority overlap both horizontally (different people and committees engage with the same issue) and vertically (many decisions are liable to review by some other body). The lack of focus in decision making results in an absence of executive authority; while professional management is subject to random amateur interference. In consequence, able people are not easily attracted to management roles; and so the amateurs view the professionals with often justified and frequently reciprocated contempt.

-- John Kay, How a proud corporate history can lead to poor governance

A business has many sub-organizations. They may be functional (sales, accounting, etc.) or regional (EMEA, Americas, etc.), or specialized (e.g., product). A company may consist of all three: regional sales and marketing teams, working with multiple product teams, all of whom share corporate-level finance and legal. We want the organization structure to balance customer service with operating efficiency: completely autonomous divisions offer high customer service at a cost to our customers or to our profitability, while completely silo'd organizations squeeze every penny of efficiency at a cost to customer service. Competitive customer service at the lowest cost of execution lies somewhere in between these extremes.

Captive IT faces the same challenge as the rest of the business: organize to provide the greatest level of service while containing costs. IT generally organizes around technical roles: we have infrastructure people, database people, helpdesk people, software development people, and so forth. We also have specializations therein: we have ERP developers, who are not the same as our front-end developers, who are not the same as our legacy system developers. And none of them are quite the same as our QA people.

These sub-specializations are fairly well entrenched because career path is generally associated with role, and even specific technologies. For one thing, deeper expertise in a narrow set of technologies will command a higher salary than shallow expertise in a wide range of technologies. For another, a manager is unlikely to promote a promising member of the web development team to be tech lead of an ERP team because the technical knowledge is not transferable.

IT leaders structure their organizational hierarchy with this in mind. For utility functions, this works just fine: provisioning hardware and e-mail accounts is the same no matter who the user is. But in strategic software development, the business domain influences technical implementation, so IT needs tighter alignment with the business. The specialist IT structure is mapped to more granular business customers in a matrix: we form delivery teams to support a business line or a specific product owned by the business, but each team's tech lead reports to a VP of engineering within the tech organization.

Like everybody else, IT is under cost pressure. The greater the pressure, the more likely IT leadership is to make something into a shared service, which translates into fewer people owning multiple responsibilities for multiple teams. Quality assurance, project management, and techops, for example, can provide greater service when paired with a business partner, but become organizations unto themselves (with fewer staff) as a means of creating cost efficiencies.¹

From an organizational perspective, this makes things somewhat untidy within IT because we have a matrix (shared services) within a matrix (development teams organized by business line, but reporting up to an engineering leader). If there is a shared service within a shared service, such as DBAs being part of techops, we have a matrix within a matrix within a matrix. It's turtles, all the way down.

Add to this the recent phenomenon of product organizations. A product hierarchy - common but by no means exclusive to tech firms - is chartered to elevate users (people who use the software) and customers (those who pay the bills for those who use the software) in ways that subject matter experts and software engineers are not able to. As the proxy for consumers and buyers, they influence priorities and packages of functionality. But product owners don't necessarily have strong footing in either the business domain or software development. In practice, they act as a referee between SMEs and engineers. At best they're an emerging function clawing at opportunity from a different perspective; at worst they're another level of intermediation in the decision making process.

And so we have the situation described above by John Kay: no small number of people being brought to bear on a problem, but a structural inability to get results.

With no defined power structure, the vacuum is filled by people who turn non-executive roles into a near full-time occupation. [...] Petty politicians enjoy the feeling of being at the centre and jostle for power; the power they seek is not the ability to get things done but the negative power that comes from “no decision without me”. Secrecy about matters of no significance bolsters their sense of self-importance.

-- Ibid.

Instead of better business alignment, we have fragmented ownership and competing priorities and agendas. Matrices create, rather than alleviate, impediments to getting things done.

In Part II, we'll look at executive disenfranchisement in the matrix organization.

 

¹ It's worth noting that the decision to make something a shared service is frequently justified as a means of promoting "best practices". Functions like QA or devops that are fragmented into separate product teams will show inconsistent performance; consolidating them into a single function should, in theory, be a step toward making them more consistent (ignorant of technical, asset or personnel restrictions on that). The irony is that somehow, "best practices" - whatever that's supposed to mean - will compensate for the fact that a critical function is deliberately being starved of investment.