Self-Insuring Software Assets

When we buy a house, we also buy insurance on the house. Catastrophic events can not only leave the homeowner without shelter, they can be financially ruinous. In the event of a catastrophe, the homeowner has to be able to respond quickly to contain any problems, and be able to either enact repairs herself, or mobilize people and materials to fix the damage. Repairs require building materials and a wide variety of skills (electrician, mason, carpenter, decorator). Most homeowners don't have the construction skills necessary to perform their own repairs, so they would have to set aside large capital reserves as a "rainy day fund" to pay for such repairs. But homeowners don't have to do this, because we have homeowner's insurance. In exchange for a little bit of cash flow, insurance companies make policyholders whole in the event of a catastrophe by providing temporary shelter, and providing the capital and even the expertise to make repairs in a reasonable period of time.

When we build software, we don't always buy insurance on the software. For software we build, we underwrite the responsibility for the fact that it will be technically sound and functionally fit, secure and reliable, and will work in the client and server environments where it needs to operate. As builder-owners, we have responsibility for these things during the entire useful life of the software. This obligation extends to all usage scenarios we will encounter, and all environmental changes that could impair the asset. If regulation changes and we need to capture additional data, if a nightly data import process chokes on a value we hadn't anticipated, if our stored procedures mysteriously fail after a database upgrade, if the latest release of FireFox doesn't like the Javascript generated by one of our helper classes, it's our problem to sort out. There is nobody else.

In effect, we self-insure software assets that we create. When we build software, we underwrite the responsibility for all eventualities that may befall it. Self-insuring requires us to retain people who have the knowledge of the technology, configuration and code; of the integration points and functionality; of the data and its structures; and of the business and rules. It also requires us to keep sufficient numbers of people so that we are resilient to staff turnover and loss, and also so that we can be responsive during periods of peak need (the technology equivalent of a bad weather outbreak). Things may be benign for most of the time, but in the event of multiple problems, we must have a sufficient number of knowledgeable people to provide timely responses so that the business continues to operate.

The degree of coverage that we take out is a function of our willingness to invest in the asset to make it less susceptible to risk (preventative measures), and our willingness to spend on retaining people who know the code and the business to perpetuate the asset and to do nothing else (responsiveness measures). This determines the premium that we are willing to pay to self-insure.

In practice, this premium is a function of our willingness to pay, not of the degree of risk exposure that we are explicitly willing to accept. This is an important distinction because this is often an economic decision made in ignorance of actual risk. Tech organizations are not particularly good at assessing risks, and usually take an optimistic line: software works until it doesn't. If we're thorough, previously unforeseen circumstances are codified as automated tests to protect against a repeat occurrence. If we're not, we fix the problem and assume we'll never have to deal with it again. Even when we are good at categorizing our risks, we don't have much in the way of data to shed light on our actual exposure since most firms don't formally catalogue system failures. We also have spurious reference data: just as a driver's accident history excludes near-miss accidents, our assessments will also tend to be highly selective. Similarly, just as an expert can miss conditions that will result in water in the basement, our experts will misjudge a probable combination of events that will lead to software impairment (who in 2006 predicted the rise in popularity of the Safari browser on small screens?) And on top of it all, we can live in a high risk world but lead highly fortunate lives where risks never materialize. Good fortune dulls our risk sensitivity.

The result is that the insurance premium we choose to pay in the end is based largely on conjecture and feeling rather than being derived from any objective assessment of our vulnerability. Most people in tech (and outside of tech) are not really cognizant of the fact that we're self-insuring, what we're self-insuring against, the responsibility that entails, and the potential catastrophic risks that it poses. Any success at self-insuring software assets has little to do with thoughtful decision making, and more to do with luck. If operating conditions are benign and risks never manifest themselves, our premium looks appropriate, and even like a luxury. On the other hand, if we hit the jackpot and dozens of impairments affect the asset and we haven't paid a premium for protection, our self-insurance decision looks reckless.

