laptops

Be a Partner, not a Vendor

Years ago, I received a frustrating email from a disappointed client. I was confused – from an engineering perspective, this should have been a model project. It nailed the requirements on time, under budget, with great documentation, full unit test coverage, and even included some cutting-edge original research and upstream open-source contributions.

Here's the email (emphasis added, scare quotes original):

There are a number of reasons we are shutting down the job. . . . [T]he developers did believe that some shortcuts were made and that no initiative was taken to make the video module better outside of the “requirements”. I think on our next joint effort, we need to be much clearer from our part. Realistically, we would have preferred to pay more, but had help thinking and making the video module better.

I appreciate you sending the remaining balance back.

Now, my team could have just laughed this off and called it a day. Here is a client complaining that we met the requirements! But I realized he was right! I learned two things from this:

Service is not what you think
This client sent early signals that he was not open to feedback. We got a rigid set of requirements, and a few attempts at suggesting improvements were swiftly rejected. Rather that enter into a conflict, it was easier to fulfill the requirements as written. But we should have persisted; a true partner needs to engage with the full product lifecycle, even if that means risking a conflict. Behaving meekly is not good service.

You aren't a cog
When all was said and done, his email summed it up perfectly. We are paid for thinking. The real value we bring as an agency is in product design and architecture, not punching keys or a TODO list. The latter could be offshored for a lot less money. The former requires a partner, not a vendor.

We run into this kind of thing all the time, and have long called ourselves "opinionated developers" -- we're going to push back on requirements and let you, the client, know what we think is a worthwhile investment of their budget. But that's just the first step -- what does this mean in practice?

A couple months ago we found a new question to clarify right from the start: "What is the most/least important part of this project -- budget, spec, or time?" This is a hidden assumption that if you get wrong, you're bound to disappoint the client. Many clients are fine with spending more budget to get the functionality just right. For some, the timing of the launch is the most critical thing, and cutting some of the user experience refinements is better than missing the deadline. For others, it has to work just right, even if it delays launch. And some simply have no extra budget to spend, it has to meet the requirements for the agreed-upon budget.

Clarifying these priorities really helps with becoming a good partner with your clients -- if you're not on the same page, there's bound to be trouble...

Add new comment

Restricted HTML

  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • You can use Markdown syntax to format and style the text. Also see Markdown Extra for tables, footnotes, and more.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <pre> <code> <pre> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <p> <br>

About the Author

Dylan Tack, Director of Engineering

Dylan is a software engineer with more than a decade of experience working with a wide variety of clients including the Linux Foundation, PBS, Habitat for Humanity, TV.com and the Emmys. His background includes training as an electrical engineer, but he became passionate about open source through his work with a university genetics lab.