text:
tag:blogger.com,1999:blog-306218752019-01-31T21:47:01.766-06:00The Agile ManagerIT leadership, governance and management @ rosspettit.comRoss Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-6640390746514411472019-01-31T21:47:00.000-06:002019-01-31T21:47:01.734-06:00Enterprise Change is Leadership Change
From the COO's perspective, the corporate IT department has hit rock bottom and they keep digging. Very little gets deployed, and the software that does make it live is embarrassingly bad.

IT is not exactly a clean canvas. ERP, CRM, document management and other key systems started life as COTS products but have been configured beyond recognition to a point where they can't be upgraded, and they're so ancient they've been disavowed by their vendors. Adding insult to injury, we're sitting on decades worth of data, but can't point to a single insight we've ever gleaned from it. The COO is not going to be jockeying to get IT reporting up to him any time soon.

The CEO has all but lost patience. She can't understand why she gets the same dead-end answer of "legacy systems" when she asks the CIO "why do we have to spend so much on IT?", "why are our systems not in the cloud?", and "why aren't we mining our data?" The board is asking her these questions, and she's got to have answers, not the same excuse.

* * *

IT knows it has a lot of problems. More than a few believe that the way it works is a big part of reason why. Every delivery team is blocked for reasons of access, authorization, and answers it needs from armies of people spread across a myriad of IT functions. Organizationally, there are silos within silos and shared services within shared services. If teams could work more independently toward a goal they would get a lot more done.

Somebody gets the idea that maybe we can solve this through better process. If we were to adopt Agile we'd have control and predictability and quality and speed-to-market. If we reorganize into cross-functional product teams, we'd get better solutions and some real insights.

A pilot or two here, a consultant or two there, a few slide decks and a site visit to a respected technology firm, and it's decided: we have seen the future, and it works. We're going to change.

We're a large enterprise, so we need to roll out change at scale, and in a controlled manner. And so we get the enterprise Agile change program...

* * *

Over the years I've had the opportunity to examine several enterprise Agile change programs that are well under way. Those that were not living up to their initial fanfare (and quite a few of them were not) share a few common characteristics.

All organizational communication flows still go on one direction. The new "product operating model" bears striking resemblance to the old "program operating model": it moves from analysis to specification to development to deployment, all in a sequence of straight lines going left to right. There are no feedback loops anywhere in this cycle. As a result, there is no tolerance for team-level discovery let alone empowerment to act of its own accord on what it has discovered. Every team is free to build the product they were told to build. People are still bound to the plan, just like always.

Labor is assumed to be interchangeable. The Agile team model assumes there are no silos within a team: once a developer pair is free they take the next highest priority Story. But enterprise IT is loaded with specialist labor: this person only does front-end development, this person Java, this person Tibco, this person ABAP. Creating "cross-functional" teams doesn't cut it: the work distribution will be asymmetric and the team will lurch from blocker to blocker. It doesn't help that enterprise IT is also primarily staffed by contract labor. Contracting firms and their employees have incentives that favor labor specialization. The Agile operating model needs poly-skilled people, but enterprise IT doesn't have many people like that today and there are institutional headwinds against there being more of them tomorrow.

Process is the primary problem we face. No matter how collaborative and encompassing, a different mechanical process will not overcome the rot that plagues enterprise IT organizations: messy and multiple point-to-point integrations, a shortage of systemic knowledge, overloaded data structures, and poor data quality are not problems solved by a change in how work gets done. These problems are much larger than any one delivery team can possibly solve. Worse still, a process that requires a low-friction working environment to be successful doesn't stand much of a chance of taking root when the friction is very high.

As a result, enterprise Agile change programs don't make sense through an Agile lens, but they do make sense through a Waterfall lens. The change is largely cosmetic: Agile has just introduced surrogate terminology for how we've always done things. "Intake" and "portfolio management" are new words for "big up front design" and "detailed project plans" and rob the teams of functional discovery. Architecture activity that surfaces technical design before development robs the teams of technical discovery. Cross functional and even co-located teams can't solve the big problems mentioned above in data, dependencies and system knowledge. Our new process might make us a little better on the margins, but in the main we still have the same integration hell, the same usability shortfalls, the same systemic brittleness and the same quality problems that we always did. The result, as others have written, is Agile in name only.

All right, so top-down change risks getting neither the mechanics nor the values of Agile. Wouldn't a bottom-up change program be more values-centric? A couple of months ago I wrote that bottom-up change - that is, linear scaling of team-level phenomenon - is inadequate for enterprise needs because there are enterprise dynamics and challenges that do not exist at the team level. This means there are classes of need that a focus on team-level process misses entirely.

The answer is not simply "do both top-down and bottom-up at the same time". To change an enterprise requires a change in leadership, not process.

Top-down change must not be charged with trying to answer the questions that enterprise IT has always mistakenly thought it had to solve: those of predictability and control. The only valuable top-down change is cultural. Cultural change is a leadership problem, not a process problem.

If we care about feedback, then by definition we value learning over being right all the time. If we value learning, than our operating model needs to be a picture of knowledge acquisition and application, not a picture of output control. There need to be at least as many (if not more) arrows depicting communication flows going backwards as forwards in the process. More importantly, it must be clear how that feedback is internalized and acted upon in the operating model. In the absence of that, learning is at best an accidental curiosity.

But even cultural change is not enough. Devolving authority and creating a means for genuinely incorporating feedback to team level execution is useless unless people are able to do these things in an unencumbered fashion. That means acknowledging the ground truths of the state of our technology and staff, and taking deliberate action on them. This is not easy to do. Long-tenured people in the organization likely made decisions that contributed to the current state of affairs. It's humiliating for somebody to admit that "past them" contributed to the reality of "present dysfunction."

As hard as that is, acknowledgement only goes so far. As Lisa Simpson pointed out to Homer as he came face to face with the fact that he is a rageoholic, acknowledging the problem is the first step. Dispiriting for Homer, it is not the last step. Acknowledgement has to lead to action that reforms. Without definitive action and lasting commitment to that action, the learned helplessness that plagues organizations with these conditions will erode the will to change.

It's all well and good to champion process, and by looking at process we can understand how ineffective we are and what we can aspire to be. But process will not overcome years of bad choices that have infected our people, assets and data. Process change that ignores these problems or denies they are encumbrances will at best be rendered inert, at worst will result in giving people responsibility without authority.

Leadership is not asking one group of people to make good on another's bad choices. Leadership creates the conditions where the rank and file have a fighting chance. Process is part of that, but in enterprise IT with large legacy estates, process is rarely the primary solution.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-73760656609731415112018-12-31T19:16:00.000-06:002018-12-31T19:16:06.734-06:00I'll be Gone, You'll be Gone
The Financial Times recently ran a long article describing the breakdown of governance over the Crossrail development, the first new underground railway in London in over a century. Good governance is usually only appreciable by its absence, but the Crossrail case allows a before / after contrast between the presence of good and, after the sacking of a key board member, the presence of bad. Early on, "TFL's representative on the Crossrail board ... had kept a close eye on costs, and asked all 'the difficult questions' according to one individual close to the board". Yet after his departure, "It [the board] endorsed everything rather than challenging [management] and asking questions.". As a case study in governance, the FT article is an analysis very much worth reading.

The article also describes a nefarious management phenomenon common to complex, long-term investments: "And the management often doesn't care because they know they won't be there when the project isn't delivered on time and to budget."

I recently read John Kay's book Other People's Money: The Real Business of Finance. In Chapter 4, Dr. Kay describes the trading mentality that replaced that of stewardship across much of the banking sector from the 1980s onward. He introduces the subject using a quote from a senior industry figure: "''We are investment bankers. We don't care what happens in five years.'" The people who make the promises and ink the deal are not the people responsible for fulfilling the promises and seeing the deal through.

The FT article describes this phenomenon within Crossrail: "...like all long-term projects, it suffered from management changeovers at contractors and suppliers. 'You always have a lot of baton changes on large-scale projects like this... So although they will have been suppressing bad news, none of the people who were round the table at the beginning are still there - it's the nature of careers that no one stays for 10 years.'"

Or, as Dr. Kay put it, "Traders need not wait to see when or whether the profits materialise. I'll be gone, you'll be gone."

A little over a decade ago, a collapsing mortgage market in the United States metastasized into a global financial crisis when the value of complex structured products (think collateralized debt obligations backed by sub-prime mortgages) on bank balance sheets suddenly collapsed. Chuck Prince, CEO of Citigroup during the run-up to the global financial crisis of 2008, will forever be enshrined in the annals of finance history for his regrettable statement that 'as long as the music is playing, you've got to get up and dance.' "Soon after," writes Dr. Kay, "Prince was forced from office and Citigroup was bailed out by the US taxpayer."

Earlier this year, Crossrail development, which had appeared to be moving successfully along, fell off a financial cliff, requiring two capital injections in rapid succession, just so they could keep paying the bills. Per the FT: "'It feels as if they clung on to the schedule they had until it became clear that it absolutely couldn't be delivered,' he says. 'But when they dropped it, it seems that they had nothing left to work to. That would explain what looks like a sudden collapse.'" The chairman of Crossrail has been forced to resign (its chief executive having exited just before the bad news broke), and Crossrail has been bailed out by the UK taxpayer.

In the post-collapse analysis of financial crises, Dr. Kay points out that the principal actors are not particularly adept at critical self-assessment. "Rogue traders normally protest that the activity would eventually have been profitable if the bank had not closed its position, just as the gambler dragged home from the casino tells his wife and the world that he would have come out on top only if he had been allowed to stay longer." Additionally, the principal actors in the early stages - who are the primary beneficiaries of "cash borrowed from destiny with some random payback time" - have a tendency to deflect any doubts about the merits of the rewards they reaped in the time before the crash. "With the cognitive dissonance of the tailgater, he [Mozilo] would explain that the considerably larger amount he had received for his services as chief executive of Countrywide was justified by the profits that his company had reported from the sale of mortgages before the borrowers failed to pay them back." While deflection on the grounds that the collapse was episodic rather than systemic may be delusional, it is a convenient pound-the-fist-on-the-table argument to justify individual financial rewards of questionable merit.

In the banking sector, the problem was borne of a combination of the agency problem (the objectives of managers are materially divergent from those of the board) twined with moral hazard (no downside exposure to idiotic risks). It remains to be seen whether or not this proves to be the case with Crossrail. But with a management extracting high compensation derived from other people's money, a large number of contractors each working in a silo, an established pattern of suppressing bad news, and a forced buyer of last resort, Crossrail certainly appears to possess many of the same characteristics.

Per the FT, "People are always adventerous on costs and time because they don't want to tell the truth." The first and last line of defense against the agency problem and moral hazard is good governance. Poor governance plagued the banking sector in the years up to the 2008 financial crisis: few directors of financial institutions had any "sophisticated understanding of banking and risk", consisting as they did of "leading clients, ex-politicos and community leaders". Crossrail appears to have become plagued by the same, with one of it's principal stakeholders having the attitude of "'give him a call when it's time to cut the ribbon.'"

There is no easy fix to poor governance because governance tends to be self-referential among its members and lacking in tools for self-correction and continuous improvement. As Dr. Kay writes, "Their attitude was not the comprehensive immorality of the overt fraudster but the willful blindness of those who do not ask questions when it would be embarrassing, or at least inconvenient, to know the answer. Upton Sinclair's remark is again relevant: 'it is difficult to get a man to understand something, when his salary depends on his not understanding it.'"

Governance is only as effective as each governor, which is why I advocate for everybody in a governing role to study and practice the positive behaviors of activist investors. Given the variable - and generally poor - standard of governance in place over most investments, there needs to be a standard of excellence in governance practice. Activist investing is the closest thing we have to such a standard.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-89713615953607090892018-11-30T22:45:00.000-06:002018-11-30T22:45:19.459-06:00The Fallacy of Composition
That six month experiment with Agile practices yielded off-the-charts results in time-to-market with quality, as well as sponsor and user satisfaction. It cost a lot, but everybody is smitten, and word has gone round the company. Everyone wants to know: what was different? Well, everything: automated build pipelines, stories, stand-ups, showcases, spikes, desk checks, you name it. Ok, great. Let's make sure everybody in the organization is doing those things everywhere, all the time.

That "Agile pilot" was a deliberate investment in the formation of behaviors designed to yield local (that is, team-level) optimization. Sustained, intense concentration on collaboration among consumers, designers, builders, testers and managers resulted in more experiments, more builds, more deployments, and more frequent feedback. This resulted in not only a better software asset, but an outcome that everybody is emotionally invested in.

The immersive nature in which these new muscle memories were developed came at a cost. You took the flack for using unapproved tools. You paired up your staff, effectively doubling the size of the team and more than doubling the run rate. You had to deal with the daily drama of your employees coping with the muscle confusion of learning new ways of working as well as having to deal with strong consultant personalities. A long-time employee quit - and with him, years of tribal knowledge walked out the door - because he was demoralized by the experience. No one seems to remember that your business partner all but demanded that you to pull the plug on the entire exercise just a few weeks in. With success comes selective amnesia.

Still, it was a success, if a success on a small scale. The experience of success in the small makes us prone to gross misunderstanding of what success looks like in the large. It is easy to fall victim to the fallacy of composition: the inference of the properties of the whole from the properties of its parts. There are two obvious ways this manifests itself: in not being aware of characteristics of success at scale, and in not being aware of the characteristics of what it takes to scale it up.

A small product team with no external dependencies is a closed ecosystem, like a terrarium. A terrarium ecosystem is not particularly diverse, and any deficiencies are easily corrected through minor adjustments a manager can directly make through direct intervention. An enterprise-scale ecosystem has a geometrically larger number of dependencies and interactions; these are not very easily compensated for by management-level employees through direct intervention.

Success at scale requires understanding an organization as a whole, through different lenses. "How do we spread these practices throughout the organization" looks at mechanical activities that yield local (team-level) optimization in a fixed span of time. They make no provision for what happens at an organizational level over a long span of time: different parts of the organization will move at different speeds, held back by legacy constraints that are not so easily undone; inter-team and inter-organizational dependencies are not simply solved through wistful promises of "alignment"; people with scarce skill sets cannot be co-located with every delivery team that needs them; how hiring is done and who is hired will determine whether change is sustained and evolves; procurement practices that buy for unit cost optimization rather than outcomes reward vendors for the wrong behaviors; operating company norms that prioritize efficiency at the expense of learning will render feedback loops inert.

In failing to see the characteristics of the organization that are not present in the parts we are looking at, we are blind to the organizational phenomenon that will impair and ultimately reverse the benefits of change.

It is also important to recognize that the characteristics of change at large scale are not the same as the characteristics of change at small scale.

When answering "what is different", the rigor, discipline and commitment necessary to raise the bar tend not to be part of the answer. This separation of "ends" and "means" invites dilution of skill transfer and subsequently dilution of the skills themselves: coaching replaces immersion, decks and self-service wikis replace coaching. In addition, the implicit reduction of risk - having been "proven out" in a pilot, the practices must no longer require a heavy investment - recasts Agile as an operational problem rather than one of learning and growth. It's just a different process from what we follow today, right?

