I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Thursday, September 30, 2021

The Manager-Leader versus the Manager-Administrator

We saw last month that just because somebody is the manager of an Agile team does not make that person an Agile manager. The Agile manager does specific things: advances the understanding of the domain, has a symbiotic relationship with the do-ers, creates and adjusts the processes and social systems, and protects the team’s execution. By virtue of doing these things, the Agile manager is a leader, whereas the traditional manager is just an administrator.

I have been fortunate to watch the rise of Agile competencies over the last two decades. I have been less fortunate to watch Agile management competencies erode as Agile has spread in popularity. Although there are undoubtedly numerous reasons why, one immediately stands out: while the value system that underlies the behaviors described in the previous post is highly compatible with the creative company mindset, it is highly incompatible with the operating company mindset.

The creative company - e.g., a studio that yields original work, anything from entertainments to custom software assets - benefits from how much it exposes itself to environmental uncertainty and how effectively it internalizes relevant learnings from it to create a successful, if unique and one-off, solution. In contrast, the operating company - a firm that mass produces products or provides mass volumes of labor to deliver solutions - benefits from environmental certainty that allow it to apply patterns that create consistency enabling repeatable solutions at scale. The greater the consistency, the greater the automation, the lower the labor proficiency level required, the lower the cost of execution, the higher the margin and cash flow. Whereas the creative studio model thrives on chaos, the operating company thrives on consistency.

This is a tectonic fault line in the application of Agile management practices. When Agile is brought to bear in an operating company context with an overriding mission to provide consistency of outcomes, the value system that fosters the management behaviors that get things done through people in the face of a volatile set of circumstances is simply ignored. The words remain - adaptive planning, continuous feedback, and the like - but the values that give rise to them in the first place simply dissipate.

The presence of Agile terminology twined with the absence of the Agile value system gives license to people in management roles to do pretty much anything under the aegis of “being agile”. Take “adaptive planning”. In practice, “adaptive” is used to mean anything on a spectrum from no management and no plan (“we’ll figure it out as we go, on somebody else’s dime”) to dictatorial management-by-plan (“the team is free to meet the commitments they make during the planning exercise.”) Planning itself is an exercise in plausible deniability for managers: if the do-ers create the plan, management is the act of holding people accountable for the plan they came up with, not for the continuous adjustment of the plan or refinement of the business outcomes in the face of what is learned through execution. And reporting against a plan is somewhat perversely passed off as “governance”, itself an overloaded term with no actual meaning beyond “fancy word for management reporting.”

The net result is that managers of Agile teams have found ways to make themselves passengers in Agile teams because they only do administrative, communication, and reporting tasks. Former IBM CEO Lou Gerstner referred to these kinds of managers as “presiders”. Mr. Gerstner deemed presiders to be useless. Do-ers in Agile teams deem presides to be useless as well.

I wrote a decade ago that Agile gets corrupted when it goes corporate. That phenomenon is not unique to Agile, of course. By way of example, look at cloud computing: who knew that “migrating to the cloud” was as simple as moving a data center from owned on-prem to leased in somebody else’s facility? Yes, people still pass this off as “cloud migration”. Enterprise scale, enterprise politics and enterprise vendors have a tendency to dilute concepts - cloud, Agile, you name it - to a point of rendering them inert. ‘Twas ever thus.

Yet while Agile concepts are bound to be co-opted, this does not have to be the case for Agile execution. Managers can choose to be drivers of outcomes rather than plans, work with the team rather than outside of it, create social systems rather than schedule meetings, and protect the team’s execution from external forces rather than allowing them to steamroll the team. These, among other things too numerous to list here, define excellence in management.

Pursuing excellence is a choice that always rests with practitioners. There is a reason why the administrative burden of Agile has always been defined as “lightweight”, and isn’t to ease the workload of managers: it is to give managers the bandwidth to take a leadership role in a peer relationship with engineers, designers, analysts, and all the other do-ers in a team. That door is always open to managers in an Agile team, but the decision to walk through it or not rests with the individual manager.

