Saying yes for free is the wrong answer. So is saying no.

Every project I’ve worked on, the same thing happens. Not sometimes. Every single time.

On contracted work, it all gets agreed up front: what was sold, what the customer gets, who’s responsible for what, where one side’s scope ends and the other’s begins. Clean on paper. Everyone knows the deal.

Then commissioning starts. You’re standing at the machine with the operators, going through the functions, and it begins:

“Could you add a button for that?”

“Could you move that window over here?”

“Could you make it do this when that happens instead?”

Small stuff. Reasonable stuff. Often genuinely good ideas — the operators run this machine every day, they know it better than anyone, and half of what they suggest would actually make it better. And none of it — not one of those requests — is in the contract. We are not getting paid to do any of it.

This already has a name

In Sweden we call this kind of work an ÄTA — Ändrings-, Tilläggs- och Avgående arbeten. Changes, additions, and deductions. Work that falls outside what was agreed.

It’s not a dirty word. It’s a completely normal, legitimate part of doing contracted work, and every market has its own version of it — a change order, a variation, whatever you call it where you are. The point is that it has a name because it’s expected. Scope changes. The question is never whether the “could you just…” requests will come. They always come. The only question is how you handle them.

And most of us handle them badly.

The two wrong answers

When the requests start, engineers basically do one of two things.

One: we just do it. Say yes, build it, move on. Free.

This feels generous and easy in the moment, and it’s a mistake. Someone pays for those hours — and it’s not the customer, it’s your own company. Worse, you’ve just taught the customer that asking gets them free work, so they keep asking. And free things get treated as worthless. You gave away real engineering and got nothing for it, not even credit.

Two: we say “sorry, that’s not in our scope” or “we don’t have time.” No.

This feels disciplined. It’s also wrong. You come across as rigid and unhelpful at the exact moment trust is being built. You kill ideas that might genuinely improve the machine. And you still leave money on the table — because that request was very likely something the customer would have happily paid for. You turned a possible sale and a goodwill moment into a flat no.

Both reflexes are lazy. One bleeds money, the other bleeds the relationship. In my opinion, both are stupid.

The third answer

Here’s what we should do instead — and it’s not complicated.

1. Always say yes to hearing it. Never shut a request down at the machine. “That’s a good idea — let me write it down.” The operator feels heard. It costs you nothing.

2. Write it down. Literally. Pen, paper, a running list, whatever. Capture every request as it comes. You’re not committing to anything by writing it down — you’re just collecting.

3. Don’t promise and don’t refuse on the spot. You don’t own the budget, so don’t act like you do. “I’ll look into this and come back to you.” That’s the whole line.

4. Take the list to whoever holds the wallet. Your project lead, your project manager — whoever controls the money. Then cost it out properly: hours, material, a real number.

5. Go back to the customer with the answer and the price. “Yes, we can do all of this. It’s outside what we agreed, so it’s an ÄTA — here’s what it would cost.” And you already have the number ready when you say it.

Then the customer decides, with full information in front of them.

Why this is better for everybody

The customer gets heard, and gets a real choice — not a surprise on an invoice, not a door slammed in their face. They might say no, and that’s fine; they made the call.

Your company gets paid for work it would otherwise have given away for free.

The relationship stays warm, because your answer to “could you…” was never “no.” It was “good idea, let me look into it.” That’s a yes to the conversation, which is what people actually remember.

And nobody gets blindsided. The cost is on the table before any work happens.

The one exception

Sometimes free is exactly right. You’re in a tight spot — the customer’s frustrated, the project’s been rough, you could really use the goodwill — and the request is genuinely tiny: a few minutes, almost no effort, but it means a lot to the operator. A small spend for a big return.

In that case, give it away. But do it the safe way, because everything above still applies. Never promise “free” at the machine — if it turns out bigger than it looked, you can’t walk that back, and “actually, this’ll cost you” after you’ve said yes is a horrible conversation. So the line is still “let me look into it.” Then you go check it quietly, on your own. Only once you’ve confirmed it really is five minutes with no complications do you come back: “Did that thing you asked for — and this one’s on us.” Deliver free as a finished surprise, never as a promise. And be ruthless about how rarely this actually applies.

Why I’m writing this as a junior

When you start out, you think the job is the technical work. The code, the wiring, the I/O, getting the machine to run. That’s most of it, sure.

But recognizing an ÄTA the second you hear one — and handling it like this instead of reflexively saying yes or no — is also the job. Nobody teaches it. It’s not in any course. And it’s worth real money to the people you work for and real trust with the people you work with.

So learn to hear it. The next time someone says “could you just…” — and they will, on every single job — don’t say yes, and don’t say no.

Say: “Good idea. Let me write that down and get back to you.”

Then capture it, route it, cost it, and let them choose. That’s the whole skill.