The Agile Manager
Saturday, January 23, 2010
  Sustainability versus Efficiency

My friend Bradford Cross posted an interesting blog on wages last week. It’s a great piece, particularly his comments on Henry Ford's approach to business profitability.

To a great extent, the Ford model Brad refers to is dependent on the combination of volume and productivity. That aspect of the model came to a screeching halt for Ford in the 1920s when the Model T simply passed its "sell by" date. Once the product outlived its market, sales volume dropped. They not only discontinued production in response to growing inventories, they didn’t have their next product, the Model A, out of the design phase. They were forced to shut down the line for months. That put quite a dent in accumulated profitability. They also lost their lead in market share.

The focus on volume and productivity drives businesses to aggressively remove cost and increase productivity from repeatable processes to maximize profitability. In so doing, they're not focused on sustainability, they're focused on efficiency.

Sustainability requires constant change. We have to constantly think about the surrounding business conditions: labor patterns, competitive threats, customer needs and so forth. Sustainability requires us to be primarily concerned with where the business is going to be tomorrow. Efficiency requires everything to stay the same. We luxuriate in the simplicity of holding everything else constant when we focus solely on efficiency. When we pursue efficiency, we're focused on where the business is right now.

In the extreme, we optimize relative to the circumstances of this moment in the hope - the hope - that time will stand still long enough for us to draw an income, have 2-point-something kids, take a decent vacation every year, and accumulate sufficient wealth to retire.

Hope may be audacious, but it's a lousy strategy.

In efficiency-centric businesses, it’s not uncommon to find people doing substantially the same things that people were doing 10 years earlier. Because the definition of work is consistent, it’s repeatable, and that makes everybody's job that much simpler. That's true for everybody in the business: people on the line do the same tasks, people in HR recruit for the same positions, people in finance forecast costs in the same business model, and so forth. When things don't change all that much - markets, supply chains, etc. – a business can make a lot of money, and individual wage earners draw a steady income. But in an age when things change a lot, you can't make a lot of money this way for very long. A business optimized relative to a set of circumstances that are artificially held constant is a business in a bubble. Production of any sort can't operate in a bubble. At least, it can't operate in one for long. The longer it does, the bigger the mess when the bubble bursts.1

Brad mentions that Ford's model was more complete than volume and productivity. There's another dimension that, if executed, makes a business sustainable and less prone to seismic interruption: constant innovation in response to external factors. With that must also come invention, which is of course not the same as innovation. This is also not the same as internally-driven innovation. To wit: while shaving a few seconds off the time it takes to tighten a bolt might make bolt-tightening more efficient, it's useless if the market has switched to rivets in place of bolts.

If we aggressively evolve both what we make and how we make it, nobody in production will be doing what people were doing 10 years ago, because those jobs didn't exist 10 years ago. They won't exist 10 years from now, either. In fact, we don’t want entire categories of jobs that exist today to exist a decade from now. This means we have to be less focused on the known (what we’re doing) and more focused on the unknown (what should we be doing?) This makes work a lot harder.

Well, as it turns out, building a sustainable business is hard work.

In innovation-centric firms, production isn't in a bubble. In fact, it's very much integrated with its surroundings. That's where Brad's reference to “worker skill” comes into play. In technology, it’s more than just a question of skills: it’s a question of both capability and the passion to acquire more knowledge.

This may seem to be blatantly obvious: of course those are the workers we want. How hard can it be to hire them? It’s just a recruiting problem, right? Brad specifically makes the point that there’s a (wildly mistaken) school of thought that assumes we can get the best people by spraying a lot of money around.

If only it were so simple, as Brad points out. It's very difficult to succeed at this, not only because it requires a change in recruiting behaviours, but because it means significantly disrupting an internal business process. That's harder than you might think: the efficiency-centric mindset is firmly entrenched in business, government, and the universities that educate the management that run them both.

