The Bun Protocol

The Bun protocol is a lightweight, decentralized request routing protocol. It is designed to be the simplest possible way to handle requests that are shared by a distributed group of people. We use it mostly to handle incoming client requests.

The metaphor

Sia's Home baked Kanelbulle! Yum!

When a bun (= issue or request) comes in it is warm, juicy and soft. If it sits around for a day it will get cold. If it sits around several days it will become dry and hard. You can warm up an old bun in the microwave oven as long as it hasn’t become too dry.

So, a bun should be eaten fairly quickly or thrown away. No use stuffing it in a box. If you can’t eat it yourself, offer it to someone else – before it gets cold, dry and hard!

Sample buns

How the protocol works

A bun is born when someone asks you for something and you decide that “hey, this is a bun”. Typically through email, but sometimes a phone call or a conference mingle.

A bun always has an owner – the person who received the bun. Or more specifically, the person responsible for the communication channel through which the bun appeared. For example, you are of course responsible for any emails sent directly to you, while the office team is responsible for requests to, etc.

When you have a bun, you are responsible for taking care of it before it gets too dry! Preferably within 1 working day, definitely within 2.

You have 3 options:

The one thing you should NOT do is just let the bun sit and dry. Better to explicitly throw it away in that case (i.e. tell the sender that we can’t help).

So initially a buns appears through a “push” protocol, i.e. the initial recipient gets the bun whether he wants to or not. After that, however, everything is “pull”-based.

Summary of the rules

We don’t always succeed in following these rules, especially the 1-2 day age limit. But we really try our best, and we’re at least aware of when we fail.

Why it works

We’ve used the protocol for many years and it works really well. Here are some reasons:


Does this work for all types of requests?

We don’t know. But it has worked well enough so far, and we haven’t come up with any kind of request where it wouldn’t work.

What if several people want the same bun?

If several people are interested in the same bun, they talk to each other and sort it out.

Strictly speaking, the first person to take the bun has it, so in theory we have a race condition. In practice, however, when a potential conflict arises the involved people talk to each other (by phone or email) and decide on who should take the bun, based on who can serve the client best, who needs the bun most, and other relevant factors.

So being the bun holder doesn’t really mean “this is MY client”, it means more like “I’ll make sure this gets taken care of!” – (by me or whoever else is most suitable).

We get potential conflicts regularly (typically 2-3 people offering to take the same bun), but it is almost always resolved in a gentlemanly fashion, using good ol’ communication and trust between the interested parties. I help you today, you help me tomorrow, and in the long it run it more or less evens out.

The conflict handling process should help solve the edge cases.

What if it is a business-critical request? Shouldn’t some central authority handle it?

The closest thing we have to a central authority is the acting Finance Officer. If one of them received the request then, well, they already have it.

What if you received the request? Well, do you think it is business critical and should be handled by the business developer? In that case get in touch and ask her to take it from you. If you don’t know what to do, broadcast it to all Crispers (or even external partners that have bought into this protocol) and ask who wants to take it.

But don’t forget – the bun is still yours until someone else explicitly takes it from you!

But what if I accidentally throw away an important bun!?

Example: Customer X calls you and says they needs agile coaching. You respond “Sorry, but I can’t help right now.” But you didn’t know that your colleague Hans is available and could have taken this client, and you didn’t know that Customer X was an important strategic customer. Ouch.

You shouldn’t have thrown away that bun. Would have been better to email your colleagues and at least given somebody a chance to take the bun before you threw it away. Live & learn!

So, yes, you might accidentally throw away an important bun. But that doesn’t mean you have to :o)

Why not forbid people to throw away buns?

Sure, we could do that if we were very scared of losing important customers. But fear comes with a price tag. Sometimes we receive distinctly sour buns. “Can you help my dad install Windows on his PC”. Or “MAKE MONEY FAST $$$$$” :o)

What if all sour buns received by everyone were routed to the business developer or the whole team? That would be a horrible waste of time.

There is great strength in having “waste filters” at all inputs channels to the organization, so we can focus on the important buns rather than waste time on obviously sour ones.

Sure there is a risk that we might accidentally filter out some tasty buns, but that’s OK. Our guiding principle is “ask for forgiveness rather than permission”, and learn as we go.

What about traceability?

Traceability can be useful, for example we could write the buns into a backlog or CRM system or something. That doesn’t conflict with the bun protocol, we could just add that on top. But traceability has a cost. The overhead cost of each bun increases, due to writing & reading & updating information in a tool. So we don’t really prioritize traceability.

Won’t a bun get dry if it gets sent around between people for too long?

Yes. So keep that in mind when you pass around buns. Check the age, all emails have dates. Use common sense. If it is an urgent bun, it is getting old and you want to send to someone else, then call instead of sending email.

How do we avoid buns getting dropped between chairs

Be very clear in your communication. Short, clear phrases like:

We use the subject-line HELP! for all bun-routing emails.

What would be alternatives to the bun protocol?

Let’s say something important comes in, such as a request from a new potential client. Some alternatives to the bun protocol would be:

Nah, we like the bun protocol better. It introduces a minimum amount of discipline and rules without becoming a burden.

What are the potential disadvantages of the bun protocol?

Bun protocol -