4 min read

A Disturbing Development

A Disturbing Development
I'm a sucker for both the art and music of Disturbed. All credit goes to them I assume.

The people that I'm responsible for do all sorts of amazing things.

But I don't always get to see of understand those things, because I'm typically operating at a different level of abstraction. A level that is a few steps removed from the actual work that is happening.

I think that lack of understanding does a disservice to the day-to-day operations of the team. The set of tasks and responsibilities that every person needs to be capable of doing to keep the machine working.

Like how to be disturbed.

Ten Thousand Fists

The role of disturbed is simple: someone who acts as the shield for the rest of the team. They are disturbed so that others can focus.

The role covers off responsibilities like:

  • Responding to alerts
  • Proactively checking dashboards
  • Answering questions from internal teams
  • Fulfilling requests from external teams
  • Executing on small, incremental improvements unrelated to projects

For my team, it's a role that is only in effect during normal business hours. We have a separate on-call role that responds to critical events outside normal business hours but it's somewhat irrelevant to this conversation.

The disturbed person rotates on a weekly basis, and there is a roster that everyone in the team is expected to be a member of. It wouldn't be fair if it was only a subset of the team who got interrupted.

Maintaining a balanced disturbed roster is so important that qualifying for entry into it is one of the first things that new starters must do. It's the first big goal, and must be accomplished within their first quarter.

The disturbed role has a bunch of different benefits:

  • It allows other engineers to focus without getting interrupted
  • It maintains an appropriate standard of operational support
  • It creates a feedback loop for building good, easy to support tools and processes

But it's not perfect. It comes with some downsides as well:

  • It is fundamentally different from software engineering (reactive)
  • It can be very exhausting depending on load
  • It requires a wide breadth of knowledge from the person in question

At this point, I like to think that I know a fair bit about the disturbed role. After all, I've been managing the team for over two years now.

But I don't think I understand it.

Inside The Fire

Most of my knowledge around the disturbed role has been gathered from a safe distance. I understand it through the experiences of others. I see the impact and effect of the things that they have to deal with.

But I haven't lived the experience.

There is a world of difference between understanding something conceptually and actually experiencing it. Subtle nuance that is lost in translation, and emotional or mental impact on the person in question that is muted because it's happening to someone else.

That's not good enough.

So, it makes sense to me that I should find a way to get into the disturbed roster myself. To follow the same rules and processes that everyone else does. To experience the same pain and pressure.

Down With The Sickness

I can see a lot of obvious benefits to qualifying for the disturbed roster.

The first is empathy generation. Disturbed is a big thing that my engineers need to deal with, so the more I understand the role and exactly what it entails, the more empathy I will have for the people who I require to do it.

Empathy is an important thing to cultivate when you're responsible for people. Hell, its important even when you're not directly responsible for people, because it allows you to put yourself in their shoes and really get a sense of whether or not you're making their lives easier or harder.

You should be aiming for easier.

The second benefit is identifying improvements. As someone in a position to make decisions, the more I understand the disturbed process, the more likely it will be that I can propose improvements or optimisations.

Yes, the engineers themselves are almost certainly in the best position to propose improvements, but I can benefit from a different perspective. It's less likely that I'll get lost in the weeds of actually doing the role, thus forgetting to take a step back and analyse why it's difficult and exhausting.

The third is technical knowledge. One of the reasons why getting into the disturbed roster is the first thing that every single new-starter accomplishes is because it forces them to understand the systems and processes within the team from an operational point of view.

I could benefit from that knowledge as well.

It's not like I don't understand things, but there is a depth of understanding that is lacking as a result of not having to actually do the operational side of things. I know how our migration system works conceptually, but I've never needed to debug why a migration failed for example. That seems like a useful skill.

The last is to be able to act as an emergency pressure valve. This one is a bit of a stretch and assumes that I'm going to be both competent at the role, and available when necessary, neither of which is guaranteed.

But I could conceivably act as a gap-filler when times get tough, or when the team wants to focus on an innovation week or just when I want to give someone a break without disrupting the other work that is happening. The possibilities are endless!

Obviously, it's not all puppies and rainbows, because getting into the disturbed roster would be a real investment of my time and mental space, one that does not necessarily line up with my high-level responsibilities as a manager.

It's a bit low-level when compared to things like painting a vision of the future or growing and scaling those around me.

Still, it sounds worthwhile to me.


Similar to last week's post about educating myself on psychology, this is another blatant attempt to motivate myself to actually do something.

I've wanted to get into the disturbed roster ever since I started, but it's perpetually a few items from the top on the priority list.

It's obvious that I can't commit the time to follow exactly the same onboarding process that everyone else does. Not with all of my other responsibilities.

But perhaps I can approach it like I do shadowing other managers.

Carve out a week each quarter to shadow the disturbed person. Treat it no different to any other shadowing and focus on it entirely.

I still get all of the benefits that I want, just over a longer period of time.

But that's okay.

I'm nothing if not patient.