If a tree falls in the woods and no one is around to hear it, does it make a sound? While it’s an interesting thought to ponder, the short answer is: Yes, it does.
A murkier (and more valuable) question to ask is: If an incident occurs, and it’s not tracked (or accurately reflected in your metrics), will it impact an engineering team’s ability to maintain efficiency, deliver projects predictably, and align to business priorities? The short answer: Also yes*.
*The downstream impact isn’t readily known and it’s not until leaders have a complete picture that they begin to understand how incidents affect engineering operations.
And that’s why it’s so crucial to have accurate, holistic visibility into incidents like bugs, outages, service degradation, security concerns, and what team(s) are working on them. In this blog, we’ll explore how to do that with LinearB and deep dive into how it can help you improve key impact metrics–like MTTR, CFR, and the effect they have on engineering investments–by ensuring simple, flexible visibility into engineering effort spent on incidents.
Engineering Data is Messy
A key consideration for engineering teams is ensuring incidents are tracked accurately. This is crucial for three reasons:
- Determining overall quality of releases
- Conducting root cause analyses when something goes wrong
- Ensuring that engineering is focusing time and money on initiatives that drive value
This may come as a shock (insert sarcasm) but tools like Jira don’t have a sterling reputation for data hygiene and accounting for all work being done. The reasons for why this is include:
- Jira requires discipline and constant care to be a good source of truth–and no one likes data entry
- Tooling inconsistency–some teams don’t keep incident data in Jira, preferring tools like PagerDuty or Bugzilla. And some even use Jira AND other tools
- Manual effort and knowledge barriers–the “best way” to track issues and incidents in Jira is to create custom workflows
And beyond the tool consideration there is also the fact that incidents are categorized differently depending on the org, team, business unit, and how they work. As an example some organizations track incidents as tasks and issues, others use things like custom fields and labels. This variance makes it difficult to quickly quantify and optimize how much time, effort, and money is spent on issue resolution (instead of aligning to business priorities like creating new value).
Benefits of Flexibly (and Accurately) Tracking Incidents
One of the most tangible and immediate benefits of better visibility of incidents and how much time and money you’re devoting to them is the ability to optimize your engineering investment and resource allocation strategy.
With an accurate, highly flexible incident management tool, a clearer picture of engineering’s investments begins to form. Incidents–like bugs and security issues–will likely be bucketed into KTLO (work that needs to be done in order to maintain SLAs, continuity, and keep the company operational). Used in combination with Investment Benchmarks, you’ll know exactly how much time you’re spending on incidents and how much time you SHOULD BE spending on them according to industry data.
In addition to driving better business outcomes, LinearB helps with data accuracy and hygiene–no more worrying about whether functional bugs, technical bugs, or security issues are categorized and reflected correctly in Jira. LinearB also enables retroactive reporting of incidents after they've occurred, ensuring you can report appropriate/correct timestamps.
Another benefit of increased data accuracy is easier root cause analysis when things go wrong. This has a big impact on a company’s bottom line, because when downtime occurs, minutes matter. To get more granular information–easily accessible from LinearB–just click a spike in your Metrics view or go straight to Activity to see the incidents in your pipeline.
Last but not least is the freedom and flexibility that comes with enabling hybrid organizations that want to use Jira, other incident tracking tools, or any combination to work their way–without the FUD of not maintaining visibility into the work being done.
Incident Tracking and DORA Metrics
DORA Metrics–Cycle time, Deploy frequency, CFR, MTTR–are crucial, foundational indicators of engineering health and efficiency. When working to set up an engineering metrics program, DORA metrics are considered table stakes. In fact, LinearB gives away DORA metrics.
When teams leverage LinearB as an incident tracking tool, they can go a level deeper. CFR and MTTR are the DORA metrics most impacted by incidents like technical or functional bugs. Too often, tools just stop at “here are your MTTR and CFR values”, without showing you what is contributing to those stats.
LinearB offers more visibility and granularity so you can take action on the work that’s contributing to these values. It also increases accuracy of these metrics as it doesn't rely on manual inputs and uses telemetry from common issue tracking tools in addition to Jira.
Cleaning Things Up
With LinearB and its Incident API, holistic incident visibility, management, and optimization is easy to attain because it doesn’t require engineering organizations to change their ways of working with Jira. In fact it enhances your use of Jira by making it another data point rather than the entire source of truth. There are no required changes to Jira structure, no special organization of issues needed.
LinearB helps reduce the burden and ensure 100% flexible/customizable/self service visibility into your issues–whether you use Jira, PagerDuty, Bugzilla, Datadog, other issue tracking tools, or some combination of all of them. Simply put, LinearB is the most flexible incident tracking tool because it supports:
- Choice of detection method (API or tags)
- Detection method selection at the team or group (team of teams)
- Date and time custom fields
And we’re always working to further improve the solution!
Pro-tip: We recommend using the REST API for the highest degree of data accuracy, reduction of manual work, and more flexibility in how work is structured for scaling organizations that have issues spread across BUs/departments/tooling.
- Generate an API token by following the instructions here: https://linearb.helpdocs.io/article/79fmogrxw3-how-to-generate-release-api-tokens
- Go into your Company settings and select “API Integration” as your incident detection method
- Select settings at the Organization/Company level AS WELL AS the team and/or group level
- Select which issue types, severity, custom fields, labels, and other filters you want to use to calculate CFR and MTTR (DORA metrics and KPIs of release stability and quality)
- Use this REST API to create, update, search, and get incidents in LinearB
We’re working to make LinearB incident management capabilities and DORA metrics even more powerful, flexible, and granular by adding an all-new metric to LinearB: Mean Time to Detect (MTTD). This planned enhancement makes use of the “impacted_at” and “issues_at” custom fields to break down how quickly a team is able to detect an issue in production and begin taking action.
This will provide teams with more detail and granularity for MTTR–offering another dimension to the overall quality and stability picture and helping teams better understand MTTR.
In addition to the MTTD enhancement, we just released support for tracking incidents via custom fields. Ensuring maximum flexibility is an ongoing investment priority and we are committed to continuously improving LinearB and ensuring it remains the best incident management tool available.
You can get started today with LinearB as an incident management tool on a Business or Enterprise subscription.
If you’d like to see these features in action, schedule a demo with one of our experts.