Interrupt-driven engineering: Working on what matters at Aha!

On the Aha! team, The Responsive Method (TRM) guides our interactions with customers and one another. Responding to requests quickly and thoughtfully maximizes the value we provide to customers and is a key pillar of our success.

Part of this responsiveness involves what we call being "interrupt-driven": treating interruptions as a useful stream of information rather than an unwelcome distraction — and embracing the chance to help others when their attention is on the problem at hand.

Narrow focus vs. wider impact

Some engineers are suspicious of the interrupt-driven principle at first. We're on the maker's schedule, and we need unbroken focus time! Being expected to respond immediately to interruptions sounds like a recipe for a scattered mind and shallow impact. And after all, isn't the job of a good manager to shield their engineers from distraction?

The problem with this is that no one can do their best, most impactful work by blocking out the outside world.

Code and other technical work are only as valuable as the problems they solve, and the worst way we can use our time is by building the perfect solution to a problem nobody has. So it follows that we must pay attention. The best engineers embrace this truth.

It's not just engineers who do deep work

Managers also need time for deep work. The most effective engineering managers don't spend all their time shielding their teams from external requests, batting away the unimportant and bundling the critical items up for the weekly meeting. Instead, they take a bigger-picture view of the work and people involved, have a broader understanding of the technical domain, and spend plenty of time deeply focused on their own work.

Ensuring collective gain

Everyone on the team has their own areas of expertise. Sometimes, a few minutes' worth of insight can save hours for a less experienced engineer or days of frustration for a customer. Does that sometimes come at a cost to the engineer's focus on their own work? Of course. But the cost varies, and so does the benefit. So being interrupt-driven is absolutely the right approach when the collective gain outweighs the personal cost — and it frequently does!

How does being interrupt-driven work in practice?

Just like product managers, engineers need to think carefully about how to manage the stream of interruptions and tackle tasks that arise. So what does interrupt-driven engineering at Aha! look like?

1. Sharing the load

Because we recognize the cost of context-switching, Aha! operates an engineering support rotation. Each engineer, regardless of role, spends a week every couple of months responding to escalated tickets and fixing bugs. This frees up the rest of the team for deeper focus.

2. Maximizing our impact

Principal engineer Justin Weiss, who led development of our real-time text editor, says this of the editor's code:

Because I was the one who knew it best, people would regularly come to me for questions about the editor. I'd frequently jump on calls (some quick and some spanning hours) to help share enough of the foundation so we could arrive at the solution together.

Not every engineer has led a project like this, but every engineer spends much of their time working on features. So being interrupt-driven offers opportunities to help others who are less familiar with a specific area.

3. Understanding true urgency

Distinguishing the urgent from the important is a critical skill to develop. For example, a colleague might ask for a review of the large pull request they've been working on for several days. This is important work, but it'll take time to address properly. Besides this, they probably don't need it reviewed right now — so it's fine to let them know you'll finish your current task and look at it later. On the other hand, a pull request that addresses a production bug should usually be reviewed straight away.

It's worth noting here that the common advice to turn off notifications optimizes your own productivity at the expense of the wider team's. Working this way takes more discipline than just blocking out the noise. But after all, meaningful work is rarely easy.

4. Focusing on customers (and teammates, by extension)

Staying aware of customer requests is a great way to help not only customers, but also teammates. A support escalation might relate to something you fixed recently, for instance. Another engineer could spend hours tracking down the root cause. But you know exactly where it is, so you can save time and frustration by simply assigning it to yourself.

5. Knowing when to say 'no'

Being responsive is different from being reactive. It means responding thoughtfully, but not agreeing to every request. Imagine that a customer wants a feature addition to support their specific workflow. After consulting a product manager, you respond by explaining why we don't plan to make the change, but suggest a workaround or alternative approach.

Why it matters

You'll notice a common thread here. Not everything is addressed straight away, but every request gets a prompt response. Requesters aren't left wondering, and we always choose to spend our time in a way that maximizes value. That sometimes means switching tasks, but only if the trade-off is worth it. Additionally, this should be of the engineer's own volition — never dictated by shifting priorities outside of their control.

This means every person on the other side of the equation has a good experience. They either have their immediate needs met or gain clarity on when they can expect help. And in every case, we strive to maximize the overall value to the organization, which is a great way to build a successful, lasting business.

Engineers (like everyone at Aha!) are encouraged to tune in to the stream of interruptions, honing the skill of picking out those where their unique skills and experience can make the biggest difference. This doesn't mean we spend all day watching Slack or that we don't have time to focus deeply on our work. It does mean we take an empathetic, pragmatic approach to choosing what we do with our time: one that maximizes our value and impact and contributes to lasting company and personal success.

Does this resonate? Join us.

If you're the sort of engineer who cares about the bigger picture, helping others, and doing high-impact work, you should consider joining us. In a time when the tech world is as volatile as ever, we're still happy, healthy, and hiring. Check out our open roles.