"What is feasible, or beneficial, in the small may be infeasible, or harmful, in the aggregate."1 Heavy investment in immersive activities at scale - in effect, making an investment to "push" change - is prohibitively expensive at enterprise scale. The sustained period of immersive skill development that was highly beneficial in a single team is infeasible at scale. Diluting change makes it outright harmful, as it can yield false positives of everything from collaboration to quality. That whole "we're going Agile" thing will become a thin veneer over the chronic problems that plague your organization, and once that happens something that could be of genuine benefit is corrupted to a point of uselessness.

The failure to recognize that an enterprise is a geometric rather than a linear degree of difference from a single team dooms a lot of well intentioned change programs. We also see the effect in maturity models and enterprise frameworks that are precise at atomic levels of change but vague or misleading at organizational levels of change. We'll look at the latter in a future post.
 1 Kay, John. Other People's Money: The Real Business of Finance.Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-40125504279314726492018-10-31T23:10:00.000-05:002018-10-31T23:10:06.615-05:00Everyone a Beginner?
I had an exchange with Dan North about the subject I wrote about last month, Beginner's Mind. Dan asked an interesting question: what would it take to make work like this every day for everyone, everywhere?

It's a serious question that deserves serious consideration.

To start, it's worth asking: why isn't work like this today, every day, for everyone, everywhere?

There is a difference between development companies (or divisions within companies) and operating companies. A development company is in the invention or innovation business. Investors and customers place high value on seeing something new, be it features or entirely new products. There is a high tolerance for operational inconsistency from a development company. Recall of how tolerant (or at least, how much less snarky) people were towards Windows when Windows 95 was launched, or the iPhone when the 3GS was launched.

An operating company is in the consistency business. Investors and customers place high value on efficiency and reliability. There is low value in seeing something new as it interferes with set patterns and expectations. There is low tolerance for operational inconsistency. To wit: the ribbon interface that replaced the command menus in Microsoft Office 2007 was not met with enthusiasm.

A company can be both a development company and an operating company. For example, Tesla. Inventing battery technologies and designing cars that are sufficiently different from the cars anybody else has made captures the imagination of financier and customer alike. But they have struggled at the basics of manufacturing things at a modest scale. Manufacturing cars is a path well trod, so nobody places a lot of value on Tesla employees learning things already very well known by people in the auto industry.

There is still room for engaged employees in both development and operating companies, but there is a difference in the nature of their engagement. We want passionate people in the development company, people who will look for ways to deliver value where there was none before. But we don't really want passionate people in utility-type businesses: the passionate accountant who finds ways he believes his clients can dodge the taxman is not beneficial to his clients in particular or society in general. What we do want in operating companies are obsessive people looking for ways to make the core transaction between buyer and seller more efficient or incrementally more delightful without materially altering the nature of the core transaction itself. My unexpectedly very late arrival at the hotel has made it impossible for me to get dinner, but an availability of fresh fruit and healthy snacks free of charge not only satiates my hunger but makes me feel the hotel staff is concerned for their guest's well being. It's still a room with a bed and a bath, but I'm more likely to choose that hotel again in the future because they strike me as being prepared for irregular ops situations experienced by their customers.

There is a fundamental difference between these types of employee engagements. Knowledge of something that customers have never thought to do or thought possible is in the "voyage of discovery" realm. Knowledge of something that customers have long known possible and wondered "why can't / won't they do this" is in the "pay attention" realm. That makes prior questions of skill; the latter questions of will. A lot of things in operating companies fall into that latter category: a decision by a customer service person not to do something is a choice the firm they work for makes, either on the spot (by the employee) or as a matter of policy (by management).

But this shouldn't matter, should it? Either way, the employee is learning. What difference does it make?

It matters from the point of view of both the learning intensity as well as the freedom to act on what has been learned. There is less opportunity for learning and less value placed on it by investors and customers in the operating company realm, hence less opportunity to act on it. And, unfortunately, operating company jobs are the bulk of the jobs people hold today.

The business of software is somewhat unique in that the learning intensity and freedom to act are extremely high, precisely because we get to take voyages of discovery all the time. Sure, learning Pascal was something millions had done before I came along. But my ability to apply that knowledge to do things that had not been done before created a very learning-intense environment: the better my skills in Pascal, the different the class of problem I could solve with it, the more new ground I could clear.

That's great for those of us in the business of software. How do we meet the "for everybody, everywhere" standard?

The opportunity will first present itself by being able to get more people out of rote operating company jobs. But that isn't enough. Yes, in theory I don't need any human interaction at the hotel: I can check-in from my phone and use it as the room key and if I opt out of housekeeping services and order food through Seamless I would never cross paths with any hotel employee. All that does is displace more hotel staff and justify fears of our robotic future and a return to the bad old days of industrialization concentrating wealth and suppressing working classes circa the first half of the 19th century.

There is benefit to having people in opco jobs, and not just to supervise the robots. What if opco employees had tools they could use to solve different classes of problems? Not transactional tools, not canned reports that a back-office accountant can study, not 21st century green screens that clerks can use to sell an upgrade. How about tools that are (a) granular; (b) modular; (c) "programmable" by the user - where the user is not the customer, but an employee; and (d) re-composable. Opcos would be able to provide the operational consistency that investors and customers expect, while enabling a work force with tools allowing them to be less obsessed with efficiency and more passionate about solving customer problems.

What if opco employees could re-program the environment, directly, themselves?

That would certainly bring more people on the same "voyage of discovery" that people in software development enjoy. It would redefine the relationship between developers and consumers as peer solvers of problems of different granularity, not producer-user of a confined operational space. And that would mean less tilt in the playing field of the future, and subsequently less inequality.

How do we make it possible for everyone, everywhere to experience the beginner's mind we get to experience every day in software development? By treating them as problem solvers, not operator-executors.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-65022245067880905472018-09-30T22:31:00.000-05:002018-09-30T22:31:14.113-05:00Beginner's Mind
A little over a decade ago, I was part of a team introducing new practices to a 200+ person, distributed development team. A lot of people were too quick to understand them. Some participated in stand-up as if it were a one-way status meeting. Others were still creating long-lived branches in Perforce as if they were still using ClearCase. "Stories" was just a new word for the technical tasks they had always assigned. Two people I was working with at the time pointed that everybody would be well served to approach these new practices with "beginner's mind."

* * *

While on vacation in Western Ontario Province a few years ago, my wife suggested we visit an amethyst mine. I had distant memories of doing some lapidary work with my dad back in the 1970s, so I picked up enough small stones for tumbling. Over the years, my dad had grown serious enough about the hobby to build out a considerable workshop of tools, slabs and rough. When I told him that I had picked up a few pounds of amethyst, he gave me a spare rotary tumbler. Five weeks later, I had my first batch of polished stones in nearly 40 years.

I was also disappointed. The polished stone looked good but not great. Why did so many have fractures and chips?

I did some research and tumbled some more stones and learned that to get better results I would have to improve the quality of the rough as well as my technique for tumbling.

To improve the rough, I learned to recognize characteristics of amethyst crystals that were more likely to fracture in tumbling, and excluded these. I did a full inspection after every stage of the tumbling process and removed any stones showing signs of damage so that a shard would not float around the barrel and contaminate other stones in the batch.

I had to improve my technique, too. Stones take quite a pounding in a rotary tumbler. While this action erodes sharp edges off the stones, it also increases the probability of damage. I learned that ceramic media in the barrel can cushion the impact. I realized that the barrels can be difficult to completely clean; even a tiny piece of previous-stage grit can contaminate a batch, so I obtained different barrels for different stages of grit. I also questioned the 7-days-per-each-stage tumbling recipe: what's so special about a week? I sampled stone in the tumblers once per day, comparing it to stone that had been in for a full week, and found I could reduce the amount of time spent in every stage.

Eventually, my dad gave me a lapidary arbor so I could grind the rough into shapes that would tumble more successfully. Later, he gave me a lapidary saw so I could cut fractured stones, allowing me to harvest more from the rough: instead of grinding away one half to save another, I could cut a stone along an obvious fault line and shape each part into a stone that was more likely to tumble successfully.

I quickly realized that the saw and arbor would let me do more than prepare stones for less bad tumbling outcomes. After a bit of research led me to cerium oxide belts and expanding drums, I figured out how I could hand-shape stones from rough to polish without using the tumbler. Hand shaping a stone is time consuming, but far less damaging than tumbling. There is risk: what appears to be innocuous sanding can expose a deep void, and careless handling on the arbor can result in a shattered stone. Still, when I have a very special rough stone, I can shape and finish it by hand, sanding out imperfections while retaining its unique characteristics.

The lapidary world is not too interested in making unique shapes out of small rough on saws and arbors; it is primarily concerned with creating faceted stones or cabochons (domed shapes in fixed sizes). To be serious about lapidary work, I would have to make one or the other or both. I had the tools for cabs, so over the course of several months, I taught myself how to slab, trim, dome and polish cabochons. I had some jewelry findings from my dad and acquired a few more of my own to set the cabs into as finished jewelry pieces.

It occurred to me that what makes lapidary work so satisfying to me is that I approach it with beginner's mind every day that I get to do it. Every stone I work on, every technique I follow, every tool I use is an experiment and therefore a learning opportunity. Through the simple, frequent act of trying lots of different things I have made hundreds of little adjustments to my workshop, my tools, and my methods. The net result is I am more efficient, more accommodative to failure and mistake, have higher throughput and better product quality today than I did at any point in the past.

And I'm still learning. Every day.

The joy of the lapidary work is not the final product. If it ever became that, it would be a chore, a job, and it would lose its allure. The joy of the lapidary work is the never-ending discovery. Some days I work in the workshop, some days I work on the workshop, but no matter which it is I learn something every day, and every day I take action on what I learn.

* * *

In the business of software development, the primary focus is on the product: these features, this timeframe, this cost. When the product disappoints - it costs too much, it takes too long, it isn't reliable, it is difficult to use, it doesn't do what it's supposed to do - the process of how it is made gets as much attention as the product we're trying to make. Those times of focus on the process lead people to investigate things like Agile and Lean and continuous delivery. Sometimes, to people unfamiliar with them, Agile and Lean and continuous delivery appear to be magic.

There is nothing magical about things like Agile and Lean and continuous delivery. The only magic is the (re-)experience of beginner's mind when somebody is first exposed to them. They force us to re-examine the orthodoxy we have long accepted - for reasons we no longer remember - for how we work. They let us break out of the psychic prison that is the modern operating company environment.

Despite containing elements of continuous feedback that drive continuous improvement - build pipelines, retrospectives, experiments - the change to Agile or Lean or continuous delivery does not typically result in a permanent state of beginner's mind. They captivate only for the short period when people care about process: we're broken, we need a fix, this process looks like a fix, let's adopt this process. As important as change may be at the time, product eventually triumphs over process, while change fatigue casts a pall over attitudes and budgets alike. Management wants mastery of whatever mechanical processes they've agreed to; they're not interested in perpetual, indefinite refinement.

Dan North has long argued that first and foremost a company should aspire to be a learning organization. A propensity for organizational learning underpins a lot of well established management theory and more recent instantiations of it, things like autonomous work teams, Agile practices, and Lean startup. If the real objective is not to become a learning organization, these will be little more than mechanical acts that serve only to make software development less bad.

There is merit in being less bad. There is value in fleeting moments of joy from reconnecting with our younger, knowledge-acquisitive selves. But change that does not aspire to rewire people permanently to their beginner's mind does nothing more than make a job less of a slog. It is still a job.

It is not a passion.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-56247133938648048102018-08-31T20:42:00.000-05:002018-08-31T20:42:13.568-05:00Organizing for Innovation, Part VI: Putting It All Together
As we saw in the previous posts in this series, organizations of autonomous teams can scale. Scaling requires different team characteristics (requisite variety, redundancy of function, double-loop learning and minimum critical specification), a different mental model of organization (brain, not machine), a different kind of hierarchy (purpose, not control), and a different style of leadership (guide, not command).

This sounds like it would be chaos in practice on a small scale, let alone enterprise scale. And even if it does work, it sounds like a revolutionary approach to organization. Visualizing it helps explain how all these things combine to create an organization that innovates as well as operates.

The organization of autonomous teams is not chaos. Teams are invested with authority, communication pathways develop along the hierarchy of purpose, the structure adapts itself to the domain, and organizationally-driven objectives plus team incentives align behaviors and outcomes. Of course, this looks nothing like traditional organization, in which hierarchy is the principal means of control, communication, and alignment. Still, while an organization of autonomous teams may be unfamiliar and conceptually unsettling, it isn't chaos.

And, although it may seem revolutionary, it isn't new. Academic research on organizations of autonomous work teams dates to the 1950s, and the early adopters of it were industrial firms. While it may be a way of working that a lot of tech companies happen to adopt for themselves, it is not an organizational phenomenon that has sprung out of tech. So it isn't all that revolutionary, either.

It may not be chaotic or revolutionary, but it is a big leap from how just about every enterprise functions today. The way they work reflects the board's priority for the company. I've written before that companies are financial phenomenon more than they are operating phenomenon. Executives tasked by their boards to prioritize returning cash to investors will look to maximize cash earnings (EBITDA) and free cash flow. In so doing, those executives create an environment where managers must be more concerned with costs than creativity from operations. Managers, in turn, condition employees and contractors to value activity over learning, output over outcomes, and narrow individual independence over broad group autonomy. In this environment, employees, managers and executives are rewarded for every dollar not spent for output; they will not be rewarded for any dollar spent on learning.

With enterprises increasingly feeling the heat from new companies, technologies and products, executives charge managers with extracting more innovations from the business. Managers go about looking at changing ways of working, recognizing that innovation is partially a byproduct of "how" things are done. But as long as the priority of the board is to return cash to investors, the first mission of "how" things are done is to be predictable, because predictability ensures consistent cash flows and consistent cash flows ensure that interest payments, dividends and buybacks can be made while protecting the bond rating. The autonomous team structure is incompatible with predictability.

The autonomous team structure is internally consistent (not chaos) and been around for long enough with enough successes (not revolutionary) that it can succeed, even at scale. Pursuing it is ambitious, and operationalizing it is plenty difficult. But success with it has less to do with operationalizing than it does with the tolerance for it in the capital structure in which it operates. Autonomy - that is, abdication of centralized control - is the price of admission for innovation. Innovation at scale requires autonomy at scale. Autonomy at scale requires the board be committed to innovation, not cash returns, as their top priority.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-19274031079327647992018-07-31T20:20:00.000-05:002018-07-31T20:20:01.408-05:00Organizing for Innovation, Part V: The Leadership Challenge
Organizations of autonomous teams require a different set of behaviors than organizations that are run like a machine. People in a self-directed team form their own appreciations for what should be done, prioritize what will be done, and self-determine how it will be done. They are unencumbered by hierarchy, expected to communicate with anybody in the organization they need. They are unencumbered by role definition, as people simply do whatever work is required even when that means acquiring new skills or knowledge. They are unencumbered by organization, as teams form task-forces to solve for problems that are beyond the scope of any single defined team.

This all sounds great. Who wouldn't want to work this way?

The majority of people working in enterprise IT today, that's who.