Choose wisely.

Tuesday, August 31, 2021

What, Exactly, Is Agile Management?

Engineers have long had a poor relationship with managers. There are the stories long told of engineers unconstrained by management executing high stakes skunkworks projects, or more modestly using guerilla tactics to sneak unauthorized features into products that delight users. There are popular caricatures such as the pointy-haired manager in Dilbert, or Ford Motor’s management as portrayed in the movie Ford v Ferrari. Historically, management has never been loved, and in fact is often loathed, by engineers.

This all seems different in Agile. Management appears to be well integrated in Agile teams, not an overhead, nuisance, or encumbrance as it is in traditional project management. If we accept the fact that Agile is a value system and not a set of mechanical processes, it stands to reason that there must be something different about the norms and behaviors of Agile managers vis-a-vis traditional managers. What is it that makes Agile management different from traditional management?

A good place to start is by looking at the fundamentals of Agile team dynamics. First and foremost, as Paul Hammant is fond of saying, there are no passengers in an Agile team.

An Agile story is an expression of end-to-end business need. Although completing a story may require contribution from people in different roles - QA analyst and developer and experience designer, for example - each person is still responsible for the entire outcome of the story. Each person is responsible for the outcome because team performance is measured on collective output (specifically, stories in production) as opposed to the sum of individual output (tasks completed by individuals). Every member creates the most comprehensive understanding they can of each story, which they express both through artifact (story narrative or code for example) and collaboration with other team members (story walkthroughs and desk checks). A person driving goals orthogonal to the team goal, or not driving at all, does not last for very long in an Agile team.

A less charitable corollary to Paul’s statement is that nobody can hide in an agile team. What every person does and how they do it is fully exposed to every other member of the team. This is why safety is a key characteristic of an Agile team: by making it safe for any person to admit they don’t know how to do something, it is easier for the team to collectively adapt and make the most of the strengths of the people it has. It does mean, however, that mismatches - people who overstate their skills and competencies - will be exposed very quickly.

Combined, this means that no individual can phone it in. One person who does a substandard job affects the performance of the entire team. Consider a team using story narratives to surface complexities in business requirements. A business analyst who consistently does a lackadaisical job will effectively export the analyst responsibilities to a developer. Developer productivity - and therefore story card throughput - will suffer as developers compensate for substandard analysis work.

The obvious conclusions are (a) every individual drives to the collective output of the team; (b) every individual must strive to perform a high state of excellence; and (c) a team cannot maintain a level of performance any higher than the level of excellence achieved by its weakest performing member.

For people working in roles directly related to creation and evolution of a software asset - experience designers, developers, QA analysts - this is easy to understand. We all understand the consequences to an Agile team trying to compensate for inadequate design artifacts, vague requirements, poor quality code, and ineffective tests: rework cycles, additional handoffs, and poor quality, among other things.

But what do these three things - drive, excellence, and minimum collective effectiveness - mean for people in management roles?

