Sonya Siderova

The through-line

Across these sources, Sonya Siderova returns again and again to one conviction: decisions about work should come from evidence in the data, not intuition, authority, or habit. She repeatedly describes situations where a team looked healthy by traditional measures (velocity, sprint consistency) but was actually failing customers, and where the fix came from looking at flow data rather than working harder [1][3][14]. Over time this position sharpens from "prove there's a better way" toward something more behavioral: she has learned that evidence alone doesn't change minds, and that people need to arrive at conclusions themselves by comparing old and new approaches side by side [5][15]. Her focus has also broadened from individual team metrics toward systemic accountability, arguing that when commitments slip or burnout happens, the system is at fault, not the person absorbing the pressure [4][11].

On evidence over intuition

Siderova's writing is full of moments where she distrusts an average, a velocity chart, or a stable-looking board until she sees the underlying distribution. She found that one team's "mean was 21 days" while the "mode was 1 day," with a long tail to 130 days, concluding "if you don't know the probability, you don't know the risk you're taking when you make that promise" [9]. She applies the same instinct to a Scrum team whose "sprints were consistent" and "velocity was remarkably stable" yet whose work "was taking up to 76 days to reach the customer" [14]. Her general rule: "This is exactly why I want to see the evidence before I make a decision" [3], and she starts diagnosing not by asking how to move faster but "whether they needed to" [3].

On accountability and the system, not the person

She repeatedly redirects blame away from individuals toward the systems they work in. On delivery dates: "they're still expected to own the commitment... we start questioning the person making the forecast instead of the system that makes the forecast unreliable. I don't think that's where accountability belongs" [4]. On burnout: "I think we've put too much responsibility for burnout on the people experiencing it... The problem is the system they're working in," adding from her own experience running such a system that "some of the most committed people were the ones who absorbed that pressure for the longest" [11]. She extends this to transformation efforts, arguing leaders should "make every change prove itself before you make the next one" rather than designing an end state up front and pushing through it [7].

On changing minds and letting go of old habits

Siderova draws on a personal story, her daughter's teddy bear, to explain why proof isn't enough to make people change: "I used to think that if I could prove there was a better way of doing something, people would naturally want to change. I don't think that anymore" [5]. Her method now is to run new approaches alongside old ones until people trust the comparison, as with teams at Doodle who didn't believe a probabilistic forecast until they "tested them against" their own estimates and found "the forecasts were proving more reliable than their own predictions" [15]. She applies the same principle to herself, describing her instinct to jump to newly noticed problems as something that "never came naturally" to overcome, since "every interruption came with a perfectly reasonable justification" [13].

On focus and simplicity in improvement

She warns against loading teams with too many concepts at once: "Most improvement efforts fail because people try to learn everything at once... Every metric becomes equally important. Which means none of them are" [10]. Her preferred approach is sequential mastery: "Give the team one thing to get good at. Make it a habit. Once that's under control, introduce the next capability" [10]. This same preference for simple, low-cost interventions appears when she finds that removing a waiting state could cut delivery time by "around 30%" with "no additional people, no new tooling, no pressure to work faster" [3], and when she resolves technical arguments by returning to "what problem are we actually trying to solve here" instead of comparing solutions [12].

From the stage

In podcast appearances, Siderova discusses personal practices and philosophy not covered in her written posts. She describes committing to "no work after 5 p.m., on weekends, or during holidays" as a game-changing boundary that improved her mental clarity and creative thinking, and let her "revisit her purpose" and bring her whole self to work while feeling energized rather than drained [16]. She also explains how she persuades business leaders to invest in process improvement by framing initiatives around concrete outcomes like delivery speed rather than data collection itself, and describes using "blocker clustering analysis," distinguishing active time from waiting time, and threshold-based dashboard metrics to prioritize which bottlenecks to fix [17]. She further states her belief, after six years in the market, that successful teams "solve their own specific problems by pulling solutions from various approaches rather than following prescribed methodologies," rather than following any framework "by the book" [18].

Takeaways

• When diagnosing a delivery problem, look at the distribution behind an average before trusting it; one team's mean of 21 days hid a mode of 1 day and a tail to 130 days [9].
• Before asking a team to work faster, check whether waiting time, not work time, is the real cost; removing one waiting state could cut delivery time by about 30% with no new people or tools [3].
• Frame delivery commitments around risk tolerance, not just a date, using confidence-based options like "10 days, with 70% confidence" versus "20 days, with 95% confidence" [2].
• To change how people work, let them compare the new approach against the old one directly rather than just asserting it's better, as Doodle's developers did before trusting probabilistic forecasts over their own estimates [15][5].
• In improvement programs, introduce one habit at a time, such as "never let old work grow older," rather than teaching cycle time, throughput, WIP limits, and forecasting all at once [10].
• When a technical argument stalls, return the group to the underlying problem instead of comparing solutions, so no one has to "win" for a decision to get made [12].