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

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

Saturday, February 28, 2015

Activist Investing in Strategic Software

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

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

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

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

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

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

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

Saturday, January 31, 2015

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

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

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

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

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

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

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

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

Wednesday, December 31, 2014

The CIO and M&A, Part II

Integrating businesses is no small task.  Established workflows, systems and tools are vigorously defended yet poorly understood.  Fearing for their jobs, people will equate systemic knowledge with job security.  Many in the acquired business will cling to their legacy identity. Organizational politics - and power plays - will alter tactical integration plans.  But it is the business goals that investors signed up for - not the internal special interests - that will determine the fate of the leadership responsible for the integration.  How do we stay focused on these?

Be a business leader, not a technology partner. Technology leadership must be fluent in the broader business context of the integration and be prepared to make decisions on behalf of the business, not just the technology applied to the business.  This means being or bringing in business process analysts to simplify the operations - and with it, the technology - of the business itself.

I wrote last month that most material on the role of IT in M&A are platitudes, and this certainly smacks of one.  But the fact is, this is not something that IT departments have in recent years positioned themselves to do.  The change in moniker from "Information Systems" to "Information Technology" has been a detriment to CIOs: the word "systems" implied responsibilities inclusive of business and technology, whereas the word "technology" suggests it is solely responsible for tech.  As a result, there is less expectation that tech will shape business decisions as much as it will carry them out.  It doesn't help that business analysis skills remain low in captive IT.

M&A gifts captive IT with the opportunity to be the "resident adult" in sorting out intransigent participants in an integration. However, that opportunity exists only if it is prepared to act as a business leader and not merely a technology supplier.

Slowly strangle, don't wholesale replace. Existing systems are complex: they have highly specialized rules that were developed over a number of years, they were developed with very different architectural principles than would be applied today, and the older the underlying technology the scarcer the technological know-how there is to incrementally change them.  This makes it easy to make the case that dueling systems are incompatible with one another, are no less valuable owing to the criticality of the specific edge cases they accommodate, and can only be replaced through a large "enterprise"-scale rewrite.  Thus we have no choice but to maintain the status quo, and only costly and high-risk change can possibly sweep it away.

The headwinds to change blow fiercely; there are always plenty of reasons not to do something.

Unless both organizations have extraordinarily geriatric technology, proposing an enterprise refit will be met with skepticism in the boardroom that will cast doubt on our leadership capability.  Even a big-bang retrofit of one incumbant technology to take the place of another will receive only a grudging endorsement.  Both scenarios also create tactical confusion: should existing systems be modified to meet immediate business needs or do we wait for the big-bang replacement?  And what do we do if that big bang replacment gets delayed?

We avoid this trap by strangling existing software.  In effect, we allow our portfolio of assets to continue to evolve with the business while simultaneously deprecating and retiring them.  We do this gradually, identifying specific functionality that can be integrated and replaced.  We have the practices and technologies today - from continuous integration to feature toggles to branch by abstraction - to make this a matter of will.  It is also palatable to the board because it gives us a means to show how we are structurally reducing our cost of operations in a manner that will support the business in the short-term and sustain it in the long-term, not a slash-and-burn approach that makes it thinner at the cost of making it more sclerotic.

This will mean making some unpleasant decisions. We may have to create new code - a lot of new code - to integrate old code on our way to fully retiring it.  We may have to integrate in unpalatable ways (e.g,. at the database level) where legacy systems do not support modern architectural principles.  And there will be times when the extent of integration will makes our collection of assets very complicated.  This means that our measure of success isn't just getting things deployed, but getting things removed.  To the CIO, the critical measure is a composite "simplicity index" of all IT systems, not "integration progress" in simply making systems work together.

Insist on excellence in engineering.  When the clock is ticking, there will be temptation and pressure to cut corners.  We can create the appearance of integration with quick and dirty solutions, and all that matters in the end is that it works, not how it works.

The phrase "we'll fix it later" probably has the lowest conversion rate of any statement made in business. An implcit expectation in M&A is that we are investing in simplicity and robustness, not complexity and brittleness.  The reality is, we're not going to get money later to pay down technical or operational debt we take on. If the combined landscape has more moving parts and fragmented institutional knowledge than the sum of the parts of the combining companies, we'll have a higher cost of operations and, therefore, have failed.