Insuring against operating failures is difficult to conceptualize, more difficult to quantify and an even more difficult to pay for. We struggle to define future operating conditions, and the most sophisticated spreadsheet modeling in the world won't shed useful light on our real risk exposure. Willingness to pay a premium typically comes down to a narrative-based decision: how few people are we willing to keep to fix things? This minimal cost approach is risk ignorant. A better first step in self-insuring is to change to an outcome-based narrative: what are the catastrophes we must insure against and what is the income-statement impact should those happen? This measures our degree of self-insurance against outcomes, not on costs.

Zombie Businesses

The Lehman bankruptcy is best known as the event that triggered a financial crisis. For many firms, it also sowed the seeds of an operating crisis.

Revenues plummeted at the end of 2008. Companies retrenched by laying people off. Managers coped with smaller staffs by asking employees to perform multiple jobs and to work longer hours. With remaining employees grateful to have kept their jobs, and with the economy leveling off rather than staying in freefall, corporate profitability rebounded as early as 2009.

Smart business leaders knew this wouldn't last, because you can't run a business for very long by running people into the ground. True, jobs weren't a-plenty and a depressed housing market meant employees weren't going to chase dream jobs. Plus, economic indicators gave no reason to believe things were going to improve any time soon. Still, the employer's risk of losing people who held the business together increased every day that the "new normal" set in. Smart leaders got in front of this.

From early 2009, healthy companies boosted their capital spending.¹ They used their capital in three ways.

The first was defensive. Managers classified as much work activity as "capital improvement" as they could. Doing so meant labor costs could be capitalized for up to 5 years. This let businesses retain people without eroding profitability. This prevented companies from losing employees with systemic knowledge of the business and intimate knowledge of customers.

The second was offensive, investing in core business operations. Companies invested in technology² to lock in those post-layoff productivity gains, and to improve customer self-service offerings since they had fewer employees to service customers. These investments made operations a source of competitiveness by lowering costs, increasing efficiency, and making businesses more responsive to customers. This made these firms better able to compete for market share - essential in a slow-growth world.

The third use was financial restructuring and building reserves. This meant issuing debt, and retiring equity. Debt was cheap, as interest rates hit record lows during the crisis. Debt was also in demand, as market liquidity was making a "flight to quality" and many corporations sported high credit ratings and had large cash balances that could comfortably cover interest payments. Debt-for-equity restructuring lowered the total cost of capital. It also benefited boards and CEOs by concentrating ownership of the company in fewer people's hands.

Smart business leaders responded to the financial crisis not only by protecting operations, but by improving and reforming them, taking advantage of cheap capital during the crisis to pay for it.

But many small businesses, high-risk businesses, and poorly capitalized businesses had neither capital cushions nor creative accounting to protect their operations. All they could do was cut costs and hope for the best. And cut they did. The people who got salary bumps in the boom years from 2006 through 2008 became "high-salary outliers" in 2009. It didn't matter that those were the people at the core of the company's capability and drive. When facing financial ruin, the CFO calls the shots, and the pricey people are the first to go regardless the impact to operations.

These cuts may have staved off bankruptcy, but set the stage for an operating crisis by depleting firms of core operating knowledge and contextual business understanding. Cuts made at the beginning of the crisis left few people - and often no single person - fluent in the details of business operations. Those who remain can mechanically perform different tasks, but don't understand why they do the things they do. The business has continued to run, but it runs on momentum. It doesn't initiate change. It erodes a little bit here and there, as employees exit and clients find the offerings stale and go elsewhere. Costs increase as salaries and stay bonuses are showered on those with the most experience in the mechanics of the business. Pricing power decreases as employees lose the ability to articulate the value of what they provide to their customers. As more time passes, the more acute this crisis becomes: margins get squeezed while the business itself becomes operationally sclerotic.

