The Agile Manager
Tuesday, February 09, 2010
  Mercenaries, Auxiliaries, and how we Staff IT
I've spent a lot of time reflecting on Brad Cross' blog post on Wages. It got me thinking specifically about Machiavelli's book, The Prince.

Niccolò Machiavelli made some important observations regarding the conduct of a prince, making specific recommendations for what a prince must do to maintain the integrity of a state. Among other things, he wrote about the composition of forces necessary to both defend and advance the interests of a principality.

While military metaphors are in many ways inappropriate for business (business situations are nowhere near as serious as armed conflict), they are among the oldest of human endeavours and provide a rich history of organization and social dynamic. Just as there have been business books that derive lessons from such diverse personalities as Sun Tzu and Attila the Hun, we can similarly draw some interesting lessons from Signore Machiavelli.

Machiavelli observed there are four compositions of troops:
  1. One's own forces (i.e., drawn from the population of the principality)
  2. Mercenaries
  3. Auxiliaries
  4. Mixed from any combination of the above.
This provides an apt metaphor that describes a how technology “campaigns” are commonly staffed.

On the buy side, most businesses aspire to staff with “one’s own forces.” This provides a perception of control, specifically with regard to compensation, promotion, and even daily work activity. Many firms believe they have "one's own" because they staff with direct hires. But there's more to having “one’s own forces” than putting people on the payroll. The interests of the employees (or in military terms, the conscripts) must be fully aligned with the unit. A unit (e.g., a project team or an army) is victorious and with it the sponsoring organization (business or state) and the individual, or the unit is not victorious and with it both sponsoring organization and individual lose out.

If an individual is pursuing a path of personal success that is not aligned with the success of their unit, they are not, from the perspective of the principality, “one’s own forces.” In fact, they fall into one of the next two categories, that of mercenary or auxiliary. In technology, we see this all the time. For example, freshly minted university graduates are typically looking first to acquire skill and experience in a specific technology, expecting to change employer many times in the pursuit of that skill, as opposed to being motivated to fulfill a business mission enabled by the project they’re working on.

By the same token, most businesses engage mercenaries. Mercenaries are often independent contractors, loyal to no leader, and loyal only to themselves. While there can be exceptions, according to Machiavelli they're not good troops in the end because they are not dependable in battle. Specifically, they're the first to desert since they have little on the line. Also, their interests are not aligned once the battle is over. According to Machiavelli, the risk here is "dastardy," or maliciousness. Mercenaries draw income from battle, not wealth from victory. It is in their interest to seek - or to create - conflict. And this is common in the IT industry. How often have we seen an important business initiative beholden to a technology component that is laden with technical debt, the delivery of which is in the hands of mercenaries who are motivated neither by the business impact of the solution nor its reliability and affordability of maintenance? By contrast, how often do we see people develop career "annuities" for themselves, drawing an income for an extended period of time as caretakers of a business critical application that is heavily laden in situational complexity?

Auxiliaries, according to Machiavelli, are particularly dangerous. In military terms, the independent auxiliary unit seeks its own opportunities precisely because it is in a position to create attractive circumstances. In business, if a host company gives a contract firm autonomous leadership on an initiative, the host firm will find a significant portion of its forces are loyal to another. According to Machiavelli, the risk with auxiliaries is "valour". Auxiliaries are motivated by the opportunity to drive wealth from adventurism. If a buy side firm contracts with a sell side firm for an independently-functioning team, it is not out of the question that under competent leadership that sell-side firm will look to strike its own bargain with the market. It may develop expertise, capability, intellectual property or domain knowledge that it can monetize elsewhere. Alternatively, it may hold a customer firm hostage for better terms for some of these things.

The last category of forces - mixed - is in fact the most common in technology. Most firms don’t have a homogenous staffing model. They rely on contractors and outside firms for significant portions of their staff. Also, as mentioned above, there will be inconsistencies in the motivations of their FTEs. “One’s own” forces must be motivated by the wealth of the business (however “wealth” in the situation is defined) as opposed to personal income, to have it at risk, and to have a direct influence on the outcome. Very often, that isn’t the case among badged employees, which means a fair number will be mercenaries. They'll be motivated by individual interests that are not fully aligned, and may even come at the cost of their paymasters. There are also cases where there are auxiliary units lurking about in a business, especially technology: people who have worked together for many years for several different organizations, who form a shadow unit and eventually move to strike their own bargain.