I was fortunate to have worked with very strong Project Managers in my early Agile projects, people who understood the Agile value system and knew how to apply it as managers in a delivery team context. They all had characteristics that are applicable to all management roles. Among them:

  1. Managers advance the understanding of the problem / opportunity / solution domain. The best Agile managers are outstanding at scope definition and scope control. They do this by intelligently questioning different people in the team: business partners to ascertain what is truly important to the near-term business goals and is not, developers to ascertain what is tech goldplating and what is not, product managers on how can a story be split and part of it deprioritized, and so forth. It’s worth noting that codified accounting standards treat managers as overheads, for the simple reason that management is largely administrative work. By demonstrably working the details, some portion of an Agile manager's time is spent genuinely advancing the understanding of the problem/solution domain as part of a team collective. For this reason, a portion of an Agile project manager’s time can be capitalized, unlike traditional project managers who are purely expense. Traditional PMs create project plans, staffing plans and reports, schedule meetings and facilitate ceremonies. All useful, but not directly contributory to the technology asset itself. The difference is that the Agile project manager is hands-on with the problem and not simply performing tasks of administrative convenience - contracts, meetings, project plans - on the periphery of those hands on with the problem.

    It’s worth pointing out that this doesn’t happen by accident. Previous experience in a do-er role such as business analyst or developer certainly helps the manager to know the types of questions that need to be asked. But the key characteristic is both the ability and willingness to immerse and comprehend the details of the stories, the architecture, the code, the design, the tests. Good managers know how to work the problem and solution space. This applies to all levels of management, because “ground truths” always triumph over abstractions, right up to CEO and activist investor. Conversely, the manager who lacks the will or skill to internalize a domain is completely beholden to (and subsequently held hostage or simply played by) those in the team who do. This manager is the textbook definition of “overhead.”

  2. A symbiotic relationship with the do-ers in the team. PMs have to provide a variety of status reports to various sponsors and buyers. In the early days of Agile development, there were all kinds of new and novel measures: velocity for measuring throughput of stories, load factor for assessing the actual capacity available to the team, story points (or equivalent) for measuring relative story sizes, and many more. It was easy - and very satisfying - to nerd out on the management metrics, creating forecasts of scope expansion and capacity and so forth. But one thing that distinguishes the Agile manager from the traditional manager is that the team drives the metrics. The metrics are only very rarely used to drive the team. The Agile manager uses the metrics to detect a change in the situation such as domain complexity that was not previously understood, or team member skill that was over- or under-stated. Project management metrics are used by managers to ask “what has changed”, not “why are we off plan”. The objective of the Agile metrics has never been to keep the team on a plan and held to a plan. The objective of the Agile metrics is to increase the understanding of how execution is unfolding and make the necessary adjustments in one of the four variables - time, scope, capacity or quality - to respond. That’s a big difference between traditional project management and Agile project management.

    Metrics being all the rage among the management class these days, this bears a bit of analysis. Of course there are instances where metrics are used to drive the team, such as when three of the project management variables - time, scope and quality - require compensation from the fourth - capacity. By way of example, when the number of sev 2 and 3 defects escaping to production rises a bit - not unsustainable or threatening, just something that stands out - while the team focus is still on new story development, it isn’t uncommon to ask everybody in the team to try to resolve one defect every day before finishing up. True, in this case a rise in defects exposes something about how execution is unfolding, and the team needs to adapt (put in a little additional time to address quality). But in practice, this is an instance where the metrics are used to drive the team (e.g., to maintain story velocity while paying down defects), if for no other reason than the optics of few defects to go along with story throughput puts stakeholder minds at ease.

    The same nuance applies to measuring story throughput. A release plan that slots specific stories for specific future iterations sounds like a fixed delivery plan, but when scope and time are the priorities this is a reasonable exercise. It helps to answer the “will the team make it“ question, and as long as capacity and quality variables can be relaxed it is a way of depicting scenarios and anticipating responses. However, when stories are slotted to future iterations and all 4 variables are held constant by the manager, we no longer have Agile project management, we have traditional project management that has co-opted Agile terms in the pursuit of control. Obviously, this is not Agile.

    The four variables combined with appropriate interpretation and application of the metrics enable the manager to have a symbiotic relationship with executors. This manager is an Agile manager. However, when the metrics themselves are used as drivers, management has a one-way relationship with do-ers. This manager is a tyrant.

  3. Create and adapt the mechanical processes and social systems through which the team gets things done. Roy Sigham, the founder of ThoughtWorks, used to refer to the company as a “social experiment.” All teams are social experiments, random strangers brought together in combinations of varying skills, capabilities and personalities. There will be tension and conflict. There will be misrepresentations and misunderstandings. There will be volatility.

    Traditional project managers reach for plans against which they can hold people accountable. But this is not how managers fulfill their primary duty of “getting things done through people.” A high EQ allows a manager to recognize how people interact with one another. Professional experience allows the manager to recognize the skills people have and aspire to have and will never have. These and other factors let the manager create the circumstances for the right type of interactions and format - workshop, fishbowl, small group exercise, etc. - for the right subject in the right sequence at the right time to enable the team to get things done. Among other things, this takes listening and observation skills, the ability to design the mechanics and visualize how various activities will go, plus the ability to prioritize, facilitate, coach and intervene. This is management. This is how managers “get things done through people.” People who manage a plan are curators of documentation, not managers of a team of people.

  4. Protect the execution of the team. Creating a functional team is one thing. Protecting the team’s execution is entirely another. There are constant challenges to the integrity of the workings of a team. People ghosted to work on multiple teams (a “10% allocation” of a person’s time to a team is utterly meaningless). Stakeholders with differing and highly volatile priorities. Fear - or just tepid commitment - to an Agile way of working. Corporate politics. Low trust corporate cultures. The Agile manager manages upwards and outwards, keeping these threats and many others at bay, preventing them from invading the team.

    There are times when external forces must invade the team, such as changing stakeholder priorities. The Agile manager creates a constructive framework and mechanical process for the team to ingest and respond to things that cannot be deflected without creating chaos with how the do-ers are otherwise do-ing. The manager who does not protect the execution of the team from external drama is a puppet to any and all external stakeholder.

