Turn the Recurring Break into a Strategic Moat
When the same problem breaks a third time, stop patching — pull your best people off features and solve it for 100x as a competitive edge
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
When a critical problem keeps recurring despite hard work, stop treating it as a bug to patch and reframe it as a strategic investment. Pull your most talented people off feature work, have them solve it for 100x scale, and aim to turn the fix into a competitive advantage rather than a tax. This requires going on intuition, since you won't have data or past-proof to justify the bet.
Origin
Daniel Lereya's account of building Monday DB, the underlying data infrastructure monday.com built over ~3 years, born from repeated board-performance crises as customers pushed tables from ~5 columns/100 rows to hundreds of columns and tens of thousands of rows.
Core principles
- 01Performance is the number one feature — reliability and speed are themselves customer value
- 02The first and second recurrence get patched; the third recurrence signals you need a fundamentally different approach
- 03Solve for 100x, not for the current spike
- 04Strategic bets don't get the luxury of conviction from past data — you go on intuition
- 05A reliable, performant foundation isn't a tax or risk; it can be a core competitive advantage that changes how customers use the product
How to run it
- 1
Rally everyone on the acute spike first
When a critical problem spikes (e.g. performance tickets), bring the graph to the whole team immediately and think together about what you can do right now to relieve it.
Pro tip Sharing the raw graph broadly mobilizes collective problem-solving fast (see the transparency model).
Watch out A patch will improve the situation but won't hold if the root cause is structural — expect it to recur.
- 2
Recognize the third recurrence as the signal
When the same problem returns a third time, declare 'enough' — this is no longer a patching problem, it needs a fundamentally different approach.
Pro tip Track recurrence explicitly; the pattern of return is the trigger, not the severity of any single spike.
- 3
Pull your best people off features onto the deep bet
Take a few of your most talented people, remove them from feature contribution, and set them aside to think and solve the problem at 100x scale.
Pro tip Explicitly protect them from feature obligations — the whole point is depth, not throughput.
Watch out This is a real cost and a huge risk: you lose your best people's feature output for a long stretch (Monday DB took ~3 years).
- 4
Aim the solve at a competitive edge, on intuition
Set the ambition beyond fixing the issue: build something that becomes a moat. Accept that you won't have data or past success to justify it — proceed on intuition because it's the product and company you want to build.
Pro tip Reframe the foundation as customer value: when things are reliable and fast, customers even use the product differently.
Watch out You forgo the usual 'conviction from data' — this contradicts the impact-metric discipline and must be justified as strategic, not measured up front.
In the wild
Customer success flagged a spike in board performance tickets as customers scaled tables from ~5 columns/100 rows to hundreds of columns and tens of thousands of rows. The team patched it, it recurred, and on the third time Lereya said enough. They pulled a few of their most talented people off features to build an underlying data infrastructure — Monday DB — designed for 100x and as a competitive edge, on intuition rather than data.
→ Monday DB's first version (released ~1.5 years before the interview) made a huge change for customers and is, in Lereya's words, what makes monday.com an enterprise-grade platform today.
Common mistakes
Patching a structural problem indefinitely
Repeatedly applying band-aids to a recurring critical problem consumes effort and never resolves it. The recurrence itself is the signal that a fundamentally different, deeper solution is required.
Demanding data-backed conviction for a strategic bet
Waiting for metrics or past proof before committing your best people to a 100x infrastructure bet stalls it — strategic foundations must sometimes be justified by intuition and the company you want to build, not by near-term data.
Is it for you?
Best for
Engineering and product leaders whose scaling product keeps hitting the same infrastructure/reliability wall and who can afford to invest top talent in a multi-quarter foundation
Not ideal for
Early-stage teams without the talent surplus to remove top people from feature work, or problems that are genuinely one-off rather than recurring and structural
From the transcript
“on the first on the third time I said okay we had enough like uh we need to think totally different in a different way”
“let's think and solve this problem while thinking about 100x”
“instead of being like fixing an issue we want this to be our competitive edge”
“We really believe that performance is the number one feature”
“if you feel about something it is strategic, you need to not only solve problems but be super proactive”
From the episode
Inside monday.com’s transformation: radical transparency, impact over output, and their path to $1B ARR
Daniel Lereya (Chief Product and Technology Officer)