Engineering Journal · TECHNOLOGY · August 12, 2026 · 16 min read
The Feature Worked. The Work Did Not Get Smaller.
A ticket can be correct, tested, and live, and still leave staff doing the same week in a spreadsheet. Technical completion is not the same as operational relief.
By Golam Sorwar, Tech Lead and Full Stack Engineer in Dublin.
I have closed tickets I was proud of and then watched the same people open the same spreadsheet the next morning. The feature did what we said. The status was right. The email sent. The report existed. The week did not get lighter.
That gap is easy to moralise. Product did not specify. Users resist change. Engineering is too precious. Sometimes those are true. More often we shipped a technically correct island and left the crossings to humans.
I have written about watching decisions before automating them. This is the plainer cousin. Even without a model in the loop, you can succeed in software and fail in operations. The test is not whether the demo clicked. The test is whether the organisation still has to perform the process beside the software.
Context
Operational environments — a college back-office, earlier ERPs and commerce tools — are full of features that were requested as relief. If we had this screen, we would stop chasing. The screen arrives. Chasing continues because the exception, the approval, the export to finance, or the "we also have to tell so-and-so" was never in the ticket.
Engineering is close enough to hear the request and far enough to miss the rest of the morning. That distance is the subject.
I do not mean this as a speech about empathy. I mean it as a measurement problem. If you never watch the ten minutes after save, you will keep shipping nouns. The organisation will keep paying for verbs.
I have also seen the inverse: a large automation that removed a click and created a reconciliation. The click was visible. The reconciliation was a week. We counted the click. They counted the week. Both counts were honest. Only one was the job.
The problem
The apparent problem is adoption. They are not using it.
The real problem is incomplete work design. We implemented the noun they named and not the job they are measured on. The job might be get this person to a state finance will accept, or leave a trail for the next shift, or do the same thing for twenty people before lunch. A feature that handles one pretty case can add clicks to the twenty.
There is a second problem: we measure engineering done-ness and they measure leftover effort. Both graphs can be honest and still argue.
A third problem is the exception that was declared out of scope. Out of scope is fine if it is rare and named. It is fatal if it is how Tuesday actually works. Then the official feature is a brochure, and the brochure does not shrink the week.
The tempting solution
Build exactly what was asked, on time, with tests. Declare success. Offer training.
Or add more features around the unused one, hoping the island becomes a continent. You can spend a year paving a process nobody wanted to walk.
Why that is not enough
Training cannot fix a flow that is longer than the spreadsheet. People are rational. They will use the tool that gets the morning over.
Exceptions that remain outside the system will pull the happy path outside too. If the official screen cannot do the ugly case, the unofficial file will do all the cases, because switching costs.
Reporting that does not match the number a manager already defends will be ignored. They do not hate your chart. They hate explaining a second number.
Customer-facing polish that does not change staff load can still be worth it. It is a different product goal. Do not call it operational relief.
The tempting solution also hides in automation language. "Now it is in the system" can mean "now they type it twice: once for us and once for finance." That is a technically correct integration and a larger morning. If you do not watch the handoff, you will celebrate the API and miss the second keyboard.
Options
Keep shipping requested screens. Advantage: you are responsive. Disadvantage: you become a form factory. The factory can be busy and the factory floor still full of paper.
Sit with the job for a morning and implement the crossing, not only the noun. Advantage: you see the spreadsheet columns that are the real schema. Disadvantage: it is slower to start and politically harder, because it sounds like you are rewriting the request. You are.
Refuse work that cannot name the effort it removes. Advantage: focus. Disadvantage: you will be called unhelpful. Sometimes you should still do the small courtesy feature. Not every ticket is a process redesign.
Automate the leftover. Advantage: if you understood the leftover. Disadvantage: if you did not, you automate the spreadsheet. I have already argued for watching first.
Ship the crossing before the noun: the export finance already trusts, the exception path, the batch of twenty. Advantage: the week can shrink before the screen is pretty. Disadvantage: the demo is dull. Dull relief beats a beautiful island. I would rather show a dead spreadsheet column than a new empty menu.
Trade-offs
You trade some output count for outcome conversations. Leadership must tolerate a week where the ticket looks large and the demo looks small.
You trade a little purity. The first useful version might be an export that matches the spreadsheet, not a beautiful workflow. Matching the spreadsheet can be the bridge. Living on the bridge is the failure.
You should not trade away a way to do the exception in the system. Exceptions are the process. A happy path that cannot host Tuesday will not host Monday for long either.
Decision
I want a definition of done that includes a sentence from operations: this replaces X, except Y, and Y is handled by Z. If we cannot get that sentence, we are building a parallel. I will still sometimes build the parallel if the political cost of waiting is worse. I will not call it relief.
I also want a date to look again. A week after launch, ask whether the spreadsheet column died. If it did not, the feature is not late. It is unfinished. That follow-up is more useful than a satisfaction survey.
If operations cannot name the effort that dies, I ask them to show the morning. The morning is more honest than a ticket title. I would rather delay a sprint than decorate a spreadsheet they will still open.
Implementation / Thinking process
Ask what they do after they would click save. The after is usually the work. A letter that still needs a manual email. A status that still needs a finance file. A list that still needs a human sort because the filter is wrong.
Watch one ugly case, not only the demo case. The ugly case is where the spreadsheet wins. If you only watch the demo, you will pave the exception into a side channel and then wonder why the official path is empty.
If the feature creates a new report, ask which report it retires. If it retires none, you have added a number. Adding numbers is not the same as adding clarity.
Admin tools matter here. If staff cannot fix a miss without engineering, the feature has a hidden support cost. I would rather a guarded, logged correction than a clean UI that requires a developer to amend a row.
Batch matters more than beauty. A screen that does one record well and twenty records badly will lose to a spreadsheet every time. If the job is twenty, the feature is not done until twenty is cheaper.
Finance and letters are the usual leftovers. If those still happen in another tool, say so in the launch. People can accept a known handoff. They cannot accept a story that the process is "in the system" when half of it is not.
I also ask who still does the sorting. If a human is the query planner — exporting, filtering in a sheet, re-importing — the feature did not absorb the job. It added a station. Stations that do not replace the next station are how mornings get longer while the roadmap looks complete.
Failure modes
The shadow process that we bless by ignoring. It will set the quality bar.
The feature that saves a specialist five minutes and costs a junior twenty. We asked the wrong person what "smaller" meant.
The integration that creates the record in our system and not in theirs, or theirs and not ours. Someone still types. We called it automated.
The success metric that is "usage." Usage of a worse path is not a win.
The launch that added a status and not a queue. Staff still hunt the twenty in a sheet because the screen only knows one. You shipped a noun. They still have a job of twenty. The leftover is the product you refused to see.
Operational consequences
When work actually shrinks, you hear it as silence. Fewer pings. A spreadsheet that ages. That silence is easy to miss if you only listen for launch noise.
When it does not shrink, you get a second job: maintaining a feature and a workaround. That is how systems become hard to change. I wrote about that earlier as coupling. Here it is coupling to a process you did not finish.
There is a trust consequence. After two islands, staff stop asking for software. They ask for exports. That is a rational response to a factory that ships nouns. Winning them back is harder than watching the morning before the first ticket. The cheapest time to learn the crossing is before you pave the island.
Lessons
Software can be correct and still be a detour. The organisation does not owe you adoption for a detour.
Done means the leftover work has a name, an owner, and preferably a smaller size. If the leftover is "the same as before," you shipped a museum of the request. Museums are accurate. They are not relief. Relief is a smaller morning, even if the screen is uglier than the mock.
What I would do differently today
I would have put the after-save walkthrough in discovery, not in a disappointed week-two chat. The after-save is the requirement.
I would have been more willing to ship an ugly in-system exception path earlier, instead of a polished happy path that staff cannot live in. Pretty and unused is a kind of technical debt. It looks like quality in a screenshot.
I would have asked which report dies. If none dies, I would have said so in the launch, instead of implying that a new chart is a new truth. Two truths are work. Work that does not shrink is the subject of this essay.
Closing thought
A feature that works is a low bar. The bar that matters in operational software is whether the week got smaller. If you cannot say which minutes died, you are still counting tickets. If the spreadsheet is still the system, the ticket was a scene, not a change. Build the crossing, or admit you only built an island.