The 5 stages of the 5 minute job.

Working as part of a System Team, one of the most common phrases I hear on a daily basis is “It will only take five minutes!”. This is generally preceded by small talk, complements and on occasion, the odd bribe of sweets. However when someone comes to my desk with one these requests, they often leave unsatisfied.

This may not sound like the way that a system team should behave, as the intent is to be enablers for development teams. It may even sound a bit mean but there is a very good reason for this. There is no such thing as a job that takes just 5 minutes.

To see why, let’s break down what it really takes to do one of these 5 minute jobs.

Stage 1: Pleasantries

First thing any requestor is going to do is call over to the engineer they want to do the 5 minute job. For the purposes of clarity, we’ll call our requestor Steve and our engineer Brent. When Steve stops to Brent’s desk to make the request he interrupts him from what he was doing. In any sort of physical job this may be ok, Brent can just pick up whatever he was doing with minimal effort. However in any form of creative or mental profession this can be incredibly costly. Brent could be in the thought process of a major breakthrough in his day, needing only a few more minutes to piece everything together and then there Steve is, with his request for few minutes of Brent’s time. Even if Brent was to decline Steve’s request, he has already been taken out of his train of thought. As this delves into the world of neuroscience and it is difficult to actually measure the cost of an idea not being finished, we can negate the potential cost for the sake of simplicity.

We’re now at T=0, Brent is interrupted and we can start counting the cost of the 5 minute job.

Unless Steve is in a particular rush and dives straight into the ask, he is going to spend as least a few minutes having a quick chat with Brent. The usual, how are you?, how are the kids?, plans for the weekend?. Nothing wrong with people being friendly in the office, just in this context we are looking at the cost of a piece of work. So lets say Steve spends about 2 minutes talking to Brent.

We are now at T=2.

Stage 2: The Ask

Next comes the crucial part, the ask. Steve needs to do two things; first convince Brent of the need to do this work now, superseding what he was doing before. This may be easy if the work is actually more important, though experience would suggest it is not. Second, Steve needs to provide Brent with enough information to actually do the work, so he needs to go through the whole ask and ensure Brent understands it. These two things combined could amount to another 5 – 10 minutes. We can take the higher estimate here, as it generally takes some convincing that your work is more important that what is currently in flight and that the ask is generally not straight forward.

We are now at T=12.

Stage 3: The Work

Now comes the easy part, doing the 5 minutes of work, not going to tack on any extra time. Will operate on an assumption of good faith that it is genuinely 5 minutes work.

So we are at T=17

That seems reasonable enough right? Just 3 times the supposed estimate. Small enough for Steve to sleep soundly that night. However it is not the end of the story for Brent.

Stage 4: The Aftermath

Brent now needs to context switch back to what he was doing before the interruption, he needs to regain his train of thought. This is an expensive task, as humans are not efficient at context switching. It may take up to 20–30 minutes to get back to the same mental space he was in before the interruption. Assuming Brent is good at context switching, lets call it 20.

We are now at T=37. But at least that is the end of the story. Right?

If the job was done flawlessly then maybe, unfortunately it was likely done in a rush, so that can’t be guaranteed. The work will inevitably have a few defects in it and may require some rework. If this is spotted by Steve then we need to do the whole thing again. Interrupt Brent, make the same arguments of priority, do the work, then context switch back.

This brings us us up to a total of T=74. An hour and change, to do a 5 minute job, that’s not so bad. Also we got it all this time, nothing missed and the work is done done, it will never need to be touched again…

Stage 5: The Infinite Loop

That is provided Brent didn’t use any form of technology to implement the job. This is where we hit one of the lesser known truths in IT, every line of code written and every tool used are not assets, they are a liability. The perfect job that was just finished can now blossom into beautiful technical debt.

It is going to need updates to its parts, it may need to move platform over time. It will fail, break and eventually fade to the point of obsolescence. All of which will come back to Brent to rack up the T count, again and again. Over its lifetime the job could consume countless hours of Brent’s, Steve’s and other people's time.

Naturally the correct response to this is to curl up into the corner and realise that life is an endless battle against entropy and there is no point in doing anything ever again. However the point of this is not to make people despair into inaction but to look at realistic ways of reducing the T count of a piece of work, keeping it at a more manageable number, through some pretty basic acts.

Agile has you covered

One of the most common ways to help is a backlog of work, this is what all the proponents of Agile methodologies espouse. This is where Steve does his fact gathering for Brent, usually in the form of a user story, following the standard; “As a (Steve’s role), I want (the thing the jobs does), so that (I can get the value from the job)”. This formalises the talking and requirements gathering of Steps 1 & 2, so that Brent doesn’t need to be disturbed up front.

Putting the details into a user story should enable Steve to think through exactly what he wants the job to do (Acceptance Criteria), what the life cycle of the job would be, make a rough guess at how long the job might really take (Sizing), including some time for Brent to rework it where things are unclear (Capacity for defects). With this Brent will be able to take the work item from the backlog, spend a minute or two reading it and ideally be able to implement it in the 5 minutes, completing the whole thing in under 10 mins, first time.

In a mature organisation Steve could also put work items further down the backlog, like maintenance tasks, cadenced upgrades and even an obsolesce task for when the job will no longer be needed.

This can seem daunting when trying to solve a simple problem that should only take 5 minutes. If it is the first time this is being done, it will likely take some thinking and a lot of effort. However as time goes on and more of these requests are made, a process will naturally form around it. The team or individuals will create templates for the request, embed checklists of things that need to be followed while implementing it and in many cases automate away the need to do the work at all.

It won’t happen overnight but as an organisation matures these processes will evolve and work will flow. As it does this can actually free people up to have more time for informal conversations with one another, as they are not being distracted by requests.

Working Agreements

Another useful tool is to create working agreements on how best to engage people in a work context, e.g. when a person can be contacted and by who. Again Agile has out of the box answers of Product Owners that manage the teams backlog and Scrum Masters that protect them from interruption, however even they can fall short of protecting teams from everything. People continually interact with one another and a corridor conversation can easily kick off this one of these requests.

The only way to truly protect engineers time is to have good working agreements that everyone follows. Adherence to the practices in Agile, where all work comes through the backlog is a powerful one, but this can also be done outside of Agile frameworks. Simple agreements such as “no meetings before lunch”, “don’t interrupt me if I have headphones on” or “no email Fridays”, can be discussed, agreed and formalised. From these everyone can just get on with work, distraction free.

Agreements can also be set on how frequently technologies should be upgraded and when something should be shut down. Even within an Agile framework, ensuring that all the parts are kept well oiled is a difficult business and can only be achieved when there is a written agreement on when to do it.

Turning things off can be even more challenging, people can become quite sentimental of these jobs and even though it breaks every day, as long as you know the trick to get it back running there is no issue. Having defined agreements on measuring when something costs more to maintain than it brings in value are essential. They allow us to cut through any opinion based argument to keep something around that has long outlived its usefulness.

The Human Factor

Lastly the single biggest thing that can make an impact is simply respect and empathy. Understanding that the other person, is a person and not a machine. They have a life, they need to eat and sleep. They have their own priorities, workload and goals.

In every organisation everyone has their role to play, many do so in service to others. By ensuring that they get their work done, they ensure that others can do theirs. Much of this goes without anyone noticing but when making these “simple” requests, it is worth taking the time to think through the steps above and whether they are fair on the person or whether there is a better way.

It may only take 5 minutes to unlock the doors to the building but unless it is done every day, at the right time, without distraction, we would all notice very quickly that something important is missing.