One of our heroes, Eddie Jaoude, asked us to give a behind-the-scenes tour of how we handled a recent user-identified bug.
So in the spirit of learning in public, here’s how a code quality company dealt with a code quality issue.
As I wrote up the explanation, I realized that our decisions on handling this bug stemmed from our five company values: #growth, # excellence, #scrappiness, #competence, and #ownership. So I’ll talk about those too.
Let’s dive in.
The first step was learning about the bug.
One of our five core values is #growth. We want “bad news” from all sources, inside and outside of the team. We try very hard for bad news to be received blamelessly, it makes us and our product better.
So we have put together as many possible ways for users to contact us with issues and concerns as we can think of, UserVoice, Twitter, email, the Intercom button (Go ahead, try it…).
Goal is to be frictionless for users to share whatever’s on their mind.
In this case, we got a screenshot via Intercom: a modal on our Chrome extension did not look right in one of GitHub’s five _sweet_ theme preferences, specifically in one of the dark modes:
A good indicator for how a company thinks about code quality is who reads the bug reports and who handles customer escalations.
Slack’s CEO personally handled customer support for the first 5,000 users.
And consider Amazon’s customer escalation path:
Here, I read every bug ticket and feature request and propose a prioritization to Engineering.
Back to our values: two more are #excellence (solving for quality) and #scrappiness (solving for the tradeoff of sufficient quality and speed).
These are indeed in tension. We believe, as Hillel has said, that values only mean something if you have to give something up to achieve them.
One of the hardest things about managing bugs/ tech debt is messing with Engineer’s flow.
Bug fixing *now* slows down arriving at a great overall code quality product *later.* Context switching is a killer for engineers.
On the other hand, building the best possible experience is critical to the specific problem we are tackling.
Code quality tools must work exactly right or we lose the privilege to be part of the development process.
With all of that context… phew…
The specific prioritization factors for this one were: the relative engineering difficulty was low, impact to the user experience was medium-high (as a “miner’s canary” of potential lack of attention to detail).
In practice, we assume a meaningful amount of slack in each sprint for bug fixing. And it is always ok here to push off releasing features for a great developer experience today.
This bug was added to the top of the current sprint board in Ready for Dev.
An engineer worked on the ticket…
… then it passed code review …
then it passed QA, and was released shortly after.
Voila:
We then told our user to close the loop. This relates to the fourth value, #competence: we meet our commitments or acknowledge they are not met. [The opposite of competence is finessing, or hoping that someone forgets].
We may not be able to fix every bug or act on every roadmap suggestion, but our users will always get an answer and an update.
More fun, obviously, when the update is good news. ;0
Lastly — this whole process ties to our fifth value, #ownership.
Ownership means two things to us: first, we have shared responsibility for getting things done.
We nurture an overdeveloped / shared sense of responsibility. So code quality is an issue for all of us: Design, Product, Engineering, QA, DevOps, Growth, me.
Second, we try to make every decision as owners of the company and the product: what’s the right thing for both?
These are not idle words: “right thing for the product” could mean asking Engineers to work every weekend to fix bugs. But that’s the wrong answer for our company.
Given the tradeoffs above, I think we made the right call here.
/end
