Succeeding with clients that don't want to change

Hypothetical: you find what seems to be the perfect prospective client. You’ve collaborated to develop an idea with the potential to realize outstanding value. They’ve decided they trust you to capitalize on the opportunity and achieve that value via some new software system.

*But!*

But the prospect makes a point to tell you they don’t want to be trained or changed (and that you can forget about “transformed”). They compensate by emphasizing that their only objective is to produce that set of value-creating widgets the two of you dreamed up in the (much cozier, in hindsight) first paragraph.

But when the client’s preconditions—we want to benefit from your approach to building software and we don’t want to change—are juxtaposed, you can read between the lines and infer that the two statements will frequently be at odds. The former requires you to go well (making change cheap, minimizing waste, etc.) while the latter seeks to ensure a comfortable future for the client’s favorite constraints (change management, wasteful processes, etc.).

So given a client who says, “we’ve heard about how fast you can go, let’s get it done!  …just don’t try to change us,” take a moment to think about how you would approach inevitable conflicts like these:

• Your company’s craftsmen report that they can only operate at 50% efficiency in the client’s technical infrastructure and mandated frameworks (increasing the cost of ongoing change in ways you didn’t account for)
• The client’s architects & committees deny the introduction of even trivially small/isolated dependencies and libraries that your team has identified would be the best fit for the job (resulting in additional waste by way of wheel-reinvention)
• The client insists that all product decisions be made jointly among multiple product owners, leaving developers frequently blocked pending the asynchronous communication of others; perhaps even finding themselves having to arbitrate disagreements among the product owners
• The client explains that existing silos must be supplied with the deliverables they’re accustomed to—perhaps a DBA needs to certify every data column name or QA needs fully-qualified RUP use cases from which to derive test case specifications, and neither group is motivated to work within the team’s delivery cadence
• The client doesn’t mind that your team works from an index card wall, just so long as every card’s status is reconciled (and kept in perfect sync) with their issue-tracking system so that the project can be reported on exactly like all others

I know how many of my favorite developers would respond to the challenges above: “that sounds miserable.” The impact of these conflicts on the morale and growth of your own people needs to be taken into account here, too.

But what if you decide to take the client anyway? How do you avoid or mitigate some of the problems identified above and set yourself up for success? I certainly don’t have all the answers, but I have a few ideas—and all of them presuppose this premise:

When a client says that they don’t want you to change them, respond that it’s only fair that they shouldn’t expect to change you, either.

Before engaging with the client, recognize the constraints they’re placing on you and acknowledge directly and honestly how you’ll need to adjust how you’ll work with them. It might seem like you’re being harsh or counter-collaborative, but I always prefer to fail fast by risking defeat today over arbitrarily deferring the same defeat for weeks or months. (Some might argue that success is possible, even in spite of these concerns, and they’d be right. But it isn’t typical. And a deferred defeat often starts to look like a success after months of moving the goal posts.)

Some pragmatic steps you might take to keep things humming without requiring the client to change (much):

• Contract cautiously. Explain to the client that their constraints may impede your ability to deliver in a way that’s reasonably within your control, and therefore you won’t quote a price for a fixed-scope of widgets; explore optional scope contracts, look for ways to tighten delivery cycles so the relationship can be ended amicably partway through, or else fall back on a traditional time & materials arrangement
• Acknowledge the strengths of each of the (multiple) client decision-makers by proposing that each own a discrete logical portion of the system, as it will enable rapid decision-producing collaborative feedback and keep developers unblocked. (It will also force the issue if the root cause for wanting multiple product owners was individual managers’ discomfort with being held accountable for their own decisions)
• Invite them to play at your house instead of theirs when their processes and tools are going to get in your way. Set up the physical team room in your studio (or rent a neutral location). Use your own kit (workstations, card walls, CI servers, a distributed version control system bridging to theirs) and continuously deliver the client packaged artifacts of unimpeachable quality and interoperability. 

Of those, the last point is the most important. When a project is initiated under a client’s roof, they’re naturally going to concern themselves with managing the intrinsic qualities of your work; when you insist on rapidly delivering working software to them, they’re free to focus instead on the degree to which its extrinsic qualities accomplish their goals.

When a client is eager to adopt (or even willing to play along with) how you build software, then by all means go to them and coach them! Not only because they’ll get more out of it, but because you will too!

However, if a client is intent on not being changed by the likes of you, embedding yourself with them won’t just slow you down; you’ll risk losing your edge entirely. You might survive one or two engagements this way, but you probably won’t be able to sustain your ability to deliver value over the long-term.