Sonya Siderova

Sonya Siderova's public writing circles around a single conviction: decisions should follow evidence, not assumption, and systems reveal truths that individual performance reviews cannot. Across her posts, this shows up as a set of self-described "operating standards" she returns to again and again. "I don't investigate hypotheses. I investigate evidence" captures the core discipline. When a team jumps to explanations for a customer issue, her first move is to stop and ask "What do we actually know?" , refusing to chase root causes until the problem itself is verified. The same instinct appears when work competes for attention: rather than debating priority in the abstract, she picks "what's closest to done" , because finishing fast means "learning sooner" and "confirming we were solving the right problem sooner" .

This evidence-first posture extends into how she thinks about metrics and estimation. She describes an exercise that changed how she sees story points: plotting estimates against actual delivery time and finding no real relationship, since "one-point stories sometimes took more than 20 days" while "eight-point stories were sometimes delivered in just 4" . Her conclusion is that "the problem was assuming effort time and delivery time is the same thing" , because customers aren't asking about effort, they're asking "when will I have it?" . This logic underlies her broader skepticism of upfront estimation as a management tool. She recounts refusing to have thirty work items estimated before work even started, telling leadership "you can't count on my support for this insanity" , because she'd learned that such estimates inevitably harden into commitments and plans regardless of how much changes along the way .

A second recurring theme is her distrust of visibility for its own sake. She rejects the idea "that the more we can see, the better we can manage," arguing instead that "better management comes from helping people see the one thing that deserves their attention right now" . This belief shapes her advice to teams just starting with flow management: ignore cycle time, throughput, and forecasting at first, and instead "open the Aging Chart and look at the work that is already in progress" . The point isn't more dashboards but better questions, shifting conversations from "who is responsible for this?" to "what is preventing this work from moving, and what can we do together to finish it?" . She's seen this shift happen in real time with clients, describing a call that began with someone wanting to understand developer performance and ended with her turning attention to aging work and process bottlenecks until the client herself said, "maybe that's actually not the right way to do it" .

Her thinking about workflow design has visibly evolved, particularly on the subject of blocked columns. She admits she "never questioned having a blocked column" for years, treating it as an unremarkable default . Later she came to see it as "one of the biggest workflow design mistakes" she made, because it let teams stop feeling responsible for unfinished work, broke delivery data by letting items restart without an honest start-to-finish record, and killed motivation through a cycle of "start, stop, restart, pause" . The deeper realization was that moving a card to a blocked column didn't actually reduce work in progress, it just relocated it "somewhere WIP no longer counted" . This kind of retrospective correction, naming a past practice as flawed and explaining exactly why, is characteristic of how she builds credibility for her current positions.

Incentives and commitment-making form another throughline, tied closely to her account of being "a people pleaser" who used to say yes to every date and request, "the result was predictable: we overpromised, we underdelivered, my teams burned out" . That experience hardened into a refusal to negotiate: "I don't commit to anything the evidence doesn't support" , even though she acknowledges this makes disappointing people "the hardest part" of her job . She extends this ethic to how she treats people versus institutions, drawing a clear line between a delivery driver failing to meet a promise he didn't make and the restaurant that made it, tipping the driver but crossing the restaurant off her list "for good" . The same distinction between individual and system responsibility recurs in her account of a four-day workweek experiment that "completely changed how I think about incentives," reshaping her decisions since then about goals, compensation, and how success gets measured .

Concretely, her recommendations for others managing engineering teams are consistent and actionable: verify a problem exists before diagnosing its cause ; when work competes for priority, favor whatever is nearest completion to shorten the feedback loop ; treat story points as unreliable predictors of delivery time and look instead at actual flow data ; eliminate or rethink blocked columns because they hide rather than solve WIP problems ; and resist the urge to add more dashboards, instead surfacing the single signal that matters most right now . She backs these positions with real outcomes she's observed, such as a team that chose not to backfill a departing developer and instead improved its flow, cutting lead time "from 77 days to 19" over five months , and a partner whose board changed longstanding policies after just a 14-day trial once "they could see how work was actually flowing through their system" . The consistent takeaway across all of this is that Siderova treats management less as a matter of judgment calls and more as a discipline of building the right feedback loops, then having the patience, and occasionally the nerve, to act on what they show.