Monday.com Engineers Use Retrospectives and Agile Insights to Improve Sprints

Why retrospectives matter at monday.com

A retro that ends without an owner is just a complaint log. At monday.com, that matters because the company now operates at a scale where process gaps turn into product drag fast: FY2025 revenue reached $1.232 billion, R&D expense was $238.5 million, and year-end headcount hit 3,155, including 875 people in the builders group.

That is a very different environment from the one monday.com described years ago, when it said R&D had about 30 engineers, the HQ carried more than 70 dashboards, and the company was pushing 20 to 30 deployments a day through continuous delivery. Today, the pressure is bigger, the customer base is more complex, and the downside of vague teamwork is higher. Monday.com has said its largest enterprise accounts can have tens of thousands of employees, with many admins spread across the organization, so a missed handoff or a fuzzy decision can ripple far beyond one squad.

That is why retrospectives are not a ceremonial meeting in a company like this. They are one of the few recurring habits that can force accountability, expose repeated friction, and make sure speed does not outrun quality.

What a useful retro is actually for

Atlassian’s Team Playbook defines a retrospective as a chance to review the last sprint, decide what should improve next, and turn lessons into actions. That definition is useful because it draws a hard line between reflection and action. The point is not to relive blame, decorate the board with sticky notes, or produce a generic list of annoyances. The point is to identify patterns: where work got stuck, which assumptions were wrong, which handoffs created friction, and what change is likely to make the next sprint better.

Monday.com’s own monday dev guidance fits that same logic. Its Retrospectives board is designed to track action items and gather feedback for future improvements, and it can be used during the sprint, during the retro itself, and after the retro to implement and evaluate changes. That is the real power of the ritual: it is not a one-time meeting, it is a loop. The team can raise issues as they appear, discuss the previous sprint with structure, then check whether the fix actually worked.

Agile Insights adds the other half of the equation. By using historical data from the start and end of each sprint, it helps teams visualize progress against goals and compare performance over time. In practice, that gives managers and ICs something better than memory. It turns “it felt slower” into a trend, and it turns “we think this helps” into something a team can test against the next sprint.

The playbook: make the retro change the next sprint

The best retros at a fast-scaling SaaS company are short, specific, and accountable. They do not try to solve every problem in one sitting. They leave with one or two concrete experiments, an owner, and a follow-up check. That is the minimum bar if the goal is fewer repeat mistakes and cleaner execution.

A useful retro usually does four things:

• It starts with evidence. Use Agile Insights or other sprint data to look at start and end points, goal progress, and any obvious slowdown.

• It names the pattern, not the person. Focus on blocked work, confusing requirements, recurring defects, or cross-team friction.

• It assigns the fix. Every action item should have one owner and a clear deadline before the next sprint ends.

• It closes the loop. The next retro should revisit the action item and ask whether the team actually changed behavior.

At monday.com, that matters because the company has repeatedly argued that engineering should stay close to outcomes, not just output. Monday.com engineering has said the worst thing an engineering organization can suffer from is having its best engineers working on the wrong features. That is the core management risk retrospectives are supposed to reduce. If the team keeps shipping fast but keeps missing the real problem, the sprint was busy, not effective.

AI can help here too. Atlassian has noted that AI can summarize insights and make action items easier to capture. That does not change the purpose of the retro, but it does make the ritual easier to maintain when teams are moving quickly and the notes pile up.

Why this is especially important for engineers and product managers

For engineers, retrospectives are the place where recurring technical debt gets named before it becomes normal. They are also where team health issues, such as over-committed scopes, weak handoffs, or unclear ownership, can be surfaced before they harden into culture. In a company that ships continuously and serves enterprise customers with complex admin structures, a clean retro can be the difference between isolated pain and institutional learning.

For product managers, the retro is where delivery gets tied back to the outcome the sprint was supposed to create. Monday.com has long framed its engineering culture around validating features with users and staying focused on the right things. A retro that asks “did we build it?” but not “did we build the right thing?” misses the point. The whole exercise should protect the team from spending its best cycles on low-value work.

For sales-facing teams that work with product or solution engineering, retrospectives can also surface where customer commitments created strain. If a promise was hard to fulfill, or a handoff with the field team broke down, the retro is where that becomes visible and fixable. In a company whose product portfolio keeps expanding, that feedback loop matters as much as roadmap planning.

Why the ritual still matters as the company scales

Monday.com’s recent numbers make the case for a stronger, not weaker, execution habit. FY2025 revenue hit $1.232 billion, up 27% year over year, and monday vibe became the fastest product to surpass $1 million in ARR in company history. When a product line grows that quickly, small process flaws compound fast. The more ambitious the product motion, the more dangerous it becomes to rely on instinct instead of a disciplined review of what actually happened in the sprint.

That is the larger lesson inside monday.com’s own tools and engineering history. The company has grown from a relatively small R&D operation with a dense dashboard culture into a much larger organization with enterprise complexity, distributed ownership, and heavy investment in product. In that environment, retrospectives are not soft management theater. They are one of the few repeatable mechanisms that can keep execution honest, keep product decisions tied to evidence, and keep teams from mistaking motion for progress.

The teams that get value from retrospectives are the ones that treat them as part of how work gets done, not as a meeting to endure. At monday.com, that difference can show up in the next sprint, the next release, and the next customer promise that actually lands on time.