Efficiency-centric firms are process heavy. The people in these firms - badged, independent contractor and supplier alike - are very heavily invested in that firm's processes. Subsequently they resist change to the processes and practices that they have worked so hard at mastering and making “efficient.” This creates organizational headwinds so resistant to change they can bend solid steel. Any "change initiative" that isn’t blown away by these headwinds is corrupted by it. So, the boss says knowledge is power, and he's told us we’ve got to have the most knowledgeable people in the business? No problem: we’ll show how knowledge-hungry our people are. HR will set up some computer-based training and tie a portion of management bonuses to the number of training hours their people “volunteer” for. Managers will then measure their supervisors on training hours their people receive. Supervisors will set a quota for laborers. Laborers will fill out the necessary form to show they’ve hit their training quota, and circulate answer keys if there’s a test at the end so that nobody fails to meet their quota. The efficiency-centric system returns to balance with no net impact: laborers aren’t inconvenienced, management receives its bonus, and the organization can now measure how much they "value knowledge." Everybody plays, everybody... well, it's complicated. Those who lead the initiative "win" because they can report that a measured improvement took place on their watch. Those who sponsored the initiative are "reaffirmed" because the firm can now prove they have knowledge-hungry people. The rest don't necessarily win, but they certainly "don't lose." And isn't that the point these days, to make sure everybody is a winner?

We see this pattern repeated with all kinds of well-intended initiatives, whether it be a mission for zero defects or a drive to be Agile. People will do everything they can to sustain that which they have already mastered, even to a point - misguidedly or maliciously - of giving the appearance of innovating and changing. Efficiency-centric organizations have stationary inertia that is extremely resilient to internally-initiated change. Only when an external event trumps every other priority - and most often it has to be a seismic event at that, such as the complete evaporation of revenue - will a bubble burst.

This kind of industrial thinking has made its way into IT. We assume our external environment (labor market changes, technology changes and so forth) are static, so we stand up a big up-front design, put together a deterministic project plan, and staff at large scale to deliver. We also see it more subtly when people look to code "annuities" for themselves: systems that are business-critical that they can caretake for many years. This creates an expectation of job security and therefore recurring income. This isn’t just a behavior of employees or contractors looking for stable employment: there are consulting businesses built around this model.

Going back to Brad's blog post, this creates a wage discrepancy and with it, a bubble. People who accept the annuity make the erroneous assumption that the rising tide of inflation will sustain their income levels. It’s actually just the opposite: the minute somebody is working in one of those annuities, their skills are deflating because they're not learning and accumulating new knowledge. So is the asset value of the thing they're caretaking. The people who do this misread the market (e.g., assume an outsized value of the asset to the host firm) and subsequently have a misunderstanding of their wage sustainability. The resultant wage bubble lasts until the "market" catches up: either the host firm takes costs out of maintenance (e.g., by labor replacement) or retires the asset. The person who was earning what amounted to an outsized income by being in this bubble faces that same seizmic correction as Ford did in the 1920s if they're not prepared with their own "Model A" of what they're going to do next.

The mis-fit of the industrial model in technology is that industrialization makes no provision for capability: each person is the same, the only difference being they're either more or less productive than the average, and indexed accordingly. That completely ignores the impact of destabilizing change that people make in what they do and how they do it. Disruptive, externally-driven innovation should be the rule, not the exception. Of all lines of business, this should be the case with technology. And with the right group of people, it is.

Disruptive innovation pops a bubble. A popped bubble threatens entrenched interests (e.g., those who have mastered life inside the bubble). But disruptive innovation is what makes a company sustainable.


1 I am indebted to my colleague Chereesca Bejasa for using the term "bubble" to describe a team operating to a different set of processes and behaviours within such an environment. Just as a team can be in a bubble relative to the host organization, the host itself can be in a bubble relative to its market.

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
  • 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?
  • The Agile PMO: Becoming a Real Time PMO
  • 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