Last time, I introduced the Four roles your software team can't function without.
These roles are the four areas where I think software engineers need to go beyond just writing code and take on some broader responsibilities.
One of the busiest of these is a rotating role called the "Bug Warden".
What does a Bug Warden do?
The Bug Warden's core responsibility is triaging bug reports. This doesn't need to be a heavy, time consuming task. It can be as simple as delegating the investigation to another engineer:
However in practice there are a number of things the Bug Warden might need to do:
- Ask the reporter for more details
- Create a ticket in a project tracker
- Try to reproduce the issue
- Find a duplicate ticket, for issues that were previously reported
- Figure out which engineer should be assigned the bug, assign them, and @-mention them so they're aware of it
- Assign a Severity, a Release Status, and any other metadata your company is tracking
This is critical work which often falls through the cracks on teams, with Engineering assuming QA will do it, and QA assuming Product will do it, and Product assuming Engineering will do it!
What you need to track
There are a million ways to organize your bug reports, but in my experience there are two pieces of information that are critical to track:
1) Severity — A S0 bug should be worked on immediately, an S1 bug should be worked on in this release cycle, and an S3 can wait for the next cycle.
2) Release Status — Fixes often move through several environments on their way to production. So this status will either be the target environment (for a known issue) or the release environment (for issues that have been fixed):
- Fix in an upcoming release (dev)
- Fix in the current release (staging)
- Hotfix (production)
- Fixed on dev
- Fixed on staging
- Fixed on prod
These two pieces of information allow the Bug Warden and other stakeholders to make a variety critical decisions:
Should an engineer stop what they're doing and focus on a bug?
Does a release need to be delayed?
Are there fixes that needs to merged into the right environment?
If an S0 was a hotfix that went out to production, it may need to be back-merged to staging for further integration. If an S1 has been tested in the development environment, it may need to be pushed to staging.
These decisions can only be made correctly if you track the status!
Beyond bug reports
In addition to the core job of triage, the Bug Warden is also responsible for running three meetings each cycle:
Bug Warden Handoff (near the start of the release cycle)
The primary purpose of this meeting is to there are no lapses in coverage; that when your rotation is done another engineer picks up the baton.
Invitees: The incoming Bug Warden, and the outgoing Bug Warden
Checklist:
☐ Add the new Warden to a @bug-warden team handle in Slack, and remove yourself
☐ Make sure the new Warden is invited to the Cherry Pick and Retro
☐ Invite the next Warden to the next handoff
☐ Review any S0 or S1 bugs that might affect the next release
☐ Note any outstanding bug reports that still need to be triaged
Bugfix Cherry Pick (towards the end of the release cycle)
This meeting is a last chance opportunity to reallocate resources to fixing critical bugs before a release goes out. A product owner is invited so they can help the engineers understand what features are critical to ship in this release, and what issues are critical to fix before they can ship.
Often this is just a rubber stamp, but sometimes there is a critical bug that is blocking a release and at this meeting the team can raise a flag if more resources are needed to squash it.
Invitees: Bug Warden, Release Warden, and a product owner
Checklist:
☐ Quickly review any un-triaged bug reports
☐ Make sure all issues that need to be S1 are tagged as S1 and Fix in the current release
☐ Review all S1 issues to check if they have owners + will be ready for the release
☐ If the release is at risk, post in #releases-and-testing to let the team know what's going on.
Bug Retro (after a release cycle)
The last thing the Bug Warden will do is run a retrospective on some of the issues that came up. You figure out what needs to improve in your release process, testing, tooling, bug reporting, and triage.
This is a crucial feedback loop that drives your software quality up to where it needs to be.
Invitees: The Bug Warden, at least one engineer, a representative of the customer, and a product owner
Checklist:
☐ Choose a couple bugfixes from the release to retro
☐ Run through "5 why's"
☐ Note any action items
The Warden is busy
Although these handful of meetings might only amount to an hour or two per week, the actual bug triage process can take up a LOT of time for the engineer who has that responsibility.
Because of that, we always want to reassure the Bug Warden that their other development work can take a back seat while they occupy this critical role.
And it also means we don't want to assign someone who is under the gun to ship a critical feature as the Bug Warden. If someone is up for the job, and there is higher priority work for them to do, they should swap with someone else!
We can relax
Although it's real work for the engineer doing this job, the real benefit is that everyone can relax because they know someone is responsible for handling bugs.
When they're busy, the other engineers can safely ignore the #bug-reports channel knowing someone will ping them if they're needed.
Management can rest easy knowing that incidents are being investigated and the stability and reliability of the product is getting better every week.
Stakeholders from across your team know exactly where they can fire off a critical bug report to get immediate attention. And they know where to put more minor bug reports without causing a distraction.
In other words: we can all relax knowing the product is solid.
If it's still January 2025, and you are looking for an experienced Engineering Manager in San Francisco or remote... Hire me!
Part of a multi-part part series on "Software Engineering Roles"...
Follow me on X/Twitter to hear when the next part is posted!
- Part 1: Four roles your software team can't function without
- Part 2: If you have bugs, you need a Bug Warden
- Part 3: The Release Warden
- Part 4: The Epic Owner
- Part 5: The Program Manager
- Part 6: Checklists: How process gets better
- Part 7: Engineering Roles and Performance Reviews
Cover image ID 337353589 ©
Minirhenyx | Dreamstime.com
Top comments (0)