How do you keep your start-up running and fix emergency issues that crop up? How do you do it when you only have 3 developers?

That’s the problem we faced quite recently. The Way We Did Things Before™ is the way most small teams deal with issues: when an issue comes in, whoever is the expert in that area would check it out, with the help of the rest of the team.

This had a few issues:

  • The whole development team was interrupted for any issue, to figure out who should look at it.
  • Experts are a dangerous thing: they mean that parts of the system were only understood by a single person in the team. If they were to be hit with an industry-standard bus, we’d lose any knowledge of the system. The Way We Did Things Before™ made this isolation worse.

At one of our retrospectives we decided we needed to change this. So we did what any reasonable company would do: we bought a stuffed cat-unicorn hybrid.

A wild Pusheenicorn appears.

This is Pusheenicorn. It identifies as gender-neutral. It’s our Chief Support Officer, and it’s their role to sit on the desk of the Emergency Support Dude.

The Emergency Dude is picked in our morning stand-up. During the day, they can be asked by other parts of the business to deal with emergencies. Some days it’s busy, some days it’s not.

Does It Work?

We’ve been running this for a few weeks now, and it seems to work: other developers aren’t getting distracted by issues

One things we forgot to do initially was define what an emergency was. This led to a number of “emergencies” that were actually new features, or suggestions for change. In the end, we defined it like this:

An emergency is a technical issue of an existing feature that is stopping our customers or team doing what they want to do.

This works for us - anything that isn’t an emergency gets put into our product development pipeline.

So there we go: all you need to do support in a small team is get a unicorn-cat and throw it around a bit. Any questions? Let us know on Twitter.