Enterprise tech labor is highly codified (bounded responsibilities) and stratified (seniority). Aside from the fact that this serves the interests of a multitude of non-tech corporate functions such as human resources, vendor management and finance, it also provides a great deal of comfort to the individual. The employee knows very precisely what is expected of them to earn a salary increase or advance their career, while the contractor knows what they are obliged to do to satisfy the terms of their contract. Over time, jobs become working annuities that require little servicing (such as skill acquisition or excessively long working hours) for comfortable levels of compensation with job security (by e.g., being the only ones familiar with a technology, service or function).

The autonomous team environment is anathema to this. For starters, the autonomous team operates with a lot of ambiguity. New appreciations change the team's priority constantly, meaning there is no deterministic plan. Plus, people adapt themselves to the work that needs to be done as opposed to working in strict swim-lanes. An autonomous team environment implicitly subordinates the traditional goals of the individual: the success of the team is success for the individual. An autonomous team breaks down when its members put individual achievement over team accomplishment.

Of course, working this way is a question of both skill and will. Whether labor can re-orient itself from machine to autonomy is a debate well beyond the scope of any blog post, but suffice to say that some - few, several or most - will not be able to make the transition from doing what they are told to do by management, to figuring out for themselves what needs to be done and doing it. In addition, whether labor willingly chooses to re-orient itself is another matter entirely. Over-exposure to enterprise change programs - or more likely, over-exposure to failed enterprise change programs - won't inspire enthusiasm for yet another one. There is also the suspension of disbelief people need to make to give devolved authority and autonomous team structures a try.

This brings us to the leadership challenge that creating an organization of autonomous teams poses. Obviously, there are institutional barriers that have to be overcome. HR has to be comfortable with ambiguous roles and titles. Vendor contracts for supply of specialist labor have to be replaced with contracts tied to business outcomes. Finance needs an alternative to predictive planning and financial budgeting.

However, the challenge to leadership goes beyond mechanical processes and structural changes. In an organization of autonomous teams the nature of leadership changes from giving commands to guiding actions. The leader does not direct people's performance to achieve a goal (organization-as-machine), but instead projects a goal that people direct themselves toward achieving (organization-as-brain). The leader in the autonomous organization makes use of:

Concrete statements of expectations: leaders have to make expectations crystal clear. Saying "all enterprise software is deployed into production every other week" is a clear expectation. Saying "we will be a continuous deployment organization" is a woolly statement: "continuous" will be interpreted relative to the current skills and learned helplessness of the people responsible for enterprise software today. The latter statement also misses the point: how the organization functions (continuous deployment) is less important than describing what it achieves (new software released across the board every other week.) The prescriptive implications of that statement deny the people in the organization the opportunity to figure out for themselves how best to achieve the goal. The leader communicates the expectation; it is up to the people in the organization to figure out how to achieve it.

Rewards and recognition: obviously, what gets measured is what gets managed. If the goal is to increase frequency of deployments, reward the teams that find ways to make reliable production releases weekly, then twice weekly, then daily, then multiple times per day. Story-telling is important as well, especially as an organization adopts new behavioral norms and its business partners develop new expectations of it. For example, in its early days, FedEx executives were fond of repeating the story of the junior employee who rented a helicopter on his personal American Express card to fly him to a mountain location to repair snow-damaged phone lines so that they could service remote customers. When you're building a reputation for absolutely, positively getting packages delivered overnight, stories like this go a very long way.

Acknowledging and solving constraints: every team, not to mention the organization as a whole, will be short of the capacity, capability and capital to achieve every organizational goal. While constraints force institutional responses such as prioritization and innovation, they are also opportunities for a systemic change. It is the leader's obligation to work with constrained teams to identify the actions they can take today so that they will be less constrained in the future. For example, if there is a capability constraint, what can the team do now to develop skills and knowledge so that it can do more for itself? If a financial constraint, how can the team build a stronger business case or define a set of experiments to explore potential value? In the face of constraints, the leader's responsibility is to develop an organization's ability to learn how to learn.

At the foundation of the organization of autonomous teams is Theory Y. The aspirational leader of an organization of autonomous teams has to believe that people are motivated, responsible, and do not need close supervision. If you do not fundamentally believe this, do not bother pursuing an organization of autonomous teams. Once you revert to command-and-control (Theory X), you have lost the mantle of leadership in a devolved organization.

In the next installment in this series, we will put all of these concepts together to visualize what the autonomous organization looks like at scale.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-17209804724474068072018-06-28T19:54:00.000-05:002018-06-28T19:54:07.403-05:00Organizing for Innovation Part IV: Autonomy at Scale
It is easy to understand how a small organization of autonomous teams can function. When there are only a few teams, there is a small community, and it is simple for people to communicate with one another in both formal and informal ways.

It is not difficult to see how a large organization of largely independent teams can scale. For nearly 60 years, Gore-Tex has shown that devolved authority can work just fine at scale.

Autonomy scales at Gore-Tex because there is very little overlap between outerwear and dental floss, and subsequently less coordination. What happens when the business becomes complex, with lots of interdependencies among lots of teams?

Dependencies by themselves do not make it difficult to understand how devolved authority can work on a small scale. If there are 4 teams, there are a maximum of 6 communication pathways (n x (n - 1) / 2). Even if there are transitive dependencies, the small size of the community - 4 tech leads, 4 product owners, etc. - makes cross-functional communications relatively easy. But a technology organization of tens of thousands of people will have hundreds of teams - and therefore an extraordinarily large number of communication pathways. Translating a small number of enterprise goals into hundreds of millions of synapses sounds like opacity at best, chaos at worst.

There are four things that an organization of autonomous teams needs if it is to scale.

The first is an implicit hierarchy, but one of purpose rather than control.1 Traditionally, hierarchy is meant to control activity througyh supervisory responsibility and assigned decision rights: the subordinates in one division take direction from superiors in the same division. If, per the initial blog post in this series, decision rights are devolved, "span of control" does not exist in the organization of autonomous teams.

Hierarchy also influences communications. If those "higher up" in the hierarchy use the things produced by those "further down", there is an obvious pattern of communications between producers and consumers. In manufacturing, there might be different teams independently assembling subsystems such as brakes or drivetrains from individual component parts. Each of their subsystems might then be consumed by teams on the line installing them into more comprehensive systems (such as the powertrain), and, ultimately, the finished vehicle itself.

This is called a "hierarchy of purpose." The hierarchy is constructed largely around degrees of granularity. Brakes and drivetrains are smaller assemblies that form larger subsystems that contribute to the finished product. A provider of cloud-based infrastructure such as Amazon can organize in the same way: the "finished product" of a cloud instance consists of more "primitive" components of virtual storage, server and network. Each of those subsystems in turn consists of more finely grained primitive components of network protocol communication, CPU, load balancing, and so forth.

Creating complex higher-order offerings as composites of lower-level capabilities is the "platform effect" of innovation.

It's worth mentioning that enterprise program management has long tried the same structure. It chokes on itself when transitive dependencies that extend several layers deep expose the difference between a boundary in work (a team has exclusive responsibility for producing something used by many other teams) and a boundary in fact (the output is high-touch service, support and maintenance, making those boundaries porous). A primitive component must be consumable in a friction-free manner.

This is a logical transition to the second thing the organization of autonomous teams requires, which is practical patterns of communications. The platform effect scales effectively because consumption patterns are the de-facto communication patterns within the organization. In a hierarchy of purpose, the organization does not have hundreds of millions of communication pathways, because the number of consumers is limited. A cloud instance may consume a load-balancing primitive, but it does so through a more coarsely grained "network" intermediary.

The decision classes introduced in the initial post in this series act as a control system for each individual team. The wider the divergence of type of consumer, the more difficult it is to create patterns of demand and prioritize to form a product strategy. The nested team organization limits the divergence of consumer demand, which creates a narrower range of appreciations, which make cohesiveness of strategy and execution at an individual product level far easier to perform.2

The autonomous-team collective maintains enterprise cohesiveness by virtue of its communication patterns. To understand how, we have to revisit the devolved decision classes. Appreciations (what should be done) act as the organizational system for managerial decisions (what can be done); managerial decisions function as the instrumentation system for appreciations. Managerial decisions, in turn, act as the organizational system for technical decisions (how will it be done); technical decisions, in turn, act as the instrumentation system for managerial decisions.

Scope	Nature	Organizes	Instruments

Appreciations 	What should be done? 	Managerial

Managerial	What can be done?	Technical	Appreciations
Technical	How will it be done?	 	Managerial

How this works effectively in practice becomes clear when we look at the characteristics of a single autonomous team that we saw in the last post. The transmission of minimum critical specifications through a hierarchy of purpose limits the noise and confusion. The reception of minimum critical specifications from multiple consumers are interpreted as appreciations through double-loop learning. The relationship of control systems and instrumentation systems of the different decision classes categorizes the information appropriately.

The third thing required for an organization of autonomous teams to function at scale is the ability to handle extraordinary patterns of communication. As there is no hierarchy of control, the organization needs protocols that allow it to adapt itself to a changing problem space, as well as to resolve inter-team conflicts.

A dynamic problem space is addressed through task-forces, which may be short- or long-lived, depending on the nature of the need or opportunity. Task forces are formed organically from members of affected teams to solve for problems that are existential to any one team. For example, suppose three teams conclude that they need a new class of capability that is outside the boundaries of all of them. They could elect to form a "task force" in the form of a long-lived team, staffed by reassigning members of their respective teams to this new one on a full-time basis. Not all task-forces are long-lived and full-time, of course: a task force to address a simple challenge might require each person commit only 1 day each week for a month, allowing them to otherwise remain focused on their line responsibilities.

Another other exceptional form of communication are inter-team conflicts. For example, team A elects not to prioritize something really important to team B, and team B lacks the resources or capability to do it for itself. Without patterns for extraordinary circumstances, it would end with a very grumpy team B. Inter-team conflict is handled through mediation and adjudication protocols. At the first stage of mediation, an acceptable 3rd party - that is, someone who is not a stakeholder in the conflict - is asked to mediate a decision. If the conflict is still not resolved following the initial mediation, a committee of 3rd parties are formed to arbitrate a decision. This provides a fair hearing among peers without the need to resort to authority given through a hierarchy of control.

Finally, the organization of autonomous teams needs mechanisms for aligning the strategic goals of the organization with team and individual execution. Appreciations provide connective tissue among strategic, team and individual goals and objectives, but they still need to be reinforced by executive management. Intermediary (layered) objectives have a tendency to change the interpretation of organizational goals, and therefore the goals of each individual.

Alignment is achieved by telegraphing executive intent throughout the organization. There are techniques popularized by a number of firms - OKRs, V2MOM, and the Big Bets Spreadsheet - and probably many others. Whatever the mechanism, their purpose is to communicate unambiguous goals to give each individual a clear means of reconciling a decision - why, what and how - with an outcome that advances the organizational goals. This creates direct line-of-sight between effort and result - and therefore tactical action with strategic outcome - and allows the organization of autonomous teams to function without an excessive number of people in low-value supervisory roles.

With the right set of characteristics, then, an organization of autonomous teams can reach scale, even in complex environments. But it clearly has a vastly different operating model to the traditional control style imposed over the machine-like organization. Is the labor force equipped for this? Is leadership? We will look at these questions in the next post.

1 Susman, Gerald. Autonomy at Work: A Sociotechnical Analysis of Participative Management Prager Publishers, 1976.

2 There is no guarantee of control, of course. An individual team can still thrash or produce unwanted product.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-29144415392238702842018-05-31T20:34:00.000-05:002018-05-31T20:34:12.166-05:00Organizing for Innovation, Part III: A New Metaphor
Before looking at autonomy at scale, we need a different understanding of what an organization is. This matters because the way we perceive an organization will determine our interpretation of what "good" and "bad" look like.

Some years ago, I wrote that management thinking is still dominated by the "Freds": Frederick the Great, who's Prussian military structure became the model for the modern organization; and Frederick Taylor, a pioneer of scientific management. Frederick the Great organized his military to function like a machine. Frederick Taylor optimized performance down to the task level. The organization-as-machine metaphor has dominated management thinking for well over a century.

A machine is optimized to require the least amount of labor to produce the highest volume of throughput possible with minimal waste. Machines are designed such that each of its component parts performs specific tasks in a consistent and repetitive fashion. When organized into an orchestrated flow of execution, a machine will yield a high volume of consistent output.

Machines are made for optimal performance within a limited range of environmental variation; they are not adaptive to their environments. If something changes in the internal or external environments, the machine will perform at a less-than-optimal state. An exceptional condition to those the machine was designed to operate in will cause an error in execution. Exceptions are subsequently a source of inefficiency to a machine: the machine's purpose is the consistent and repetitive execution of tasks; exceptions inhibit that execution. An exception must therefore be contained so that the machine returns to efficient execution as quickly as possible.

If a lot of things change in the environment, the machine will completely break down. The machine is not designed to intelligently adapt, it is designed to single-mindedly execute.

The organization managed as a machine may achieve optimal performance, but at the cost of adaptability. We need a different metaphor for the organization: without one, we're doomed to end up with what we've already got. If we see an organization as a machine, we will define it in terms of efficiency: what gets measured is what gets managed, and when we apply old-style thinking we come to rely on old-style managing. If the organizational goal is innovation, we need the organization to have the characteristics described in the previous post in this series: it must be attuned to its environment, and it must be highly adaptable to it.

An more appropriate metaphor for the adaptive organization is to think about the organization as a brain. The brain is a highly adaptable organ:

While different regions specialize in different activities, control and execution are not localized - regions are closely independent and capable of acting on behalf of each other when necessary

Memory is distributed, not localized

Robust connectivity allows for simultaneous processing and awareness of what is going on elsewhere

Cross-connectivity creates redundancy that allows the brain to operate in a probabilistic rather than a deterministic manner, allows room to accommodate random error, and creates excess capacity that allows new functions to develop1

The brain is designed to facilitate the process of self-organization where internal structure and function can evolve along with changing circumstances; machines do not do this.

The manager in the organization-as-brain is concerned with redundancy of capability at atomic and coarse levels; recording, curation and accessibility of institutional memory; and unencumbered communications (no strict hierarchy) that are highly contextualized (explain why you want what you want). These are anathema to the manager who's goal is efficiency of execution. Redundancy is paying for something twice. Memory only matters to the most senior people as it affects decisions with long-term ramifications; in the organization-as-machine, those decisions are exclusively their purview. Open communications creates a lot of noise that interferes with orders from management. Having to explain why somebody needs something wastes time.

Traditional organizational thinking inhibits the conditions that create innovation. To have any reasonable expectation of innovation, we need to have the right expectations of how the organization functions if we are to manage in a way that fosters innovation.

Or course, a business is not managed by metaphor. But the way an organization is understood determines the way it is managed. A mindset rooted in learning rather than efficiency provides a set of "first principles" against which measurements and management decisions can be reconciled. It is therefore important to have the right mind-set about the nature of organization to understand how the organization of autonomous teams can exist at scale.

With these goals in mind, the characteristics of an organization of autonomous teams at scale become easier to understand. We'll look at those in the next post.

1 Morgan, Gareth. Images of Organization. Sage Publications, 1986.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-51306415073831851892018-04-29T23:23:00.000-05:002018-04-29T23:23:11.478-05:00Organizing for Innovation, Part II
Last month we defined autonomy by the classes of decisions that are devolved to the team level, specifically that the smallest organizational unit - a team - has the ability to decide what it should do, can do, and will do. Looking at it this way makes clear the sharp differences between autocratic and autonomous management philosophies. It also helps us to understand that there need to be very special conditions for autonomy to succeed, even on a small scale.