Investigate, measure, and draw attention to quality of engineering.  Instrument all code, looking specifically for complexity, duplication, testability, and test coverage.  Incentivise good engineering practices and reward teams that make structural and procedural improvements.  Take deliberate action against poor engineering decisions: delay an implementation rather than accept a poor one.  We have to live with the consequences of our decisions; make clear that we have invioable standards of performance.

Nobody is irreplaceable.  Inheriting somebody else's code is never much fun.  We have to deconstruct what other people were thinking at the time they created it, while simultaneously trying to understand the business context that existed at that time versus the context that exists today.  It's much easier to fight for funds to perpetuate a legacy team than it is to take responsibility for cleaning it up.

Two things to remember: it's just code, and the people behind both the code and the business usually don't have as much systemic or contextual knowledge as we project into them that they have.

To the first point, most code is not as algorithmically complex as we are told that it is.  The implementation might be complex, but implementation decisions are generally easy to discern (somebody really liked Java interfaces, so everything is implemented as an interface).  Once we figure that out, it's fairly straightforward to restructure the code and increase test coverage to make it more testable.  This is true for current and legacy languages alike.

To the second point, don't assume that the business leaders have as solid a grip as you'd hope they do as to why they do the things they do.  Some years ago, I was working with a firm to redesign fleet maintenance operations.  The existing suite of software tools were a combination of RPG, Visual Basic, Java and Excel, tied together with a number of manual integration steps.  The business operations leaders could only understand operations in the context that the technology allowed them to do these things.  We had to understand their business operations better than they did to get them to understand the actual value stream.

Do not be held hostage by tribal knowledge or the perception of that tribal knowledge.  Reward people for knowledge sharing and provide career paths for people to move beyond system caretakers to leadership roles that builds on their experience in mission-critical systems and knowledge of how the business itself operates.  Do not be afraid to cut people loose who are obstacles to change, no matter how entrenched they are perceived to be. Best of all, replacing legacy systems will reduce pockets of that knowledge: we start the clock ticking on it the minute we start to retire it.

Put your personal credibility on the line for these things.  A CIO has only as much time as the M&A horizon to create a common culture within the technology organization. Whatever the cultural norms are of the two firms at the start, insisting on engineering excellence, business leadership, and gradual improvement while being willing to accept responsibility for cutting loose tribal knowledge sets a decisive tone of change within an organization.  This creates both a new mission and a new identity for everybody.

Most importantly, we have to make it clear to all and sundry that we are every bit as much on the line for these things as they are.  We will take responsibility for a delay in implementation where quality is sub-standard.  We will develop new leaders in our organization rather than being forced to retain people in existing roles.  Our actions will speak louder than our words.

Nobody is irreplaceable.  If we fail to deliver, we'll find that out to be true for us, too.

Sunday, November 30, 2014

The CIO and M&A, Part I

"It is hard not to be cynical about this. M&A is a great process for creating fees for bankers, and for destroying the value held by shareholders."

-- John Authers, writing in the Financial Times

Industries tend to go through waves of deal-making. Sometimes it is divestiture or separation: sprawling firms that serve different buyers or markets don't achieve much in the way of operating efficiency, and a "conglomerate discount" priced into their equity means there is value that can be released by dividing a firm into multiple businesses. This is something H-P did in the late 1990s, and is about to do again. But usually, deals are acquisitions: competitors merge to gain more power over costs and prices (United Airlines merging with Continental); large firms acquire smaller ones to enhance their core (Yahoo has been on an acquisition tear in recent years), diversify their markets, or simply to prevent a firm from falling into the hands of competitors (Microsoft's acquisition of Skype).

The justification for a merger or acquisition usually involves some quantification of synergistic benefit: the two businesses have so much in common they can achieve greater profitability together far sooner than they would be able to on their own. This can be achieved through sales: Company A and Company B sell complimentary products to the same buyers; a merger of the two would allow for cross selling, resulting in larger and more lucrative sales. It can also be achieved through operating efficiencies: Company A and Company B can operate just as effectively with, say, 70% or less of their combined procurement, finance, accounting, HR and IT organizations.

