text:
tag:blogger.com,1999:blog-306218752017-01-31T22:41:07.397-06:00The Agile ManagerIT leadership, governance and management @ rosspettit.comRoss 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:blogger.com,1999:blog-30621875.post-7626413513863003292016-12-31T19:47:00.000-06:002016-12-31T19:47:15.668-06:00Myths of Replatforming
Replatforming is all the rage these days.

Platforms are conceptually popular with investors: in theory, a platform makes the mundane portions of a business efficient, scalable and adaptable, allowing a company to release the creative talents of its people to pursue growth and innovation. Replatforming makes for a convincing story following an acquisition because it explains to investors how deal synergies will be achieved, sets a tone of equivalency among employees of both the acquired and acquiring firm, describes a vehicle through which the company will reinvent itself with modern technology and practices, and conveys pragmatism in the need to clean house of dilapidated infrastructure. The replatformed business promises innovation at scale and larger cash flows from operations that, combined, position it to grow both organically and through acquisition. Destiny awaits.

In practice, replatforming is messy. Core systems are a complex web of integrated rules and functions spun over generations. They're difficult to disentangle because we have all the wrong people: most of those with the business understanding that went into building those systems have long since left, while the architects and senior engineers who created the outer layers - the web and mobile components - are still on the payroll. Replatforming initiatives become a black hole almost from the start because people don't know how to "eat the elephant": their ways of working are out-dated, they struggle to come to terms with the totality of what needs to change, and they can't envision a future that is much different from the present.

I've had a front row seat to a number of replatforming initiatives over the years, and I've seen several myths that plague them from the inside.

We'll build the platform first, then change the organization once it's live. Employees will see replatforming as an exercise in re-creating software. The existing systems have their shortcomings, but we run a multi-billion dollar business on that code, so we must be pretty good at software. Let's stick to what we know to create the software - because that's what the business needs, right? - and then we'll change process and organization once it's up and running. The fatal flaw in this line of thinking is Conway's Law: software mirrors the communication patterns of the organization that develops it. When the goal of replatforming is to rapidly innovate at scale (as it is usually alleged to be) you have to start with cross-functional, integrated teams with devolved authority that can autonomously deliver end-to-end solutions. Coming from traditional organizational structures of hierarchy, shared services and specialists, that's a lot of change. It creates confusion and disorder that just about everybody is uncomfortable with. It also makes for a slow start on developing the software that makes middle managers nervous; the more nervous they get, the more inclined they'll be to abandon organizational change. An over-managed, hierarchical, silo'd organization will develop over-engineered, tightly-coupled, brittle software; no after-the-fact restructure will compensate for that because you're bound by Conway's Law. As the saying goes, 'tis always best to begin as one intends to proceed. Replatforming doesn't succeed unless organization change precedes.

We need a product organization. As business operations become more encoded in algorithm and less executed through manual labor, we need long-term stewardship of our software from both our business and engineering communities. The popular way of doing this is by creating a product organization. Don't bother doing that if you can only define their responsibilities in a self-referential manner (e.g., "the product owner owns the product"), if you disproportionately define the scope of their responsibilities as user experience, if they have no direct accountability for how their outcomes impact the line of the business, and if you're substituting systems knowledge (how things work) for business knowledge (why things work). Not only is this not value-generative, it adds a layer of decision making intermediation and creates ambiguity in responsibilities for requirements, analysis, design, and prioritization. It's made much worse when product managers are alleged to have authority, but have their decisions reversed by higher-ups or invalidated by people with stronger business knowledge. Per the prior paragraph, we need to create the organization that will both create and perpetuate the platform. Creating a mature product organization is hard. Better to encapsulate product responsibility into the line of the business (where it arguably should be in the first place, and not adjunct to it, but that's another blog for another day) than to create a product organization stuck in perpetual adolescence. The latter will result in systemic distortions in the code, courtesy Conway's Law.

We need to put all business requests on hold for the next [long period of time] while we replatform. The older a company is and the more acquisitions it has been involved with, the more far reaching and complex its core systems will be. The more depleted it is of business knowledge - the why, not the how - the more mysterious those systems will be. Employees will be predisposed to define a new platform through the lens of feature parity with the old. The lower the caliber of business knowledge (that is, the more that system knowledge substitutes for business knowledge), the higher the degree of feature parity that employees will insist defines the minimum viable product - a position reinforced by traditional software development methods that released software once every few months, not days or hours. Additionally, ambitious replatforming efforts lay bare deficiencies in organization, skills, capability, knowledge, process, and infrastructure. Changing those takes time. These two points are conjoined to form the mistaken belief that business needs will have to take a back seat while people figure all this stuff out, but those business needs would be deferred regardless because there's no way to go live with a partial solution, and we can't very well pursue a moving target. To destroy this myth, start with that "long period of time" the business is being asked to wait. It always seems to be on the order of a year to a year and a half. At the very least double it, because nobody's estimate for something they've never done before is going to be particularly accurate. Think your customers will wait that long - two to three years - for you to get your act together? At best, a fork-lift replacement will get you tomorrow where you needed to be yesterday. From an engineering perspective, progressive strangulation of incumbent systems is almost always a question of will, not possibility. From a business perspective, progressive strangulation is a question of personas and user journeys, not features and functionality.

We'll build it the way we should have built it if we knew then what we know now. It's tempting to think our best bet is to re-build something with the wisdom our people gained from the experience of building it the first time round. That's a risky bet. It assumes they've drawn the right conclusions from their experiences. That's a lot to hope for, since that requires a lot of introspection, critical analysis, and personal acknowledgement of error and mistake, something most people aren't predisposed to do. It also assumes they've kept current with technology and process. Microservices, containerization, elastic cloud, and continuous delivery are significant departures from where software development was just a decade ago. The people who got the company into the mess it's in aren't the people who will get the company out of it. In their hands, you'll get what you've already got, only worse, like multi-generational in-bred aristocracy. Replatforming requires forward thinking technology, ideas, and execution. Changing culture, capability and mind-set requires a major transfusion; be prepared to lose a lot of blood.

Aging infrastructure, cheap capital and a dearth of innovation have fueled consolidation in a variety of industries. Replatforming will be with us for as long as those conditions exist. The myths don't have to be.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-74097885665462212842016-11-30T22:39:00.000-06:002016-11-30T22:39:06.679-06:00The Patrol Method and Objections to Self-Directed Agile Teams
In the previous post, we saw there are quite a few similarities between the Patrol method and self-directed Agile teams. It stands to reason that the resistance, doubt and objections faced by each from sponsors, leaders and members alike will be very similar. If that's the case, one can learn from the other.

These excerpts from the 1950s edition of the Scoutmaster's Handbook will sound familiar if you've ever tried to implement a self-directed Agile team:

"Some don't grasp the possibilities of the patrol method, and subsequently don't see the importance of it." If you can't appreciate the adaptability and agility of an organization characterized by strong capability and strong leadership throughout the ranks - one where people are continuously completing, learning, and adjusting to an extent that they perform best with team-level autonomy rather than top-down hierarchy - you won't see the value in a method designed to bring that about.

"Some lack faith in boys' ability to carry out responsibilities." You have to be willing to trust in people's capacity to both learn and make good decisions. Of course, trust is earned and not given, and while it takes time to develop it takes only seconds to erode. But an organization is a lot more efficient when it gets by on trust, because trust requires far less supervision and administration. Again, you have to be committed to what the right organization can deliver, and not make the organization and it's people hostage to the deliverables themselves.

"Some give up if it doesn't function perfectly right off the bat." Self-directed teams are a departure from traditional command-and-control hierarchy. The initial experience - and the initial results - can be very poor if self-direction is adopted swiftly and suddenly: self-direction requires very different behaviors and these can take a long time to develop. Until they do, teams will experience mission confusion as they come to grips with new expectations, interruption caused by external dependencies and boundaries they now have the responsibility to negotiate and manage, and seizure as people struggle to come to terms with responsibility for an entire solution rather than discreet, small tasks. How the team struggles with Tuckman's stages of group development will be mirrored in its results: at best a roller coaster where results are up one iteration then down the next, at worst a flatline where they struggle to get anything across the line. If we're not cognizant of (or better still, actually measuring) the development of new organizational "muscle memory", then the appearance of chaos within the team twined with few deliverables to show will cause the faint of heart to bail before the team gets through forming, norming and storming, to actually performing.

"Others don't like to part with authority. They found a chance to play and show off their specialties and don't realize they're stifling leadership development." Some people responsible for delivery of large programs or simple projects may be more comfortable concentrating authority rather than distributing it. This is an indication that they're more worried about the success of what they're responsible for than they are building up the people who can successfully deliver. While they may be good executors - a safe pair of hands you can trust to get something across the finish line - they're not good organization builders who can sustain what they create. Curiously enough, while self-directed teams are often accused of "not scaling", it is the characteristics common to command-and-control hierarchies - asymmetric knowledge distribution and concentrated decision-making - that don't scale.

