If you don't go on-call for your customer, you don't own it

A few years ago, our engineering teams were drowning in operational noise. Dozens of pages a week. An unstable application. Customers noticing before we did. Operations had become a side hustle—something that happened to the team rather than something the team owned. We fixed it by doing the simplest and hardest thing an engineering organization can do: we made everyone carry the pager, including the managers, including me.

DevOps is not a role

DevOps gets talked about in a lot of different ways in engineering circles. Sometimes it's a skillset. Sometimes it's a job title. Sometimes it's a team that sits between development and infrastructure, absorbing the operational work nobody else wants. We take a different view at Dovetail. DevOps is a component of our culture. It's not something we hire for. It's something you are.

The principle is straightforward. You design it, you build it, you ship it, you own it. That sentence is easy to say and hard to live by, because "own it" doesn't end when the pull request merges. It extends to every moment the code is running in production, serving real customers, processing real data.

Two of Dovetail's company values sit underneath this. "Do the thing" is about bias toward action, stepping up when something needs to happen rather than waiting for someone else to take responsibility. "When we do it we nail it" is about the standard we hold ourselves to once we've committed. Applied to operations, the combination is powerful: we don't wait for someone else to fix the outage, and when we do fix it, we fix it properly. Those values aren't posters on the wall. They're how we think about the relationship between our engineering team and our customers.

The scale of what we're responsible for

This matters more at Dovetail than it might at a simpler product company. We're a customer intelligence platform serving a significant portion of the Fortune 500. Our product has over 100 features, more than 30 of which are AI-powered. We process massive volumes of unstructured customer data (interview transcripts, support tickets, survey responses, sales calls) in real time. The surface area is enormous, and the number of things that can go wrong on any given day is non-trivial.

You either build a culture that catches these things fast, or you build a product that slowly loses the trust of the people who depend on it.

What we changed

Before we made this shift, pages fired constantly. Engineers triaged them when they had time, which often meant they didn't get triaged quickly at all. Recurring issues sat at the bottom of the backlog because there was always something more interesting to build. Our customers experienced instability that we were too slow to notice and too slow to fix.

So we went all in. We reinstated on-call as a core expectation for every engineer, not an optional rotation that a few people volunteered for. We wrote it into position descriptions for engineers and managers alike. We put engineering managers on the rotation. I went on-call. We empowered managers to ensure their teams' systems were stable, and we measured operational health the same way we measured delivery throughput and quality.

The cultural impact was immediate. Engineers on-call for buggy systems felt the same frustration their customers felt. That proximity changed the conversation. People started advocating for time to fix recurring issues instead of accepting them as background noise. Reliability work stopped being something you justified and started being something you just did. Our product experience improved almost overnight—not because we hired an SRE team, but because the people who wrote the code were now the people who got woken up when it broke.

What about wellbeing?

There's a legitimate concern here. Asking people to carry a pager sounds like you're asking them to sacrifice their evenings and weekends.

But when everyone is on-call, everyone is incentivized to make on-call quiet. The same engineers who carry the pager are the ones who decide what to build next. They fix the flaky test. They add the circuit breaker. They push back on shipping something that isn't ready because they know they'll be fielding the alert at 2am on a Saturday.

Today, our operational noise is minimal. On-call at Dovetail isn't a burden people dread. It's a reflection of the stability the team has built together, and there's genuine pride in that. The rotation is light because the systems are healthy, and the systems are healthy because the people who build them also run them.

This is what ownership looks like

We didn't make this change to be tough on our engineers. We made it because we believe that owning your product, truly owning it, all the way through to production, is an expression of care. Care for our customers, care for the quality of your work, and care for your craft.

Do the thing. When we do it we nail it. Those two ideas, applied to operations, are why our product is as reliable as it is today. If you're leading an engineering team and operations feels like someone else's problem, it's worth asking: who actually owns your product? Because if the answer is "nobody, really," your customers already know.