The expected synergistic benefits to revenue and costs are calculated, then taxed and capitalized, to come up with a hard economic value to doing a deal. This makes them important to the CEOs involved because they help them sell their respective boards - and shareholders - on doing a deal. Their importance increases in direct proportion to the premium an acquirer is willing to pay to buy another firm. Synergies can be substantial: the proposed synergies of the merger between Office Max and Office Depot exceeded the combined market capitalization of the two firms.

* * *

"Most deals fail to create value because the buyer paid too much, or because the acquirer failed in the difficult task of sticking two companies together. Glossy proclamations of new strategic visions often boil down to a prosaic cost-cutting exercise, or into a failure of implementation."

IT is at the center of deal synergy. Obviously, we don't want to pay to maintain multiple e-Commerce sites or pay licensing fees for multiple ERP systems. But redundant IT systems can increase the cost of doing business: if we need people in finance to write custom reports to combine financial reporting across the two businesses, the merger has increased our total cost of operations. We need to combine systems, and do so quickly.

There are plenty of cookie-cutter frameworks for combining businesses, even their technology systems and operations. This also means there are plenty of platitudes to go round: "Involve the CIO as part of the executive team from the start" and "IT doesn't work in isolation". True, but not very helpful. Rubber hits the road in M&A in the actual combination - and reduction - of systems. Platitudes will not change an ugly operating reality.

IT in M&A can be a very messy business. For example, suppose Company A acquires Company B and intends to move Company B - running a highly customized & partially proprietary ERP - over to Company A's similarly customized, but commercial-off-the-shelf, ERP system. Company B has very different business processes and communication channels from Company A. The new divisional leader for that part of the combined company is from Company B and decides he wants those processes applied to the combined business. IT must now make changes to Company A's ERP system and dependent code to accommodate this change, in addition to migrating data. Costs just went up and the consolidation timeline just got longer - and depending on your point of view, it looks like an IT problem.

This also applies to the mundane stuff. For example, IT learns that the data and data structures in Company B don't exactly line up with Company A, so data migration is going to take more effort than originally expected. IT responds by creating data warehouses to house consolidated data so that Finance can run its consolidated reports. Costs just went up, as did operational complexity: those warehouses - and the ETL that refreshes them - have to be maintained and updated.

When companies pay a premium to fair value of net assets for a business they acquire, the excess is recorded on the balance sheet as goodwill. In theory, the value of the combined business should increase as synergies are realized, obviating the need for goodwill. The reality - and core to Mr. Auther's comments above - is that companies have a tendency to pay too much in acquisitions and end up taking a writedown. One study found that between 2003 and 2009, some 4,600 firms wrote-down goodwill due to impairment, amounting to 20% of total recorded goodwill. The study went on to report that there are some serious ramifications to this. For one thing, "the news of goodwill write-off [...] precede[s] CEO resignation and can trigger shareholder lawsuit." For another, "Firms with goodwill write-offs significantly under-perform in future." (Feng Gu, Goodwill and Goodwill Write-off: Economic and Accounting Implications)

So, in a M&A situation, there's a lot on the line for the CIO: you don't want to be the reason the boss loses his job, and you don't want to be a reason why the stock price underperforms. But your operating reality is messy: you're beholden to tribal knowledge of systems you've inherited through the acquisition, you're at the mercy of business decisions that are made for local optimization or simply local convenience, and you're under the gun to enable finance and accounting to create the patina of a combined business for the benefit of the people who approved the deal. As CIO, you'll be under pressure to extend and even bump your payroll to prevent loss of knowledge, create teams to chase business decisions with new software, and take on technical and operational debt to make good on immediate needs.

There is no playbook for this.

Next month, we'll look at how a CIO can square this circle.

Friday, October 31, 2014

Can a Business Rent a Core Capability?

Tech utilities - things that automate administration, enable communication or improve employee productivity - started as a labor expense, became a capital expense, and have now become a rent payment. This final state is an efficient economic relationship for buyer and seller. The buyer has more flattering financial statements and can negotiate for non-core services at a gross level (e.g., a single cost per employee). The seller's income is the rent they can extract from buyers. Utility sellers tend to enjoy monopolistic or oligopolistic market conditions, but there is still room for optimization and even disruption that drives prices down.