People on the buy side and sell side of technology generally don’t recognize these distinctions. Generally speaking, people on the buy side (a) don’t recognize that their staff are mixed and not "one's own" especially in the absence of contractors; (b) don’t understand the consequences of their staffing mix (e.g., what does it mean from a retention perspective that people aren't first-and-foremost die-hard employees committed to the success of the business imperative?); (c) fail to understand the nuances of how to deal with each group specifically (e.g., in project crises, we tend to see a lot of rah-rah managerial fluff spewed forth from buy-side leadership to sell-side people who are completely disconnected from the business situation at hand); and (d) have no idea the risks and opportunities of each group.

By the same token, the sell side doesn't appropriately approach the market. Sell-side firms that aspire to be "auxiliary forces" talk as if they can be "one's own" (the ubiquitous word "partners” is usually invoked), yet they usually sell themselves as mercenaries to the classic formula of people x time x rate. In this effort based formula the risk is borne by the buyer, but the impact of mercenary pricing cuts both ways. Sell-side firms very often end up in mercenary situations yet fail to price and structure it to reflect the “income” that it really is, mistakenly believing they're developing a vehicle for “wealth” (i.e., a sustainable business opportunity.) Finally, sell-side firms typically fail to understand the full terms and conditions required of both parties for the supplier-vendor relationship to be fully aligned to perform as “one’s own” for the business mission at hand. Very often, they export the problems they have as a sell side business (such as hitting revenue targets or maintaining margin) into the value proposition offered by the sell side. It comes as no surprise that in the end, they default into a cost or "mercenary" engagement model.

The nature of forces – and the consequences – haven’t changed all that much since the dawn of time. The lessons of Machiavelli for the state apply to both technology buyer and seller alike.

The buy side sources staff from a market overwhelmed with sell-side firms offering technology specialists, vertical market expertise and bodies in bulk. The buy side needs to have the right expectation for the right type of firm. The large-scale staff-aug firm has some of the characteristics of an auxiliary, but when it comes right down to it aren't they really just a large mercenary outfit? And does a firm with deep vertical "practices" have aspirations to monetize (possibly to our disadvantage) the expertise derived from the solution we're engaging them for? Alternatively, are we trying to engage a genuine partner firm in a mercenary model? For that matter, do we do things on the buy side to create the circumstances that allow us to engage "one's own" forces? Perhaps most importantly, do we recognize the fundamental characteristics that make a person or a firm suitable for that kind of engagement?

The buy side also needs to consider the project mission. Perhaps the organizational politics have compelled us to go in pursuit of some boondoggle but we know that sooner or later, people will come to their senses and cancel the project. Or perhaps we have a situation where we need to prop up a project deliverable only until we complete negotiations for an alternative solution. In such cases, the buy side firm would be foolish to allocate "one's own" forces, and would be better off to engage mercenaries or auxiliaries.

Curiously enough, a lot of business press has covered this from the perspective of the buy side. It’s worth reflecting on this in greater detail from the perspective of the sell side, or the supplier of “forces.” That will allow sell-side firms to recognize the right characteristics, opportunities, and circumstances for deploying capability across their customer portfolio.

Firms on the buy and sell sides – from established to start-up – experience this phenomenon. Many buy side firms wish to engage, and many sell side firms wish to be engaged, as "one's own." To do that requires trust, which doesn't come easy and must be earned every day. It also requires some form of a shared opportunity model, and very, very few examples of this exist today. This isn’t to say that true partnerships can’t be forged, but instances of this are the exceptions and not the rule in technology. Auxiliary and mercenary buying patterns – transacting for specialized knowledge or bulk capacity (people x time x rate) – are the rule in IT.

A fully aligned partnership - that is, sourcing for "one's own" in Machiavelli's model - is possible only with like minded people who form deep relationships built on a firm foundation of trust and fundamentally aligned interests in achieving a business goal. Those like minded people on whom you can build that trust relationship are hard to find, and they're few and far between, but seek them out and you'll build mutually sustainable businesses.

Labels: , ,

 




<< Home
Agile approaches to IT leadership, governance and management

About Me
    Name:
      Ross Pettit
    Location:
      Worldwide
 
