While continuously refining roles and information flows in an organization, covering the regular and non-erroneous situations is usually a handful. Nonetheless, dynamic scenarios and anomalies are a regular thing for most companies and, as a consequence, they end up being handled ad-hoc. Or not handled at all.
In programming, when faced with anomalies or erroneous situations we have a great construct to handle those effectively and clearly: exceptions.
The sink is clogged
I was baffled at how, at one point, most people in the office knew about how the sink was clogged, yet no one had raised the issue. It became clear that it had not been a case of dismisiveness or volunteer’s dilemma, since some handy people took it upon themselves to fix it – unsuccessfully. And it seemed that no one wanted to bother us with something so mundane.
Yet it remained unsolved.
It brought me to different situations we had seen in the past, and I started to realize that one common thread was the fact that it was not business as usual. At the same time, I noticed that:
- It was unclear if that was something to be raised and how.
- There was no guidance on handling exceptions since it makes for a highly bureaucratic environment to be as detailed.
Framing these scenarios as Exception Handling can make it useful for teams and leadership to provide lightweight ways to have prompt and effective responses should they need so. And unlike “If you see something, say something”, it drives autonomy in some cases. Some exceptions must be handled locally.
Thoughts on implementation
Exception Types
Having some distinct Exception Types will enable everyone to confidently channel anomalies to the right person without too much noise and overhead. The balance to strike is not having too many Types, as it becomes a burden on the raiser, nor too little, as it becomes a burden on the handler.
That effectively changes over time and size and sometimes there’s no Type and there should be a “Generic Exception” case – as there normally is.
Raising
Be clear on the importance of raising things (and the volunteer’s dilemma) and how. The “how” should be easy (Trello, Mail, Slack, All-hands) to avoid delays. Tuning what’s an anomaly that we care and which is not takes time and examples, so be patient.
Asking for solutions might get in the way of knowing about problems.
Propagation
Much like exceptions, not everything reaches the top. Some types will propagate more than others, and that should be made explicit. There are different criticalities and sometimes handling those in a closer scope is what is expected.
Handling
One concern that you might have is that many things are not worth the effort to solve, so you might get overwhelmed. And I agree, but I think it’s a great opportunity to have an opportunity to state a brief rationale.
Exceptions are normal
Don’t get frustrated with exceptions, as they are a normal part of any organization and the world. Having a lightweight, not heavily structured mechanism to deal with that is a great tool for agility and autonomy.
Juan Saavedra 