But disruptive tech is not a utility. It needs to be developed, and developing it requires a capability in technology (design, coding, testing, etc.) In recent years the trend has been toward renting that capability rather than owning it. This begs a question: can we rent the capability needed to deliver disruptive tech? If today's disruptive tech becomes tomorrow's status quo, doesn't that mean it needs to be part of a firm's core competency?

Two significant factors stand out when considering this question: the state of evolution of the (would-be) disruptive tech, and the extent to which it is genuinely disruptive.

Let's look at the latter part - the extent of disruption - first. New technologies disrupt by creating new behaviours and expectations among its users. In the process, it siphons market share by shifting market participants from one activity to another. Obtaining a book changed from making a trip to a bookstore to an online purchase that triggered a package shipment to an electronic distribution. Social media is a form of entertainment that shifts people's allocation of their leisure time.

Creating new behaviours is more disruptive than being the first to apply technologies established in one market segment into another: streaming video to personal technology on airplanes is interesting, and doubtless it will allow airlines to eliminate in-seat entertainment systems that add weight and burn jet fuel, but it brings established behaviours into a different context. Still, this is more disruptive than developing technologies that mimic existing functionality in the same segment: being late to the game with a "me, too" strategy does not generate much in the way of behaviour change.

With this in mind, let's consider the other dimension, the state of evolution of that technology: is it in research, is it an arms race, or is it a mature solution?

A company investigating a disruptive technology for its potential doesn't have to own the means by which it does that investigation. An exploratory investment is generally developed rapidly and deployed frequently to accelerate the rate of exploration. The differentiating value of effective exploration are speed, adaptability, and the ability to interpret the feedback from the experiment. It may succeed, or be a mild success, or be a complete bust. It's safe to rent as this is a non-operating capability. That a firm does this suggests the firm in question is slow growth and run for efficiency and lacks an R&D capability, but this describes a lot of firms: oil majors have separated into refiners and E&P, and pharma firms have similarly split into generics and growth / R&D firms.

However, a disruptive technology that rapidly gains adoption must become a core competency, and quickly at that. This is a phase when a firm is learning new rules for competition. Firms must learn what works and what doesn't (what we do and don't do), and what matters and what doesn't (what we measure and pay attention to, and what is just a distraction). Successful firms have to rapidly master new business operations under the pressure of scale and growth. Success is equal parts business and tech: the business is changing and the tech is brand new. Renting the tech capability puts a company at a disadvantage because it will not develop core competencies, fundamental skills, communication patterns, and organizational leaders critical to it's "new normal". In a tech arms race, it's not safe to rent.

The extent of disruption determines impacts the feasibility of renting. It is safer to rent capability where the tech follows established patterns. When a firm consumes established technologies to create products and solutions for a specific vertical, there is greater value in the business knowledge because the tech contributes less value to the solution. This makes it safer to rent the tech capability. The less disruptive, the less the risk: there's little point in owning a capability with a mission to mimic somebody else's tech.

Of course, the economics of renting or owning are muddled by other market forces. A start-up compensating employees with equity is not paying market value for its labor and is therefore renting, similar to how a lender owns a house that a borrower lives in. And tech buyers have no choice but to rent tech labor from services firms because of labor scarcity.

A company might have to rent because of prevailing labor market conditions, or because renting gives it a shot-in-the-arm that allows it to catch up when it is caught unprepared by a technology shift. But as Machiavelli counseled, one holds conquered territory with one's own forces, not mercenaries. A company has to own its core.

Tuesday, September 30, 2014

Tech: From Owning to Renting - to Owning Again?

In the 1970s, the predominant business strategy was vertical integration: own the value chain from raw materials to retail outlets. The research of the time supported this. The Profit Impact of Market Strategy database produced by the Strategic Planning institute concluded that diverse & vertically integrated businesses were significantly more profitable than narrow and focused businesses (PIMS 1977, slide 67). Michael Porter argued in Competitive Strategy that vertical integration enabled cost leadership, which was more likely to win market share than a strategy of differentiation. Vertical integration also created a barrier to entry to competitors, and provided defense against powerful buyers & suppliers and the threat of substitutes (Porter 1980, pages 9-15, 35-37). Corporate strategies assumed long-term existence and growth; this made employer-employee relationships more durable, so a firm could be a destination employer for people across a diverse range of roles. Companies like American Telephone & Telegraph and General Electric could pursue diversification and vertical integration in no small part because they could be all things to all people.

