Don’t kill the Messenger — Incident response teams and the culture of their organization

Joel Lindow
Nov 8 · 4 min read

The software industry is jam-packed with brilliant people. Nobody is questioning that. However there are are many people involved in every software organization that contribute to customer success, timely delivery of features, management of defects and handling Production Incidents. These people may not be the strongest technically skilled individuals within an organization, but the services they offer to a software company are an important piece of the organization as a whole.

However, many software organizations that tote an inclusive and mindful culture have a blind spot that is rarely addressed or taken seriously. When you’re not delivering features, tweaking the code base or knocking out user stories… sometimes you’re seen as a second class citizen among kings and queens. The recognition of the value these people bring is extremely important and should be a part of the overall work culture.

Sure, you hire rock star developers and make sure they know how great they are… but what about the unpopular people who have the task of logging and presenting production defects, alerting teams to production outages or rounding up SME’s for sensitive issues that require a timely solution? Are they rock stars at the role they play? Are they seen and treated as a burden on your insulated development teams? Although unpopular, does the technical debt they recognize give areas where true improvements could or must be made? Do they advocate for the capacity of your developers and their scheduled sprints? Do they protect your production environments and strive for acceptable Mean Time To Response from SME’s (Subject Matter Experts)as well as help push for a timely Mean Time To Restoration of the production environments your applications live in?

Most likely, if you’re honest with yourself, the answer to all these questions was “Yes”. So why do these people typically receive such strong pushback? Why are they blamed for development teams being beyond capacity or unable to deliver scheduled work? Why is the work that these team members do seen taken so personally by people that simply want to “release new features” and nothing else? Why do these people experience culture related burnout quicker than most people in the organization? After all… these people are simply the messengers that deliver the information needed to harden and improve the application you’ve worked so hard to provide to your customers. Aren’t these people basically the watchers on the wall who identify issues on the horizon?

Here’s a suggestion: Include these people in discussions with development teams. Invite these people to your planning events. Make these people a part of your developer family. With regular communication you will be able to get a quicker vision of the areas in your applications that might be blind spots. You also just might build a culture that recognizes these people as equally valuable parts of the development process that your developers are so proud of.

Another suggestion, while we’re throwing ideas at the wall: Be realistic and leave room in your sprint capacities that will allow for your developer teams to actually handle issues that come in from your Production Support and Incident Response teams. No developer wants to be 4 days into writing a complicated feature, with another one lined up immediately after, and no room to break away to fix something that’s wrong with a feature that written 6 months ago and is now acting unreliabliably or acting tempermental. If your developers don’t have the capacity to handle incoming defects and production incidents… well… they’re going to start burning out, working too many hours and also not delivering scheduled work in a timely manner. Beyond that their work will be rushed and most likely not be given the time it takes for them to apply the critical thinking that they, as rock stars, need to deliver good solid code.

Keep in mind that the people in your organization are all 1 big team. It shouldn’t be tribal. It shouldn’t be egotistical. It shouldn’t be resentful. It should be filled with great communication, accountability and recognition of the importance of every team members role.

So, yeah! There’s a lot more to unpack around this subject but this is a great place to start thinking about how you see your support staff and how your organization treats interacting with them. These people are usually extremely passionate about advocating not only for the end user but for your development teams capacity. However, they do not control the developers scheduled capacity nor do they create the defects / incidents that they encounter. They are simply the messengers.

Don’t kill the messengers. They’re simply doing their part.

Joel Lindow

Written by

Advocate for End users as well as Developers within the Software Industry. Believer in strong and healthy work culture.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade