To require or not require (fields): that is the question

Required fields have been a hot topic at FireHydrant. Choose too many (or the wrong ones), and you unnecessarily annoy your team during an incident or encourage sloppy data entry that someone has to come back and clean up manually. Don't use them at all and risk insufficient data to efficiently propel an incident toward resolution. But despite the controversy, required fields for incident declaration was one of our most-requested features — and it's now available as an option for configuring your instance. 

The debate within our product team centered around ensuring that we didn't build any impediments to people's first experience with the product, declaring incidents. We feel that 1) it should be as easy and intuitive as possible for anyone to declare an incident, and 2) teams must be able to capture the full scope of their incident from the moment something seems off. We considered whether required fields would force investigation outside of FireHydrant incidents. Or worse, push people to abandon the incident declaration process altogether. 

But there's a bigger picture: driving progressive reliability practices inside organizations. And that means working toward capturing necessary and accurate data from the moment an incident is declared. Ultimately, we believe that requiring a field or two upon incident declaration can play an essential role in improving an organization's overall maturity in incident management. If you're considering required fields as part of your process, we've got a few tips for ensuring that you can capture consistent incident data while promoting confidence and efficiency among responders. 

Align your team to your priorities

Many teams that wanted to implement required fields were trying to solve for inconsistent data entry when responders kicked off incidents. When we spoke to users about why they weren't populating important incident data, it became clear that this wasn't a usability or training issue but a confidence issue. Maybe they hadn't learned enough about the situation to determine a severity or were unsure who might get paged if they selected a functionality. 

Priorities for incident management can differ from team to team. Educating responders on what your values are is a great place to start. If your organization values declaration speed over accuracy, communicating that to your responders during training sessions and documentation will go a long way toward boosting confidence in the declaration process. If your organization places more value on accuracy, it'll be helpful to acknowledge that you're comfortable losing the initial period of documented investigation and skewing your MTTR. 

Introduce a 'triage' severity 

Configuring your severity levels to include a 'triage' option is a great way to bridge uncertainty. A triage incident can have less automation attached to it. Our internal team has set up the 'triage' severity only to open an incident channel (and signal to observers that we're not quite sure what's going on yet). The issue can be closed if it turns out to be a flappy alert or an acceptable level of degradation. No one got paged, no comms were sent out, and the person who declared the incident had a safe – and documented – place to investigate. As a bonus, triage incidents give your team data to help prioritize alert hygiene, responder training or other technical or process debt.

But what if something more is going on? Escalation in FireHydrant is easy; all you need to do is run /fh edit in your incident channel and upgrade the severity of your incident. Upon escalation, FireHydrant runbook automation will automatically remind responders to include the proper metadata through messages to the incident channel and DMs to the incident commander. We use triage incidents here at FireHydrant and have found them to be a low-impact way to evaluate everything from customer escalations to error reporting alerts.

Limit the number of fields you require at declaration time

Configuring required fields is your 'with great power comes great responsibility' moment. As with all forms, each required additional field increases dropoff or junk data significantly. We've found the sweet spot to be requiring severity and functionality. It's enough information to get the right people involved with the appropriate level of urgency. 

Get started

If you’re ready to require information in your incident declaration process, it’s simple to get started. Head on over to your settings and select which fields should be required at incident declaration. You can choose from eight different options including severity, priority, functionality, and description. We’d love to hear how it goes. As always, I’m available for your feedback at dylan@firehydrant.com.