Every Friday, an employee prepares the total value of won deals for the sales meeting. She exports the data, removes duplicates, adds up the figures and formats the file. It takes one hour.
A colleague proposes an automation trial. The manager asks for a written proposal. Another team needs to approve it, but there is no deadline for a response and nobody knows who can authorise the trial in their absence.
This case was constructed for the article. The weekly hour and the amounts below are example inputs. The task under examination is specific: produce the same report without copying the same information every week.
Four weeks later, six hours have gone into the task
In this scenario, four weeks pass without a decision. The report has been prepared four times, taking four hours. The colleague has also spent two hours on her proposal and approval discussions.
The business has therefore spent six hours and retains exactly the same manual process. This does not prove that automation would have succeeded in two hours. It establishes the cost incurred while no decision was made.
The proposal describes a trial that would neither change sales data nor replace the report yet. A response could request another check, set a date or reject the trial for a specific reason. None of those decisions arrives in this case.
The following Friday, the manual task will still have a known deadline. The improvement proposal will still have none. Preparing the spreadsheet fulfils the week’s obligation. Chasing the trial adds work without establishing when it will produce a result.
The automatic total would be wrong by 1,200 euros
The person preparing the report objects that the export contains duplicates. These are the three rows in the example dataset. The amount is the total value of each deal, not a share assigned to the salesperson.
| Deal | Associated salesperson | Total deal value |
|---|---|---|
| A42 | Previous owner | €1,200 |
| A42 | New owner | €1,200 |
| B17 | Current owner | €800 |
Deal A42 appears twice following a change of owner. Adding the rows produces €3,200. Counting each deal once produces €2,000. The manual preparation therefore removes €1,200 that would otherwise be counted incorrectly.
Replacing the copy with an automatic sum would repeat the error every Friday. The objection contains the rule missing from the proposal: the report must count deals, not export rows.
A trial that can be accepted or rejected on its output
The trial can now have a scope that does not require general faith in automation. It uses a copy of the export, produces a second file and leaves the normal report unchanged.
For the dataset above, the expected result is €2,000. Deal A42 must appear once. If two rows with the same identifier contain different amounts, the tool must flag the conflict rather than silently choosing one.
The person preparing the report then compares the two files using real exports approved for the trial. Every difference must be explained before replacing the normal file. A decision can now rest on outputs available for inspection.
The colleague can choose how to produce the second file. She cannot change the definition of a won deal, discard a conflicting row or send the export to an unauthorised service. Autonomy has boundaries that can be checked in the work itself.
During Drynuary, some decisions had already been made
At Gridky, during Drynuary, we did not need repeated approval for stabilisation to take priority. The CTO and CEO had agreed to pause new features. That decision applied to the whole team, including requests from the priority client.
Developers chose issues according to severity and recurring exceptions. Changed code had to be tested and reviewed before merging. The choice of fix remained with the team, while the required checks were not left to individual preference.
That is the division of decisions I can describe in this real case: product priorities had been agreed before the work, implementation choices stayed within the team, and reviews checked the results. We had a senior team committed to the task.
Permission to try is not permission to replace
In the report example, the first approval concerns a parallel file. Replacing the report comes later, after comparing outputs. Treating those as one decision requires justification of the final process before anyone is allowed to test it.
The duplicates are a good reason not to replace the manual work immediately. They also provide a specific case against which to test the proposal. The objection becomes an expected check, with a result of €2,000, rather than a reason to wait indefinitely.
The next Friday makes the change observable: an authorised trial has produced a comparable file, or the same employee is doing the same work alone. Asking for initiative in a meeting changes neither outcome.
Waiting after work is already finished is examined in A fix finished on Tuesday, released the following week. Both situations appear in the five faces of technical debt.