"Still others have the old idea of training by mass instruction too ingrained in their systems to change." The best way of learning is to do something and not just study it. But on-the-job training can be very expensive, especially if somebody does, and re-does, and re-re-does, and still doesn't get a basic grasp of what it is they're doing. There is a certain allure to separating skill acquisition from skill application, if for no other reason than we can measure the effort spent on skill acquisition in the form of number of hours spent in classroom training and number of people who earn certifications. Things like training and certifications are proxies for competency: if we earn the certifications we will know what we're doing which will jump-start our execution. This makes people feel good about progress toward plan. But giving training to an individual and that individual demonstrating competency are entirely different things. The prior is useless without the latter.

"Also, some by temperament aren't suited to this way of training and are happier in a system other than the Patrol method." Quite a few people can't function without a strong hierarchy. Asking them to perform in a system defined by collaborative teams of peers who are self-directing themselves toward reaching a goal is an unreasonable expectation, and potentially damaging, to somebody who simply can't function that way.

From this, we can glean the characteristics a leader committing to the formation of self-directed teams needs to have if they are to succeed.

Humility - Self-directed teams are about its members, not its leaders.

Patience - A self-directed team will suffer setbacks and disappointments, particularly in the early going. The point isn't to obsess about failure, but to make sure every member of the team learns from it and doesn't make the same mistakes again.

Faith in people - If you believe people need to be told what to do, rather than can figure out what it is they need to do, you'll not get far with self-directed teams.

Belief in the wisdom of crowds - You have to believe that the whole is greater than the sum of the parts, and that a hive-mind will come up with a better solution through execution and continuous feedback than one dictated to them by a small cabal of people.

These prior two points suggest that you have to espouse a professional rather than an industrial mindset. If you can do that, you have the mindset for self-directed teams.

Commitment to the method - Above all else, you have to believe that if faithfully applied, the method will create the conditions - generalized skills, strong leaders, and independently-functioning units - under which a program is far more likely to succeed than if it is delivered in a command-and-control style. If you lack confidence in the values behind the method, you'll be quick to abandon practicing the method.

"The troop that is run as a club, with the Scoutmaster as boss, dies when the boss leaves." Hierarchies with central decision-making can be effective, but they are brittle because of their dependence on a handful of key people. If your goal is to build a resilient, evolutionary, adaptive organization, the price of admission is decentralization. Decentralization requires empowerment; empowerment requires atomic leadership and capability. The history of organizational development teaches us that the process of building an organization that can function this way is a very difficult one indeed.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-91433477202135345772016-10-31T23:44:00.000-05:002016-10-31T23:44:00.876-05:00The Patrol Method and Self Directed Agile Teams
As part of my research into method earlier this year, I picked up a 1959 edition of the Scoutmaster's Handbook. The core of the philosophy for a Scout troop was what Robert Baden-Powell, the founder of Scouting, called the Patrol method. The early editions of the Boy Scouts of America's version of the Boy Scout Handbook were mostly written by the same person, William "Green Bar Bill" Hillcourt, and revised over many years.

The Patrol method Hillcourt described in the Scoutmaster's Handbook was essentially a self-directed Agile team. The key characteristics are:

Small team size: patrols are 6 to 8 people. Several patrols form a troop, but patrols are autonomous.

Pairing: experienced people teach new people on the team.

Continuous feedback: the Court of Honor is "...a peer system in which Scouts discuss each other's behaviors and is part of the self-governing aspect of Scouting."

Servant leadership: achieved through an emphasis on service to others (an expectation shared by all), as well as stressing that the highest leadership roles are expected to assist those in the troop to train themselves as opposed to telling them what to do. "A Scoutmaster's job is to help boys grow - by encouraging them to learn for themselves."

Hands-on over theory: "No meeting should be inside - all activities should be outdoors".

Respond to change: "If the planned program doesn't work, be resourceful. Throw some out, if necessary, to suit conditions."

Transparency: "Encourage members of the troop committee to attend regularly."

Stakeholder management: "When they come, have something definite for them to do."

Chickens and pigs: "Keep visitors on the side lines. Most of the time visitors come to see what is happening. Don't let them interrupt the meeting."

Generalize skills by rotating pairs and responsibilities through the duty roster instead of allowing people to specialize in tasks.

Tool construction: pioneering techniques forge useful tools from available resources that make you more productive and comfortable.

Each team owns the plan: troop goals and patrol objectives are set by members of the patrols themselves, not dictated the adult leadership.

Adaptability in technique: "Fortunately, there is no standard way of planning the program of a troop. A group of robots using a standard pattern in exactly the same fashion would pretty soon kill Scouting. Each troop works out its own way..."

A code with positive goals: the Scout Oath and Laws provide a value system for conduct, in much the same way that the Agile Manifesto is a value system for software delivery.

There are many more similarities I could draw out between the Patrol method and Agile teams. The point isn't to suggest that the concept of self-directed teams are influenced by the Boy Scouts - it doesn't matter whether they are or not. Or that there are no new leadership philosophies under the sun - servant leadership concepts are at least 2,500 years old at this point.

The point is to learn from what the people championing that method experienced when they applied it: intransigent doubt that the method can work because it turns leadership responsibility over to the team, or that learning-by-doing is inferior (e.g., doesn't provide value for money, or isn't more effective) to training by mass instruction.

If the concepts aren't new, the objections to them aren't, either. The strengths of a self-directed team might be self-evident to the initiated, but they're not an easy sell to those who are not - for reasons that have been with us for time immemorial. We can learn from their setbacks.

In the next post, we'll look at how champions internalized objections to the method, and what they observed happened when the method was compromised for sake of implementation.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-484281423768587872016-09-30T23:56:00.000-05:002016-10-02T10:55:52.818-05:00Ecosystems and the Energy Source of Last Resort
It's fashionable for a company to proclaim itself an ecosystem. A mobile phone company makes handsets for users and curates an app market place for developers. The virtuous cycle of an ever increasing collection of apps motivating an ever increasing population of consumers. They have the benefit of steady cash flows from existing customers and constant growth from new ones attracted by an increasingly complex array of products. There are a number of self-proclaimed commercial ecosystems, ranging from online lending to conglomerates of retail, credit and loyalty.

Markets are kind of like ecosystems in the way participants reinforce one another. Buyers and sellers come together in sufficient numbers to perpetuate a market. As more buyers emerge, more sellers offer their wares in the market, which attracts still more buyers. An increase in the number of buyers triggers more complex and diverse products, making the ecosystem more interesting, if not more robust. To wit: demand for tomatoes triggers cultivation of different varieties, some of which are resistant to disease or insects that others are not, increasing the resiliency of the lycopene trade.

Ecosystems aren't inherently complex: a simple terrarium consisting of a lamp, dirt, water and seeds will yield plants. Commercial ecosystems aren't complex, either. We can stand up marketplaces for mobile phone software or money lending or property investing. In doing so, we hope to encourage people to risk their labor by writing software they hope people will buy, or their capital they hope will find a worthy investment. With the right marketing and promotion (i.e., fertilizer) we might attract ever more buyers and ever more sellers, creating a growing and ever-increasing community.

One thing an ecosystem needs to survive is a constant supply of energy. The sun provides an uninterrupted supply of energy to the Earth. It can be consumed immediately (e.g., through photosynthesis). It can also be stored: liquefied dinosaurs are effectively stored energy that originated with the sun. Energy from the sun can be concentrated in many other forms, and accessible to parts of the planet when they're directly exposed to it. This allows formation of more complex life and lifestyles. Some spot on the Earth may suffer drought or fire or some other disaster that wipes out the basic plant life that supports more complex life forms, but the constant energy from el sol means that a devastated area has a source of energy it can draw on to re-develop.

In commercial ecosystems, capital is energy. Markets are highly vulnerable to periodic contractions of liquidity. Both asset classes and tech products fall out of favor, destroying the fortunes of sellers quickly (bank equity values in 2008) or slowly (Blackberry software developers from 2008 onward). Turn off the lamp and the terrarium becomes barren.

Markets require a constant supply of capital in the same way that ecosystems needs a constant supply of energy to survive volatility and seizures. In financial markets, there are market makers who guarantee a counterparty to every trade and buyers of last resort who provide liquidity in the event of a sudden seizure of market activity. It's the latter - the Federal Reserve and the European Central Bank buying sovereign and commercial paper as well as lending to banks with the expectation that they will do the same - who act as the constant supply of energy that keeps commercial ecosystems functioning. Markets will surge and markets will plunge, but it is the "energy source of last resort" that sees markets through the peaks and troughs.

Economic cycles - credit or tech - aren't new phenomenon. When they turn, they expose the fragility of the businesses at their mercy. Late last year, lending marketplaces found themselves with plenty of loans they could write but fewer willing to buy them. The solution they turned to was to introduce a buyer of last resort, initially in the form of banks and eventually in the form of investment vehicles they created themselves.