I wrote above that each person in an Agile team drives to the team outcome; that each person must strive to achieve excellence; and that the team will move only as effectively as their weakest performing member. We’ll look at patterns and antipatterns of management behavior in the next post.

Saturday, July 31, 2021

What Can You Do With Less?

In the heady days of the dot-com boom, it became common for investors to challenge would-be entrepreneurs with the question, “what can you do with more?” To the aspirant (and typically struggling) startup, the question was profound, if for no other reason than they were buried in the realities of trying to keep their own narrow universe from imploding on itself.

The question is still asked today, just in different ways. For example, the Wall Street Journal recently profiled the relationship between Masayoshi Son of Softbank and Adam Newmann of WeWork, specifically how Mr. Son prodded Mr. Newmann to pursue ever more ambitious goals in 2018. That ambition culminated in a goal for WeWork to grow revenue from $2b to over $350b in 5 years (making it larger than Apple), a mooted valuation of $10t (making it equal to about 1/3rd the total market valuation of all US equities), and a pitch for $70b in financing. It was certainly more; although, what actually followed was certainly less.

While the question remains the same, the question behind the question is not. A quarter of a century ago, it wasn’t clear what tech companies would succeed, and what success would look like, if in fact any would succeed at all. Spending more in the pursuit of success was a way to have less dependency on serendipitous technology and market phenomenon in the pursuit of what everybody knew was the future. Owning more of the value chain, spending more on marketing and awareness campaigns, signing up more partners, and so forth were ways to project influence over the things out of one company’s direct control. From a finance perspective, this was small beer: the price to try everything and fail wasn’t a whole lot more than the price to try a few things and fail.

Today, if every business must be a digital business, the question of success or even survival is not what is being put to the test. Instead, it is a test of one’s of ambition: if the future of [insert your industry name here] is digital, the question isn’t whether [insert your digital strategy here] has the potential to succeed or not, but whether it will become the dominant digital path in its industry or just an also ran that becomes a footnote in history. You must think bigger than a digital strategy: what are you going to do to impose your vision of the future on the commercial and non-commercial ecosystems relevant to your future? “What could you do with more?”