Business strategy changed in the 1990s, insisting that companies were better off focusing on "core competencies" while renting anything deemed non-core. A retailer, for example, should concentrate on sourcing merchandise to sell and developing the outlets through which to sell it, but rent the accountants, IT, back-office staff and real estate to operate and administrate the business. The thinking was that a firm could not be expert at doing everything, it would have cost bloat in non-core areas and lack the expertise to contain it, and that firms needed to pay ruthless attention to their core as competition would only intensify. It also became accepted that a firm could not be a destination employer for non-core employees and therefore could not expect to be attractive to top flight people across the board. Outsourcing for business and technology services reduced the number of employees and associated costs, allowed significant operating costs to be negotiated on a gross basis rather than an individual one, and made labor arbitrage accessible to firms for which it would have been too risky and difficult to pursue by themselves.

This change happened quickly. Perceptions of corporate durability imploded in less than a decade through consolidation (increase in M&A) and bankruptcy (over-leveraged with junk-grade debt and unable to make debt service payments). This eroded the employer-employee relationship and made any single firm less broadly appealing. Kodak outsourced IT to IBM in 1989, ushering in large-scale IT outsourcing that fueled the rapid growth of firms like Accenture and TCS over the ensuing two decades. GE created a business process outsourcer - Genpact - in the late 1990s, spinning them off as an independent company within 10 years. Firms separated asset ownership from asset usage, creating holding companies that own the real estate and rent it to subsidiaries that run business that occupy it. In a relatively short span of time, companies went from owning everything and renting nothing, to owning little and renting everything, with lots of financial intermediaries springing up to minimize tax burdens and squeeze rents.

In technology, cloud computing extends this story arc. Prior to the advent of computers, business was labor intensive. When companies first invested in computer technology by buying mainframes and hiring programmers, they did so to create efficiencies in their administrative operations. Companies reduced their labor expense, and the hardware and software they acquired appeared on the balance sheet as capital investments in the business. In the process, they also made business application development a "core competency" of their business. Within 40 years, most of those administrative processes were standardized by commercial-off-the-shelf ERP products. But that ERP solution still appeared as an asset on the balance sheet because software licenses, customization, and server infrastructure were capitalized assets of the firm, even if the people who led the customization and implementation were rented and not employees.

This is beginning to change. Cloud, Saas, and BYOD allow firms to rent technology rather than own it. As businesses have consumed increasing amounts of computer technology over the years - communication tools, productivity tools, business administrative software, servers, routers and end-user devices - company balance sheets have become increasingly "tech asset heavy". Renting makes their balance sheets "tech asset light". Rent payments put a dent in cash flow from operations, and the cost of renting can be higher than the cost of owning. However, renting improves performance ratios such as "return on assets" and "capital intensity". This flatters the CEO and the CFO.

Early computer technology transferred labor intensity of business activity (lots of clerks on the payroll, performing manual chores) to capital intensity (computers & software automating these chores, booked as capital assets), but it was still accounted for as something the business owned rather than rented. Cloud, SaaS and BYOD will drive out the lingering capital intensity by shifting the technology assets from "own" to "rent". A business still has costs associated with these things (it has to generate invoices and collect from customers), but as the underlying functions become more and more commoditized they offer no strategic advantage, and are instead treated as a tax on doing business. There is still room for innovation - new firms will emerge to offer new ways of providing these services to minimize this "tax" - but these are commodity offerings competing in a race to the bottom on price.

Businesses originally owned their tech capability, because that was the prevailing way that businesses operated, computers and computer skills were scarce, and firms derived significant competitive advantage from being early adopters. That changed because strategic thinking changed, technology became commonplace, and a lot of business technology became utilitarian. But what's true for utility tech is not true for disruptive tech, that is, tech that disrupts business models. Businesses are no longer consumers of tech, they are becoming tech. If every firm is a software firm, does technology need to return to the core? Will the business practices that developed and evolved with renting be adaptable, irrelevant, or an outright encumbrance? We'll look at those questions in the next post.

Sunday, August 31, 2014

Why Commercial Contracts Matter In Agile Software Development

"We value customer collaboration over contract negotiation." -- The Agile Manifesto