Any self-proclaimed ecosystem without a backstop buyer - that is, without a constant and reliable source of energy - will be at the mercy of commercial cycles. Mr. Market will not hesitate to turn off the terrarium lamp when the cycle tells him to do so. Once off, he is not so willing to turn it on again. But he might not reach for the switch for the first place - and might very well be first to harvest green shoots after a devastation - as long as there is an energy source of last resort.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-24089642888635886142016-08-31T22:51:00.000-05:002016-08-31T22:51:00.142-05:00Method, Part II
Last month, we looked at method as a codification of experience borne of values and expressed through rules, guidelines, practices, policies, and so forth. This month, we'll take a look at the relationship between method and the things that influence it, and that it influences.

The principal framework is an article by Cliff Jacobson describing the change in method that impacted camping and outdoor activity starting in the 1950s, drawing comparisons to changes in method in software development. When we think of method in software, we generally think big: "Agile versus Waterfall". But there are more subtle changes that happen in method, specifically through the codification of skill into tools.

Plus ça change...

* * *

Method...

... and Values

"Environmental concerns? In those days, there were none. Not that we didn't care, you understand. We just didn't see anything wrong with cutting trees and restructuring the soil to suit our needs. Given the primitive equipment of the day, reshaping the land was the most logical way to make outdoor life bearable.

"In 1958 Calvin Rutstrum brought out his first book, The Way of the Wilderness. Suddenly, there was new philosophy afield. Calvin knew the days of trenched tents and bough beds were numbered. His writings challenged readers to think before they cut, to use an air mattress instead of a spruce bed. Wilderness camping and canoeing were in transition."

-- Cliff Jacobson

As values regarding nature changed from "tame the land" to "conservation", the method of camping had to change. Of course, it took a long time for the new values to settle in. And even once it did, it took a long time for practitioners to change what they did. Resistance to change is a powerful thing, and both practitioner and gear lag would have kept practitioners executing to an old value set in the field for a long, long time.

Values changed in software, too. When users of software were largely internal to a company, before software became such a high cost item for non-tech companies, and before software was weaponized, development moved at a much slower and more deliberate pace. Once the values changed, the method of software delivery was also pressured to change. The change in relationship between humanity and the outdoors is similar to the change in relationship between companies and their software.

... and Skills

But this narrative applies to both a wholesale change in method as well as to the transition from skills-centric to tool-centric method.

"I discovered the joys of camping at the age of 12 in a rustic Scout camp set deep in the Michigan woods. It was 1952, just before the dawn of nylon tents and synthetic clothes. Aluminum canoes were hot off the Grumman forms, though I'd never seen one. Deep down, I believed they'd never replace the glorious wood-ribbed Old Towns and Thompsons."

Early backpackers had to make do with bulky tarps, fashioning poles and tent pegs from branches - sometimes, even sapling trees - in their campsites. The emphasis among the early outdoorsmen was on the skill of adapting the environment to human survival, and achieving Spartan levels of comfort was a symbol of mastery. Being able to fashion poles and pegs from tree limbs was important in the 1940s as tents didn't necessarily come with them. This was not only destructive, it became unnecessary with the evolution of lightweight and portable aluminum poles and stakes. In a relatively short period of time, being good at pioneering became, at best, only useful in an emergency (you need to fashion a tent peg because you discover you've lost some aluminum ones).

Building Agile trackers in spreadsheets and crafting them anew with each project was somewhat akin to fashioning new tent pegs every time you go camping. Creating a new tracker with each project was a waste of money, and having 5 different teams with 5 different trackers was confusing. The advent of cheap commercial trackers made this unnecessary. Still a good skill to have in an emergency - a project tracker so badly polluted with low priority Stories and tasks is an impediment when you want to make a clean and quick start - but fashioning a tracker is no longer itself a core skill.

... and Tools

"The emphasis had shifted from skills to things."

Early tools supporting a method are crude, often hand made and narrow in their usefulness, and several tend to spring up at the same time. The emphasis is on skills.

But with ever increasing popularity of the activity (trips to the Boundary Waters, or Agile software development) comes the tools. Skills take time to learn and master. Tools make the activity at hand easier to perform, and subsequently more accessible and more enjoyable to more people because they're more successful at it. Canoes are made of strong yet lightweight materials so they're more tolerant to misuse while simultaneously easier to portage. Sleeping bags are made of synthetic materials that are water resistant (unlike down) so that somebody who does a sloppy job at packing a canoe pack won't suffer if the bilge water soaks the contents of the bag.

Of course, tools can be a source of efficiency or a source of trouble. A hatchet makes it easy to build safe, small fires out of short cut sticks. But a hatchet can cause grave injury to somebody if they don't know the proper method for chopping wood with it. Nobody is likely to suffer bodily harm from an over-engineered build script (no matter how many felonious thoughts cross the mind of other people in the team) but an overloaded, single-stage build that reduces build frequency and that fails frequently will cause more harm than good.

"Today, high-tech gear and high-powered salesmanship have become a substitute for rock-solid outdoor skills."

As the complexities of a method get codified into the gear, it becomes difficult to separate one from the other. The tools become a proxy for the method because the state-of-practice matures in conjunction with improvements in science (materials or software) and affordability. Today, we create sophisticated, multi-stage pipelines that instantiate their deployment environments and deploy on every commit. 15 years ago, it was amazing to have a build run every few minutes that would both compile source code and run tests. We can't imagine forging our own crude tools to do basic tasks, or even why we'd want to do it.

Newer tools don't lend themselves to older practices. Tightly rolling a modern (down) sleeping bag won't get it into its stuffsack. Managing cloud instances like rack-mounted servers in a physical data center will run up the bills really fast.

This can be a serious point of confusion for middle managers tasked with making their organization "Agile". If we use Jira, Jenkins and jUnit we must be Agile.

... and People

"I felt quite inadequate, like a peasant in Camelot."

Tools can render entire skills sets irrelevant. The right brain creativity to fashion a tracker for some specific project was no longer needed when the commercial tracking tools arrived. It became a left brain activity of making sure all the requirements were entered into the tracker and configuring canned status reports. Suddenly the thing somebody did that was an act of value has been rendered obsolete by the gear.

The information modeler who was capable of telling the right story based on the nature of the task and team is shoved aside by the efficient administrator who's primary job is to maintain team hygiene. It's entirely possible that the hygienist doesn't really understand why they perform the tasks they perform, but they've been told to hustle people to stand-up and make sure people update status on their (virtual) cards. They're also much cheaper than the craftsman they replaced.

