Ethics of Spending Client Money¶

When a client pays a software firm to build something, the firm is being trusted with two things: the work itself, and the judgment about whether the work is worth doing. Most disputes between vendors and clients are really disputes about the second of those.

Engineering ethics, in this context, is not abstract philosophy. It is the everyday practice of treating someone else's money with the same care you would treat your own, and being willing to say uncomfortable things when that care requires it.

Why the Pressure Goes Toward "Yes"¶

The structural incentives in nearly every vendor-client relationship push toward agreeability. The client is paying. The client has a deadline. The client has an idea they have already pitched internally. The team on the vendor side has hours to bill, a pipeline to fill, and a renewal to protect. Everyone, on both sides, has a short-term incentive to keep building whatever the client originally asked for, and almost none to slow down and ask whether they should.

This is why "yes" is the default answer. It is the path of least friction in the moment, regardless of whether it produces the best outcome over the life of the project.

The discipline of good stewardship is the discipline of not defaulting to yes when yes is wrong.¹

What Stewardship Actually Looks Like¶

A few concrete behaviors distinguish a vendor practicing stewardship from one practicing order-taking:

Scoping down before scoping up. When a client describes a feature, the first instinct should be to ask what problem it solves and whether there is a smaller version that solves enough of it. The first instinct should not be to estimate the version they asked for.
Naming alternatives the client did not ask about. If buying solves the problem better than building, say so, even if it shrinks the engagement. If a process change would eliminate the need for the software entirely, say that too.
Refusing work that will not earn its keep. Some features cost more to build, run, and maintain than they will ever return in value. A vendor who builds them anyway because the client asked is being paid for activity, not for outcomes.
Telling the client when to stop. Most software is over-featured rather than under-featured. The most valuable thing a vendor can sometimes say is "the next dollar is better spent somewhere else."
Surfacing trade-offs the client cannot see. Operational cost, maintenance burden, and complexity load are largely invisible to clients at the moment of decision. A good vendor makes them visible before the decision is made, not after the invoice arrives.

These behaviors are not about being difficult or contrarian. They are about being useful in a way the client cannot easily evaluate from the outside.

What Bad Stewardship Looks Like¶

Most poor client work is not malicious. It is a series of small failures of nerve.

Quoting the feature instead of questioning it. The client asks for X. The vendor estimates X. Nobody asks whether X is the right thing to build.
Letting scope creep go unchallenged because the hours are billable. Every "while you're in there" request gets added to the work without a conversation about whether it is worth doing, because saying no is awkward and saying yes is profitable.
Hiding bad news. Schedule slippage, ballooning complexity, and integrations that turned out to be impossible get softened, deferred, or buried in status reports instead of named directly while there is still time to course-correct.
Optimizing for the renewal rather than the outcome. Decisions get made that maximize the chance of the next contract rather than the chance of the project actually succeeding. Over time this erodes the trust that made the renewal possible in the first place.
Treating the client's first instinct as the requirement. "They said they wanted it" becomes the justification for never re-examining whether they should.

In every one of these patterns, the vendor is technically doing what the client asked. The client is still being poorly served.

The Conversation You Owe the Client¶

A few habits make stewardship operational rather than aspirational:

Put trade-offs in writing. "Here are three ways to solve this, with rough cost and risk for each, and our recommendation." Clients cannot make informed decisions without an informed picture, and they cannot remember a verbal one.
Distinguish "we can build that" from "we recommend building that." Both can be true, but they are different statements, and clients who hear only the first will routinely assume the vendor endorses the work.
Document the rejected alternatives. When a decision goes against your recommendation, log it. The client gets to make that call, but the record protects everyone when the decision becomes relevant later.
Name the long-term costs at decision time. A feature that adds half a developer-day per month of maintenance for the next five years has a real price tag, even though no invoice will ever show it as a line item.
Be willing to lose the work. A vendor who is never willing to walk away from a request is a vendor who is structurally unable to push back on one. This makes their pushback meaningless when they finally offer it.

Key principle

Agreeability and good stewardship are not the same thing. The most valuable thing a software firm can sometimes say is "we do not recommend spending money on that."

David H. Maister, Charles H. Green, and Robert M. Galford, The Trusted Advisor (Free Press, 2000). The canonical text on the difference between a vendor who executes requests and an advisor whose value depends on being willing to challenge them. Argues that trust is built through demonstrated willingness to put the client's interest above the immediate engagement. ↩