Contracts for software development have historically included language that specifically defines the software being developed. This protects the buyer from paying for an asset that does not serve its business needs, the seller from requirements drift or expansion, and allows both parties to agree to duration and cost.  Traditional development contracts also stipulate the process by which the software is to be developed and tested, and how changes will be accommodated.  Since the way something is produced has direct bearing on the quality of what gets produced, specifying the process protects the buyer from slipshod work practices, and gives the seller a formal framework to control the development lifecycle.  The parties are trading a long-dated asset for a series of short-dated cash flows; being specific about the work being produced and the means of production is a means of protecting each party's economic interests throughout.

But with Agile becoming more and more widespread, contracts that stipulate requirements, team composition and change control processes lock both buyer and seller into a commercial arrangement that is an encumbrance (requiring constant amendment to accommodate changes) and may actually interfere with delivery.  Agile development requires more flexible contracting.  So it comes little surprise that a core tenet of the Agile manifesto is that people involved in developing software should constructively collaborate with one another to deliver a valuable business asset, not conform to a strict protocol that defines allowable behaviours.

The rigidity of traditional contracts has led firms in the Agile development business to experiment with looser contractual language.  In principle, this makes sense.  Agile teams deliver more frequently, so the lag between the buyer's cash and the seller's delivery isn't as great as it is with traditional software development.  Frequent showcases and deliveries improve trust and confidence between buyer in seller in ways that can't be codified in the language of a contract.  The benefit of looser language is that as teams learn more about the actual business needs and technical complexity of what they are developing, they have more freedom to act (and react) as the situation warrants.  There should also be limited downside. Even if the contract is vague, a buyer won't pay if she doesn't like what the seller has produced, and a seller will suspend work if he has an unwilling or incompetent buyer.  The people involved have maximum leeway to get stuff done and they'll let each other know in the most direct means possible when they're not happy.

In place of precisely defined language, it isn't uncommon to see development contracts that capture none of the intent whatsoever, and define only a supply of an unspecified number of people for an indefinite period of time.  If the understanding ex-contract is that the seller is there to develop software for a particular purpose in a particular manner, the contract is, in theory, at best a formality and at worst takes too much time.  If the development work is treated as R&D rather than a capital investment, doing this doesn't flaunt accounting practices (which require strict definition of capital work).  And if one party is disappointed with another during development, they'll make that abundantly clear by suspending performance until they are happy.  This is the triumph of the desire to get stuff done over the formality of contract law.

"That is, while there is value in the items on the right, we value the items on the left more."

But contracts do matter.

A contract expresses the value each party places in the other and the respect they have for one another.  The preamble language defines who the parties are or think they are as an acknowledgement of the strengths that each bring to the relationship: they are disruptors ("re-imagining the classroom for the 21st century"), or market leaders ("the nation's largest provider of financial services to retirees"), or specialists ("the leading provider of software development services to municipal governments in the tri-state area").  This underscores goals of the buyer (the disruptor is buying an innovative solution; the market leader wants cost efficiencies) and the capability of the seller (technical, process or subject matter expertise) and why the two parties want to work together.  In the contract, if the buyer is just a business no different from any other, and the seller is just a provider of people, the relationship will eventually come to reflect this, too.

A contract communicates the outcome the parties are working toward.  If the buyer wants an asset, they are committing to developing an asset in conjunction with a partner, and both buyer and seller are drivers in achieving that goal.  If the buyer wants only to rent capacity from the seller, the seller will be a passenger in the buyer's goals.

A contract defines a bond between two organizations, a bond that is meant to be durable in good times and in bad.  The more closely twined buyer and seller, the more likely they are to resolve their differences and difficulties. The more disposable a relationship, the more likely one party will dispense with the other when greener pastures beckon.

We don't want contracts that are ignorant of the need for flexibility.  But convenience erodes commitment: flexibility achieved through ambiguity undermines a sense of partnership. It is better to achieve flexibility through provisions that define the parties, define the mission, and define a bond.  This creates a commitment to the principles of a relationship.

Contracts exist between companies; relationships exist among people.  A relationship will always trump what's written in a contract.  But people come and go, and relationships are constantly tested.  A contract easily exited undermines the commitment of a relationship.  Good contracts are not an encumbrance to delivery: they strengthen the commercial ecosystem through which delivery happens.