Just as there are zombie loans (banks keep non-performing loans on their books because they don't want to take the writedown), there are zombie businesses. They transact business and generate revenue. They have years of history and long-standing client relationships. Such a business may look like it can be successful with some investment, but lacking that core operating knowledge, it's a zombie: animated but only semi-sentient.

These firms will only have attracted risk capital late in the post-Lehman investment cycle. Because they haven't been making investments in efficiency or customer service, their first use of fresh capital will be to hire new operational support people in an attempt to get caught up. That's costly and inefficient, and it just adds capacity of people who know how to perform the same mechanical tasks. It won't change the fact that austerity depleted the firm of fundamental operating knowledge. New managers brought in with this investment will struggle to unwind the piled on (and often undocumented) complications of the business, while new people in execution roles will get no further than replay of the mechanical processes for running the business.

Resuscitating these businesses - bringing much needed innovation and structural reform to a firm that has been starved of it for a long time - is a time-consuming and costly proposition. First, nobody has time to spare: they're constantly on fire trying to control operations and contain costs of the fragile machinery of the business. Second, they don't know what to do: because nobody knows the business context very well, there isn't anybody who can competently partner on initiatives to reform the business. Third, middle managers lack the will: the trauma of the cuts and years of thin investment will have rendered decision makers reactive (keep operational flare ups under control) instead of aggressive (reinvent the business and supporting systems). Fourth, those same middle managers can only conceptualize the business as what it has always been; they'll lack the imagination to see what it could be.

Surviving a prolonged downturn is not necessarily the mark of a strong business. As Nassim Taleb pointed out in The Black Swan, a lab rat that survives multiple rounds of experimental treatment (say, exposure to high dosages of radiation) isn't "stronger" than rats that do not. The survivor will be in pretty bad shape for the experience. The heroic story of the tough and resourceful survivor isn't necessarily applicable to the business that survives tough times. The apocryphal story of the zombie is a better fit.

¹ Many businesses reported a significant uptick in capital spending from 2009-2011 compared to 2006-2008.

² Strong corporate IT spending is one reason why the tech sector was counter-cyclical from 2009-2011.

The Return of Financial Engineering - and What it Means for Tech

Soon after the financial crisis began in 2008, companies shifted attention from finance to operations. Finance had fallen out of favour: risk capital dried up, asset prices collapsed and capital sought safe havens like US Treasurys. The crisis also ushered in a period of tepid growth undermined by persistent economic uncertainty. This limited the financial options companies could use to juice returns, so they focused on investing in operations to create efficiencies or fight for market share. In the years following the crisis, the "operations yield" - the return from investing in operations - outstripped the "financial yield" - the return from turning a business into a financial plaything.

Since the start of the crisis, central banks have pumped a lot of money into financial markets, principally by buying up debt issued by governments and financial assets held by banks. This was supposed to spur business activity, particularly lending and investing, by driving down the cost of both debt (lower lending rates) and equity (motivating capital to seek higher returns by pursuing riskier investments).

Whether lending and investing have increased as a result of these policies is debatable. One thing they have done is encourage companies to change their capital structure: low interest rates have made debt cheaper to issue than equity, so companies have been busy selling bonds and buying back their own stock. There are financial benefits to doing this, namely lowering capital costs. It benefits the equity financiers by concentrating ownership of the company in fewer hands. But beyond reducing the hurdle rate for investments by a few basis points - and not very much at that given low interest rates - this doesn't provide any operational benefit.

What's not debatable is that it's brought about a return of financial engineering. CLOs and hybrids are back. Messers Einhorn and Buffet are engineering what amount to ATM withdrawals through preferred share offerings from Apple and Heinz, respectively. The OfficeMax / Office Depot merger is addition through subtraction: projected synergies exceed the combined market cap of the two firms.

When financing yields are higher than operating yields, business operations take a back seat to financial philandering. Consider Dell Computer. Dell's business lines are either in decline (services) or violently competitive (PCs and servers). Does it matter whether Dell is funded with public or private money? Will being a private firm make Michael Dell better able to do anything he cannot do today? It is hard to see how it does. But it does let him play tax arbitrage.

This suggests a bearish environment for investment in operations. The shift to debt in favour of equity, the rise in share buybacks, dividend payouts and M&A suggest that companies have run out of ideas for how to invest in themselves. Cash flow that would otherwise be channeled into the business is betrothed to financiers instead. Debt yields are kept low and roll-overs made easier by stable and consistent cash flows, and equity easier to raise when cash flows from operations are both strong and consistent. This compels executives to set a "steady as she goes" agenda - not an aggressive investment agenda - for business operations.

A reduction in business investment is not particularly good news for tech firms selling hardware, software or services to companies. But it's not all bad news. Rewarding financiers by a starving business for investment makes a company sclerotic. That clears the way for innovators to disrupt and grow quickly. But until those innovators rise up, finance is positioned to stymie - not facilitate - business innovation.

Investing in Software Through Experts, Analysis or Discovery

Whether investing in equities or in software, there are three distinct approaches to how we make an investment decision: based on our intuition or experience, based on our analysis of an opportunity, or based on our ability to rapidly discover and respond to market feedback. Let's look at each in turn.

When we invest based on experience, our decisions are rooted in the expertise we've gained from things we've done before. When based on intuition, our decisions are based on strongly held convictions. An equity investor familiar with retail might recognize demographic changes in specific geographic areas (e.g., migration of families with young children to Florida and Texas) and intuitively invest in firms exposed to those changes (such as commercial construction businesses operating in those areas). In the same way, somebody who has first hand experience can invest in developing a technology solution: the inspiration for Square, Inc. came from a small firm that couldn't close a sale because it couldn't accept credit cards. Although expert investing will likely involve a little bit of analysis, for the most part the investor relies on gut. Because we invest primarily on the courage of our convictions, capital controls on intuitive investments tend not to be very strict. In absolute terms, the capital commitment is generally small, although in relative terms the committed capital may be quite large especially if it is a private placement. As a result, the capital tends to be impatient: trust in an expert lasts only so long; investors will get cold feet quickly if there aren't quick results.

We can invest based on research and analysis. Value investors in equities study company fundamentals looking for firms with share prices that undervalue the assets or the durability of cash flows. In the same way, we can look for value gaps in business operations or market opportunities and identify ways that technology can deliver value to fill those voids. The foundation of the analysis are things such as value-stream mapping, or competitive analyses of solutions developed by sector and non-sector peers. From this, we can produce a financial model and, ultimately, a business case. We need expertise to develop a solution, but by and large we make our investment decision based on the strength of our analysis. In absolute terms, the amount of committed capital can be quite large. But, having rationalized our way to making an investment, the capital controls tend to be strict, and the capital tends to be patient.

Finally, we can invest based on our ability to discover and adjust based on market or user feedback. Traders move in and out of positions, adjusting with changes in the market and hedging based on how the market might change. Over a long period of time, the trader hopes to end up with large total returns even if any given position is held for only a short period of time. We can do something similar with software, using approaches like Continuous Delivery and Lean Startup. In this approach, we aren't just continuously releasing, but rapidly and aggressively acquiring and interpreting feedback on what we've released. We can also use things like A/B testing to hedge investments in specific features. When we invest this way, we do so based not so much on our expertise or analysis, but based on our willingness and ability to explore for opportunities. Capital controls are strict because we have to explain what features we're spending money on and how we're protecting against downside risk of making a mistake. The capital backing a voyage of discovery will be impatient, wanting frequent assurances of positive feedback and results. But at any given time, the amount of committed capital is small, because investors continually evaluate whether to make further investment in the pursuit.

Each of these approaches makes it easy to answer "why" we are making a particular investment. Why should we part with cash for this particular feature? Go ask the expert, or see how it fits in the business case, or go get user feedback on it. "Why" should drive every decision and action made in pursuit of an investment. Without the "why" there is no context for the "what". In its absence, the "what" will suffer.

No approach is universally superior to another. The approach we take has to play to our strengths and capabilities. Either we have people with expertise or we don't. Either we have people with analytic minds and access to data or we don't. Either we have the ability to rapidly deliver and interpret feedback or we don't. The approach we take must also be suitable to the nature of the investment we're making. A voyage of discovery is well suited for developing a product for a new market, but not for an upgrade to a core transactional system. The business case for investing in a customer self-service solution is going to be much more compelling than a business case for developing a product for an emerging market segment.

Just because we take one of these approaches is no guarantee of success. Not all investments are going to pay off: our experts may turn out to have esoteric tastes that aren't appealing to a mass audience. Our thoroughly researched market analysis might very well miss the market entirely. We might deliver lots of features but not find anybody compelled to use them.

Worse still, each of these approaches can be little more than a veneer of competency to unprofessional investing. A hired-in expert may be a charlatan. Many a manager has commissioned a model that inflates benefits to flatter an investment - only for those benefits to never be realized. Just because we can get continuous feedback from users does not mean that we can correctly interpret what that feedback really means.

Most of the time, of course, we take a hybrid approach to how we invest. We supplement expertise with a business case, or we charter an investment with a business case but use Continuous Delivery to get feedback. However we go about it, we need to get the essential elements of the approach right if we're to have any chance of success. Otherwise, we're just unprofessional investors: investing without experience, thoughtful analysis or an ability to respond quickly is reckless use of capital.

Entirely too much software investing fits this bill.

Sector Seven Is Clear

Many years ago, there was a television ad that showed an intruder being chased through a building by two security guards. The guards chase him from room to room, and ultimately down a long hallway. At the mid-point of the hallway, there's a line painted on the floor and wall. On one side of the line is a large number 7, on the other is the number 8. The intruder runs down the hallway, over the line. The two security guards come to a sudden stop right at the line. They watch as the intruder continues to run down the hallway into some other part of the building. After a pause, one of the security guards grabs his walkie-talkie and announces: "sector seven is clear". The intruder is still in the building, but the security guards no longer consider him to be their responsibility.

Every now and again I reference this ad in a meeting or presentation, in the context of Industrial IT. I've been reminded of it again recently.

Industrial IT encourages specialization: It is easier for HR to hire, staff, train and procurement to contract for people in specialist roles. And specialization is comfortable for a lot of people. Managers - particularly managers who have a poor grip on the work being done - like specialization because it is easier to assign and track tasks done by specialists. People in execution roles take comfort in specialization. It's easy to become proficient in a narrow field, such as a specific database or programming language. Given the slow rate of change of any given technology, you don't have to work too hard to remain acceptably proficient at what you do. You only face a threat of obsolescence. A commercial technology with sufficient market share and investment mitigates that risk to the individual.

Specialization means the most critical information - systemic understanding of how a solution functions and behaves from end-to-end - will be concentrated in a few people's heads. This knowledge asymmetry means those few people will be overwhelmed with demands on their time, creating a bottleneck while others on the team are idle. There will be a lot of hand-offs, which increases the risk of rework through misunderstanding. Because no single specialist can see a solution through to completion, nobody will have ownership for the problem. At least, not beyond making sure Sector 7 is clear.

I've written about it many times before, but Industrial IT prioritizes scale over results, specialists over professionals, predictability over innovation, and technology over value. Industrial IT is large but fragile: it struggles to get anything done, there aren't enough heroes to go around, its delivery operations are opaque, and it produces high-maintenance assets.

Even when there is executive commitment to change, it takes a long time and concentrated effort to change the industrial mind-set at a grass roots level.

We have to reframe problems above the task level. Everything we do should be framed as a meaningful business result or outcome, complete with acceptance criteria against which we can verify success in the business context. For example, the problem isn't to fix the payload of a specific webservice, the problem is to allow multiple systems to integrate with each other so that sales transactions can be exchanged. Agile Stories are particularly helpful for defining actions this way, whether new feature or defect. Stories make it possible for each person to explain why something is important, why something is valuable, why they are working on it. Back to our example, I'm fixing this webservice because until I do, there won't be order flow from a principal commercial partner. Stories are also helpful as they let us measure the things we do in terms of results, and not effort.

But there's more to this than process. Each person must feel personal ownership for the success of their actions. The job isn't to code to a specification, or to test against a test case. The job is to create a solution that enables a business outcome. Each person must ask questions about the completeness of the solution, and be motivated to verify them in the most complete manner possible.

Which makes the point that this is, fundamentally, a people challenge. We're asking people to change how they understand the problems they're solving and what "done" means. We're asking them to change their behaviours in how they investigate, test and verify what they do. More broadly, we're asking them to build a contextual understanding for the work they do, and more importantly why they are doing it. And we are asking them to take responsibility for the outcome: I will know this is complete when ...

Do not under-estimate the challenge this represents. The transition from industrial to professional is amorphous. There are false positives: people who sign up for this too quickly don't understand what's going to be required of them. It isn't long before the never ending chorus of "I don't" starts: I don't know how to do something, I don't have that information, I don't know how to find that out. And we can't take anything for granted. We must constantly challenge people's contextual understanding: can they explain, in a business context, why they are working on something, who it benefits, why it is important.

Not everybody will make this transition. For some, because this isn't their calling: not all assembly line workers can become craftsmen. Others will self-select out, preferring the comforts afforded by a specialist's cocoon.

All of these things - changes in process, practice, behaviours and people - require a tremendous amount of intestinal fortitude. The would-be change agent must be prepared for a frustratingly slow rate of change, and to invest copious amounts of time into people to help them develop new context and new muscle memories. On top of it, leaders are in short supply and mentors are even scarcer in Industrial IT shops. Legacy assets and systems (and their legacy of patchwork integration, bandaged maintenance and situational knowledge) will slow the rate at which you can make new hires productive.

The benefits of changing from industrial to professional are obvious. While the destination is attractive, the journey is not - and be under no illusions that it is. But who we work with, how we work, and what we get done in a professional IT business make it worth doing.

Engaging Auxiliary Forces for Strategic Software Solutions (Part II)

I wrote previously that "if one is to compete, one has no choice but to rely on auxiliaries or mercenaries" when you have to respond quickly to a competitive threat. Before looking further at engaging auxiliaries, it's worth considering the "if one is to compete" statement. As unattractive as it may sound, a firm can opt out of competition. Sometimes, the most compelling business option is to run the business for cash. How have late moving legacy firms fared in industries that have undergone strategic shift? E.g., will RIM and Nokia destroy more value than they will create by being late followers of Apple and Android?

Opting out is strategically unattractive. (In fact, it's downright Machiavellian.) But it should never be ruled out. And there isn't much to be said for "putting up the good fight" if you're ill prepared to bring it. It's simply a very public form of corporate seppuku that vapourizes equity and destroys careers.

However, if a firm chooses to compete, and has neither the capability nor the luxury of time to create a capability, it has no choice but to rent that capability by entering into an agreement with an auxiliary or mercenary force. As I pointed out in Part I, this relationship favours the seller.

How can the buyer mitigate the risks? By knowing when and how he or she wants to exit the relationship.

Buyers of auxiliary forces are tempted by what appears to be the best of both worlds: contracting allows the buyer to get an asset developed with minimal effort on behalf of the buyer. But the economics work against the buyer as time passes. The longer a supplier relationship lasts, the greater the dependency of the buyer on the seller, the stronger the seller's negotiating position over time. And development doesn't end with a single act of delivery: there is considerable activity required at the margins, things ranging from data migration to usage analytics. These costs are the buyer's to underwrite. Suppliers are thus able to expand their range of services and derive more cash from the relationship. This increases the costs to the buyer, which erodes the viability of the sourcing strategy.

Anticipating the terms and conditions of the exit are subsequently of prime importance to the buyer.

If the buyer has no alternative but to engage auxiliaries - if, for example, the buyer is purely a marketing company taking a flyer on a technology investment - it faces a long-term relationship with a supplier. The buyer's best bet is to engage auxiliaries as long term equity holders with minority rights in the relationship. This aligns the seller with the buyer and reduces (but most likely will not eliminate) cash bled from the buyer to the seller. By contrast, if the buyer intends to derive significant benefit from the intangible (technology) assets and, by extension, leverage its capability in technology, the buyer must engage auxiliaries for a short period on a fixed income basis, all the while preparing to transition away from the seller to "one's own" forces.

Supplier relationships are economically sticky. Switching from one supplier to another is generally a poor exit strategy. Equity relationships are difficult to unwind amiably (that is, without attorneys). Fixed income relationships come at the cost of the buyer, who will be bled to death pumping cash into multiple suppliers who will not underwrite the cost of a transition.

Thus the onus is on the buyer to make quick but considerate decisions when engaging an auxiliary. In the case of an equity relationship, the buyer must convince the seller to accept a minority equity position, and determine the viability of the investment quickly (reward or wind it up) so that minority position doesn't languish. In the case of a fixed-income relationship, the buyer needs to be able to exit the supplier relationship for a team of "one's own" forces, relegating the supplier to a minimal role at a transitional moment.

But there are often circumstances that muddle a buyer's judgment. With a gullible or desperate supplier, a buyer can prolong a supplier relationship in the hope that an investment will prove viable. By playing labour arbitrage, a buyer can defer the difficult task of building one's own forces. But whether equity or fixed income, the buyer has to remember that the economics of an auxiliary relationship are in decline for the buyer the minute the ink is dry on a contract. When engaging auxiliaries, the buyer must make quick investment decisions and take quick action. The longer a supplier relationship lasts, the more the power in the relationship shifts to the seller.

No matter the nature of the relationship - equity or fixed income - the buyer must not enter into an "arms length" relationship with the seller. The buyer must be engaged with the seller, constantly monitoring and auditing the deliverables over the life of the relationship. A buyer must be capable of competently auditing the work being done by the supplier before entering into a supplier relationship. If he can't, he is not a qualified buyer and must be regarded as a principal source of risk to the capital being invested. Investors in strategic software are wise to challenge the capability of the buyer as well as the seller.

Entering into a supplier relationship buys time for the buyer to build his or her own forces. These forces must be of equivalent or superior capability to those of the supplier. It might not be of equal size - an indigenous team may be smaller in size than a rented team - but it must be of equal capability. An own force inferior to auxiliaries will be manipulated by the auxiliary to the disadvantage of the buyer. With a team of equal capability, the buyer can quickly eclipse the influence of the supplier in the fulfillment chain. A buyer can preserve credibility with a slower velocity from an indigenous team, but not lower quality.

Auxiliaries can be useful to buyers to compensate for a short-term vulnerability, but only if the buyer has an exit strategy. Sellers, not buyers, benefit from long-term supplier relationships for strategic solutions. Buyers must make quick decisions about investment viability, and take competent actions in building the forces necessary to sustain them.

Engaging Auxiliary Forces for Strategic Software Solutions (Part I)

At one point or another, most firms will engage "auxiliary forces" - contract with firms for development teams - to develop software for them. If Machiavelli were sourcing software projects, he wouldn't approve.

"These arms [auxiliaries] may be useful and good in themselves, but for him who calls them in they are always disadvantageous; for losing, one is undone, and winning, one is their captive."

Niccolo Machiavelli, The Prince, Chapter XIII

Machiavelli counsels the prince against the use of auxiliary forces in battle. An auxiliary is not the same thing as a mercenary. A mercenary is a hired gun, loyal only to him or her self. A prince engages an auxiliary when he arranges for another principality to supply forces. The members of an auxiliary force will be loyal to their leader. The risk to the warring prince is that the kingdom with which he has entered into partnership will change terms during or after the battle.

Thus Machiavelli favours the use of one's own forces for important work. It is easier for the prince to align his force's interests with his own interests, and subsequently count on their loyalty and service because everybody stands to gain the same things for the same risks. In the heat of battle, mercenaries are likely to flee, while an auxiliary is likely to seek negotiations that minimize losses. After the battle, the auxiliary is likely to seek negotiations with the prince who invited them into the campaign. (More about this, below.)

Of course, business isn't warfare. But there are some business lessons we can learn just the same.

In software development, auxiliary forces have their place, particularly for utility services sourced for utility solutions. Consider an ERP implementation, complete with code customization. There is a large, diversified sell-side labor market, many alternative sources of that labor, pricing is more formulaic, risks and success criteria are known to some degree of specificity, and the work is not deemed strategically critical (not when everybody has an ERP). This commoditizes the sell-side offering, which favours the buyer.

The sell side has power in utility work only in times of acute labour shortage, which gives the sell side pricing power. But tight supply doesn't make a commodity into a strategic resource; it simply makes it a more expensive commodity. Like any commodity, shortages tend not to last very long: buyers will be priced out of the market (curtailing demand), while suppliers will find ways to create new labour capacity such as training new people (increasing supply). And sellers of services deal in a perishable commodity: time. Only in periods of very high demand will sellers press forward a negotiating advantage borne of tight supply. A billing day lost forever is strong incentive to a seller to do a deal. Whether a buyer engages for a utility service by contracting mercenaries (hired guns under the direction of the buyer) or by hiring an auxiliary (a partnership for delivery of the solution as a whole), the buyer has the upper hand when buying utility services. Or, perhaps, it is more accurate to say that the advantage is the buyer's to lose.

On consideration, Machiavelli wouldn't mind auxiliary forces when they're deployed for utility purposes. It is foolish to distract your best people with non-strategic pursuits.

But he would not approve the use of auxiliaries to achieve strategic solutions. The buyer of a strategic, unique, competitively differentiated solution must put more scrutiny on suppliers, navigate custom pricing, underwrite general and ambiguous risks, and has less certainty of the outcome and the business impact. The buyer will also be weighing intangible advantages in potential sellers, such as business domain or advanced technology knowledge. This makes for a small, opaque and poorly diversified market for any given strategic investment. This favors the seller.

By engaging auxiliary forces, the buyer can get a head start on a strategic solution. But then, it doesn't matter how you start, but how you finish.

A territory conquered by an auxiliary leaves the auxiliary with a strong negotiating position: as the saying goes, possession is nine-tenths of the law. The auxiliary force, in possession of the conquered land, can set terms for turning it over to the prince. This can also be true for strategic software investments. Strategic software doesn't end with a single act of delivery. It will need further investment and development. Their knowledge of the created software - the business domain, the code, the deployment scripts, and so forth - give the auxiliary force a familiarity of "the terrain" that the buyer simply doesn't have. This gives the auxiliary firm an outsized position of power to renegotiate terms with the buyer (e.g., usurious terms for ongoing development and maintenance), or to negotiate with firms who are competitors to the buyer to create a similar solution.

But what about intellectual property and contract laws? Don't they protect the buyer? When the focus shifts to contracts, it means both parties have brought in the lawyers. Lawyers are simply another type of armed force, one that can be both highly destructive and very costly. Lawyering-up simply escalates an arms race between the buyer and seller (or in Machiavelli's parlance, the prince and the auxiliary).

It's no surprise that Machiavelli concluded that auxiliary forces were not worth the risk in strategic undertakings. Anything of strategic importance to the prince must ultimately be done by the prince and his own forces.

This is an easy rule to write, but not an easy rule to live. Building a force (or in software terms, a team) capable of creating a strategic software solution requires world-class knowledge, experience, and facilities. It requires trained personnel and the ability to continue training. It requires the ability to recognize greatness and potential, and the ability to hire both. It requires innovation in tools, techniques and results.

It was Peter the Great's aspiration for Russia to have an ocean going navy. But he didn't start by emptying his treasury on local contractors to build his boats and hire people off the streets to serve as his officers. He studied English ship building and hired German Naval officers to train his officers and enlisted ranks. He invested in developing a capability. He played the long game to allow Russia to become a capable naval power, and not simply a nation with a floating armed force. When time permits, when one has the luxury of playing the long game of disruption, one can own, rather than rent, capability.

Time does not always permit the long game, especially in businesses whose models are being stampeded by software. If the competition has moved first, if one has to respond swiftly, one has no choice but to rely on auxiliaries or mercenaries if one is to continue to compete.

How best, then, for the buyer to engage an auxiliary or mercenary force, given Machiavelli's counsel? We'll look at the terms for this kind of an engagement in Part II.