In rapidly growing markets, there is some wisdom in this. Industry lifecycles are characterized by relatively short periods of rapid growth pursued by hundreds of equity financed competitors that are followed by long periods of slow growth dominated by a handful of oligopolistic market participants sucking cash flow from operations to service debt, finance buybacks and pay dividends. An overwhelming majority of the small competitors that exist during the rapid growth phase won’t survive and the small ones that do won’t matter much. As Larry Ellison pointed out years ago, “The No. 1 software company in every segment makes all the money. We never buy anything where it doesn‟t put us in the No. 1 position or get us in such a strong No. 2 position that we think we can get to No. 1 very quickly.” When a clear market opportunity emerges, the stakes are very high indeed.

Of course, not all tech is about potential for world domination. Sometimes it is about utility. Utilities - think electricity, water, and the like - are taxes on a business. As we saw a couple of months ago, one of the overriding questions that dogs utility tech investments is, “do we have to do it now?” Another is, “what could you do with less?”

This latter question can be responded to as an appeal to value more than to cost. Even within the most mundane of utility tech opportunities are innovations, sometimes small, but innovations nonetheless that are legitimate sources of value. While many (if not most) utility tech investments will never have a comprehensive value proposition, often they can be unpacked so that the utility investment can lead with value realization. Decoupling legacy technologies through APIs and abstraction layers allows for creativity not just in how utility tech is delivered, but how fundamental business problems can be solved. When successful, a utility tech investment can be reframed from a single all-in commitment to a series of investment tranches that deliver both near-term value and long-term utility. When we do this type of analysis, we very often find there is quite a lot that can be done with less.

This draws a great deal of ire, of course. Enterprise IT doesn’t much like requesting a little more funding for the same initiative year after year after year, much less the specter of a long-lived hybrid tech landscape resulting from only partial modernization. Tech vendors prefer large commitments from their customers before they will offer discounts or commit top people. And, this appears to legitimize the lack of confidence that corporate capital allocators have in an IT function’s competency.

But when the relationship between enterprise IT and the rest of the business is characterized by low trust - still all too common to this day - it behooves IT to meet the trust deficit head on. Doing so demonstrates good stewardship of capital and provides transparency into why and how IT spends that capital. It also makes utility tech spend far less self-referential (I still see “we’re moving to the cloud because the cloud is better” as a business case justification) and far more aligned with business goals. And leading with value while asking for tranches of “less” is not an acknowledgement that IT isn’t trustworthy as much as it insists on a high-trust partnership with business and IT on achieving the outcomes. IT doesn’t get a blank check to do tech things, but then neither does the business get anything it might ever want. Both are equal partners in shared outcomes, and partnerships cannot function without trust.

“What can we do with less?” is a good question to ask. Because sometimes, less really is more.

Wednesday, June 30, 2021

Labor's New Deal

The pandemic has created a lot of interesting labor market dynamics, hasn’t it? Week after week brings a new wave of employee survey results that make it clear a lot of workers want to retain a great deal of the location independence they have experienced over the past year. Multiple studies report roughly the same results among knowledge workers, globally: 75% want flexibility in where they work, 30% don’t want to return to an office, and 1 in 3 won’t work for an employer that requires them to be on site full time. In addition, 1 in 5 workers expect to be with a different company in the next year, as many as 40% are thinking about quitting and over half are willing to listen to offers.

This isn’t just sentiment: employees are voting with their feet. The Wall Street Journal reported a few weeks ago that the share of the workforce leaving their jobs is the highest it has been in over twenty years.

Labor wants a new pact.

The post-COVID recovery is a once-in-a-decade economic recovery. To the extent that a company’s growth is indexed to the growth of its labor force (where near-term automation is not an option), a company has to hire. If it doesn’t, it’s going to sit out this recovery. That means businesses are motivated buyers of labor.

The American economy is surging, but employers are struggling to fill skilled and unskilled positions alike. One factor is the absence of slack in the labor market. Curiously, the labor participation rate is plumbing levels not seen since the 1970s. The number of 18 to 65 year olds actively working has been in steady decline since the mid-2000s, a few years before the 2008 financial crisis. It dropped significantly again with the pandemic, and has not yet recovered to pre-pandemic levels. Statistically, there should be labor market slack, but there is no slack as quite a few working age people are electing not to rejoin the workforce. Another factor is that with every company hiring it’s hard for any one employer to achieve visibility among job seekers. A simple search for “product manager” positions in Chicago yields over 6,300 openings; in New York over 6,800 openings; and in Dallas over 5,800 openings. Social media banners announcing “we’re hiring” are useless when every company is hiring.