This is pretty destabilizing to people. Where Cliff Jacobson felt inadequate by the gear (and the associated cost), the individual can be stripped of their own sense of self-worth by a change in the method. This can happen when the method changes owing to the values (we need to deploy daily and Waterfall won't let us do that). You might have fancied yourself pretty good at software within your organization, but now the boss is telling you that your worldview is out of touch, you're not up to scratch and you're not only told that you're going to do it differently, but how you're going to do it. That's not likely to elicit warm and welcoming feelings. Just the opposite.

But it can also happen when the change in method is a shift from skills to things. Suddenly anybody can appear to be good at project tracking. That can stir resentment that encourages resistance to the tools and pine for the spreadsheets.

The reverse - a sudden shift from tools to skills - has no less an impact. There are development stacks that are entirely tool driven. When the boss comes in and announces that all vendor dependencies in the code and process gotta go, the tool dependency no longer compensates for weak skills. The person accustomed to going glamping may not much care for back country backpacking.

... and Basics

"Chemical fire-starters take the place of correct fire making; indestructible canoes are the solution to hitting rocks; bizzard-proof tents become the answer to ones inability to stormproof conventional designs; GPS positioning has replaced a map and a compass. And the what-if-you-get-your-down-bag-wet attitude attracts new converts every year. In the end, only the manufacturers win."

Cliff Jacobson argues that tools are a poor substitute for skills. Where they support the value system - Leave No Trace camping - they're welcome. But where they are simply gadgets for convenience or separate the individual from the experience, they're not. They're also predatory, exploiting a person's laziness, or fear of being unable to master a skill, or feeling of inadequacy in dealing with challenging situations that might arise.

To same extent, the impulses that spurred the software craftmanship movement are likely similar to those of Messers Rustrum and Jacobson:

"'I've canoed and camped for nigh on seventy years and have never got my down bag wet,' he bellered. 'People who get things wet on trips don't need new gear. They need to learn how to camp and canoe!'"

Pack correctly and paddle competently and you'll never sleep in a soggy bag. We don't need armies of people mindlessly executing test scripts if we build in quality in the first place.

... and the future of method.

Method is a mirror, not a driver. It reflects values and experience, it doesn't create them. Values shift as our priorities change. Experience changes as we learn what new technologies allow, and sometimes re-learn discipline long lost. Method reflects this; it doesn't inform or define this. The values and experience are there, or they are not.

Method is never a destination. It's an echo.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-25272313822841934602016-07-31T23:57:00.002-05:002016-08-01T00:02:40.249-05:00Method, Part I
Last month, I went on a 6 day, 55 mile canoe trip with several friends. I last went canoe camping in the 1980s with the Boy Scouts. Being out of practice, I bought books from as far back as the 1950s to as recent as 2010 on canoe camping, studying everything from gear and technique to meal planning and water purification.

Some things haven't changed much over the years: Duluth packs are still in fashion because of their low profile when placed inside a canoe and on your back while portaging one. Some things have changed a lot: plastic barrels with harnesses have replaced the old wooden Wanigan boxes. Some things seem to be over-engineered replacements: you could use a GPS and a map, but a compass works really well, doesn't require batteries, and costs a lot less.

No surprise that the method I learned for canoe camping (and backpacking in general) in the 1980s is different from the method practiced today. The method has changed for a lot of reasons. One is technology: materials science has changed what we pack and how we pack as gear is lighter and easier to compact. Another is economic affluence: we no longer make things once in camp, you buy them in advance and pack them in. Yet another are environmental standards: leave-no-trace has us carry food in the thinnest of packaging since we pack it all out.

The method I learned wasn't exactly state-of-the-art, even for the 1980s. For one thing, the leaders had learned method a decade (or more) before I joined. For another, the Boy Scout troop I was with had acquired most of it's gear in the 70s, and some of it dated to the 60s. Gear was expensive, so upgrading it wasn't an option. While our method was effective, it was far from cutting edge.

Clearly, to make a canoe camping trip in 2016, my method needed to change.
* * *
Method is the codification of experience into rules, guidelines, policy, principles, behaviors, norms and so forth. Method is intangible, but it has tangible manifestations: gear and tools are derived from method so that it can be followed, and performed with efficiency.

One reason we develop methods is so that people new to a craft can learn it in a safe and responsible manner: if newbies can build a cooking fire without burning down the forest, they don't go hungry and future campers will have a chance to enjoy the same forest. Sound method spares disaster and frustration. Another reason for developing method is that is allows us to codify knowledge and build on collective craft, pushing the boundaries of technique and gear: the risk of forest fire means we're better off cooking over stoves rather than campfires, which encourages research into energy sources and stoves, which creates safer, lighter and higher density energy sources for cooking, which allows more people to backpack safely for longer periods in remote areas.

There are methods for all kinds of things. NASA's Manned Spacecraft Center defines a method for putting human beings into space and bringing them back alive. FASB defines methods for accounting practices.

Methods are developed by people who have first-hand experience of what works fantastically well, sorta OK, and not at all. This is why people who define methods have to be hands on: method defined by people without experience is just pontification. But those same people need to be abstract thinkers, aware of the un-changeable forces that need to be dealt with. We have to perform a barbecue roll of a spacecraft throughout a journey to the moon, otherwise it'll freeze on one side and burn up on the other.

Methods are a means of practicing a value system. We perform fire safety following this protocol because we're more concerned with the damage we would cause if we lose control of the fire than we are for having a heat source to cook dinner. Values are powerful, because they supersede any rule or practice that is part of the method. If the RCS ring is activated on a Gemini spacecraft, the astronauts have to come home: the procedure is irreversible and we're more concerned with bringing them back alive than pursuing mission objectives that could put their lives in danger. Values are non-negotiable - in theory, anyway. Compromise your values and you cast doubt over the integrity of the method you insist that everybody follow. If you can take fire out of the ring to perform some stunt, it clearly doesn't matter whether fire stays in the ring or not, so "fire safety" must not be that important to you.

Methods define responsibilities and authority. I'm the voyageur, so I'm the navigator of this canoe trip. I'm Capcom, so only I talk to the astronauts. Changes in method are threatening to people where they upset how they understand power dynamics in a group.

The world around changes, so method needs to evolve. Knowing how to make a backpack (Boy Scout Fieldbook, 1967) isn't particularly useful with increased affluence and advances in materials science. People also need to evolve with method to stay on top of practices, as does their gear: practitioner lag sows seeds of confusion, while gear lag can make some activities impractical, if not impossible.

Except when stipulated by law (e.g., accounting standards), there are no shortage of methods for performing the same activity. National Outdoor Leadership teaches a method for canoe camping and backpacking that is different from the Boy Scouts, which is different from Outward Bound, which is different from the method taught by countless other organizations.

When everybody in a group is trained in the same method, we have uniformity of conduct. The group can be expected to socially reinforce the method should one member slack off in a key area (sanitizing cookware) for reasons of convenience (hates doing the washing up).

When people in a group are trained in different methods, or some are trained in no method at all, the differences can range from trivial (you packed in magnesium? That's great mountain man, we have plenty of matches in multiple waterproof containers) to severe (I'm sure you're not planning to burn down the forest, greenhorn, but fire stays in the ring just the same). The differences can be learning experiences, or competitions, or sources of conflict and dysfunction within the party. People can get pretty worked up when every ounce of their being tells them that something is important (secure the canoes overnight because a strong gust of wind can flip - and wreck - a canoe) but other members don't feel as strongly (securing is overkill as gusts that high are highly unusual).

Differences in a small group are mirrored by the differences among method "experts". In the same article in the Summer 2016 edition of Boundary Waters Journal, one expert writes "[getting wet on portages] is completely preventable", while another, 6 pages later in the same article, writes: "Forget about keeping your feet dry. They will be wet." Not only will the disagreements be mirrored, so will the intensity of the arguments about them. This comes as no surprise as method is a proxy for a value system, but the arguments are rarely over the values, and usually over the practices themselves.

Sometimes, we set out to learn a new method by choice. Other times, we're forced to. The means of teaching method range from immersive to suggestive. At one extreme are those who teach method by breaking us down and rebuilding us, to strip away our preconceived notions and ideas, developing new muscle memories for a way of doing things. At the other are those who observe what we do today, suggesting and coaching how we could do something differently, allowing us to decide and trusting that the obviously superior method will prevail.

The student of a new method may embrace it enthusiastically. Or may never be convinced it is better than the one long practiced. And if not a willing adherent to a new method, being told that you have to change your method is threating. It says that the expertise you developed is irrelevant, unnecessary, inferior, or just plain wrong. It erodes your seniority within a system that is based on that method. It's tough being told "the world has moved on from your understanding of it."

We have many methods for developing software, too. We'll look at how we apply those in Part II.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-67734715852306962762016-06-30T23:09:00.000-05:002016-06-30T23:09:00.151-05:00In Tech, Portfolio Management is a Metaphor, Not a Way of Life
A few years ago, I wrote about the chronic misuse of the word "governance" in technology. The word "portfolio" is suffering the same fate.

The reason for introducing the word "portfolio" into tech management is that some portion of tech spend is really an investment in the business, something that differentiates it and gives it a competitive edge - for example, mobile or web client-facing apps, or internal software that codifies workflows to capture efficiencies. This is fundamentally different from utility tech, the basic technology a company needs to function, such as ERP or email. To get a better return from our strategic opportunities, we should think in terms of investing-like behaviors and outcomes, as opposed to traditional project-oriented ones (such as time and budget). The word "portfolio" enters the lexicon because when we have multiple technology investments, we logically have a collection of them. Since most firms have more opportunities for investment than capital to invest, there is a degree of selectivity of what gets included in the investment portfolio.

While I was writing chapter 8 of Activist Investing in Strategic Software, it occurred to me that the use of word "portfolio" in technology has increased in recent years. Unfortunately, the activity described by aspirant "technology investment portfolio managers" are a very small fraction of those characteristic of financial portfolio management. The principal problem is that the word "portfolio" suggests a degree of decision-making flexibility that the captive technology investor doesn't really enjoy. Consider:

Although we can create diversity of our investment outcomes, the strategic software investor is limited to a single investment type - e.g., an operationally-based delivery. A financial investor has many more choices of vehicles and outcomes than a captive investor does. There are no fixed income products available to the captive technology investor, it's all equity. Plus, although we can run multiple experiments to qualify an investment and accelerate our delivery frequency to get things in production faster, all of our investment positions are inherently long. The only short position we can take in something is not to invest.

While there are countless investment opportunities, it's rare that a company can pick and choose every investment it makes. Some investments are forced on it by regulation; others by competition; still others by reliability of dilapidated legacy assets; and sometimes because the boss says this or that is what we're going to do and that's all there is to it. A captive technology investment portfolio isn't as discretionary as a financial one.

Our investment goals are denominated in different and sometimes only quasi-economic measures of value. All financial investments denominate their performance in the same measure, even those that have explicit non-financial goals. As I've written before, it's futile to concoct synthetic measures like "business value".

Most often, we can't measure the impact of any given investment in isolation of all other changes a business makes to itself and those that happen in its commercial ecosystem: we change the economics, processes, technology, and policy of our business all the time, while our commercial partners are also making the same changes to theirs. Isolating an outcome to a single decision or action (like a specific tech investment) is very difficult. In addition, because counterfactuals are unprovable, we can't measure whether an alternative investment would have yielded a better or worse outcome. In contrast, we can measure our results of financial portfolios against how well "Hindsight Capital Partners" performed over the same time period.

Venture capital is a high risk business that has more misses than hits. The success rate doesn't improve when the VC is corporate rather than financial. A company doesn't have unlimited capital to experiment at scale and can't afford to have a low success rate on investment decisions.

As much as we may want to be investors, the portfolio metaphor is very limited in captive investing situations. It lacks diversity, is inherently imprecise, and both performance and competency as investors are as much a matter of opinion as fact. It's potentially dangerous, too, because managed poorly it can damage its operational solvency (that is, the capability to get things done through technology) by making a mess of its capital management.

The premise of the book I'm writing - that activist investing behaviors yields better performing tech investments - is also substantially a metaphor. There are real aspects to it, specifically that shareholder activist behaviors - being investigative, inquisitive, interrogative and invasive - are highly suitable to captive technology investing. But "shareholder activism" only goes only so far: we can't buy out other "investors" and we don't gain control of the board through proxy fights. We have fewer levers to throw to change outcomes, and virtually all of them are operational (process, scope, personnel) in nature: few are the captive investments that can show better performance on the basis of financial engineering alone.

While metaphors are limited, they do help us to interpret our world differently. When we think in investment terms, we see financial expectations and possibilities much more clearly than when we think strictly in operating terms. When we think in shareholder activism terms, we understand the importance of good governance structures and mechanics, and the need for diligence by those investing in the business through technology. Interpreting delivery of strategic software through these lenses adds dimensions that make the operations that create them more value-generative to their host businesses.

But we do ourselves no favors by getting carried away with it. As helpful as the portfolio metaphor is, it's just a metaphor - not a way of life.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-86551738041799031762016-05-31T23:58:00.004-05:002016-05-31T23:58:39.541-05:00The Times, We've No Idea How Much They're Changin', Part III
In the last post, we looked at the changing relationship between people and possessions, particularly how the perception of land has changed. But there's more to this than just changes in dwelling and mortgage finance. Land was part of a land-labor-laborer troika, a relationship that has existed since the dawn of humanity. Land could feed and protect the laborer and be a means to a better life, but not without expending labor to till the soil and construct buildings. Just as the perception of land is changing, the perception of labor is changing as well, which erodes the relevance of this troika on an individual level.

Over the course of centuries, labor evolved from a means of subsistence, to a means of income, to a means of achieving economic prosperity (through entrepreneurism and meritocracies). It also was a source of individual identity and self-worth: to be employed communicated one's ability to contribute to society. Yet labor has taken a beating in recent years. A two decade period of nearly uninterrupted growth that began in the early 1980s made labor for the real economy king by the late 1990s (peak employment and household income levels), but a couple of recessions soon thereafter meant it went from being scarce to abundant before the first decade of the new century was out. Meanwhile, real economy jobs lost favor to jobs created by ever-cheaper capital, through things like venture-capital subsidized start-ups, property flipping, and day trading. These latter jobs produced far more lottery winners (remember equity options in the 1990s?) than their real economy counterparts. Other factors, like the erosion of job stability, the replacement of pensions with 401(k)s, and more recent worry over the gig economy and robots and automation displacing real economy labor, have cast labor as transient and eroded it's perception as a cornerstone of societal durability.

Labor has gone from champ to chump in less than 20 years. It's no wonder every spring commencement speech contains the obligatory "pursue your passion" line: the not-so-subtle message is that labor on its own is no longer a thing of fulfillment.

This belies the idea that labor is a vehicle to achieving quality of life. Because real wages have been stagnant for nearly a generation, there's less perceived value to labor. If you don't feel that your lot will improve through your labor, you're less inclined to labor for anything better.

Not to mention that for many people there's less urgent need to labor. Previous generations accumulated a lot of wealth, creating familial support nets. Empty-nester parents welcome their children back to live with them in cavernous houses (compared to the small houses of their grandparents and great-grandparents where they couldn't return even if they had wanted to). The cash they accumulated through investing has become inter-generational transfer payments. Why work to meet your own subsistence needs if you don't have to?

Labor, which was once at best a key to individual freedom and at worst a denial of recreation time, is being cast as indentured servitude (we're forced to work by the system) or an emotional prison (the job isn't someone's passion, it's just the job they could find).

This points to change in the definition of what freedom is.

In the 1960s, we had a generation push back on going to war because it didn't understand why they should have to (e.g., go fight a proxy war in a far away land). Today, we have a generation pushing back on going to work because it doesn't understand why they should have to (e.g., if we have so much food and so much stuff why do we have to solve the same problems over and over again that just lead us to more food and more stuff?) Freedom is becoming independence from the need to solve basic problems long ago solved like transportation and food to pursue Maslow-like self-actualization. Freedom is no longer something each person achieves individually by "working the land", it's provided by a sophisticated, intricate system that charges rents in exchange for alleviating burdens - both cost and time - of ownership.

We started this blog series with the observation that change can be a long time coming, particularly because economic habits die hard. We'll still have household formation, individual property ownership, and most of us will have to work for a living for a long time to come. Tax receipts are substantially derived from income. And the land-labor-laborer troika has been displaced before (productivity increases during the industrial revolution de-valued labor for two generations) only to find its way back (the rise of America as an economic power in the 19th century). Yet these ideas around labor are in the ether, to a point that Switzerland will hold a referendum next month whether or not to provide a universal basic income for every citizen.

Which brings us back to where we started. The winds of change blowing today would alter fundamental economic relationships that have been around for centuries, and the technology is here now to make them practical realities. The technology exists today to change shelter, transportation and investment activity of an individual to allow them more free time to pursue personal fulfillment, but that's no guarantee that a critical mass of people will in sufficient numbers, or will do so before societal winds change direction. The times, they have a-changed, and they'll continue to do so. Change happens at a societal pace, not a technological one.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-71392368155671875062016-04-30T20:41:00.000-05:002016-04-30T20:41:14.055-05:00The Times, They're Still A-Changin', Part II
I ended the previous post by stating that the stage is set for more radical change. Why?

Consider the changing attitude toward land, property and shelter.

For the pre-1965 generation, land meant a lot of things. It was wilderness to be fought with, to be made into a suitable place to live. It was where you built your shelter. It was how you earned or supplemented your living, by farming, mining, logging, or guiding. It was sweat: always one more addition, improvement, or repair to be made. It was the story of America as taught to schoolchildren: land was the reason why the Pilgrims came, and "taming the land" was said to bring out the best in the early settlers who were themselves held out as American heroes and role models. It was very personal history, too: settlers intertwined family stories - and legends - with the land itself.

Land was freedom, and property ownership was independence.

Property was extraordinarily important to the American psyche. A great deal of desirable land remained remote and undeveloped until well after the Second World War (the Interstate network wasn't begun until the Eisenhower administration). Familial bonds with land were strong, particularly where property passed from generation to generation. Schools taught the history of European settlement, including battles with indigenous peoples and noteworthy settlers. A lot of the materials, tools and trade were similar to those employed by generations past, so people could relate to how their grandparents had lived. Activities like camping and hunting gave young people first hand experience of how the European settlers and indigenous people lived, reinforcing the perception of land as well as the myths about it. Land was a great investment ("they're not making more of it" as the saying went), appreciating in value virtually everywhere and almost without interruption. In part, this built up a perception of value in land. And in part, it was a reminder that you weren't too far removed from the rough-and-tumble of the wilderness.

Land no longer captures the American imagination quite so much. More people live in dense urban areas, a large number of them rent, and those who do own expect to move - either upsizing or downsizing - long before their mortgage matures. People who bought property from 2002 through 2008 suffered financially and emotionally with the housing collapse. High crop yields create less demand for farm acreage and farming families. Land has been repurposed: farms near urban areas were more valuable as residential subdivisions, and previously remote rustic areas have been developed into recreation communities or suburbs. Building and zoning regulations restrict what property owners can and cannot do with their land. Early to mid 20th century industrial manufacturers favored rural or suburban owners with the space for industrial products; 21st century providers of services and digital products - that is, where the American economy has been shifting toward for the last 40 years - favor densely populated urban centers. History classes emphasize the high cost - war, disease, resettlement - borne by indigenous peoples at the hands of European settlers. Activities like camping are now either cheap vacation choices (ever notice how many private campgrounds there are near floating casinos?), or some combination of tests of strengths balanced with stewardship.

Land is no longer freedom. Renting is freedom: renting allows you to have many different living experiences and gives you the freedom to change your living accommodation based on your lifestyle, rather than having your lifestyle dictated by the land. Land is red tape and well rehearsed ceremonies to purchase plots or pull permits; it ties you down to a mortgage and a location.

The changing perception of land also reflects the fact that shelter and sustenance - things directly related to land ownership and management - are problems long ago solved on a mass scale. There is little value in rehashing them again and again on an individual basis, when we could use our life's energy to solve the next wave of challenges, from sustainability to space exploration.

There's been a similar change in attitude toward another symbol of independence, the automobile. Because it was a way to get away ("freedom of the open road") or quite literally a means of getaway (think John Dillinger, or Bonnie and Clyde), the automobile captured the American imagination. But the automobile has changed from a symbol of freedom and possibility to one of captivity (monthly payments) and inescapable utility (suburban communities aren't designed with walking in mind, and suburban mass transit is inefficient). The car that sits idle in the garage nearly 99% of the time isn't untapped potential, it's a tax of modern living.

The things which were the physical incarnation of freedom for prior generations have become symbols of economic entrapment to newer ones. Per the previous post, technology enabling things like the "sharing economy" aren't leading change as much as they're riding the changing wave of sentiment.

This wave has a long way to go before it crests. The shift in attitudes toward land and transportation portends a change in asset ownership and associated activities like lending and insurance that we've long taken for granted. That doesn't mean a concentration of assets in the hands of a few owners: technologies like blockchain make it easier to fractionalize ownership. This will allow people to invest in small fractions of many residential properties bundled into a single instrument, and do so incrementally over a long period of time. In essence, they would live in a rented house, but own small fractions of many others. Just as people have shown a preference for passive over active investing, future generations may find it appealing to be able to invest in residential real estate without the need to mortgage future cash flows for a specific spot of dirt in an asset appreciation lottery.

Of course, that's all "some day". But change is afoot, and the stage is set for more still more that goes beyond assets, to the nature of labor itself. We'll look at that in the next post.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-35236606965696318672016-03-31T22:23:00.000-05:002016-03-31T22:23:01.384-05:00The Times, They Have A-Changed, Part I

"This technology revolution was not invented by robo-advisers. They have simply noticed, and taken advantage of, a broader and deeper shift towards passive investment through ETFs and index funds."

-- John Gapper, Robots are Better Investors than People

We like to think of "technology revolutions", but as Mr. Gapper points out, revolutions aren't led by technology. The landscape is littered with shuttered technology companies that showed that a thing was possible, but failed to foment a "revolution".

Revolutions happen once we have critical mass of people with different attitudes and behaviors. Consider the changes in investing behaviors referred to above. Once investors realized that actively managed funds charged higher fees but performed no better (and frequently worse) than passively managed funds, they switched. Today, as investors come to realize that financial advisors are charging fees for putting their money in passive funds, they're amenable to robo-advisors that charge lower fees for doing exactly the same thing.

A change from human advisor to robo-investing won't happen at the pace set by technology, however. It took a long time for investors to change their preference from active to passive funds. Index funds first appeared in the 1970s, as did research showing that active funds didn't consistently outperform the broader market. Yet it took decades for investors to invest differently.

Why did it take so long? Attitudes, prejudices and predispositions take a long time to change. Sometimes they don't: those who hold a belief may never let it go, even in the face of overwhelming evidence to the contrary. And, people financially, politically or emotionally invested in something will fight to preserve it. Active fund managers initially derided passive funds, while today, facing massive capital outflows, they're fighting for survival. Those who stand to lose from change will also fight back with marketing designed to co-opt the next generation, such as the way manufacturers of sweet fizzy drinks simultaneously play to an older generation's nostalgia while encouraging them to create a sentimental moment - vis-a-vis their product - with a grandchild.

No matter how much technology we throw at something, entrenched behaviors don't start to change until a generation comes along that isn't as emotionally committed to them. And that still only describes how change starts, not how it finishes - and it can take a very long time to run its course. To understand the dynamics of change, we need to look at both ends of the generational spectrum: as people enter, people also leave. This is most obvious in the workforce where, in general, people join around age 18 and leave around age 65.

The United States has just completed a major generational shift, not so much for the one arriving as the one that has recently left.

The Great Depression and the Second World War shaped American domestic and foreign policy well into the 1990s. Yet as long ago as 1965, America had reared a generation without any direct experience of either, making them less constrained by the values held by the people who had come before them. And, starting 1965, a generation began to arrive born to parents who were themselves bred following the Depression-and-WW II-era. Prior to 1945, most everybody had direct experience to the privations of one or both. After 1965, we had generations grow up in households where those two seminal events were things their grandparents told them about from time to time, and which they only briefly studied in high school history classes.

Despite the social upheaval that coincided with the maturation of this post-depression-and-war generation (the late 1960s), the value system of the pre-1965 generation dominated American society and the American workplace, first through sheer numbers (those who held it made up the bulk of the working population) and later through positions of seniority (older people were more likely to hold executive positions).

The numbers are now vastly different. People born in 1945 reached age 65 in 2010. There are very few in the American workforce with a direct experience of life during WWII, let alone the Great Depression. Nor are there too many who are just one generation removed from those events (that is, grew up in households directly influenced by them); those who are one-generation-removed will largely exit the American workforce by 2030.

It's no coincidence that we've seen more change in the last decade than we arguably did in the three previous decades combined. But not so much because of a new generation arriving, bringing with it new expectations and demands, as much as the old generations leaving and relinquishing the top rung of authority and social influence. Out of numbers and out of power, those value systems no longer hold sway. Although we live and work in a "post-1965" world today, it took over 40 years - two additional generations - for that to happen.

Because change is a function of society more than technology, it's slow in coming but swift once it arrives. And, while a lot of change happened with the completion of the pre- to post-1965 shift (at least, in the workforce), the stage is set for still more revolutionary change. We'll look at specific examples in the next post.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-69519279758485468602016-02-29T23:45:00.000-06:002016-02-29T23:45:01.191-06:00How an Operational Gap Becomes a Generation Gap Becomes a Valuation Gap
A decade or so ago, when an IT organization (captive or company) hit rock bottom - bloated payroll, lost confidence and ruptured trust resulting from rampant defects, rocky deployments, functional mis-fits, and long delivery cycles - it would give anything a try, even that crazy Agile stuff. It didn't matter if it was incumbent management with their backs against the wall, or new management brought in to clean house, desperate times called for desperate measures. To people looking to shake things up, Agile made intuitive sense and a lot of it was appealing, even if its proponents had a bit too much evangelical zeal and some of it sounded a little strange. So they'd bite the bullet and do it, selectively anyway: a build server was easy to provision; releasing software for testing every couple of weeks was done easily enough, and getting everybody in the same physical workspace (or at least in close proximity to one another) could be done with a little arm-twisting; of course, developers were instructed to only pair program "opportunistically", and automating QA was a fight nobody wanted to fight, so they'd sit with the team and test incrementally but go on testing the way they always had. Still, even with compromises, there was a good story to tell, usually to do with much higher quality and eliminating rework, and that made Agile A Good Thing for all parties concerned.

Fast forward to today, and we see that Agile is much more ambitious. A few short years ago we were content to have an automated build execute every few minutes; today we want every check-in to trigger a build that is promoted through progressively more complex tests in virtual environments managed, instantiated and torn down by scripts. We used to be content releasing for user testing every other week, and to production every couple of months; we now aspire to release to production many times a day. We used to want Master Story Lists to guide incremental development; today we want to iteratively experiment through code and have the feedback inform requirements definition and prioritization. We used to be satisfied with better delivery of internally-facing software; today we want to evolve software products that are used by people across our ecosystem, from interested parties to customers to investors to employees. Today, Agile wants to push against everything that creates an artificial or temporal constraint, be it organization, management, accounting policy, or even capital structure.

Although Agile has evolved, the entire tech world hasn't moved with it. In fact, some of it hasn't moved at all: it's still common to see non-Agile organizations that do big up-front design; work in functional and skill silos; have manual builds, deployments and testing; and make "big bang" releases. And, it's still common for them to face a "rock bottom" moment where they conclude maybe it's finally time to look into this Agile stuff.

As hard as it was a decade ago to inject Agile into a non-Agile organization, it's much harder today for a non-Agile organization to complete a transformation. This seems counterintuitive: since the non-Agile to Agile path is so well trod, it should be much easier than it was in those pioneering days of yore. Although there's never been more tools, frameworks, languages, books, blogs, and countless other resources available to the individual practitioner aspiring to work differently, organizational change tends not to be self-directed. The challenge isn't taking an organization through the same well-established game plan, it's finding the people - the transformational leaders - who are willing to shepherd it through its journey.

Unfortunately, re-living the same internal negotiations to reach the same compromises, solving technical and organizational problems long ago solved, only to end up with an operating model that is considerably far short of the state-of-practice today is not a destination opportunity for an experienced change leader. Even assuming, as my colleague Alan Fiddes pointed out, that the change agents brought in still have the vocabulary to carry on arguments last fought so long ago, any change agent worth their salt isn't going to reset their career clock back a decade, no matter the financial inducement.

This might simply mean that the approach to change itself is what has to change: require far less shepherding from without by expecting more self-directed change from within, brought about by setting the right goals, creating the right incentives (motivate people) and measuring the right things (what gets measured is what gets managed). Why shouldn't it be self-directed? It isn't unreasonable to expect people in a line of work as dynamic as software development to keep their skills sharp and practices current. For people leading an organization that's a little dated in how it develops software, then, the question to hold people to isn't "why aren't you doing Agile" but "we're going to deploy any time and all the time effective fiscal Q3, so how are you going to operate to be able to support that?" It's amazing what people will do when sufficiently motivated, change agents be damned.

Whether there's a more effective means of change or not, being far adrift of the state of practice points to a more severe threat to the business as a whole: a generation gap.

* * *

Three decades ago, the state of practice didn't vary that much across companies. Yes, there were people coding C over Rdb deployed in VMS on minicomputers and people coding COBOL over IMS deployed in OS/390 on mainframes, but the practice landscape wasn't especially diverse: waterfall prevailed and a lot of code was still data-crunching logic run in batch. At the time, captive IT, consulting firms, governments, new tech firms (think Microsoft in the mid-80s), and established tech stalwarts (H-P, IBM) could reasonably expect to compete for the same labor. College grads in Computer Science or Management Information Systems learned practices that reinforced the modus operandi common to all consumers of business computing.

The landscape has changed. Practices are far less homogeneous, as they've had to evolve to accommodate a diverse community of interactive users pushing for features and functionality with little tolerance for failure. The familiar combatants still slug it out for labor, but must now also compete against tech product firms untethered to any legacy practices, norms, policies or technologies. Today's grads are trained in new practices and expect their employer to practice them, too.

Companies lagging behind in their state of practice will struggle to compete for newly minted labor: why would somebody with highly marketable tech skills go to work at a place stuck in the past, when they can work in a more current - even cutting edge - environment?

This isn't just a hiring problem. A practice gap is fuel for a generation gap if it deflects young, skilled people from becoming employees. By failing to hire the next generation employee, a company develops an intrinsic inability to understand its next generation customer.

A company isn't going to reach a new generation of buyer - consumer or business - if it is tone deaf to them. A company ignorant of the next generation's motivations, desires, values and expectations has little chance of recognizing what it isn't doing to win their attention, let alone their business. Since social systems are self-reinforcing, a company is unlikely to break the deadlock of ignorance and inaction.

Failing to bridge a generation gap not only cuts a business off from growth opportunities, it sets the stage for long-term irrelevance. Investors recognize this, even when management does not. Growth changes from being a "risk" to being an "uncertainty", and when that happens a company's future1 is no longer priced at a premium, but a discount. In this way, an operational gap becomes a generation gap becomes a valuation gap.

Outdated practices are an indicator that management has it's head buried in the sand: it has a problem it can't see, that it doesn't know how to solve, that is starved for information it can't get because it has elected to disassociate itself from its source. The motivation to change how you practice shouldn't be to become more competitive today, but to still be relevant tomorrow.

1 By way of example, Yahoo net of its Alibaba holding and cash has frequently been valued at or near $0 by investors in recent years.
 Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-84478840484054049502016-01-31T18:47:00.000-06:002016-01-31T18:47:03.826-06:00Are Microservices to Ecosystems as Core Competencies were to Conglomerates?
As far back as the 19th century, industrial firms pursued vertical integration strategies. The thinking was that by owning the supply chain from raw materials to retail outlets, a firm had direct control over its entire cost structure, making it better able to squeeze efficiencies out of it and being less susceptible to supply shocks. This was important because, for large industrial firms, competing on price was the primary strategy for winning market share.

During the 1950's and 60's, companies also pursued conglomerate strategies: bringing seemingly unrelated businesses under one roof, sometimes seeking synergies (as Sears did owning a retail merchandiser and retail brokerage - "buy your stocks where you buy your socks"), and sometimes not (as LTV did owning a steel company and an airline). The rationale for the conglomerate was entirely financial: cheap (mostly debt) capital allowed large companies to grow through acquisition, and regulators were less likely to block acquisitions of unrelated firms on monopolistic grounds.

By the 1980s, both strategies had begun to lose favor. The financial benefit had evaporated: high interest rates clobbered the profits of debt-fueled acquisitions and forced divestiture. But the operating benefits weren't there, either. Different types of businesses (manufacturing, distribution, retail) require different types of leadership and have very different cultures. And, within each of those businesses, some functions are differentiating (such as fleet optimization for a logistics company) while some functions are not (nobody beats their competitors by having a superior accounting back office). Management thinking embraced "core competencies": own and hone the things that differentiate, rent and commoditize the things that do not. This also allowed for better matching of capital with company: the risks and returns from a company that owns a fleet of railcars is easier to assess than the risks and returns from a company that owns ore mines, railcars, and foundries. By breaking them up, the individual investor can choose what types of businesses to expose their capital to (a raw materials company, or an asset company, or a refining company), and the pricing of that capital more accurately reflects the risks.

Tech firms today are embracing the "vertical integration" and "conglomerate" strategies of yore by positioning themselves as "platform" and "ecosystem" companies. The thinking is that by combining multiple and diverse capabilities into a single offering, a company creates both efficiencies and synergistic value for counterparties in some activity, such as crowdsource funding or payments. The ecosystem strategy takes this even further, combining unrelated capabilities under one roof (eBay buying Skype in 2005, SAP developing HANA in 2010, Facebook buying Oculus in 2014), often justifiable if only because digital commerce is still in its infancy and nobody is really sure what's going to work and what's not.

But what if you could extract utility-like functionality from within an ecosystem into an independent company? Take payroll as an example: rather than have every Human Resources platform company need its own team of people to write and maintain state and federal witholding rules, hive those off into an independent business that makes them available as a metered service offering, charging a tiny usage tax (say, $0.001) each time it's invoked. The technology to do this is certainly available: code the algorithms as a microservice or a blockchain smart contract, and deploy them in an elastic cloud environment (as usage will tend to spike with pay cycles).

To the HR platform company, there are a lot of good reasons to do this. It monetizes a non-value generative activity (nobody subscribes to a payroll system because their implementation of the witholding rules are better than everybody else's). It throws off utility-like revenue streams that move in lock step with the broader job market. It disaggregates a staid HR utility function that needs to be deployed infrequently (potentially only as often as once per year, when new tax laws come into effect) from more innovative ones that are more exploratory in nature and demand frequent deployments (such as time entry performed through emerging wearable tech). It separates a legacy and risk-averse tech culture from a cutting-edge risk-prone one. It takes a high fixed cost for maintaining a non-differentiating characteristic off the P&L (teams maintaining rule-heavy legacy code are rarely inexpensive). It's stable cash flows would be attractive to debt finance, better aligning capital investment in HR technology. It removes asymmetric risk that can be more accurately insured (smothered in a platform, correct calculations offer no financial upside, while a faulty calculation exposes it to costly litigation and reputational damage).

True, it eliminates a barrier to entry of future competitors. And, while the market would support a handful of utilities to prevent monopoly, thin competition would give those utilities oligopic pricing power. But it creates a one-time financial windfall for the first movers, laggards would be pressured to subscribe by shareholders demanding the same structural benefits to the income statement, and low switching costs would keep utility pricing power in check.

Given that tech is in a period of both cheap capital (interest rates remain low, VC levels remain high, and companies such as Alibaba and Facebook can make acquisitions inexpensively with their own high-priced shares) and rapid growth (growth in consumption of tech products such as social media today mirrors growth in consumption of manufactured goods in the 50s and 60s), it's little surprise that we're seeing a return to industrial strategies past. But technologies like microservices and blockchain could be the modern equivalent of "core competencies" to sweep through businesses. Blockchain proponents already champion the potential of decentralized autonomous organizations (DAOs). With MBAs now eschewing investment banking in favor of tech companies, financial engineering of this nature isn't too far away.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-50345077576043829742015-12-31T18:40:00.000-06:002015-12-31T18:40:05.780-06:00Counterfactuals
Earlier this year, my house should have burned to the ground. A CR2032 battery exploded and caught fire in a confined place dense with flammable objects. But my house didn't burn down: at the moment the battery exploded, I was sitting a few feet away from it. I heard a loud bang, investigated, and stamped out the fire within a few seconds.

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

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

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

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

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

The landscape of strategic software investing and governance is riddled with speculation. As much as we would like to think we've made the best decision available to us, or dodged a bullet, we rarely know with certainty. No matter how formulaic we're told that portfolio management or delivery operations can be, they will never be as optimal or predictable as promised, because business is imprecise and untidy.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-54564223994666827452015-11-30T23:58:00.000-06:002015-11-30T23:58:01.072-06:00Corporate Middle Management as an Autopoietic System
[T]he aim of such systems is ultimately to produce themselves: their own organization and identity is their most important product.
-- Gareth Morgan, Images of Organization, p. 236.

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

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

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

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

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

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

[W]e can describe autopoietic systems as those producing more of their own complexity than the one produced by their environment.
-- Carlos Gershenson, Requisite Variety, Autopoiesis, and Self-Organization.

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

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

* * *

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

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

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

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

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

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

The policeman is not here to create disorder. The policeman is here to preserve disorder.
-- Richard J. Daley, 48th Mayor of Chicago

What does change look like under these circumstances?

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

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

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

Bad events in organisations are generally the product of bad systems rather than bad people ... [W]e need to go on and ask what it is about modern corporate life that has made such misbehavior not only possible but appear increasingly common.
-- John Kay, Organisations advance by asking "what went wrong" rather than "who is to blame

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

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

-- Warren Buffett

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

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

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

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

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

The difference between a change leader and a caretaker isn't lofty vision or inspiring words, it's the ability to create maximum potential within the organization, and the motivatiors that drive people's behaviors and actions to realize it.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-53092917906052671852015-09-30T23:42:00.000-05:002015-09-30T23:42:00.880-05:00Capitalizing Tech in a Cloud / SaaS / Continuous Delivery World
Around 2010, when US companies could count on a recovering domestic economy, a weak US dollar, and growing emerging market economies, CFOs didn't need to work that hard to flatter the income statement. This has changed: the US recovery has been inconsistent, emerging markets are performing poorly and the US dollar is strong (taking the edge off overseas revenue). Plus, firms are carrying more debt than they were a few years ago, making the optics of the P&L that much more important.

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

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

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

What does it mean? Well, we don't know. For one thing, we're not really there yet. We know that this echoes the supercycle of businesses separating into asset-light operating companies (e.g., retailers) and asset-heavy finance companies (e.g., REITs). But we also know that a lot of firms still license captive ERP systems (no SaaS), operate captive data centers (no Cloud), and issue hardware to employees (no BYOD). In development, Continuous Delivery is still more idea than implemented among firms predisposed to capitalize rather than expense their software development costs. The execution trend toward tech asset light matches - but lags - the financial trend.
For another, specifically with regard to capitalizing development, we fit Agile under FASB 350-40 without violating the intent of the original AICPA policy (SOP 98-1), but we never explicitly formulated policy to reflect how work got done in an Agile world. For as much as we made Agile perform better than Waterfall under capitalization policies (e.g., better opex/capex ratio), it's always been an ill-fitting Waterfall suit around an Agile body. Fast forward, an today we have Continuous Delivery, which takes Agile concepts of frequent delivery and Lean development practices to the next degree. This extends the already long tail: accounting policy (treatment) lags tech execution (Continuous Delivery is still wishful thinking in most firms) lags financial expectation (asset light).

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

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

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

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

If the capital cycle still matters, this is bad for tech. If the tech cycle trumps the capital cycle, it doesn't. We'll look into that a bit more closely next month.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-50392006450745919532015-08-31T23:14:00.000-05:002015-08-31T23:14:00.070-05:00Capital Structures and Organizational Pathologies: Tech Investments in Slow Growth Equity Funded Companies
The volatile nature of tech companies makes them better suited to equity funding as opposed to debt. Equity is high-risk capital: owners are exposed to the upside of growth (you stand to make a lot of money), but also the downside of failure (you stand to lose everything you put in). Debt is not: how much risk is there to the lender when the borrower guarantees a return? Plus, in the event of a liquidation, creditors are first in line to be made whole.

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

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

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

But are they?

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

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

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

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

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

Changing the culture from "coast" to "hustle" challenges the company's willingness to act, all the way to the board. Sadly, if the stock price gets a lift simply by basking in the reflected glory of actual tech innovators, the board is more likely to interpret it as a validation of its decisions to date than it is willing to depart from them. The firm may be tech ready, but it is change averse.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-26585889691865828302015-07-31T22:55:00.000-05:002015-07-31T22:55:00.228-05:00Capital Structures and Organizational Pathologies: Tech Investments in Debt-Fuelled Capital Intensive Companies
Portrait of a growing company: a corporate parent with two-thirds of its enterprise value in debt, running two separate but interdependent divisions: a capital intensive asset heavy business, and a cash generative consumer-focused operating firm.

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

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

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

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

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

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

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

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

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

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

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

Next month, we'll look at other operating pathologies driven by the capital structure.
Ross Pettithttp://email@example.com:blogger.com,1999:blog-30621875.post-15784666733314195072015-06-30T17:12:00.000-05:002015-06-30T17:12:00.280-05:00Without the Right Capital Structure, There is no Software Company Within
Is every company destined to be a software company? From a production perspective, there's reason to believe so: relatively minor things that were once the domain of hardware (configuration set by switches on a circuit board), operations (merchandise re-ordering based on sales and quantities) or subscription (license fees paid for usage) have become things that are now the domain of software (configuration is set through a browser interacting with Java code running in a Linux variant deployed on a hardware device; algorithms that automatically re-order merchandise based on seasonal, demand & promotional variables; advertising-sponsored or use-metered interaction). Virtual data centers, real-time algorithmic pricing, and new media are simply larger versions of that same phenomenon.

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

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

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

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

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

Next month, we'll look at the organizational pathologies created by different capital structures and how those make a firm that innovates and competes through software as opposed to a firm that ingests and consumes software.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-46840428313479571082015-05-31T20:21:00.000-05:002015-05-31T20:38:17.338-05:00Would Uber be so intriguing if we thought of it as the next American Airlines?
Suppose for a minute that self-driving cars become commercially available. Obviously, a lot has to happen before we get to that point, but suppose that it does. What happens to the economics of ground transportation?

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

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

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

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

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

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

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

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

Still, it suggests that the future of the dial-a-car business will be an exciting one, but for a different set of reasons than anybody is projecting today: intense competition, race-to-the-bottom pricing, volatile earnings, and the occasional trip through bankruptcy. Not exactly the kind of future that captures the imagination.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-17400186282229242272015-04-30T22:51:00.000-05:002015-05-01T09:19:45.466-05:00Matrix IT Organizations, Part II: The Inmates Are Running the Asylum
A few months ago, we took a look at the pathologies of matrixed organizations: no focus, amateur management, and people waging turf wars to secure power that they can exercise without consequence. The result is stationary organizational inertia, the portrait of a seized-up business.

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

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

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

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

-- Ibid.

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

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

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

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

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

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

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

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

The options aren't all that great in this situation, which is why professionals aren't attracted to them in the first place. If you're brought in as Chief Executive or part of an executive team with an explicit mandate from the board to make sweeping change, you have a chance. But if you have a weak board overseeing a delusional CEO and a sales force for whom every dollar of revenue is the same, all producing initiatives that require tech and operations to compromise to compensate for a lack of revenue, you're wasting your time: you're in the asylum, and there's no one to hear you scream.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-43479346449866257182015-03-31T21:41:00.000-05:002015-03-31T21:41:00.192-05:00Activist Investing in Strategic Software Chapter 1 Excerpt - Why Governance Matters
I've published drafts of the introduction and first 4 chapters of my book, Activist Investing in Strategic Software. I still have some citations to finalize, several visuals to integrate and a lot of editing to do. But the foundation is there. A sample of the book (currently, just the introduction) is available on from the site.

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

* * *

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

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

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

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

-- Gavin Anderson, Chairman, Governance Metrics International

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

Just as a corporation is an investment of capital, so, too, is strategic software. What is true for a company at a macro level should be true at a micro level. The characteristics of good corporate governance should be present in IT governance: an independent board that sets expectations, chooses and changes leadership as necessary, and validates results reported by that leadership.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-83848837746094815932015-02-28T22:03:00.000-06:002015-03-01T17:47:35.077-06:00Activist Investing in Strategic Software
A few years ago, I felt I had enough experience - and had put enough thought into the subject - to write a book on governance in software development. I had observed that most tech firms and captive IT organizations are largely left to self-govern, and both are pretty light touch about it. I had also observed that governance is widely misunderstood and the term is used in technology in a lot of different ways, almost universally incorrectly. With more ambitious investments being made in software and the success rate of large projects not getting all that much better, the need for better governance was there. Plus, it seemed to me that if IT didn't get its act together soon enough, the CFOs of the world were going to get IT's act together for it, so it also made sense to write it from a bit more of a financial rather than an operations perspective.

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

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

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

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

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

But today, the first draft of the first chapters of my book, Activist Investing in Strategic Software, is available on Leanpub.
Ross Pettithttp://firstname.lastname@example.com:blogger.com,1999:blog-30621875.post-47283906089033084792015-01-31T23:41:00.000-06:002015-01-31T23:41:00.200-06:00Matrix IT Organizations, Part I: Turtles all the way Down
Multiple layers of authority overlap both horizontally (different people and committees engage with the same issue) and vertically (many decisions are liable to review by some other body). The lack of focus in decision making results in an absence of executive authority; while professional management is subject to random amateur interference. In consequence, able people are not easily attracted to management roles; and so the amateurs view the professionals with often justified and frequently reciprocated contempt.
-- John Kay, How a proud corporate history can lead to poor governance

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

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

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

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

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

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

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

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

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

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

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

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