It seems plausible that autonomy can work among a small group of people having a natural predisposition to collaborate and low asymmetry in their depth of skills and knowledge. But there has to be more to it than just a handful of similarly talented and like-minded people working together. If there isn't, than successful autonomous teams are largely an accident of hiring, and not a replicable phenomenon.

According to Morgan, there are four things that characterize an autonomous team.

One is redundancy of functions.  Team members have the skills to be able to perform each other's jobs and substitute for one another when necessary. They are called "redundant" functions because each team member has skills they are not using for the work they are doing at any point in time (e.g., coding a new feature doesn't require a change to the build script). A team of poly-skilled people is itself an organization that is flexible enough to reorganize down to its most atomic level - the individual contributor. It adapts naturally because "[t]he nature of one's job is set by the changing pattern of demands with which one is dealing."1

By comparison, a team of specialists can be an autonomous unit when the external environment is stable, but it cannot sustain autonomy in the face of changing conditions because specialists lack the ability to adapt. When a specialized skill becomes unnecessary, the specialist becomes redundant along with it. A revolving door of members destroys the cohesiveness of a team.

The lack of individual adaptability also creates apathy within each member of the team. Problems such as poor quality or long time-to-market are seen as "someone else's problem" to solve because specialists working on the line don't know, or don't care, or don't have the authority to solve them. As a result, "[a] degree of passivity and neglect is thus built into the system."2

The team of specialists therefore lacks the capacity to self-organize because its members cannot change their job to reflect the changing patterns of demand, and because each member is invested in their skillset more than the team itself. Fixing problems within a team of specialists must be initiated and controlled by higher authority that exists outside the team. In dynamic external conditions, a team of specialists is doomed because the whole will always be less than the sum of its parts, while a team of generalists will acquire the skills and knowledge it needs to solve whatever the problem at hand may be.

Another characteristic of autonomous teams is requisite variety. A team's internal capabilities must mirror the breadth and depth of the environment within which it functions if it is to deal with challenges and opportunities posed by the environment. That skill variety must exist within the team itself so that it can be directly applied where and when it is needed.

A team lacking diversity of function must depend on others so that it can respond to environmental challenges. That dependency impairs a team's ability to self-organize and act, and therefore erodes its autonomy. For example, a team that develops an appreciation for something it should do will be inhibited from doing it if it has to negotiate with other teams for skills it does not have itself.3

Satisfying requisite variety is where technology platforms enable autonomous teams. While it is true that it is people and not assets who innovate, the assets can enable or prohibit such innovation. Teams that can consume components produced by others in a self-service manner do not suffer a dependency. The more comprehensive the components available for consumption, the greater the requisite variety a consuming team can possess, the larger and more complex the environment a single team can engage.

There is more to requisite variety than just skills and capabilities. It also makes a case for human diversity within a team. The appreciations a team develops are richer and more nuanced when they are recognized and crystalized through the diversity of its participants. Another way to look at it is, a homogeneous team will develop homogeneous solutions, and through a lack of human diversity will be structurally blinded to both opportunity and threat. By way of example, I once worked with a bank that was slow to realize that the average age of their employee matched the average age of their customer, that the average had been steadily rising for many years and was now well above the national population average. Year-on-year growth of assets under management looked spectacularly good, primarily because wealth distribution overwhelmingly favored the baby boomer generation. Unfortunately, it completely masked a dearth of new customer acquisition. Along the way, they had become generationally tone deaf, failing to develop experiences and products that appealed to younger generations and subsequently grow their customer base.

The next characteristic of autonomous teams is minimum critical specification. Vague charters and ambiguous boundaries create the capacity for self-organization because they build-in the expectation that teams are responsible for self-definition. A team cannot rely on management edicts that tell them what to do and how to do it. A team must instead define itself through practice and inquiry. General guidelines give a team an abstraction that they must constantly solve for, bringing them face-to-face with the appreciations, or "why" they do or do not do something.

Telling a team precisely what to do robs it of the capacity for self-determination and self-organization because it locks them into a swim lane. A team that is precisely chartered is institutionally specialized. We saw earlier that a team loses adaptability when its individual members lack redundancy of function. In a similar fashion, an organization loses adaptability when individual teams lack minimum critical specification, because teams themselves are stripped of their capacity to adapt based on what they see on the line.

Finally, a team must be capable of learning how to learn. This is also known as double-loop learning. Single-loop learning is the ability to detect and correct deviations from the norm, responding to threats to contain and minimize the impact of exceptions. In double-loop learning, a team is able to analyze a situation in its totality and question the relevance of the things that it does as well as the need to do things it is not doing. Single-loop learning is concerned with staying on-course. Double-loop learning is concerned with determining whether a team is doing what it should be doing in the first place. A well-functioning Agile retrospective is an example of double-loop learning.

Both minimum critical specification and learning how to learn point to the need for abstract thinkers, people who can understand a situation and adjust accordingly. Large ex-growth enterprises are operating companies, not developing companies. Operating companies need efficient execution, so they are populated with concrete thinkers, people who are conditioned through incentives and rewards and professional certifications to keep the ship sailing "steady as she goes". Abstract thinkers are constantly questioning why and looking for the right course of action based on all available information. To the concrete thinker, an exception is a problem to be contained. To the abstract thinker an exception is an opportunity to learn.

These four characteristics - redundancy of function, requisite variety, minimum critical specification and learning how to learn - make it possible for a team to self-organize, self-direct and self-regulate in response to changing external conditions. It is not difficult to see how these form the core characteristics of autonomy. It is also not difficult to see how their respective antitheses - specialization, dependency, precise chartering and single-loop learning - are the defining characteristics of the sclerotic organization.

Combined, these characteristics create what Susman4 calls "learning cells" within an enterprise. While they form the basis of the autonomous team, a cell does not simply multiply to form a more complex organization. We'll next look at what it takes to scale the learning organization.

1 Morgan, Gareth. Images of Organization Sage Publications, 1986.
2 Ibid
3 If "does not have" is institutionalized as "can not have" through shared services - for example, because of an acute shortage of supply, or because those functions are used as control mechanisms to "protect production" - then the pretense of "autonomy" is a veneer over the management anti-pattern of "responsibility without authority".
4 Susman, Gerald. Autonomy at Work: A Sociotechnical Analysis of Participative Management Prager Publishers, 1976. Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-18745810878077195522018-03-31T19:24:00.000-05:002018-03-31T19:24:23.197-05:00Organizing for Innovation, Part I
Innovation happens through people, not assets. Assets can be an impediment to innovation: software that is brittle, monolithic, poorly encapsulated, or high-maintenance inhibits creative new uses of it. But assets don't innovate by themselves. Innovation happens through the people you have.

We saw last month that innovation is stifled where management's prevailing goal is control. If we want innovation borne of individual creativity, the reasonable thing to do is to look at organizational structures of autonomy and devolved decision-making. Unfortunately, as we saw two months ago, there are no formulas for devolving decision rights. We also saw there are few reference implementations, and no objective measures that show autonomous structures outperform command-and-control styles. Deciding to devolve requires unflinching conviction that it is the right thing to do, and the intestinal fortitude to muddle through what doesn't work to figure out what does. Because there are no half-measures of devolution, the stakes are high: by choosing to do this, you are betting your career and possibly the entire business on its success.

To better understand devolved decision making, it helps to understand the classes of decisions that define autonomy. According to Susman, there are three:

Scope	Nature	Environment	Artifact	Hierarchy

Institutional	What should be done?	Accommodate or defend against what it cannot understand or cope with	Appreciations	Board

Managerial	What can be done?	Decisions are uncertain and highly reactive	Strategic plans	Senior management

Technical	How will it be done?	"Supervisors of risk": decision making is fluid and creative	Implementation plans	Middle management

Source: Susman, Gerald. Autonomy at Work: A Sociotechnical Analysis of Participative Management

It is conceptually easy to understand how devolution works in small companies because the distance between decision makers and decision executors isn't very great. Start-ups don't have large boards and employees take direction directly from the founder, who is less concerned with precision execution than finding things that drive usage and growth. Senior technology leaders who decide on the "how" are also the people who implement the "how". There isn't much distance between the Chief Executive and the Chief Cook and Bottle Washer.

The larger the organization, the more polarized the control over each decision class. Appreciations - why should we do something - are the provenance of the board, who are few in number and very far removed from the insides of the company and the ecosystem in which it functions day-to-day. Questions of "what" are held tightly by management, providing a means of co-opting the board in assessing how well management executed, not necessarily on the success it achieved in exploiting the appreciations the board set forth. Held to performance targets from management, and saddled with lowest-common-denominator rented labor (thank you procurement departments everywhere for dehumanizing the secondary labor force for nearly two decades now), questions of "how" are similarly held tightly by technical managers.

The more disenfranchised the line - as in, the greater the extent to which individual employees are only permitted to do exactly what they're told to do - the harder it is for anyone to fathom a devolved model, let alone function within one.

The gulf between "stay in your lane" and "chart your own course" makes clear that there is much more to devolving authority than investing small teams with the responsibility of figuring out what they should do, can do, and will do. In part II, we'll look at the organizational characteristics of a self-directed team, one that functions in a genuinely autonomous manner. After that, we'll look at autonomy at scale: what needs to be in place for autonomous teams to function cohesively in a complex corporate ecosystem.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-80199887874454503302018-02-28T22:14:00.000-06:002018-02-28T22:14:00.478-06:00Innovation Versus Control
Firms in industries ranging from financial services to retail pharmacy to fast food aspire to be "platform companies." In the minds of their chief executives, the emergence of Amazon and the evident superiority of platform economics make this necessary for their continued survival. It is also a good story to tell Wall Street as it allows a firm to create the aura of being the technology leader in their space while trafficking in the success of companies like Amazon.

"Platform" is conceptually conveyed as a technological phenomenon. But it stands to reason that the defining characteristic of the platform organization is neither the technology assets that they produce (e.g., friction-free consumable primitives), nor how they produce them (e.g., lean and agile process). The benefits of a platform are only yielded if the creativity and imagination of the rank and file can be unleashed through those assets, to experiment, learn, and implement quickly. This means devolving decision rights far down into the organization, a.k.a. autonomous teams.

I've been brushing up on organizational behavior theory, and during my research I came across this paragraph. There is a lot of wisdom condensed into these two sentences:

In general, the longer the time period required for the consequences of strategic decisions to be realized and evaluated, the less flexible are resources for commitment to alternative objectives. Furthermore, (1) the longer the time period in which strategic decisions operate as constraints on the decisions made by technical-level personnel and (2) the lower the complexity of the tasks required to carry out operational plans, the more likely that operational planning will take place at a higher level.

-- Gerald I. Susman, Autonomy at Work

The first sentence neatly captures why things like Agile and Continuous Delivery and Lean Startup are so appealing. We reach critical mass of feedback on a strategic imperative - and therefore judgment on the wisdom of that imperative - more quickly with lots of frequent deliveries of small but business-valuable things than we do with infrequent, large deliveries of comprehensive business solutions. The sooner we reach the inflection point where a body of feedback confirms or contradicts a strategic decision, the more quickly we can move on to the next phase of our strategy, or change course. This separates the sclerotic laggards from the adaptive innovators. In addition, the presence of continuous market intelligence serves to separate the agile and adaptive from the strategic flailers.

This is intuitively obvious, but seeing it in black and white serves as a means test for the fulfillment of business strategy: is a firm asserting, confirming, or just guessing at what the market will buy?

The second part of the paragraph helps us to better understand the organizational dynamics within a small and innovative company versus those within a large integrated program team or an enterprise.

The first part is simple enough: the longer it takes to realize a strategic imperative... Longer is bad, check; already established in the first sentence. The second part is where it becomes interesting: and, the simpler the tasks required to deliver that strategic imperative... This statement is an indictment of the labor carrying out those tasks and the management defining them.

All together, the second sentence tells us that a long-lived initiative expected to be fulfilled through simple tasks relegates executives to the role of supervisor.

This is a damning statement in a number of ways.

The moniker "executive" is highly relative, potentially to a point of meaninglessness. The greater the degree to which technical execution is decomposed into simple tasks, the higher up the responsibility for operational planning. The higher up the responsibility for operational planning, the less meaningful the title of the person doing that planning. C-levels engaged in day-to-day prioritization and resource allocation are not executives. They are mid-level managers who have benefited from title inflation. It also means that the scope of executive decision-making - strategy - is concentrated in just a few hands. This renders quite a few people executives in title only, and deprives a company of its next generation of leadership by stifling their formation.

Anyone touting the potential for innovation from a delivery team engaged in task execution is living in a world of make-believe. Innovation stems from the combination of autonomy and complexity: give a team the freedom to solve a complex problem any way they see fit, and they are likely to come up with something novel. A system based on completion of simple tasks deprives a team of any complexity to sink their teeth into. Additionally, a system of rudimentary task completion is inherently a control system, which has zero tolerance for independent thought or action that is off-plan. Innovation is scarce where control is the priority.

Enterprise-y Agile processes function as systems of control, not innovation. Any system that adjusts the work to suit the labor instead of adjusting the labor to suit the work will require a high degree of centralized control. Enterprise Agile processes tolerate, and even advocate, decomposing work into tasks and assigning them to specialist labor. This values the control of labor over the creativity of labor. Per the previous point, technical-level employees are systemically disenfranchised. A system based on control through tasks offers no leeway for devolved decision rights; the only right an individual has is to complete the tasks they've been told to complete. This makes enterprise Agile processes more prone to suppressing than unleashing innovation.

The dynamics of small teams in small companies are not directly transferable to small teams in large enterprises. Small teams in small companies have high degrees of overlapping responsibility, little tolerance for specialization, light processes, and engage in high-bandwidth, omni-directional communication. Large organizations codify things such as roles and responsibilities, career development, processes, and work (e.g., technology) guidelines, and engage in low-bandwidth, hierarchical communications. In small companies, trust is largely based on the expectation that everybody will do whatever it takes to achieve a common outcome; in large companies, trust is largely based on the expectation that specialized people respond to precise requests with precise responses. Team dynamics are functions of HR structures, organizational values and systems, communication patterns, and ingrained behavior patterns, all of which are highly resistant and even subersive to change when they have decades to develop within a company. The executive in a legacy enterprise who says they want to transform the company into a "start-up" betrays their naïveté of the magnitude - and unlikeliness - of that task.

The paragraph at the beginning of this post captures what many in the tech biz have experienced for decades. Since the 1990s, enterprise IT has been a story of scale. As it scaled, it became more prominent on the income statement, and was forced to place a premium on control. Occasionally, it basks in the reflected glory of innovative consumer technology firms, or gets elevated by a CEO as a source of untapped potential. Unfortunately, enterprise IT has never been able to reconcile an expectation for innovation with the fact an over-emphasis on control gives everybody in management a demotion, suppresses innovation, and stifles attempts at organizational renewal, all while holding a company back from fulfilling its strategic potential because it takes such a long time to get anything done.

