> ## Content Index > Fetch the complete content index at: https://signal.happychases.com/llms.txt > Use this file to discover other available public pages before exploring further. # Building software that's allowed to be boring - URL: https://signal.happychases.com/software-thats-allowed-to-be-boring/ - Published: 2026-11-03T06:00:00.000Z - Updated: 2026-11-03T06:00:00.000Z - Description: Staff engineer Sarah Lindqvist has spent fifteen years keeping payment systems running at 3 a.m. She makes the case for dull technology, short meetings and the quiet heroism of the on-call rota. - Author: Maya Chen - Tags: Engineering, Interviews Building software that's allowed to be boring 0:00 /2940 1× Every time you tap a card at a coffee shop, a chain of systems you'll never see has to work perfectly in under a second. Sarah Lindqvist has spent fifteen years building and maintaining those systems. She is currently a staff engineer at a mid-sized European payments company, where her team is responsible for the part of the stack that, in her words, "absolutely cannot be clever." This week, Maya and Daniel sit down with Sarah to talk about why the most reliable software is often the most boring, what a healthy on-call culture actually looks like, and the hardest lesson she ever learned at three in the morning. ## In this episode - **00:00** — Cold open: the night the database ran out of disk space - **03:40** — What a staff engineer actually does all day - **11:15** — The case for boring technology - **22:30** — Innovation tokens and how to spend them - **31:05** — On-call without burnout - **39:50** — Writing incident reviews that people actually read - **45:20** — Advice for engineers early in their careers ## The case for boring Sarah's central argument will be familiar to anyone who has read Dan McKinley's widely shared 2015 essay "Choose Boring Technology," which she cites as a turning point in her thinking. The idea is simple: every new technology a team adopts brings unknowns — unfamiliar failure modes, missing documentation, fewer people who know how to fix it. Teams have a limited capacity to absorb those unknowns. "Boring doesn't mean old," Sarah says. "Boring means *understood*. It means that when it breaks — and it will break — someone on your team has seen it break before and knows where to look." > "Your users don't care what your stack is. They care whether the payment went through." She is careful not to romanticise stagnation. Her team does adopt new tools, but deliberately, a few at a time, and only where the new thing solves a problem the old thing genuinely can't. Everything else stays dull on purpose. ## On-call without burnout The longest stretch of the conversation is about on-call, and it is where Sarah is most passionate. She has seen colleagues burn out on rotas that paged them several times a night for alerts nobody could act on. She has also seen teams where on-call was barely noticeable, and she is clear that the difference is almost entirely cultural. Her rules, roughly paraphrased: 1. Every alert must be actionable. If nobody needs to do anything, it isn't an alert — it's a log line. 2. If someone is paged overnight, they start late the next day. No exceptions, no guilt. 3. The person on call is not expected to fix everything. They are expected to stabilise and escalate. 4. Every page gets reviewed weekly, and noisy alerts get deleted or fixed. "The goal is that on-call is boring too," she says. "A quiet week on call should be the normal week, not the lucky one." 🎧 **Signal is listener-supported.** Members get an ad-free feed, bonus episodes and early access to new interviews. [Become a member](#/portal/signup) — it's the best way to keep the show independent. ## The incident she'll never forget The cold open tells the story of a night, early in Sarah's career, when a database quietly filled its disk and stopped accepting writes. Nothing dramatic happened at first. Then everything happened at once. It took her team six hours to fully recover, and most of that time, she says, was spent not knowing what was wrong. What changed afterwards wasn't primarily technical. The team started writing blameless incident reviews — documents that focus on what happened and why the system made it possible, rather than on who made a mistake. Sarah now considers them one of the most valuable things a team can produce. ## Key takeaways - **Boring means understood, not old.** The value of a familiar tool is that your team already knows how it fails and how to fix it at 3 a.m. - **Spend novelty deliberately.** Treat new technologies as a scarce budget. Use them where they solve a real problem the existing stack can't. - **Alerts must be actionable.** If nobody needs to do anything when it fires, it belongs in a log, not on someone's phone. - **Protect the person on call.** A page overnight means a late start the next day, and the job is to stabilise and escalate, not to be a hero. - **Write it down.** Clear notes and blameless incident reviews are how teams learn, and how trust is built across a rota. - **Reliability is a culture.** The tooling matters, but the habits matter more: weekly review of pages, honest retrospectives and permission to delete noisy alerts. ## Transcript excerpt **Maya:** What would you tell someone who's two years into their first engineering job? **Sarah:** Learn to read other people's code before you get too attached to writing your own. Most of your career will be spent inside systems someone else built. And write things down. The engineer who writes the clearest notes is usually the one everyone trusts at three in the morning. ## Mentioned in this episode - "Choose Boring Technology," an essay by Dan McKinley - The idea of "innovation tokens" — a limited budget for new technology choices - Blameless postmortems and incident reviews - Service level objectives (SLOs) and error budgets ## About our guest Sarah Lindqvist is a staff engineer at a European payments company, where she leads the team responsible for transaction processing and settlement. She has worked in payments infrastructure for fifteen years, previously at a high-street bank and a small fintech that was later acquired. She mentors early-career engineers through a regional women-in-tech programme and writes occasionally about incident response. Outside work, she restores old bicycles, badly by her own account, and is training for her first long-distance cycling event. ## Credits Signal is hosted by Maya Chen and Daniel Osei. This episode was produced and edited by the Signal team. Our guest's views are her own and don't represent her employer.