"Can you change the text on the signup button?" Asked Travis, from marketing.

"Not really, I am in the middle of a project. I can take a look next week when I am done" responded Anna.

"Come on Anna, please it's just changing text, how long do you think it'll take?"

"Ok, Travis you are right, it's 5 minutes I'll let you know when it's live"

If you have ever been a developer at a small or medium company, you have been in Anna's shoes. What is more, you can probably spot at least a couple of issues with this interaction.

Just in case, let me list a couple here:

• Anna has been interrupted by something without context and in a setting where she is not inclined to ask any

• If Travis asks this, what is stopping Eva or Bob from asking for similar things

• Once Anna has opened that door, it's complicated to say no to the next ones

• A lot of small quick fixes might get done, but the (hopefully) important longer projects get delayed ad nauseam

I believe in this article I can introduce to you a way to solve this, with the bonus of aiding to assign responsibility to those 'shadow' tasks that need doing but are no one's task.

The idea

Deliberately assign some team time (grouped or individually) where high-priority, small tasks are handled.

Some examples (but to each their own) of tasks that might qualify:

• Low impact bugs

• Wording changes

• Feature tweaks

The history

Sadly I must admit that the origin of this iteration of our (non)-revolutionary idea is lost to the fog of time. But I do know that when I got introduced to it, it had been copied from someone else. In the following sections, I will walk you through how I was introduced to the idea as well as how it morphed over several iterations.

Once a week we all dance for the king

I was introduced to this idea when working in Paris at Study Advisor.

Every Monday, the tech team would spend the day as the 'fous du roy' (King's jesters) and would handle the little tasks and bugs of the week. Well, to be honest... The tasks kept accumulating, but at least the most urgent ones were being handled.

Sadly, this presented some problems:

• Small fixes could turn out to need more than one day to fix.

• Every week the tech team would spend at least one day 'not advancing' on their projects (that is 20% of the time)

• It was taking a toll on the tech team members to 'drop' everything once a week and work on something else.

• Other teams within the company might still wait a week or more to have their needs met.

The next iteration of this idea fixed the identified problems

This court needs a rotating jester

The solution we found to those problems was to have a rotating jester, so one member of the tech team would be the jester for the week (yes, the whole week). A board would centralize the requests from the other teams and the bugs with a perceived 'importance' for the team and the jester would be responsible for prioritizing and fixing or implementing the small things.

The idea behind this was that at the limit, the tasks would not represent a week's work, so the jester would be able to advance on their assigned feature as well during the week.

Higher impact bugs got added to the purview of the jester, as they would be the ones shouldering the weight of the interruptions on behalf of the team.

While this iteration solved the previously mentioned problems, it uncovered a rather big one, what happens when there are too many high-impact bugs or the jester is not the best person to handle an issue.

A jester is not enough, let's call Spoc(k)

The next iteration of this idea was slow to come, I had left the team at Study Advisor, and at the company I joined (Yago) there seemed to be less of a need for such a figure.

Little did we know that one day one of us would take a vacation and it would coincide with a rather nasty (but seemingly) low-impact bug.

At that time we discovered that our teammate was not only handling his fair share of work, but on top of it, he was handling all the little bugs and modifications.

In our discussion as a team, I brought forth my experiences as a king's jester and we proceeded to implement the next iteration of the idea, but this time we would be Knight's, more exactly Single Point Of Contact Knights (because backronyms rock 🖖).

The Spock would have the same responsibilities as the jester previously had, but we added the fact that their responsibility was 'making sure things got done' rather than necessarily doing it themselves.

The Spock would primarily work as a single point of contact for bugs and requests, and although primarily they would be the ones solving the issues, they could call on other team members if they needed help or if someone else was better suited for the task.

And here concludes (for now) our story of kings, jesters, and Spock 🖖

Summary of benefits

• Low visibility or ad-hoc tasks are no longer anyone's problem

• 'Business' is more satisfied with the tech team as the team is less of a blocker for 'easy' changes

• The bigger the team, the less proportional time is devoted to low-impact tasks

• Making it rotational (I recommend weekly) makes it take less of a mental toll on the team

Potential fallbacks

• If every small task is 'of the utmost importance' prioritization might be a problem

• If a hand-off is not put in place between Spocks, some small tasks might be done twice or lost in the transition.