Saying yes for free is the wrong answer. So is saying no.
Operators ask for small changes on every commissioning job. Doing them for free is wrong. Refusing is wrong too. The right move has a name.
A translation in your language isn’t ready yet — showing the English original.
On every project I’ve worked on, the same thing happens.
On contracted work, everything 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 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.
This is a normal, legitimate part of contracted work, and every market has its own version of it. A change order, a variation, whatever it’s called where you are. 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 question is how you handle them, and most of us handle them badly.
The two wrong answers
When the requests start, engineers do one of two things.
The first is to just do it. Say yes, build it, move on. Free. It feels generous and easy in the moment, and it’s a mistake. Someone pays for those hours. Your own company. You’ve also 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.
The second is to say sorry, that’s not in our scope, or we don’t have time. 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.
In my opinion, both are stupid.
The third answer
What to do instead isn’t complicated.
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 and it costs you nothing.
Write it down, literally. Pen, paper, a running list, whatever. Capture every request as it comes. Writing it down commits you to nothing. You’re just collecting.
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.
Take the list to whoever holds the wallet. Your project lead, your project manager, whoever controls the money. Cost it out properly: hours, material, a real number.
Then 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 a change order, and here’s what it costs. You already have the number ready when you say it.
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. No surprise on an invoice, no 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.
The relationship stays warm, because your answer to “could you” was never no. It was good idea, let me look into it. A yes to the conversation is what people remember.
And nobody gets blindsided. The cost is on the table before any work happens.
The one exception
Sometimes free is exactly right. The customer’s frustrated, the project’s been rough, you could 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 the job turns out bigger than it looked you can’t walk it back, and telling someone it’ll cost money after you’ve already said yes for free is a horrible conversation. So the line is still: let me look into it. Then you check it quietly on your own. Once you’ve confirmed it really is five minutes with no complications, you come back with: 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 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.
But recognizing a change order 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 the next time someone says could you just, and they will, on every job: don’t say yes, and don’t say no. Tell them that it sounds like a wonderful idea, and say you’ll write it down and get back to them.
Learn how this aligns with our vision and core
Read more at tianengineering.com — https://tianengineering.com/articles/saying-yes-for-free/