The most interesting thing about that paragraph? It was first published in 1976. Industrial, not tech firms, were the prominent companies of the time. The lessons remain the same.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-34869315724516635372018-01-31T22:53:00.000-06:002018-01-31T22:54:13.055-06:00You say you want a devolution...
"This isn't to say that alternative approaches to management are dead, or that they have no future. It is to say that in the absence of serious upheaval - the destabilization / disruption of established organizations, or the formation of countervailing power to the trends above - the alternatives to the Freds will thrive only on the margins (in pockets within organizations) and in the emerging (e.g., equity-funded tech start-up firms)."
-- Me, September 2013

I wrote that nearly 5 years ago. That previous summer I cracked the spine on some management books I had last read a quarter of a century earlier. When I first read those books in the 1980s, there certainly did seem to be a management revolution afoot. In the late 1970s, large industrial firms in the US were plagued with quality and performance problems, a rank-and-file that was fully aware of but apathetic to them, and management that was clueless about what to do. The epitome of the industrialized era in western nations turned out to be a company that would systemically disappoint both customer and investor alike. The long dominant organization-as-machine model was commonly perceived to have matriculated to a state of intellectual bankruptcy. Out went command-and-control, in came employee empowerment and team autonomy. Meet the new boss!

Yet when I read these management books anew in the early 2010s, it was clear that the revolution had been stopped dead in its tracks somewhere along the way. Same as the old boss!

I have had reason to re-visit this recently, this time in the context of enterprise technology platforms. A company that develops recomposable, atomic components that can be consumed in a self-service manner by other developers can help to yield more coarsely-grained solutions more quickly. Making those coarsely grained solutions recomposable components as well should enable an organization to create with both greater ambition and speed.

The objective of a platform is not to build both big and small things more quickly or to build more efficiently, but to create more effectively. A platform should allow for a greater number of experiments and more comprehensive feedback. Employees closest to an opportunity - current and potential consumers, technology, competitors, people and capital - are the ones best positioned to pursue that opportunity through exploring, learning, and adjusting. In an emerging area of business or tech, a local team muddling through stands a better chance of success than a distant management imposing its will over a market. In practice, muddling through experiments and feedback requires some degree of authority devolved to the team level, so that a team can decide and act for themselves.

The notion of authority devolved to the team level brings up the question of the autonomous organization yet again. Plus ça change...

The same old idea comes with the same old questions. What does an organization of autonomous teams look like? Can it work? How does it scale?

Before we ask, "can an organization of autonomous teams work?", we have to ask, "what does autonomy at team level mean?" Does it mean the authority and responsibility for what they do and when they get it done? Does it include design and architecture? Can they act on things that are nominally the responsibility of other teams? Do they get to pick and choose the people on their team and the providers they source people from? Do they have to secure their own funding? Who do they answer to? How are they measured?

It may mean all of these things, or it may mean just a few. Autonomy is in the eye of the beholder. To some, just having operational autonomy - authority over what, when and how a team fulfills delivery goals - is sufficient. To others, operational autonomy without owning the P&L and balance sheet - everything from capital to compensation levels - is merely responsibility without authority under the guise of self-direction.

Every firm that has gone down this path has come face to face with the same questions and challenges. Every firm of any scale that has achieved any degree of success has ended up with some hybrid implementation: some things are decentralized, some things centralized; some for a short period of time, others for a longer period of time, and some permanently. For example, we want teams to be responsible for the production operations of their creations, but we must first incubate an ops capability; once we are comfortable that ops has completed its gestation period it will be broken up and absorbed into the line teams. However, to alleviate administrative burden and to avoid violating labor laws we will have a centralized HR function, but we do want ideas to compete for funding, so we will have utility and risk capital allocation processes.

One question, many different answers, and answers that change at different points in time as circumstances require or allow.

When there are many different answers to a single question, it is the wrong question to ask. Looking for specificity where there is none will only sow seeds of confusion and ultimately doubt. And, while there is plenty to be learned from the experiences of others, self-reported testimony must be taken with a grain of salt, and the success of others comes with no guarantee of portability.

A better question to ask is, how convinced are you that team autonomy is a solution to whatever challenges you face? You need to be overwhelmingly convinced that it is, because you need a high tolerance for the ambiguity, uncertainty, and constant adjustments and experiments you will have to run to find and maintain the right balance - that is, construct the right hybrid - for your set of circumstances. You also have to be comfortable without a lot of hard evidence that it solves whatever you had hoped that it would. Even had you not devolved a greater degree of decision-making to the team level, that product might have been a success, that innovation might have emerged, those employees might still have joined your firm. Can't prove the counterfactual.

If you are convinced, and decide to add your name to the list of those that have elected to crack this nut, the operationalizing questions are much different. The one that you will ask again and again and again is the obvious: how do we strike the balance: what do we think that hybrid should be today? what do we think it could possibly be? how do we go about figuring that out?

In addition, given the cyclical love-hate relationship with devolved authority, you must also ask: what makes it more likely, and what makes it less likely, that it will have staying power in your organization?
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-31236074298982469872017-12-31T22:08:00.000-06:002017-12-31T22:08:02.713-06:00And you may ask yourself, how did I get here?

It quickly became clear that the problem was not to explain why the market was in decline. it was to explain why the market had ever been so large in the first place.

— John Kay, Merry Christmas, whether or not you celebrate it with a sherry

Managers become interested in innovation when their company's fortunes start to wane. Innovation is a hoped-for remedy to arrest the decline, spark new growth, and convince nervous investors that management is up to the task.

I have written previously that executives looking for business innovation should not start by looking at technology, but at socio-economic changes that can be exploited or responded to in part or in whole by a technological solution. For example, what makes the sharing economy possible is a willingness for people to monetize their vehicles, home, and spare time because real wages have been stagnant for over a decade and homeowners are underwater on their property mortgages. Similarly, what makes robo-investing viable is a change in investor attitude which once eschewed "average" returns but not embraces them in favor of trying to beat the market. In each case, the stage is set for change by socio-economic factors, not apps and algorithms.

But before figuring out what to try and do next, John Kay makes the point that executives should look at the historical context of their own businesses to understand how it got to where it is - or once was, if past its peak of glory - in the first place. A product or market that was simply "of its time" - and regardless how long, whose time has come and gone - will not benefit from incremental innovation and promises only to consume a lot of investor capital in pursuit of "radical reinvention."

Management that understands the socio-economic factors that gave rise to the opportunity for the business in the first place will recognize the change in conditions, monetize the decline if the change is permanent, and respect investor capital by trafficking in facts. As unflashy as it may be, sometimes the best strategy is not a capital intensive boondoggle in pursuit of a product revival, but periodic marketing campaigns that appeal to consumer nostalgia.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-60330240110755576492017-11-30T23:14:00.000-06:002017-11-30T23:14:00.171-06:00Looking for disruption? Don't look to technology
The chattering classes would have us believe that technology disrupts. It does not. Socio-economic conditions change to create an incongruity that is ripe for exploitation. By way of example, the technology to enable the sharing economy existed for years, but monetizing everything from spare time to the spare bedroom only became appealing when mortgages went underwater, wages stagnated, and the labor participation rate dropped. That computer technology was at the center of this disruption should be no surprise given the rise of the Information Age several decades ago. It certainly wasn't going to be steam engines.

Rather than understanding the disruption phenomenon through the lens of change that has already happened, it is worth looking at the change that has not happened but should have given the availability of technology to bring it about.

For at least 40 years now, we've been told that technology will revolutionize education. Kids can learn from home in immersive media-rich environments, receive continuous feedback on their work intertwined with their lessons, learn at their own pace with tutors and resources delivered to reinforce or accelerate their learning, and so forth. And it could: plenty of technologies exist that make it practical for students to learn advanced subjects in virtual environments, tapping into tutors for private study and multi-media libraries on-demand to experience subjects as never before.

But the revolution hasn't happened. Kids today are still transported en masse to large brick buildings to get talked at for hours on end, just as they have for decades. If better ways of educating the masses are in their second, third, even fourth generation, why are we still closer to the one room schoolhouse than "I know kung-fu"?

We are because entrenched interests create stationary socio-economic inertia that is difficult to overcome. Consider:

K-12 education is free daycare: with real wages stagnant, high levels of single-parent households, and record levels of household debt-to-income, most families do not have the luxury of having a stay-at-home parent.

Education is publicly regulated, publicly provided, and publicly financed: power dynamics of education are political, not commercial, because politicians define education standards, schools are funded by tax revenues, union dues finance political action committees, and teachers (and bus drivers, and school administrators) vote.

Education is big business. Tax reform that targets university endowments has elicited quite a cry from what are arguably hedge funds that happen to be associated with universities (the top 4 US universities have combined endowments over $103,000,000,000). There is also $1,200,000,000,000 in student loans, a debt market that, like all fixed income markets, has an insatiable appetite for growth.

School sports is big business at the high school and collegiate levels. To wit: it is a little bit shocking that the highest paid public employee is a professional entertainer, rather than a professional administrator or legislator. Of course, sports is big money to the institutions with limited compensation - scholarships pale in comparison to the television revenues - to the athletes.

The status quo is not without its defenses. This is important to understand because these defenses are a bulwark against disruption. One defense is that community schooling develops social interaction skills. Another is that team activities like sports and music extend the educational experience beyond fact mastery. These justifications are increasingly without merit. There are no social benefits to bullying, peer pressure, and substance abuse among teenagers; clearly, we can create healthier environments for children to come to terms with diversity, open dialogue and complex social interactions than the toxic environment that is the modern education system. And with so many schools cutting back on arts programs and non-revenue sports (every sport but football and basketball), families increasingly have to go private (meaning, pay out of pocket) for their children to be able to participate in them.

