Daniel Lereya is monday.com’s Chief Product and Technology Officer. In a direct interview, he described the company’s growth to more than $1 billion in annual recurring revenue and its emphasis on transparency and customer impact. — Lenny’s Podcast.

Visual summary of operating lessons from Daniel Lereya.

Part 1: Radical Transparency

  1. On Data Visibility: monday.com made live business metrics visible across the office so employees could see company performance. — Lenny’s Podcast.
  2. On Strategic Alignment: Shared daily metrics help teams align around the business outcomes the company is trying to improve. — Lenny’s Podcast.
  3. On Interviewing: Before its IPO, monday.com displayed live account, churn, and signup metrics where even interview candidates could see them. — Lenny’s Podcast.
  4. On Cultural Transformation: Seeing a competitor ship far faster prompted monday.com to rethink its product architecture and operating pace rather than simply work harder. — Lenny’s Podcast.
  5. On Decision Making: Lereya argues that widespread access to metrics lets more people notice problems and contribute solutions. — Lenny’s Podcast.
  6. On Correcting Course: Shared dashboards let people outside leadership flag changes such as a drop in conversion; Lereya does not claim every weak project was thereby shut down. — Lenny’s Podcast.
  7. On Hierarchies: After monday.com went public, it adapted transparency to legal constraints through a company-wide information app and role-gated confidential data. — Lenny’s Podcast.
  8. On Motivation: Lereya says daily team-number updates keep builders close to whether their work is actually being adopted. — Lenny’s Podcast.
  9. On Vulnerability: Lereya describes shared metrics as a way to avoid leaders carrying bad news alone and to enlist the wider team in difficult problems. — Lenny’s Podcast.

Part 2: Impact Over Output

  1. On Measuring Success: Lereya measures product work by customer impact and validated change, not by the volume of features shipped. — Lenny’s Podcast.
  2. On Working Backwards: He asks teams to picture how the product should be better for customers in the next quarter, then work backward to the necessary changes. — Lenny’s Podcast.
  3. On Busy Work: A project without a clear intended change for users and a way to measure it fails Lereya’s impact test. — Lenny’s Podcast.
  4. On Prioritization: For greater impact, Lereya sometimes prioritizes making existing value easier to discover or use over building another feature. — Lenny’s Podcast.
  5. On Customer Empathy: Lereya asks product teams to understand the customer problem and opportunity before settling on a solution. — Lenny’s Podcast.
  6. On Resource Allocation: When AI-block adoption lagged, monday.com prioritized a terms-of-service change that opened access to more customers rather than simply shipping more AI features. — Lenny’s Podcast.
  7. On Celebrating Wins: Daily updates make changes in customer usage visible to the team and invite discussion about why a metric moved. — Lenny’s Podcast.
  8. On Long-Term Thinking: Lereya links impact orientation to measurable customer value; the interview does not establish that this practice alone caused the company’s $1 billion ARR. — Lenny’s Podcast.

Part 3: Speed and Execution

  1. On Execution Traps: A “trap” is Lereya’s fixed timebox for a project: the team reduces scope to deliver the core value by the deadline. — Lenny’s Podcast.
  2. On Shipping Fast: Lereya describes applying deadline traps even to an enterprise offering, where the temptation to delay until everything is complete is strong. — Lenny’s Podcast.
  3. On Perfectionism: An early release need not feel complete; Lereya prefers focused customer feedback to polishing so much that the team overbuilds. — Lenny’s Podcast.
  4. On Iteration: After a timeboxed first release, the team should continue iterating in response to customer feedback rather than treating version one as final. — Lenny’s Podcast.
  5. On Defining Scope: In Lereya’s trap method, time is fixed and scope flexes; the constraint shifts discussion toward the core user value. — Lenny’s Podcast.
  6. On Breaking Bottlenecks: In the AI-block example, the team worked with legal to remove an access bottleneck and expanded availability within two weeks. — Lenny’s Podcast.

Part 4: Setting Audacious Goals

  1. On Impossible Targets: The competitor’s release of 30 column types pushed monday.com to set an ambitious goal that could not be met with its old one-column-at-a-time approach. — Lenny’s Podcast.
  2. On Scale of Ambition: monday.com set a target of 25 additional column types in one month to force a different approach to building the product. — Lenny’s Podcast.
  3. On Breaking Assumptions: Lereya says a goal that the existing process cannot meet should prompt teams to rethink the process itself. — Lenny’s Podcast.
  4. On Team Alignment: The 25-column target gave the team one concrete product capability to pursue instead of counting many small weekly outputs. — Lenny’s Podcast.
  5. On Risk Tolerance: Lereya describes launching multiple products at once as a deliberate risk taken despite concerns about customer confusion and go-to-market complexity. — Lenny’s Podcast.
  6. On Challenging the Status Quo: monday.com announced five new products simultaneously when it chose to become a multi-product company rather than test one offering at a time. — Lenny’s Podcast.

