The Efficiencer Model

If your team is salaried and there’s no replacement project waiting, finishing early reduces the invoice without reducing payroll. You can still approve the better approach. But your engineer has handed you a revenue problem along with a useful recommendation.

Jonathan Stark described that pressure in a 2009 account of managing a software firm. His strongest developer sometimes finished projects faster than the firm could find new clients, while a slower, lower-paid junior brought in steadier billing. Stark reasoned that, if money got tight, the stronger developer would have to go. He described a dilemma, not an actual firing.

The detail that matters is the shortage of replacement work. If another paying project is ready, efficiency frees capacity you can sell again. A firm can also choose a smaller invoice to earn trust and repeat business. Stark’s account illustrates a pressure under particular conditions; it doesn’t tell us how most consultants behave.

What the invoice leaves out

The deeper risk is a filter on what your best people are willing to recommend. Consolidating systems can remove an implementation. Buying an existing product can remove a custom build. Questioning the business need can remove the whole engagement. If those recommendations make the firm miss its revenue target, someone has to defend them internally before the client even hears them.

The client can inspect the hours you billed. They can’t inspect the alternatives that never reached the proposal.

An efficiencer practice makes removing unnecessary work part of what the client buys. That requires a way to pay for the judgment, including when the judgment leaves less work to sell.

A fixed fee moves the conflict

For a defined result, a fixed fee changes what finishing early does to revenue. If the contract permits the integration in place of a custom build, and the result passes acceptance, the fee stays the same. The firm keeps the agreed revenue while freeing capacity. Any delivery cost actually avoided adds to margin; idle salaried staff still draw their pay. The firm also bears the cost of overruns within the agreed scope.

Why should the client pay a custom-build price for a small integration? They may have agreed to pay for a result regardless of the route, but that agreement alone doesn’t make it a good deal. Their comparison is the fee plus what the result will cost to run, against the cost of meeting the same need another way. A larger margin for your firm doesn’t establish that the client came out ahead.

That cost incentive can reward shortcuts too. Omitting recovery procedures or leaving awkward cases for the client’s staff also reduces the vendor’s work. If acceptance only checks that a report appears, those omissions may pass.

Bengt Holmström and Paul Milgrom examined this tradeoff in their 1991 model of incentives across multiple tasks. When output is easy to measure and quality is difficult to measure, rewarding output can divert effort away from quality. Their model explains why stronger incentives can make some parts of a job worse. It doesn’t measure how often software vendors cut corners.

Applied to the reporting example, that means agreeing on more than a demonstration. A report might show the right total on a clean sample and duplicate records when someone reruns a failed import. Acceptance can require reconciling the report against the source records after both a normal run and a recovery.

Ongoing service charges and manual work belong in the comparison too, including the client’s staff time needed to recover a failed run. The contract needs a way to distinguish a defect the vendor must correct from a changed requirement the client must fund. Otherwise, each disputed detail becomes a fight over whose margin pays for it.

Payment tied to a business outcome adds another dependency. Delivering working reports is something a vendor can test; reducing the client’s operating costs also depends on whether staff adopt them and retire the old process. Even then, time released from report preparation is capacity. Calling it cash savings requires identifying an expense that actually falls.

A savings-based fee needs an agreed baseline for comparable work, a measurement period, and named client responsibilities. If the client produces fewer reports, lower costs could reflect lower demand rather than better software. The agreement also needs terms for what happens when the client doesn’t supply data or make the agreed changes.

If you can’t yet establish what has to change, hourly work can be a defensible way to buy investigation. The 2024 federal procurement rules for time-and-materials contracts reserve that form for work that can’t be estimated reliably, when no other contract type is suitable. They require oversight and a ceiling price. That’s a public procurement rule, but the distinction is useful here: uncertainty gives hourly pricing a purpose. A spending limit and a review of what the investigation established give the client a stopping point before authorizing more work.

The option to stop

A fixed fee still rewards completing the project you sold. It doesn’t automatically reward discovering that the project should be cancelled. A percentage of savings can create a similar problem: the seller benefits from a baseline that makes the savings look large. Changing the invoice unit leaves room for judgment to serve the fee.

One way to reduce that conflict is to make the initial decision a separately paid piece of work, with no commitment to buy implementation. Its deliverable is the comparison the client needs to choose: build, use something they already own, or leave the process alone. Payment has to depend on delivering that comparison, regardless of whether the client approves a build.

In the reporting example, the comparison needs more than a promise that the existing software will do the job. It can include a report run against the required records, the costs of operating each option, and any assumptions still untested. The client should be able to see why an option was ruled out. A supported decision to leave the process alone can complete the assignment.

That arrangement has limits of its own. A firm hoping to win the build still has an interest in recommending one. The assessment itself also has to justify its cost: if a capable internal technical leader can test the existing-software option and explain the tradeoffs, the client can make the decision without buying an external assessment.

If the client needs outside expertise, they can separate assessment from delivery and keep the evidence usable by another provider. That means handing over test results and cost assumptions, so the client can have the recommendation checked rather than starting the investigation again. The cost of that second provider learning the context belongs in the decision as well.

The smaller integration tests whether your firm can benefit from doing less. The harder test comes when the client can solve the problem without your firm at all. What, in the agreement you’re about to sign, pays you for telling them?