Recent Work
  • New York & Philadelphia, October 2009: Keynote at Agile East: Budgeting and the Financial Implications of Agile
  • Webinar, October 2009: The Agile PMO: Real Time Governance (with David Leigh-Fellows)
  • Chicago, October 2009: Panel Discussion: Budgeting and the Financial Implications of Agile
  • Calgary, Toronto, & San Francisco: September 2009: The Agile PMO: Real Time Governance (with Jane Robarts and David Leigh-Fellows)
  • alphaITjournal, 13 May 2009: Governing IT Restructure
  • Webinar, April 2009: Restructuring IT
  • The Cerebral Dad, November 2009: Missing a First
  • Previous Posts
  • Sustainability versus Efficiency
  • Is Google to IBM as Apple is to Apple?
  • Restructuring IT: Anticipatory Responsiveness
  • Restructuring IT: Organizing for Results
  • Join Your Peers at an Agile Governance or Budgetin...
  • Restructuring IT: The Detroitification of IT
  • Restructuring IT: "Too Big to Fail" Doesn't Equal ...
  • Restructuring IT: A Different Look at the Business...
  • The Case for Restructuring IT
  • Are You Ready to Restructure?
  • Selected Articles and Publications
  • Measuring Measures, 30 December 2009: Build Brands with Luck and Persistence (with Bradford Cross)
  • alphaITjournal, 24 February 2009: Restructuring IT: Changing Fundamentals In-Flight
  • alphaITjournal, 21 January 2009: Come the Hour, Come the Leaders
  • alphaITjournal, 19 November 2008: States of Governance
  • alphaITjournal, 22 October 2008: Volatility and Risk of IT Projects
  • Webinar, 19 September 2008: An Agile Readiness Assessment
  • alphaITjournal, 17 September 2008: Is Your Project Team "Investement Grade?"
  • alphaITjournal, 25 July 2008: Are You Marking IT Projects to Market, or Meltdown?
  • Press release announcing the launch of alphaITjournal.com, July 2008
  • ThoughtWorks Studios Blog, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Agile Journal, April 2008: Quality Assurance: Value Added Partner, not Blunt Instrument
  • The Wall Street Journal, Letter to the Editor, 25 March 2008: IT Leaders Must Change, Not the Business Side
  • Agile Journal, February 2008: Management Driven Metrics Versus Metrics Driven Management
  • Agile Journal, January 2008: The Dichotomy of Change
  • Agile Journal, December 2007: Building High Performance Capability
  • Agile Journal, November 2007: Mythical Agile Shortcuts
  • Agile Journal, June 2007: The Agile Organization
  • Agile Journal, January 2007: Business Value Applied: Aligning the Day to Day with Business Imperative
  • Agile Journal, December 2006: An Agile Approach to IT Governance
  • Agile Journal, October 2006: So You've Decided to 'Go Agile' - A Pragmatic Approach to Onboarding Agile Project Management
  • Agile Journal, June 2006: An 'Agile Maturity Model?'
  • Agile Journal, March 2006: Agile Processes: Making Metrics Simple
  • A complete listing of articles published on alphaITGovernance on alphaITjournal.com
  • A complete listing of articles published on The Agile Manager on Agile Journal
  • Translator (Spanish to English), 1999. Homestyle Recipes for Financial Management Candioti, Eduardo. 5th Edition (Bilingual). Universidad Adventista del Plata Press.
  • Presentations
  • Atlanta, November 2009: Agile Southeast: Budgeting and the Financial Implications of Agile
  • New York & Philadelphia, October 2009: Keynote at Agile East: Budgeting and the Financial Implications of Agile
  • Webinar, October 2009: The Agile PMO: Real Time Governance (with David Leigh-Fellows)
  • San Francisco, October 2009: The Agile PMO: Real Time Governance presented to the Project Portfolio Managers Professional Association
  • Chicago, October 2009: Panel Discussion: Budgeting and the Financial Implications of Agile
  • Calgary, Toronto & San Francisco, September 2009: The Agile PMO: Real Time Governance (with Jane Robarts and David Leigh-Fellows)
  • Webinar, April 2009: Restructuring IT
  • Webinar, 5 November 2008: The Agile PMO: Real Time Metrics
  • ThoughtWorks CIO Update Video, June 2008: Taking Agile Maturity to the Next Step
  • Webinar, June 2008: Agile Made Us Better, but We Signed Up for Great"
  • Webinar, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Zürich, March 2007: Swiss Testing Day 2007 - A Pattern for Continuous Testing in Dynamic Domains
  • Munich, January 2007: OOP 2007 - Forge behind the Firewall
  • San Francisco, December 2006: SDForum - The Future of Open Source Communities: The Impact of Exchanges, Forges and Marketplaces
  • Sydney & Melbourne, November 2006: ThoughtWorks Australia - Quarterly Technical Briefing
  • Toronto, October 2006: e-Financial World Expo - Trends in Financial Services Application Development
  • Webcast, July 2006: Agile Journal - Enabling Global Business Success
  • Blogroll and Links
  • Mike Ward
  • Richard Durnall
  • Paul Hammant
  • Paul Julius
  • Muness Alrubaie
  • Adrian Wible
  • Mike Roberts
  • Miško Hevery
  • Bradford Cross
  • Zoonabar
  • Joe Z
  • Sean Doran
  • Shaun Jayaraj
  • Carl August Simon
  • Tom Looy
  • Archives
    July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 /


    Content © Ross Pettit 2006-2008

    Powered by Blogger