Delivery & Risk
The Free Favour That Cost Us Six Weeks
Principal Architect · 25 June 2026 · 7 min read
It was twenty past four on a Friday and the client's infrastructure manager caught me by the coffee machine. "While you're in there anyway," he said, "could you just pull the two Manchester switches into the same config baseline? Shouldn't be much." I said yes in under three seconds. I felt good about it for about nine days.
Nobody ever asks you for six weeks
That's the part that gets you. Nobody walks up and says "I would like to extend your project by a month and a half at no extra cost, please." They ask for one small thing, in a friendly way, at a moment when saying no would feel petty.
The Manchester switches were genuinely small. Maybe a day and a half. But saying yes to that one taught everybody involved a rule, and the rule was: this team absorbs things. Over the next eleven weeks we absorbed a second site, a reporting requirement that arrived as a screenshot in a chat message, a change to the out of hours cutover window, and a "quick" firewall rule review that turned out to touch a rulebase nobody had cleaned since 2019.
Every single one was defensible on its own. Added up, we delivered six weeks late, and because none of it was ever written down as a change, the six weeks read to everyone outside the team as us being slow.
That is the real damage. It isn't the extra work. You can do extra work. It's that the extra work becomes invisible, and invisible work gets recorded as incompetence.
The favour has a second half, and you never get shown it
Here's what I did not understand at 4:20 on that Friday. When you accept a piece of work informally, you accept the whole lifecycle of it informally.
You don't just build the thing. You test it, which nobody scoped. You document it, or you don't and it becomes a support problem in nine months. You hand it over to an operations team who were never told it existed and who will quite reasonably refuse to take it. You defend it in a review meeting against a requirement it was never written to meet. And when the client's own auditor asks why the Manchester switches have a config baseline that isn't in the design document, you get to explain that.
A day and a half of work. Five days of consequence. That ratio is roughly consistent in my experience, and I have never once estimated a favour by including it.
Two answers exist, and "yeah, no problem" is neither
So here is the position I've landed on, and it is stricter than most people are comfortable with.
Every request that wasn't in the agreed scope gets one of exactly two responses. You absorb it, deliberately and visibly. Or you raise it as a change. There is no third option where it just quietly happens.
Absorbing is fine. Absorbing is often the right commercial call, because the relationship is worth more than the day and a half and because being the team that flatly refuses everything is its own kind of failure. But absorb out loud. "Happy to do that, it's about a day, I'm logging it as absorbed at no cost so we both have a record." Twelve seconds. That sentence is the single highest return thing in this post.
Where you put the line between absorb and raise is a conversation to have with whoever owns your commercials, once, rather than a judgement you make freshly every time under social pressure at a coffee machine. Agree the threshold in advance and write it down. Then the answer on the Friday afternoon is arithmetic instead of character.
What makes the absorbed pile dangerous is that it's the only category with no paperwork by default. A change request leaves a trail whether you like it or not. An absorb leaves nothing at all unless you deliberately make it leave something, which is why I now keep a plain list called "absorbed", four columns, date, what, who asked, roughly how long. It takes about a minute a week and at the end of the project it is the most persuasive document I own.
The awkwardness is the point, by the way. A change request is not an accusation. It's a way of making sure the person asking gets to decide whether the thing they want is worth what it costs. Absorb everything silently and you've taken that decision away from them. You've also taught them that your estimates are soft, which will be remembered at the next commercial negotiation, not appreciated.
Your team is saying yes to things you never hear about
The favour at the coffee machine at least happened to me. The ones that hurt more are the ones that happen three hundred miles away, on a site visit, to an engineer who has no idea he's making a commercial decision.
Here's how it goes. Your engineer is on site for two days doing a survey. The client's operations manager wanders over, friendly, and asks whether while he's here he could take a look at why the wireless drops in the warehouse. Your engineer is competent, helpful and twenty six years old. He says yes, because saying no to a customer feels like something he'd get told off for, and because he genuinely wants to help.
Four hours gone. No record. The client now believes wireless troubleshooting is part of what you do. And your engineer will not mention it to you, not because he's hiding it, but because in his head it wasn't a thing that happened. It was just being useful for an afternoon.
I have seen an entire delivery bleed out this way, a half day at a time, across five engineers over four months, with nobody ever making a decision anyone would recognise as a decision.
The fix is not a policy about refusing clients. That would be miserable and it would make your team look unhelpful, which costs you more than the hours do. The fix is to give your team a sentence they can use that says yes without giving anything away for free.
Mine is: "Yeah, I can take a look at that. Let me just flag it to my lead so it's on the record." Ten words. It keeps them helpful, keeps them out of the awkward position of being the one who says no, and routes the decision to the person whose job it is to make it. Say it to your team explicitly, and say why, because otherwise it lands as a rule about bureaucracy rather than a bit of cover you're giving them.
Then honour it. If an engineer flags a request to you and you say no, you go and have that conversation with the client yourself. If you make them deliver the no, they'll stop flagging things within a fortnight and you'll be back where you started, without knowing it.
Monday morning
Find the last three things your team did that were never in the plan. Not the big ones. The small ones people have already stopped mentioning.
Put them in an email to whoever owns the commercial side of your work, with an hours estimate against each and one line at the top: "These were absorbed at no cost. Flagging so the record is accurate. Going forward I'll confirm absorb or change request in writing on each one."
You will not get a medal for that email. What you'll get is that the next time you say something costs two weeks, the person reading it believes you.
Principal Architect
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