The way the status quo in education has been defended is akin to how the status quo has been defended in wealth management. As passive investing emerged as a threat to active management, defenders of active management argued that passive investment can at best yield "average" returns (that is, returns that match the market) - and who wants to be "average?" That sentiment, twined with selective data flattering to returns on active investing (such as Peter Lynch's aggregate performance and selective years from selected funds), kept money in active for decades despite a preponderance of evidence showing superior performance of passive over time. Stationary inertia is not only quite powerful, it is vigorously defended.

It isn't difficult to imagine just about all primary, secondary, and 100 and 200 level university courses delivered digitally: there just isn't a lot of room for variation in teaching Principals of Financial Accounting I, and how many ways can we dissect James Joyce that machine learning can't match? And, although there would still be a need need for physics, chemistry and medical labs, it would not be necessary at the basic levels: while there is quite nothing like playing with chemicals, a lot of STEM experiments can be modeled in virtual reality, allowing a student to live like Wile E. Coyote without having to depend on cartoon physics to survive the experience.

Technology may have influenced education, but it hasn't transformed it. At best, technology has been co-opted to reinforce the classroom model. The technology exists today to make primary through associate degree education a utility. If unleashed, technology would allow for much more advanced and exploratory work at the boundaries of research. But something has to threaten the easy money in education before that happens. Technology cannot do that by itself.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-78026535202614426342017-10-31T22:21:00.000-05:002017-11-01T13:23:26.649-05:00The Would-Be Innovator's Dilemma
It is appealing to think of your trading partners and competitors seeing your company as an industry leading innovator. More soberly, you know it's only a matter of time before the fundamental economics of your business shift not only out of your favor, but out of what you've always known them to be.

Unfortunately, as we saw last month, innovation is an increasingly expensive game. You aren't the pied piper who will lead industry change, nor can you afford an escalating arms race developing weaponized technology. How do you play the innovation game to win if you don't have infinitely deep pockets to finance voyages of discovery and if you don't have the clout or the charm to convince others to finance your vision?

Do You have the Financial Profile of an Innovator?

It is unrealistic to ask a debt-laden utility to suddenly find its creative mojo. Because it must extract maximum cash flows to service its capital structure, it is organized for maximum operating efficiency. Given that efficient utilities are intolerant to irregular operations, it goes without saying that they are similarly allergic to excessive bouts of creative thinking.

Companies that loaded up on debt in recent years have taken themselves out of the innovation game. Innovation is risk, and equity - not debt - is risk capital. A company that is serious about innovating cannot be beholden to investors demanding predictability. It must have sufficient high-risk capital to engage in high-risk investing.

Changing capital structure doesn't imply foregoing operational discipline. Ambitious innovation - that is, not the incremental kind - is expensive. The bigger your war chest, the longer you can stay in the game. Not to mention that having positive cash flows from operations means not having to beg investors for cash infusions just to keep the dream alive. Retained earnings are investment capital with the lowest cost of capital a firm can get. The operative word is "retained": operational efficiency doesn't fuel innovation if cash is pledged to investors. In exchange for foregoing distributions, you have to convince investors that they are wagering on value through innovation.

Before you go hunting for innovation, you must first thoroughly understand the financial incongruities in your business model that benefit you so that you can be prepared for them to disappear and, more importantly, set the terms for you and your industry peers for sacrificing them. Technology drives out inefficiency. For example, software firms have had to move away from a lucrative license revenue model (pay up front) to a metered cloud-based subscription service (pay as you go). When you go looking for innovation, expect that you will open Pandora's box and unleash the commercial forces that conspire to contract those incongruities. More importantly, prepare your own company for the evaporation of easy money and prepare it to compete on different commercial terms - before someone else forces them on you.

Know Your Business, Know Your Commercial Ecosystems

It is alarming how much business knowledge erosion has already occurred. Some because of attrition, some because of acquisition, and some because expensive knowledge workers were swapped out for cheaper labor paid to simply turn the crank. Whatever the reason, you can't have much hope of ambitiously innovating if you don't have people who know why your customers derive value from you for the things that you do.

That knowledge only covers the current lay of the landscape. You have to have people who understand customer and supplier needs as well as the needs of those who could be but are not doing business with you. You may have deep insights and lots of data about a universe of companies you work with today, but that does you no good if you're not winning the business of people who will do business with you tomorrow. You can find that out through experimentation, but experimentation without context is just guessing. Context is tribal knowledge. It's hard to win the business of a new generation of buyer if none are members of your tribe (i.e., you don't employ anyone of that generation).

If the definition of value and the foundational economics are are being blurred in your industry, you probably can't project your idea of the future all alone. That means selling your ideas on partners and convincing them to move in concert. That requires a thorough understanding of your trading partner's businesses so you can explain why the innovation that is good for your business is also good for theirs.

Build Versus Buy Versus Co-Opt

We tend to think about innovation as something we have to go out and make. Big pharma showed that M&A can be an effective substitute for R&D. One is not a shortcut to the other as each is defined by a complex set of competencies and capabilities. Making requires competency in experience empathy, product management, design, analysis, engineering, analytics and many other skills. Acquiring requires competency in valuation, negotiation, financial engineering, integration (which itself extends to things like corporate culture) and rationalization. Do not go in pursuit of either making or buying in a big way until you build confidence that you have capability to execute competently in a small way.

Of course, the business landscape is littered with expensive technology boondoggles gone awry, and M&A is more likely to be value destructive than value generative. Sometimes the best use of capital is co-opting an emerging threat to the prevailing economics. Whether banks were ever quaking in their boots at unregulated peer-to-peer lenders stealing their most lucrative borrowers, the banks certainly did a good job fueling P2P lending growth to a point of dependency. The tightening of the credit cycle caused banks to pull back their buying, creating a crisis with peer-to-peer lenders that resulted in those would-be disruptors filing for banking licenses themselves - becoming the very thing they set out to disrupt in the first place. Instead of competing by creating a competitive marketplace or buying an emerging competitor, the established banks effectively greenmailed the threat.

Restructure to Innovate, then Innovate or Die

If the easy money of the idea economy has long past, and if "big ideas" are the only ones that will move the needle, then innovation is not incremental but wholesale in scope. This makes it a serious investing activity that encompasses the enterprise, not a lab in the business or a side R&D function. That requires the appropriate capital structure and investors (innovation is risk), the right knowledge (invest in what you know), and the acumen to choose when to act through making, acquiring or co-opting. Leading innovation doesn't have to mean creating "the next big thing", but it always means being prepared to exploit it.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-37477220617900831692017-09-30T22:42:00.000-05:002017-09-30T22:42:10.314-05:00Innovation Exhaustion

"We've tried nothin' and we're all out of ideas."

-- Ned Flanders' mom, "The Simpsons", season 8 episode 8: Hurricane Neddy

We're constantly being told by the popular business press that we live in an "ideas economy," where survival is a function of disruption because consumer behaviors and emerging technologies are conspiring to obsolete the economics of established businesses. There are plenty of examples - music publishing, mass-market retailing, local transportation - where new entrants have left a wake of creative destruction in their path.

Management consultants love to trot this stuff out, because fear of the unknown (who will destroy your company?) twined with tantalizing prospects of runaway riches (you could be the next air-b-n-amazon-uber-twit-book!) make for eager and pliable clients.

What those management consultants don't tell you is, it's expensive being in the ideas business. R&D isn't cheap: there is far more demand for engineering labor than there are engineers to be hired. And, a lot of R&D is terminal: you have to try a lot of things before you find something that pays for itself. Costly research that tells you only what not to do is cold comfort when you're trying to figure out what it is you should be doing.

It also appears that the economics of the "ideas economy" have been slowly eroding for a very long time. According to this paper, the number of people working in research has grown at a much faster rate than economic growth. Consider semiconductors: "The number of researchers required to double chip density today is more than 18 times larger than the number required in the 1970s." Inflation has risen only 6.5 times since 1970. Yowza.

Of course, that could mean there are too many slackers in research jobs, or that we have more eggheads than our economies can afford. But the real culprit seems to be a scarcity of ideas: they're just getting harder to find. As Izabella Kaminska wrote in the FT, "if research productivity is declining it stands to reason it is being offset by increased research effort. This essentially implies that it is getting harder to find new ideas as research progresses."

A big reason for this is economic maturation. There were far more impressive productivity gains in the early stages of the industrial revolution and microcomputer revolution than there were later in their respective lifecycles: the once factories were mechanized and all the back-office accounting computerized, the big and easy gains were made.

But even Amazon is showing signs of innovation fatigue. In the last 6 years, sales are up 5x, but employee headcount is up 10x. Liabilities are growing as fast as cash, suggesting free cash flow isn't improving with time. And, Amazon's growth rate is far lower than what Wal-Mart's was at a similar point in its history. If growth has slowed, capital intensity is up, and total labor spend is up, either platform monopoly economics aren't what we think they're supposed to be or they will take a very, very long time to materialize. This isn't to say Amazon isn't going to grow, or be a threat to traditional retailers and other industries, but it is to say that even Amazon is showing evidence of idea exhaustion.

What about the major disruption that appears to be on the horizon, like distributed ledger technology?

Blockchain could eliminate redundancies across companies, reduce fees for simple transfers, and usher in all kinds of innovation. It can, but the economics won't materialize as rapidly as ideas of yore. As long as the network is stubbornly difficult to secure and access, trust will remain with the institutions using the network, not the network itself. As long as trust remains with institutions and not the network, the institutions will have no choice but to maintain their own ledgers for a long time. That means that companies in ecosystems that adopt distributed ledger technology will find opportunities for innovation and gain some efficiencies, but will not be able to exploit its full potential for quite some time. Innovation and productivity from disruptive ideas, while still present, will fall short of potential.

This is the storyline with all emerging disruptive technologies. We may get autonomous long-haul trucks but we will still require drivers in the cab, we have shared ledgers but a lot of that data will remain duplicated throughout consuming organizations, we allow initial coin offerings but we regulate them as securities. There are economic benefits, sure, but the economic windfall they promise is just out of reach. That revolutionary new economy is delayed at the airport.

The chattering classes are telling us that we live in an "ideas economy" a full half-century after it was ripe to traffic in ideas. A more appropriate term might be the "ambition economy", because to reap the benefits of the possible requires a significant break away from the known and familiar. That's more than innovation driven by a single firm; it requires moving ecosystems of consumers, suppliers and regulators.

For those caught in the crossfire - firms that don't much like the prospect of winning a participant trophy in a costly innovation arms race, and don't have the gravitas to lead ecosystem change - what alternative do you have? We'll look at the options next month.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-39243822534936477662017-08-31T22:38:00.000-05:002017-08-31T22:38:10.930-05:00Partners
"Greed and patience don't live together very well."
-- Keith Jackson, ESPN 30 for 30, Who Killed the USFL?

Businesses rely on a network of suppliers to operate and grow, including providers of components, back-office operations, distribution, marketing, retail, information technology and even office supplies. They do this for a variety of reasons, ranging from areas of specialty (assembling large finished goods is different from manufacturing small, precision components), depth of expertise (some companies are better at selling things than making things), accessibility of labor (difficult to hire in a location where there are too many jobs chasing too few employees), and appeal to the people with the skill set (a wholesaler doesn't offer that much career growth for an attorney).

All relationships, whether personal or commercial, are based on need. A buyer looking for widgets will go to another supplier if they can't get the widgets they're looking for. Similarly, a seller may choose not to sell widgets to a cheapskate buyer, and will find other customers instead.

Although rationally the statement of cash flows should triumph in commercial relationships, we're very often asked to extend our balance sheets to help someone else. In a commercial context, this is the point at which terms like "supplier" and "vendor", "client" and "customer" are ditched in favor of the aspirationally higher ground implied by the word "partner". Rather than evaluating transactionally (this relationship comes at a high cost to me), we evaluate strategically (this relationship is important to me).

Choosing to underwrite a shortcoming in a relationship is to make a leap of faith that there will be tangible or intangible rewards for doing so. The executive who keeps changing the specifications but always gives a glowing recommendation, the company that provides your firm with the annual revenue if not the timely cash flows. A partner puts up with deficiencies because they get much more out of the relationship.

Partnership, then, encompasses more than just a relationship of need, but a relationship worth it to both parties to make sacrifices to sustain. When we partner, we each agree to ebbs and flows in the relationship - "in sickness and in health" - and that we will not merely tolerate, but accommodate. A seller that has to roll somebody off a team because they can't travel; a buyer that has to reduce the amount they spend. In these situations, a partner sets aside the short-term impairment for the long-term benefits of continuity and consistency.

Of course, there are more benefits than merely convenience. Each partner changes independently, and those changes keep the partnership relevant and fresh. In the process, each learns continuously from the other, evolves what they do and matures how they do it. Strong partnerships make stronger individuals.

Partnership implies equivalency. Yet the commercial world is full of alleged "partnerships" that are superior-subordinate, making them inherently unbalanced. Companies stay in condescending or even abusive relationships because they're afraid of the uncertainty of the alternative. Sellers do this because suckling at the teat of easy revenue is far easier than hustling new business. Buyers do this because they feel held hostage by a supplier. Even though it comes at a high commercial cost (squeezed margins) and high human cost (second class status and compromised careers for those involved), such business "partnerships" can last for a long time.

Egalitarian partnership, then, is more often wishful thinking than willful practice.

Whatever else they may do, partners do not try to get the better of one another. If one party feels it has to out-maneuver the other in every contract negotiation, pad or dispute every invoice, cast doubt on quality or contribution well after delivery as a means of finagling a discount, or flaunt payment terms, it isn't a partnership. This isn't competition that makes for stronger individuals and better outcomes, it's subversion that prioritizes individual gain over mutual outcome.

There's nothing wrong with transactional relationships, and if we're honest, most commercial engagements don't have the potential to become genuine partnerships. Partnership is investment, and like all investments, there's only so many you can make and maintain. Over-using the term and confusing one type of relationship for another does the people and companies you do business with a disservice because it implies a commitment to them that you're not making. Transact faithfully with all (the world is a better place when it gets by on trust), and partner intensely with those who equally benefit from your association.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-65180584753213760182017-07-31T23:56:00.002-05:002017-07-31T23:56:59.308-05:00Invest in What You Know
Every day, millions of people buy expensive things they don't know much about: cars and residential homes, enterprise software and entire enterprises. Having a deep pocket - or investiture by people with deep pockets - is the only qualification required for an individual to have buying authority. As we saw previously, emotions have a share - often a disproportionate one at that - in buying decisions. This makes value a relative rather than an absolute concept, and absurd as a summable metric.

When purchases get large, we re-cast them as investments. As assets, acquisitions appreciate in value on their own (e.g., real estate) or they enable us to derive greater economic value than we otherwise would without them: a truck depreciates in value, but it is inefficient to run a flower delivery business without a truck, so having a truck on the asset line of the balance sheet boosts revenue on the income statement. Unfortunately, a lack of expertise in the things that we buy tends to give non-economic factors an important role in the decision. We may know horticulture and the asthetics of flower arrangement but not know much about forecasting operating costs and reliability in city driving, so our business investment comes down to factors like style, comfort, or just liking one salesperson over another.

Purely financial investments aren't immune to this, either. We're not experts in industrials or tech firms or utilities or the ETFs that collect them, so we develop criteria (consistent dividends, revenue growth), create justification frameworks (safety, income), and consult experts (research firms), but in the end we follow our emotions (I soooooooo love their products I'll park my IRA in their stock). We want to equate investing with rationality, but a lack of expertise - and the pressure to make investments - make it anything but rational.

Many people in the tech industry - myself included - have advocated recasting technology as a financial phenomenon that yields returns rather than an operating cost to be minimized. Well, more accurately, recasting some portion of technology this way. We don't need to measure return-on-the-time-and-expense-system: it's a tax on our business and all we want to do is pay as little per staff member as we possibly can. But we can't expect to create high-risk call options (R&D) or make strategic capital allocations (platforms) with stay-in-your-swim-lane staffing and structure. Form follows finance: because of the outsized effect that finance has on operations, we start by changing the funding model, which clears the path for new structure and process. Follow the money.

If tech is going to function as a financial rather than an operating phenomenon, it must take its guiding principles from financial investing. Benjamin Graham implied and Peter Lynch practiced the idea that you should only invest in what you know. Get to know the industry dynamics, the company in particular, and the people operating it before pledging any capital. You'll still have disappointments, but far fewer surprises. This separates thoughtful investing from reckless gambling.

In technology, "investing in what you know" requires substantial business domain knowledge and tech fluency with generous helpings of behavioral science and economics. Successive waves of efficiency gains mean we can't take intimate business knowledge for granted any more. All the organization, process, and ceremonies won't compensate for a lack of these things, the evidence of which is seen in the reference cases of Product organizations that create confusion rather than cohesion, and the large replatforming initiatives that require additional cash calls and goal reduction to be deemed successes. If we're going to "invest in what we know", the leadership imperative is in securing the fundamentals so that we have the basic competencies in place.

But that presents us with a recursive investing challenge. Developing the capability to competently invest in technology is an investment itself, and must be held to the same standard: are we investing in something we know? Do we know what we're looking for in that investment into capability? Or will investments in our future leaders be more emotional than rational?
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-10072901286154943732017-06-30T23:12:00.000-05:002017-06-30T23:12:18.929-05:00The Value Myth
When we think about value, we think in terms of hard measures like increasing revenue or decreasing cost, or soft measures like increasing customer satisfaction or reducing customer friction. This all sounds great, but we know in practice that value is not as concrete as we would like to believe: projections are conjecture, there are multiple forces at work that determine the result we get, and counterfactuals can't be proven to know for fact whether we'd have been better off doing something different or nothing at all given how circumstances played out. Good as it might be that value allows people to relate their actions to hoped-for outcomes, it is naive to think that the outcomes will result from the sum of the actions that we take. Business is far more complex and far more messy.

Saying otherwise is disingenuous, because it gives business a theoretical tidiness that it simply does not possess. Perhaps this is inevitable when non-business people like program managers (coordinator-administrators) and developers (engineer-nerds) traffic in business concepts (finance). Whatever the reason, it isn't helpful if tech wants to be taken seriously by the professionals - particularly the finance professionals - who run the business. Showing a direct line-of-sight from tech or process to business outcome sets up tech to get played and manipulated. Going from tech to business value in one step is a short-cut to being relegated by the board; it is not a path to business relevancy.

In this series of posts, I've taken a different tack, focusing on value and worth as behavioral rather than economic concepts. It stands to reason that if value and worth are in the eye of the beholder, their definitions will be heavily influenced by individual biases. Success of any business initiative comes down to behaviors, so the better we understand those the better we understand the complexity of what value really is in a complex business context.

Value is different things to different people for vastly different reasons. Consider insurance claims. During a storm, high winds blow a tree down and onto a house, collapsing a section of the roof. Insurance adjusters don't care about the aesthetics of different colored roof shingles used in the repair. The adjuster only cares that the roof is repaired and the house won't be taking on ballast the next time it rains. The insurance adjuster is under orders to repair the house with minimum impact to the insurance company's cash flow, and is therefore focused on the utility (which is easy to quantify), not the aesthetics (which are not). That the first thing any prospective buyer will point out is that those green roof shingles clash with the existing gray roof shingles appears nowhere in the adjusters "cost of repair" spreadsheet: whether green or gray or fluorescent pink, those shingles will keep out the rain and the snow and the critters. For the insurance company, the asset they insure was repaired with minimum impact on their cash flow.

The same applies to tech. An engineer infatuated with the tech stack supporting a hopelessly implemented feature set. A user clinging to an interface backed by an impenetrable monolith of code. The CFO who is tone deaf to responsiveness and excessive defects, solely because of the price. Try as we like to frame "business value" as an absolute, in practice it is a relative concept, interpreted and reconciled to the motivations and desires of each individual in the value chain. What gets measured is what gets managed, so "business value" becomes the means through which individual value is realized: we need this over-hyped cutting-edge tech stack because it will help us deliver it faster; how conveniently coincident that experience with that over-hyped cutting-edge technology flatters the resumes of the people working on it.

This creates cascading re-interpretations and re-assertions that smother value, ironically justified by the pursuit of value. A firm I audited years ago had, some months prior, formed a cross-functional committee of tech, business and finance to choose a mobile development toolkit. Business believed it needed a mobile solution, tech aspired to create one, but the board didn't share in the enthusiasm. In the end, finance won out, choosing the tool that cost the least but that tech found unstable and yielded software solutions the business didn't much care for. The tool was never used. Instead, developers rolled their own frameworks and infrastructure, below the radar of the CFO and with a wink-and-a-nod agreement with their business partner that they would do so. The purchased framework had negative value to its intended constituents, to a point that tech believed there was more value (and with the complicity of business in the decision, to the business as well) in creating proprietary development infrastructure. Whether spending twice for infrastructure was tech rescuing the "value" jeopardized by a crap product, or tech being intransigent and subversive to the board's agenda, all depends on your definition of value under the circumstances.

We don't win the triple crown of value all that often. Marketing doesn't appreciate losing the pricey boutique firm they could talk to each and every day, but tech looks like stars to the CFO for sending the work to a cheap offshore supplier. The CIO doesn't like being held hostage by employees who used an obscure tech stack in the name of getting something done "faster", only to be making it debilitatingly expensive as they exit the firm and go into private practice. Eliyahu Goldratt pointed out the tradeoff of local optimization for systemic optimization a long, long time ago. Local optimization infiltrates every value calculation, in temporal ways that defy models of value.

 We want to believe that "value" is an absolute measure of something that improves the condition of the enterprise: In unitate es virtus. But we know that people have different interpretations and goals that materially impact the business outcome, so value is a weighted sum of disparate, unexposed agendas. The larger the enterprise, the more complex the calculus.

Value is money, and where there is money, there is politics. With that in mind, value is perhaps best understood as something Mike Royko taught us about the fundamentals of politics many years ago: Ubi est mea?

"Where's mine?"
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-69097779566252485642017-05-31T23:38:00.000-05:002017-05-31T23:38:00.234-05:00Questions of Value
In March, we looked at questions of worth. This month, we look at "questions of value".

In the dictionary, value is defined by worth, and worth is defined by value. Why ask the question twice? Because even if they refer to the same thing, the words mean different things in different circumstances. In economic terms, "worth" refers to stored value, such as accumulated financial reserves (one's "net worth") or the price we're willing to pay to replace something we already own. We use the word "value" in reference to economic (or other) power unleashed by something that we have or do. An object has sentimental "value" to which we ascribe an inexplicably high economic "worth". An investment in a truck yields economic "value" on the income statement well above the worth we ascribe to it on the balance sheet, because without it we couldn't achieve delivery efficiencies.

Value traffics in moving, worth in storage.

Value is what we're willing to pay for something in exchange for the returns that it provides. We value cars for reasons ranging from their resale value to the status we think they project to the friends and strangers who see us driving it. We value houses for the school districts we can put our kids in, the relative price of houses nearby, their convenience to how we live and make our living, and the status that living in that post code conveys.

In software, we want to make decisions about where we invest based on value. But because we can't predict the future, value is conjecture. This forces us to ask: what defines value? And who defines value?

Value, like love, is a many splendored thing. There is value derived from features, there is value derived from construction, and there is value amplified from not spending too much. An asset that does many things, is low maintenance, and costs little will be higher yield than one that does few things, is high maintenance, and costs dearly. The problem of defining value is the problem of projection because there are no absolutes in those projections.

This creates a bit of a problem, because value is a future-tense term, and we can't know with much certainty what the most important characteristics are to realizing that value. This becomes a big problem when we want to "buy for value". Worth is bankable, if vulnerable to erosion; value is in the eye of the beholder and may never materialize.

Consider a house. Buyers define all kinds of evaluation criteria, things like proximity to public transportation, newer appliances, and rooms and layout that accommodates their possession and lifestyle. But a house is a building and its utility is a function of its construction as much as its design. Since most home buyers aren't carpenters or plumbers or electricians, they're not able to judge quality of the build. They rely on the opinions of experts. Hence we have inspectors, who are licensed in most states and built into residential contract law to provide their expert opinion on the house.

Selection criteria and expert opinions only go so far, though. A homeowner doesn't really know if a house is what they want until they've lived in it for a while, and besides, some of their criteria will be contradictory and some of their priorities will be out of order. Inspectors have limited expertise with building codes, practices and materials, and they're only spending a couple of hours looking over the carpentry, masonry, electrical, plumbing and mechanical of an entire building that took hundreds of person days to build. For all the sweating and scrutiny, at best our opinions tell us that we shouldn't buy something; they don't necessarily tell us specifically why we should. All house purchases are compromises, and in the end, the purchase is made for substantially - perhaps even largely - emotional reasons, and complex ones at that.

This applies to all kinds of purchases where "value" is a factor. Like cars: we develop criteria (seats, storage, zero-to-sixty speed), poll experts (trade press like Consumer Reports and Car & Driver), but still make a decision that is partially - even largely - informed by emotions. Look, it's got four doors, space for the kids & clubs, it's fuel efficient, and will you just look at those shouty rims?

Questions of value become even more conflicted when multiple stakeholders have different ways in calculating value, and ambiguous authority in setting it. We'll take a closer look at that next month.
 Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-25875827278030381012017-04-30T21:47:00.000-05:002017-04-30T21:47:09.744-05:00Concrete Versus Abstract
Until a few years ago, enterprise software development was pretty easy to justify and execute because the income statement was the primary customer. Automating back office tasks, expanding market reach, creating customer self-service tools, even legacy technology replacements were all investments that could be explained in a straightforward manner as taking costs out or capturing revenue that would otherwise have been lost. Business cases weren't all that complex, and results were easy to direct.

The nature of enterprise tech investments has changed. We want consumer-facing tech that is less workflow-driven and more situationally adaptive. We want platforms on which we can quickly build complex applications, not a collection of solutions that we tie together with jumbled integration and overlapping data warehouses. These investments are justified not by cost or revenue, but by a future defined by new consumer behaviors and new services; it is a future we do not control and over which we cannot judge our influence, and by their emergent nature offers no baseline for measurement. As tech investments become more ambitious, their investment criteria become more nebulous and vague, their justification more speculation and hope, and their actual impact more difficult to trace and validate.

The landscape has become far more abstract, too. For one thing, the business threats have become less physical. A business had months to prepare for a rival building an outlet down the street, but can't immediately see (let alone know how to respond to) a purely digital competitor slowly siphoning away customers. For another, the tech is less tangible. Technology was easier to grasp when you could map software solutions to a handful of rack-mounted servers and desktop PCs; try explaining cloud-based AI architecture to non-tech buyers as anything other than a black box.

Yet enterprise execution remains rooted in the concrete. Companies achieve scale and efficiency through disciplined execution: develop patterns of operations, sweat the details, codify procedures, and spread through an ever growing network. The more cookie-cutter, the more predictable; the more efficient, the more cash flow from operations.

I've written before that this encourages heavy levels of debt finance, and that debt finance stifles investment by crowding it out: debt not only consumes cash that could otherwise be used for investment, it discourages high-risk investments with unknown returns. Debt finance binds a company to a tomorrow that is the same as today. Visions are equity plays, not debt ones.

Capital structures aside, there's another aspect to this: enterprise leadership that isn't equipped for the challenge. The enterprise leader must be capable of forming a considered opinion on tech and business matters to know whether someone is feeding them the level truth or blowing sunshine up their backside. That leader must be able to describe the world through the lens of a plausibly achievable future state, not something that comes across as improbable sci-fi, and more substantive than a how-things-have-always-been-only-faster state. That leader must be pragmatic enough to know how to walk the fine line between enabling knowledge workers to hold the future hostage to their subject matter expertise, and overwhelming those knowledge workers with change fatigue, maturing them into future operating leaders of the business.

This requires a leader with depth of knowledge in operational, technical and financial matters. It also requires an ability to think abstractly and translate abstraction into concrete action. He or she will have to articulate an integrated business & technology operating model, restructure finance from cost-driven to investment-driven, and change recruiting and retention and contracting practices. Plus, she or he must be able to explain why the current modus operandi is geared toward running the wrong kind of business (an efficient opco), and what is necessary for it to become the business it needs to be (an efficient opco ingesting the innovation generated by a biz&tech platformco).

This leader cannot over-emphasize one area - the transformation, the vision, the tech, the finance - above others. Doing so creates an imbalance that will lead to organ rejection by the established enterprise. Key enterprise constituencies don't react favorably to having their area of specialization demoted. It starts whispers that "this person leading our so-called replatforming just doesn't get the business" that undermine their leadership.

The hard-driving entrepreneur, the professional administrator, the technology futurist are the wrong leader archetypes. This calls for statesmanship, someone who can project from policy to practice in a complex corporate and competitive landscape, translate goals and changes into multiple business tongues (the executor, the developer, the middle manager), behave diplomatically while remaining above corporate politics, and be patient for new business principles to sprout within the enterprise.

Of course, people who fit this bill are as rare as hen's teeth. Operating companies don't incubate abstract thinkers, they incubate concrete thinkers because they reward concrete execution. Nor does it help that we've taken authority away from middle managers instead of developing them into the next generation leaders.

The firm that does recognize the scope of this leadership challenge but can't staff the role from within or without will resort to the multi-headed leadership team (at least one business and one tech, potentially more from across the corporation depending on the political landscape) and hope that the whole will be equal to the sum of the parts. Conway's Law guarantees that the outcome will be plagued with local optimizations that inhibit - and potentially impair - the hoped for outcomes.

Ambitious transformative tech investments may be viable, and even necessary for survival. They need vision and execution, cooperation and skills. But they're going absolutely nowhere without the right leaders and leadership.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-60953345714227789582017-03-31T23:57:00.001-05:002017-04-01T00:04:56.584-05:00Questions of Worth
Price is the critical determining factor in purchasing decisions. If I want a new case for my tablet, and I know the case that I want, it's worth a considerable amount of my time to find the lowest price on offer for that case. A penny saved and all that.

Utility purchases are driven by price sensitivity. If I can't really say one product is a premium offering to another, I'll go cheap at the sales. I need calories after I run, a breakfast bar will do, I don't need a designer breakfast bar.

While I was writing chapter 3 of my book, Activist Investing in Strategic Software, I spent time researching the rise of centralized procurement departments in the 1990s. De-centralization in the 1980s created inefficiencies in cost management: it wasn't uncommon to find that one division was paying far more than another division for an identically skilled position supplied by the same vendor. Centralized purchasing found efficiencies by standardizing roles and position specifications and granting preferred partner status to contract labor firms. In theory, standardized buying lifted the burden of negotiation from individual department managers and found cost efficiencies for the company. Buyers could more atomically define what they were buying, sellers swapped margin for volume.

And tech labor became a utility.

Procurement's ascendance didn't create industrial IT (there were already willing buyers and sellers of narrow skill-sets), but it certainly threw copious amounts of fertilizer on it. Within a few years, we saw significant expansion of contract labor firms (or "services", or "consulting", whichever you prefer): firms like Accenture and Infosys grew rapidly, while firms like IBM ditched hardware for services. Buying became an exercise in sourcing for the lowest unit cost any vendor was willing to supply for a particular skill-set. Selling became a race to the bottom in pricing. In this way, tech labor was cast as a utility, like the indistinguishible breakfast bar mentioned above.

In captive IT, the notion of a "knowledge worker" that came to prominence in the 1980s was stampeded by the late 1990s. Knowledge workers are a company's primary labor force, but through the miracle of standardization, tech people became collections of skills, and subsequently interchangeable go-bots. By extension, tech became a secondary labor force to clients. Labor extracted rents from the client for which it toiled, but labor had no equity in the outcomes that it achieved. Tech labor was wage work. It might be high-priced wage work, but it's wage work none-the-less.

With all cash and no equity, employees now had clear rules of the game, too. Certifications became the path to higher salaries. It didn't matter whether you were competent, Sun certified you as a Java developer, Scrum Alliance a Scrum Master, PMI a Project Manager, any employer a Six Sigma blackbelt. In exchange for minor rent extraction by agencies exploiting an industrialized labor market, buyers received 3rd-party reinforcement of their contract labor model.

With all the ink being spilled on subjects that managers of enterprises like to traffic in - things like Agile delivery, product organizations, platforms, disruptive technologies, and the idea economy (obviously, some more meaningful than others) - it's difficult to understand how companies still choose to source labor like it's 1997. The people I need to build long-lived products on my-business-as-a-platform-as-a-service using emerging technologies don't fit any definition of standard procurement. These aren't left-brain skills, they're right-brain capabilities. If you buy the cheapest knob-twisters that money can buy, how could you possibly have any expectation for creative thought and innovative output?

At the same time, it isn't that surprising. Procurement sources all kinds of contract labor, from executive assistants to accountants to recruiters. Yes, technologies like Office, SAP and LinkedIn are fantastic, but they're not exactly the equivalent of serverless in tech. If the bulk of the labor you source is check-the-box, why would you expect - or more to the point, how could you be expected to comprehend - that tech is unique? Accounting is, well, accounting after all. It's not a hotbed of innovation. In fact, it's usually bad news when it is a hotbed of innovation. "Innovation" in tech is - particularly for non-tech manager / administrators - just a buzzword.

In enterprises with dominant procurement functions, "worth" is a function of "cost", not "outcome". If we rent labor on the basis of how much a unit of effort denominated in time will cost, the "worth" of a development capability is the sum of the labor times its unit cost. We therefore value scale because we assume productivity is an implied constant. If we don't understand sausage-making, we simply assume that more gears in the sausage-making machine will yield more sausage. We fail to appreciate the amount of energy necessary to drive those gears, the friction among them, and the distance those gears create between hoofed animal and grill-ready skinned product.

Thus we end up with a payroll of hundreds doing the work of dozens.

Our economic definition of "worth" precludes us from understanding what's going on. We have the labor, so it must be some sort of operational deficiency. We look to process and organization, coaches and rules. All of which is looking in the wrong place. We're not a few coaches and a little bit of process removed from salvation. We staffed poorly, plain and simple.

What a development capability is "worth" has to be correlated to the value it yields, not metered effort or even productive output. Something isn't "worth" what we're willing to pay for it, but what its replacement value is to provide the same degree of satisfaction. If we're getting the output of dozens, we're willing to pay for dozens. The capability of high-yield dozens will be more dear on a unit cost basis. But clear accounting of systemic results will favor the cost of polyskilled dozens over locally optimized low-capability monoskilled masses.

This is the economics of "worth".
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-69392871351853088552017-02-28T23:53:00.000-06:002017-02-28T23:55:01.610-06:00Our Once and Future Wisdom: Re-acquiring Lost Institutional Knowledge
Last month we looked at the loss of institutional memory and the reasons for it. This month, we look at our options for re-acquiring it.

The erosion of business knowledge is not a recent phenomenon. Management textbooks dating at least as far back as the 1980s included stories of employees performing tasks the reasons for which they didn't really understand. The classic reference case was usually some report people spent hours crafting every month that they distributed to dozens of managers and executives, none of whom read it because they didn't know what it was for. Those execs never put a stop to it because they assumed another exec knew why it was important. Then, during the much-anticipated system replacement, some business analyst tracked down the person who wrote the report specs so long ago; after he was done laughing, that person told the business analyst the crisis that triggered the need for that report ended many years ago, and he couldn't believe they were still wasting time producing that report.

This story always seemed apocryphal - of course that could happen, but people are smart enough that it wouldn't really happen - until I saw it first hand at an investment bank just 6 years ago.

Natural (retirement) and forced attrition (layoffs) have long robbed companies of their knowledge workers. The rise of automation has simply made their loss more acutely painful. Accounting for knowledge hits the income statement in the form of the salaries of experienced and tenured employees; unfortunately, the value of their knowledge has no representation on the balance sheet. Extracting greater cash flows through payroll reduction is value-destructive in ways that accountants cannot (or at any rate, do not) measure.

If we have a business that hasn't yet gone full zombie that we want to pull back from the brink, what can we do to re-build business knowledge? There aren't a lot of high cards we can draw, but playing them in the right combination offers us a strategy. None of these are discreet solutions, but are a collection of non-mutually-exclusive tools that we can use to bridge a knowledge gap.

Tool 1: Dolly the Sheep

Companies that are heavily rule-based - think insurance - eagerly moved their business rules into code. It was easy to move into code; it's just as easy to move it back into human-readable format. Hire some developers fluent in a legacy technology, make sure you have an objective way of auditing their extraction of the rule base, and identify a cadre of employees who can understand those rules well enough to more comprehensively catalog and contextualize them. It's cheap (people paid to document code will be less expensive than people paid to create code) and hygienic (preservation of business information is a good thing) and it makes our business rules accessible to a wide audience spanning business users, managers, business analysts, and quality assurance engineers.

Of course, this is data, not information. A working foundation of facts is better than none, but facts are of limited value without context. And, while it's easy to reverse-engineer facts like rules, it's not so easy to forensically construct the business contexts that encapsulate those rules. A clone of something extinct - our lost business knowledge - runs the risk of suffering severe defects. For example, ghost code - code that is not commented out but will conditionally never be executed - is likely to be confused for real code in a reverse-engineering exercise. The facts are fantastic to have, but facts are not knowledge.

Tool 2: Seek the Jedi Masters

Somebody (well, somebodies) figured out how to automate the business. There are people behind the systems to which we're bound today. Why not put them back on the payroll? If they're still alive (always a good start), local and accessible, and grateful to the company for the income that put food on their table and their children through college, welcome them home. Techniques like value stream mapping bring them back to a business-operations mindset, allowing the business "why" in their heads to be extracted in a structured and coherent manner.

Of course, this isn't as simple as it sounds. Former colleagues won't come cheap. A knowledge worker who was forced out years ago may not feel inclined to share the wealth of their knowledge. The business will have evolved since the time these knowledge workers left. Corporate policies may also interfere with a re-recruitment campaign: one company I worked with forbade engaging contractors for more than 24 months, while another forbade contracting former employees at all.

You could also hire people who work for a primary competitor: In his book The Competitive Advantage of Nations, Michael Porter pointed out how industries tend to form in clusters; so if you're in an industry that isn't post-consolidation there's a good chance you've got a direct competitor nearby, offering a source of business knowledge you can recruit from. Again, this isn't as easy as it sounds. It's hard enough determining whether the people in our own business really understand the business "why" behind the things that they do, or whether they just know the complex motions they go through. It's even harder to do that with people grounded in another company's domain: if our business knowledge is in short supply we won't have the business knowledge to ask the abstract questions to gauge their comprehension of the business; plus, we may speak fundamentally different languages to describe their implementation. If their knowledge is too finely grained - that is, too specific to the context of our competitor - their knowledge won't travel: they're a subject matter expert in our competitor's operations, not in the industry. Plus, if our loss of business fluency was the result of corporate blood-letting, it's highly likely that our competitor up the street has done much the same, and will be no richer in domain expertise than we are.

One final word of caution is that we have to challenge the "why" the experts give us. Ten years ago, I was leading an inception for a company replacing their fleet maintenance systems. Their existing system was a combination of a custom AS/400 based RPG system (that had started life on a System/34), a fat client Visual Basic application, and thin-client Java tools, all of which required manual (operator) steps for data integration with one another. The user got to a step in the workflow in the VB application, then transferred data updates to the AS/400 and resumed there, then transferred data updates to the Java application and resumed there, all over a period of days or even weeks and often going back and forth. Their experts genuinely knew their business, but had grown so accustomed to the data transfer steps that they ended up baked into the initial value stream maps we produced. It took a lot of challenging the "why" on those specific portions of the value stream before they understood how a simple shared database would eliminate lots of no-value-added inventory control steps.

Still, maintaining a connection with the people who were there at the creation helps us identify the things so important for us to know if we're going to evolve or pivot from it. In much the same way as air traffic controllers are taught how to land planes in the event the software fails on them at a critical moment, former knowledge workers can help re-build our knowledge from the ground up.

Tool 3: Buy Before you Try

If you're on your way to becoming a zombie company, why not eat someone else's brain? Re-constructing a lost capability is expensive, so buying a competent operating company - along with its digital assets - is a shortcut. This assumes that you as the buyer can make an informed decision about the competency of the people you're acqui-hiring. It also assumes that the people in the acquired stick around after the acquisition.

A reverse-acquisition can take one company's girth and bloat and wed it to another company's core nimbleness and agility. But M&A is ego-driven: the CEO or board member who wants to do a deal will see the deal through regardless the state of the acquirer or target. A few years ago, I worked with a holding company that had bought two competing firms that collected data about banks and sold it on a subscription basis. As their product was becoming digital, the value of the data they sold was plummeting (as most data tends to do when it becomes digital), so we helped them define a strategy to combine the companies and transform them from providers of data to providers of digital tools. Three days into the inception, we were frustrated that the workshops had ending up with incomplete and unsatisfactory levels of detail. We hypothesized the reason for that was because the experts weren't all that expert. On day 4 we ran a series of experiments in our workshops to test this hypothesis, and in the process confirmed that the activities they performed in the acquisition, curation, publication and distribution of the data they sold were performed for reasons of rote, not reason. The inception was successful in that it exposed am inability to execute on the strategy in the manner they had hoped to do, which led to an entirely different approach to execution.

Buying is a shortcut, and as Murphy's Law teaches us, a shortcut is the longest distance between two points.

More modestly, we can simply license technology to replace major portions of legacy systems, and train or hire experts in that technology. This, though, substitutes solution knowledge for business knowledge, and the prior isn't necessarily a proxy for the latter: even though commercial ERP systems have largely replaced home-grown ones, those commercial solutions are highly customized to the needs of the business.

Tool 4: Play Calvinball

We're barraged by business media to be internal drivers of digital "disruption" because it puts our competitors at a disadvantage, challenging their leadership by forcing them to chase after us. But disruption is also a means of rebuilding lost business knowledge: if we change the rules of the game, we're less restrained by our current assets and procedures. The more we can change, the more we set a new agenda in the competitive landscape. Ideally, we should be playing Calvinball, and make up the rules as we go along.

Disruption is a tool, not a solution. Disruption may be constrained by prevailing legislation and regulation, while regulators tend to look at established firms differently from upstarts - if they look at them at all. In the wake of the 2008 financial crisis, bank lending declined in response to higher capital requirements against risk-weighted assets and tighter lending standards; marketplace lenders skirted balance sheet restrictions and lending regulations simply by not being chartered banks. This allows marketplace lenders to underwrite loans with much more flexibility than a bank. The door to this type of disruption was closed to banks. As with Calvinball, it is the player with the ball who makes the rules, and banks (like many other regulated businesses) aren't the ones holding the ball.

Plus, when we build on existing business rules rather than replace them, we're not moving away from a dependency on fundamental knowledge that we don't have. Re-imagining how an existing offering is packaged, distributed or even consumed doesn't alleviate the need to understand the core characteristics of that offering.

Making the Best of a Bad Hand

Re-gaining lost business knowledge is a slow, sometimes difficult, and usually expensive proposition. Pushing too hard to re-acquire it is like beginning to learn calculus and non-Euclidean geometry the night before a comprehensive final exam: a grade of D- would be a small miracle. But, since strong business knowledge is key to executing any business strategy pursuing growth or evolution, a grade of D- isn't going to cut it.

Worry less about the slow rate of re-acquisition and think instead about where you want your business fluency to be in 6 months, 12 months, and beyond, and how much more effective your organization will be at those times. That guides the extent to which you employ each of the four techniques described in here and how they get you to a greater state of fluency so that you can operationalize the business strategy. For example, contracting legacy language developers to capture encoded logic and hiring in a couple of retired employees for value stream mapping sessions, all in exchange for donuts and a fat payday for a few months, may be an effective and inexpensive precursor to an acquisition, or provide suitable grounding to initiate disruptive change that re-writes the rules of an industry.

This requires us to prioritize organizational learning along side operating performance and delivery goals. The latter two are quantifiably measurable and glare at us from our financial statements; the prior is not and does not. A commitment to learning is an investment that needs board-level visibility and air cover: without the learning there is no execution, and without the execution the strategy is just an elaborate Powerpoint. Board-level patience isn't infinite, so in exchange for an investment in learning, line management will have to commit to strategic execution - even if it has to commit to execution before it has re-learned as much as it would like.

The alternatives are to be acquired (sooner rather than later, at peak value for the book of business the company still commands) or slow obsolescence (and concomitant market irrelevance). Since this gives the people in the company a fighting chance, trading a commitment to learn for a commitment to strategic execution is a fair exchange.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-77795803945333527282017-01-31T22:41:00.000-06:002017-01-31T22:41:07.405-06:00Where Has All the Business Knowledge Gone?
I was queuing for a flight late last year when two people standing behind me started talking about how disappointing their trip had been. They were in consultants in logistics, and they were lamenting how one of their clients was struggling in the wake of a business process change that another firm - a tech consultancy - had agitated for their mutual client to adopt. The client in question purchased and warehoused perishable items, hundreds of thousands of different SKUs that they distributed to retailers ranging from tiny independents to large global chains. The distribution operation was built on efficiencies: fill delivery trucks to a minimum of 80% capacity and deliver products to customers on routes optimized for time and energy consumption. Cheap distribution keeps product prices down, which makes their retail clients more competitive. The up-start tech consultants pushed for flexibility: more frequent product deliveries made to the same stores throughout the day would keep shelves stocked, so they could better match stock to store. If there's a run on one item it can be replenished much sooner, resulting in fewer lost sales. Unfortunately, more frequent deliveries required more frequent truck dispatch; trucks could only be dispatched more frequently if they spent less time being loaded with products, so the load level of a truck fell to below 50% of capacity; expedited dispatch also meant ad-hoc rather than fixed routes, which resulted in driver confusion and receiving delays that translated into higher energy and labor costs of distribution. The intra-day re-stocking didn't capture enough revenue lost due to shelves being empty to justify either lower wholesale margins or higher retail prices.

The two standing behind me were exasperated that their client "listened to those [other] consultants!"

Distribution is not a high-value-added function. Distribution can get stuff form one esoteric locale to another, but that isn't the miracle of modern supply chains. Their magic they create is doing so for mere pennies. Cheap distribution can make something produced tens of thousands of miles away price competitive with the same something produced a few doors down the street. Distribution is about efficiency, because efficiency translates into price. When you're distributing hundreds of thousands of different SKUs, you're a distributor of commodities, and whether toothpaste or tungsten the vast majority of commodity purchases are driven by price, not convenience. Capturing incremental lost sales sounds like a good idea until it meets the cold, hard reality of the price sensitivity of existing sales.

This got me to reflect: why would anybody in a distribution business agree to do something so patently counter to the fundamental economics of their business model?

They're not a company I'm doing business with, and I didn't strike up a relationship with the frustrated consultants, so I don't know this specific situation for fact. But I've seen this pattern at a number of companies now, and I suspect it's the same phenomenon at work.

The short version: companies have forgotten how they function. They've lost institutional knowledge of their own operations.

We've been automating business calculations since the tabulator was introduced in the late 19th century, and business processes since the debut of the business computer in the late 1940s. Early on, business technology was mostly large-scale labor-saving data processing. It wasn't until the 1950s (well, more accurately, the rise of COBOL in the 1960s) that we really started capturing business workflows in code. Although few could appreciate it at the time, this marked the beginning of businesses becoming algorithm companies: all kinds of rule-based decision making such as accounting was moved into code; complex rules for functions like pricing and time-sensitive decisions such as trading quickly followed suit. As general purpose business computers became smaller and cheaper in the '70s and '80s, the reach of computer technology spread to every corner of the organization. As it did, business workflows from order entry to just-in-time manufacturing to fulfillment were automated.

The work that had previously taken people days or weeks could be done in minutes or even seconds. People with intimate knowledge of the business were liberated from computational and administrative burden. The business could grow without adding staff, and suffered fewer mistakes for that growth. Computer technology fueled labor productivity throughout the '80s and '90s as more and more business processes were automated.

Then something happened that went largely un-noticed: those business people who had devised and performed the manual processes that defined the software solutions built in the '70s and '80s retired. It went unnoticed because their knowledge was captured in code, and the developers knew the code. And, the new business people hired in to replace the old were trained in how to run the code, so there was no interruption in normal business operations.

Then the original developers disappeared, either because they aged out, got better opportunities with other firms (tech people tend to change jobs frequently), or got caught up in the offshoring thing in the early 2000s. No matter how it happened, the original developers left the scene and were replaced by new people.

At this point, the cracks started to appear.

Business people knew what they did with the code and tech people knew what the code did, but neither knew why. While regular operations didn't suffer, irregular operations caused fits because nobody knew what a measured response to them was. These led to bad decision-making about the software. Among other things, the new business people didn't know the simple protocol their predecessors followed to contain a crisis. While new people had the tactical knowledge to execute tasks in the software, they didn't know how use the software in tandem with manual procedures to efficiently respond to an irregular operating situation. On the other side of the knowledge base, the new tech people didn't know why extreme scenarios weren't accommodated in the code. Again, without the meta knowledge of how to procedurally minimize a crisis inside and outside the software, they had to defend why the software wasn't "robust" enough to deal with this crisis. Since anything and everything can be codified, they had no ready answers, nor could they chart a procedural course outside of code.

With management screaming about escalating costs and poor customer service and making assurances to higher-ups that This Will Never Happen Again, the decision was made for them. So the software bloated with new rules, complexity (If This Than That), and features rarely invoked to make the software very well prepared to respond to the last crisis. Of course, given the nature of irregular operations, it wasn't entirely accommodative to the next crises. Thus went the progressive cycle of code bloat and fragility.

Once the old code became so cumbersome and brittle that executives were terrified of it, they were compelled to sponsor re-invention-through-technology initiatives. These immediately defaulted into feature parity exercises because nobody on the re-invention team had sufficient business context to imagine the business differently from how it operated (tactically) today. Because the new generation of business people had never been required to master the business rules in the same way that a London taxi driver had to have the knowledge, business users were beholden to yesterday's status quo as codified in the software that ran the business. In addition, these replatforming exercises were characterized by a shift in authority: the business people executed the rules, they didn't shape them. Tech people were the ones who manipulated the code behind the rules; they were the new shapers. Tech, not business, are the authority in replatforming initiatives.

The depletion of business knowledge and the shift of the curation of that knowledge from business to tech leads to the scenario described above: no resident adult present who can authoritatively explain why flexibility would blow out the economics of a mature distribution utility. While tech people are great at compilers and build pipelines, they're crap at business economics. Without a meta understanding of business operations, a re-invention or re-platforming initiative will be little more than a high-cost, high-intensity exercise that gets the business no further than where it is today.

I've seen plenty of companies where business understanding has been depleted. Re-learning the fundamentals is an expensive proposition. So how do we re-build a lost institutional memory? We'll look at the ways of doing that next month.
Ross Pettithttp://email@example.com