Tuesday, November 23, 2010

So You Wanna Make a Big Change

There's been a lot of buzz recently about "selling". Let's "sell" agile, and let's "sell" testing, and we're all really "selling brand You" when we look for a job (that last one was a particularly atrocious local news story on what had to be a slow news day).

I think it's great. After all, sales isn't really a dirty word. Sales is simply making people aware of the benefits and costs of something with the end results of asking them to commit to that thing. I'm sure there are more official definitions out there, but this is the one I like.

A lot of the things we're trying to sell, though, amount to a large cultural and strategic change. We want to sell someone on moving to an agile development methodology. We want to sell someone on providing testers with early access to a system. The costs of this type of change are high; it can easily take months or years to change a culture and it's inefficient while it's in progress. Cultural and strategic changes also rarely go unnoticed. Maybe if you're HugeCo and you start with one tiny project, then you can slip it under the radar. But most of us don't work for HugeCo, and most of us don't have a project that is our own domain that we can try new things with.

So let's assume we have to sell this cultural change. We're borrowing the sales verbiage, so let's borrow the techniques, too. Approaching it like it's a sales challenge, then we need to identify:
- the benefit of the change ("who wins")
- the cost of the change ("who pays")
- the people who - directly or indirectly - have to change along with it ("who cares")

From there, it's generally a matter of identifying the decision maker and decision influencers. The decision maker it the go/no-go person in the end, and it's probably the guy who's going to end up both getting the most benefit and absorbing the most cost. In the case of changing development methodologies, it's probably the head of engineering. It might be the entire executive committee.

Decision influencers are a lot more numerous. It's the sales guys who are counting on a release next quarter, and the marketing types who need a new feature for a trade show in 4 months. It's the support group who will need to handle different ways of getting customer hotfixes through development. And it's your software architects who have to implement this thing. The decision influencers are everyone who wins, everyone who pays, and everyone who cares.

Convince the influencers, and they'll help you convince the decision maker. But you have to hit most of the decision influencers, and you have to start selling. Start showing them why they should care, why they win, and why the cost is something they want to absorb because of the benefit they'll end up getting. Then you're really selling. And who knows - maybe you'll get the eventual decision in your favor.


  1. Hi Catherine,

    As I agree about selling points, I don't think that borrowing "sales techniques" is a way to go in this case. As a subdivision of management theory, there is innovation theory, and there are well-developed techniques too.

    I couldn't find an online resource in a quick search for citing, so the following paragraph is me telling about what I read.

    In general, for an innovation to be successful, it should be accepted and adopted throughout all layers of staff: regular employees, middle management, upper management.
    * For regular staff, a change must not worsen anything for them.
    * For middle layer, a change must bring material, or monetary, or status raise.
    * Upper layer is already at high status, and usually has material problems solved. So the change must bring good on emotional, or social, or political level.

    Example. One decided to introduce a practice of pairing in testing.
    3 layers in this case: testers in the team, test lead, test manager.

    Selling for testers.

    * Pairing does not affect workload but increases efficiency
    * They're responsible for their work as before but pairing increases confidence
    * They won't have to learn new things all alone
    * A common practice of peer help

    Selling for the test lead, and, partially, for the test manager.

    * Cross-training in the team makes stronger team
    * Pairing enables "force multiplication" effect
    * A new technique successfully adopted in the team makes them special too - a positive impact on status
    * Better testing means performance improvement which is usually rewarded financially or increases influence rate

    With that, I just wanted to comment that a main decision maker ("go/no-go person") is not necessary is the one who's "getting the most benefit and absorbing the most cost". A deep moral satisfaction might be much stronger motivation than material benefits. And if costs are put on the regular staff they will be resisting the change.

    Thank you,
    Albert Gareev

  2. Albert, I'm not sure which theory you're referring to by innovation theory. I know a bit about the Innovation Diffusion theory (decent primer here: http://www.rogerclarke.com/SOS/InnDiff.html), and then there's Schumpeter's work on innovation (http://en.wikipedia.org/wiki/Joseph_Schumpeter#Schumpeter_and_Innovation), or there's some of the management theory devoted to managing innovation (numerous sources, summarized fairly well here: http://www.hks.harvard.edu/netgov/files/team/innovation.pdf). Those are all interesting, but kind of not what I was intending to discuss. :)

    I think you've got some interesting thoughts, but we're talking about different phases of the process. Roughly, a change process is going to go through some set of stages:
    - problem identification
    - alternative analysis
    - option evaluation
    - option selection
    - change description
    - change approval
    - change implementation
    - measurement of efffect

    (Note that this is often not a linear process - you'll go forward one step, encounter a roadblock, go back two steps, then go forward one step again, etc.)

    I'm mostly talking about the "change approval" step. You're really talking about the "change implementation" step. That's where you get into things like obtaining buy-in from the agents of change (in your example, the testers and test managers, etc.). Obtaining buy-in covers the thing you're calling "selling for testers".

    Perhaps it would be useful to provide a bit more context. This blog post came out of a discussion we were having about "selling change to the CFO". I took it in a slightly different direction, but that was the original kernel of an idea. Any change that's going as high as the CFO (or "upper management") is a large change. Trying pairing doesn't have to affect anyone but the test team that's trying it, so there's little need to go to upper management with it. That's a small change. A big change is something that affects other groups - typically through decreases in productivity of 30% or more for some period of several weeks or months at least, or through some large increased assumption of risk.

  3. Hi Catherine,

    Thank you for the additional explanation and links provided.
    I've read the original work not in English, and, it seems, it has not been translated. Though it looks like, Innovation Diffusion theory you referred to is about same things and processes.

    From details in your reply I pick up that you are talking about either some internal problem in organization that, probably, can be solved through a change - or about *convincing* a CFO that they have a problem and they *need* to react upon it. But if a change is from "good" to "better" is there really a *problem*?