Part 5: Scaling R&D Culture

  1. On Maintaining Agility: Lereya says leadership methods that worked when monday.com was small sometimes became liabilities as the company grew. — Lenny’s Podcast.
  2. On Organizational Design: monday.com replaced ad hoc task forces with more stable product domains when growth exposed friction in the old R&D structure. — Startup for Startup — Domains.
  3. On Hiring: When forming an AI core team, Lereya selected people for talent and enthusiasm, with many learning the technology as they went. — The Stack Interview.
  4. On Decentralized Leadership: As his role scaled, Lereya had to stop holding every detail personally and delegate more effectively. — Lenny’s Podcast.
  5. On Knowledge Sharing: The move from ad hoc task forces to domains gave teams more durable ownership and deeper expertise in a product area. — Startup for Startup — Domains.
  6. On Adapting Playbooks: Lereya recommends repeatedly reassessing which strengths the current leadership role needs rather than relying on the habits that worked at an earlier stage. — Lenny’s Podcast.
  7. On Preserving Culture: In discussing R&D culture, Lereya and Tal Haramati emphasize how operating principles help engineers move toward goals and adapt as challenges change. — Startup for Startup — R&D Culture.
  8. On Cross-Functional Pods: monday.com’s domain structure groups product, design, and engineering work around stable areas rather than rotating ad hoc task forces. — Startup for Startup — Domains.
  9. On Continuous Learning: monday.com’s early AI assistants saw limited adoption, prompting Lereya’s team to rethink how AI features create measurable customer value. — The Stack Interview.

Part 6: From Developers to Builders

  1. On Role Evolution: Lereya describes the engineer’s role shifting from writing code toward designing systems and building products with AI assistance. — Engineering Leadership Podcast.
  2. On Product Ownership: The builder role crosses implementation boundaries: Lereya’s example includes a designer independently shipping a UI fix with AI tools. — Engineering Leadership Podcast.
  3. On Understanding the Business: Lereya uses internal “Big Brain” information tools to keep builders connected to the business impact of their work. — Engineering Leadership Podcast.
  4. On Breaking Silos: Lereya says the builder role intentionally blurs the boundaries among product, design, and engineering. — Engineering Leadership Podcast.
  5. On Strategic Thinking: In agent-assisted development, engineers become system designers who direct agents rather than only executing coding tasks. — Engineering Leadership Podcast.
  6. On User Centricity: His kickoff framework asks teams to fall in love with the problem before committing to a solution. — Engineering Leadership Podcast.

Part 7: AI Agents and the Future of Work

  1. On AI Execution: monday.com describes a shift from software that only tracks work toward agents that perform work alongside people. — monday.com Agentic Era.
  2. On Agentic Integration: monday.com’s agent offering is designed to operate inside existing and new workflows rather than as a separate chat surface. — monday.com Agentic Era.
  3. On AI as Team Members: monday.com frames AI agents as teammates that execute routine work while people set strategy and provide judgment. — monday.com Agentic Era.
  4. On Production-Ready AI: Lereya says AI features should move past superficial additions and deliver customer value; monday.com revised its early AI approach after limited adoption. — The Stack Interview.
  5. On Natural Language Building: monday magic lets customers describe a work solution in plain language and generate a workflow or board from the prompt. — monday.com AI Launch.
  6. On Redefining Development: Lereya says developers are increasingly designing and managing AI-agent work rather than remaining only code implementers. — Engineering Leadership Podcast.
  7. On Workflow Automation: monday.com describes agents handling campaigns, reports, workflows, and content while people direct the work. — monday.com Agentic Era.
  8. On Immediate Value: monday.com presents business impact, not merely automation for its own sake, as the point of its agent offering. — monday.com Agentic Era.
  9. On the AI-First Pivot: monday.com repositioned its platform around humans and agents working together, extending the product beyond work management. — monday.com Agentic Era.

Part 8: Engineering Infrastructure and mondayDB

  1. On Database Architecture: mondayDB was built for monday.com’s unusually flexible boards and larger customer use cases after the team found no single existing database met its requirements. — TechCrunch — mondayDB Interview.
  2. On Scalability: mondayDB 1.0 made large boards load up to five times faster; faster dashboards were a planned later phase, not a 1.0 result. — mondayDB 1.0 Launch.
  3. On Schemaless Design: The mondayDB architecture had to support customer-defined, schemaless tables with flexible filtering, sorting, and aggregation. — mondayDB Architecture.
  4. On Performance: monday.com’s engineers used column-oriented storage so flexible board queries could retrieve needed columns efficiently. — mondayDB Architecture.
  5. On Technical Debt: Recurring board-performance problems led Lereya to invest in mondayDB as a longer-term architecture rather than repeated short-term fixes. — Lenny’s Podcast.
  6. On Enabling Innovation: The later mondayDB architecture became a foundation for AI-context features including text search and semantic retrieval. — mondayDB 3 Architecture.
  7. On Enterprise Readiness: Lereya described mondayDB 1.0 as a first step toward higher performance and scale for complex customer use cases. — TechCrunch — mondayDB Interview.
  8. On Custom Solutions: After evaluating existing databases, monday.com combined its own layers with existing technologies instead of building every database component from scratch. — TechCrunch — mondayDB Interview.
  9. On Infrastructure as a Product: A monday.com engineering account describes an internal infrastructure tool becoming a product with users, onboarding, feedback, and continuing ownership. — When Infrastructure Becomes a Product.