Labor market tightness and difficulty in differentiating is forcing companies to raise wages. Large, deep-pocketed employers of unskilled labor including WalMart, McDonalds and Amazon have raised their entry level labor wages. Mid-tier and mom-and-pop competitors will be forced to do the same. And, many employers are responding to their own captive surveys yielding results like those mentioned above, offering greater workplace and working hour flexibility to existing staff and recruits. Average wages are going up, and workplace policies are changing to be more accommodative to labor.

With labor tight and economic expansion all around, employers will become increasingly competitive for labor. They will have to be aggressive just to stay in place. Imagine a company with, say, 100 experienced software engineers, project managers, QA engineers and the like that expects to add a dozen more people to the team in the next year. If they lose 20% of this knowledge workforce per the survey results, and assuming 10% of the people they put on the payroll are dud hires, they’ll have to hire upwards of 35 people to achieve a net gain of just 12.

All of this means that labor is having a once-in-a-generation moment.

Labor's power in America arguably peaked in the 1960s and has been on the wane since, the striking Air Traffic Controllers getting fired in the early 80s often held out as a seminal moment in labor's multi-decade decline. But some of you may recall that in the late 1990s, labor briefly had a moment. That was not only the go-go days of the dot-com era, but domestic US call centers were going up in all kinds of American cities, big box retailers wanted their customers to know they were "always open" and kept stores open for 24 hours a day (somebody just might be itching to buy a circular saw at 2a), and fast food drive thrus were kept open 2 hours longer than the dining rooms (conveniently, 'til after the pubs closed). For a brief period, "Sales Associate" positions came with medical and retirement benefits. Well, labor is back. The WSJ made the point last week that labor has power today that it has not enjoyed in decades. And, per the aforementioned statistics, labor is exercising that power.

With so much agitation among workers and demand for labor high, conditions are ripe for labor market “disruptors”. Some employers will simply become very aggressive recruiters of employees of other firms. If disruptive recruiting, employment and retention practices prove successful, we will see winners and losers emerge in “the war for talent.” And it isn’t start up or fringe firms taking aggressive postures. According to the WSJ, Allstate has determined that 75% of the positions they employ can be done remotely, while another 24% can be done in a hybrid fashion. That’s 99% of a traditional employer’s workforce that will have location flexibility. This means location independence may not be a worker bonus as much as it may simply be the new norm. It also means that a company may not simply struggle to hire, but that a failure to adequately adjust to the future of work will make a company vulnerable to disruption as its work force is an easy target for other employers.

History tells us that labor’s moment may not last for very long. But the longer that labor shortages last, and particularly with so much competition for knowledge workers, labor won’t come away empty handed.

Monday, May 31, 2021

Is There a Business Case for Utility Tech Investments?

Last year I wrote a piece on legacy modernization initiatives. Among the points I made was that legacy modernization is at best a break-even proposition: modernization is simply trading something old for its modern counterpart, getting the same capabilities in return. Of course, there are first order benefits to legacy modernization. Additional or more comprehensive capabilities that come standard with a new COTS product; lower labor intensity and less dependency on costly knowledge workers required to sustain legacy assets; and reducing systemic fragility (e.g., production downtime) are all very real economic benefits that have P&L impact. But by and large, these benefits at best cover the costs for a modernization effort: the new assets will come with a cost to acquire and customize, a cost to migrate, a cost to integrate with other systems, and annual costs to maintain, support and evolve. Software ain’t cheap to buy, implement and live with.

But one thing I did not point out in last year’s blog is that a legacy modernization - even a sweeping one - falls into the category of utility tech not value-generative tech.

A value-generative investment is a roll of the dice that, say, a new market opportunity can be developed or a cost efficiency can be made where none was possible before. There is some uncertainty whether a market opportunity can be converted or a cost efficiency can be realized because of factors outside of anybody’s control: that buyers will see the company as a provider of a new category service it has never offered before, that a problem space is sufficiently consistent enough to allow for systemic improvements, that the technology exists to perform the task in the environments and conditions where it must perform, and so on. A value-generative investment is the pursuit of something that may not have been necessary or possible, and therefore could not have been done before. A value-generative investment is an exercise in deploying risk capital through IT in the pursuit of extraordinary benefit that yields competitive advantage.

This does not describe legacy modernization. Investments in utility capabilities are the pursuit of improvements in the way things are done, because at present they are inadequate by contemporary standards. The risks in a legacy modernization investment are entirely to do with execution of the investment itself, not how well the investment performs post-production. For legacy modernization benefits to be realized, the assets must be built to be reliable and low-maintenance; and customization, conversion and cutover costs must not spiral out of control. The proximate causes for utility investment failure are all within the confines of the execution of the investment itself: that the people doing the work are competent in the domain and technologies; that there is low staff turnover for the duration; that the team is not creating an entire project phase of execution (in the form of unanticipated late-stage integration and testing) to solve problems entirely of its own making; and so forth. True, there are unknowns in the business domain and in the legacy systems, and such uncertainty does create the risk for costs to increase. However, uncertainty of this kind is generally covered by cost contingency in the investment proposal. Even in the extreme cases where legacy assets are completely unmaintainable, legacy system modernization is still the replacement of one known domain of capabilities with another.

The nature of the uncertainty in the investment matters because it changes the nature of the capital allocation question put to an investment committee. For value-generative investments, the investment committee is asked whether it wants to gamble some of the firm’s capital in the uncertain pursuit of extraordinary benefit. By and large, only the investment capital itself is at risk, because an investment committee can terminate an underperforming value-generative investment with little reputational and operational blowback. However, for utility investments, the investment committee is asked whether it wants to tie up corporate capital for an extended period of time to improve the quality of services within the firm. Utility investments tend to be all-in commitments, so the investment committee is also underwriting the risk that additional capital will be necessary and that it will be tied up for a longer period of time to make good on the modernization investment.

Hence these are two very different types of capital allocation. One is to bet some pocket change at a casino table with something less than 100% expectation of a full payoff, and perhaps any payoff at all. The other is to prepay for two years for a health club membership in the anticipation that regularly using the health club will result in lower insurance premiums. In capital terms, the prior is equity, the latter is debt.

The justification for each investment is markedly different. The upside potential - however remote - for a value-generative pursuit will eclipse its cost. The upside potential for a utility pursuit will be break-even at best. Even the most thorough of cost-benefit analyses will not make a utility investment a no-brainer. Look, even a value-generative pursuit that fails yields a good story for the CEO to tell the board, provided it wasn’t an outsized gamble of scarce corporate funds. But many a C-level exec has been fired for cost overruns on utility investments.

A compelling value-generative tech proposal gets the investment committee to ask, “we accept the possibility, how probable is the payoff and how long is the window of opportunity?” Yet even the most compelling utility tech proposal gets the investment committee to ask, “we accept the need to do this, but do we have to do this right now?

The question that a cost-benefit analysis for a utility tech investment must frame is, “why should we do this right now?” We’ll look at what that analysis consists of in a future post.

Friday, April 30, 2021

Armchair Regulator

Bernie Madoff, one of the greatest financial fraudsters of all time, died earlier this month. That his was possibly the largest Ponzi scheme ever created a sense of history unfolding in front of our eyes as it was exposed in 2008. That his fraud was exposed at the height of the greatest economic crisis since 1929 gave the financial crisis a name and a face that the legions of bankers, politicians, Treasury and Fed officials could not. That this was a fraud hidden in plain sight for years, probably decades, that had duped so many cemented the popular impression that nobody had their hands on the wheel of the financial economy; it was a runaway train that spelled doom for its willing and unwilling passengers alike.

My interest in the Madoff fraud has always had little to do with the fraud itself or the context of the times, and more to do with the failure of regulators to detect and investigate Madoff’s activities. The regulatory lapses would be comical if their effects weren’t so tragic.

Through the eyes of regulatory practice, the Madoff fraud is a story of what regulators did not do. The SEC received a half-dozen detailed allegations about Madoff’s business over a 16 year span, allegations that the SEC either dismissed without investigation, or investigated in a half-hearted fashion. In light of what was ultimately learned, the latter are egregious lapses in regulatory conduct. SEC officials accepted implausible statements from Madoff as fact. They failed to perform the most rudimentary of independent research. To wit: a single call to the DTCC would have revealed Madoff hadn’t executed a trade in years.

From a regulatory perspective, the primary conclusions have been (a) shame on the SEC and (b) that regulators are not looking for fraud while it is happening, only describing it in detail once it has been exposed.

Yet there are deeper, personal, questions to reflect on.

The most popular - and the most useless - of these questions is whether or not you would have been a willing investor. The “would you have invested” question is useless in no small part because it implies that the victims are complicit in the perpetuation of the fraud by their own blind faith borne entirely of greed. And it is true that for decades, Madoff’s returns were outrageous and inexplicable by all standards, yet he persisted year after year after year, attracting new investors in his ever-growing Ponzi scheme. But if invited, coerced, hounded, and even shamed by people in your trust network, would you have put money in? Of course you would have. Very few individual investors have the sophistication and skepticism, let alone the cuts and bruises and calluses, of an institutional investor. Add the marketing that Madoff employed - personal relationships, exclusivity, secrecy, and the twisted implication that because the SEC had investigated his firm no less than six times and found nothing it was quite clearly legitimate - and the individual with capital to invest didn’t have much of a chance. As the 19th century sage PT Barnum pointed out, the coefficient of suckers to birth rates has always been nearly 1.0. Very few have special immunity.

The better questions have to do with how you would have behaved as a regulator. The popular posture toward the SEC is one of disappointment, that they failed the very investors they are paid to protect, that the institution itself is corrupted by regulatory capture. Yet had you been a SEC investigator, would you have recognized the impossibility of Madoff’s returns when presented with little more than other people’s theories? Would you have been diligent with inquiries after the boss told you to drop it? Would you even have been just a little bit more hygienically thorough?

Answer those questions in the context of business-as-usual at any regulatory agency. How understaffed is the SEC? How many plausible allegations of fraud is the SEC presented with each month? And the allegations they receive, are they truly the product of independent researchers seeking to right wrongs, or are they motivated by some nefarious intent such as professional jealousy? How does the SEC balance the quantity versus the quality of investigations they undertake? How routine do these investigations become to the investigators themselves? What makes any of us think we would not ourselves be burdened by these - and many, many more - factors in the disposition of our jobs as investigators? This line of questioning is not intended to suggest the SEC was not derelict in its duties, but to point out how difficult the job is.

If the regulatory failures surrounding Madoff are examples of bad governance, what does good look like? I have written elsewhere that we can take cues from the positive behaviors and actions of the activist investor playbook. But if the regulatory lapses in the Madoff case tell us anything, it is that a playbook is one thing, a persona is another. Dr. John Kay summed this up best when he described the person best suited to do this kind of job:

You require both an abrasive personality and considerable intellectual curiosity to do the job.

It is easy to criticize the regulators in hindsight from the comfort of one’s armchair. It is another to possess the personality traits, the discipline to know when to bring them to bear, and the energy to sustain them, in every situation every day in which we find ourselves.

Wednesday, March 31, 2021

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.