Snir Kodesh is an engineering executive and founder known for scaling technical organizations and analyzing security vulnerabilities. His career spans co-founding the carpooling startup Hitch, leading engineering at Lyft and Retool, and founding the AI audit platform Petual. He is frequently cited for his practical frameworks on software planning and his technical autopsy of multi-factor authentication flaws.

Visual summary of operating lessons from Snir Kodesh.

Part 1: Strategic Planning and Roadmapping

  1. On Roadmapping Focus: "Roadmapping is fundamentally about deciding what to omit as much as what to build." — Source: [First Round Review]
  2. On Cross-Functional Alignment: "A successful roadmap requires early and constant alignment between product, engineering, and design, rather than sequential handoffs." — Source: [First Round Review]
  3. On Customer Needs: "You have to balance the loudest customer requests with the long-term architectural vision of the platform." — Source: [First Round Review]
  4. On Goal Setting: "Moving from rigid OKRs to more flexible Quarterly Business Reviews (QBRs) can provide better context for engineering teams." — Source: [First Round Review]
  5. On Adapting Plans: "A roadmap shouldn't be a static document; it needs to breathe and adapt as you learn more during the development cycle." — Source: [First Round Review]
  6. On Product Intuition: "As engineering teams scale, maintaining strong product intuition at the individual contributor level is necessary." — Source: [First Round Review]
  7. On Scope Creep: "Scope creep is often misunderstood; sometimes it indicates delayed discovery of required features." — Source: [First Round Review]
  8. On Prioritization: "When prioritizing, consider the compounding debt of leaving foundational platform issues unaddressed." — Source: [Software Engineering Daily]
  9. On Vision vs. Execution: "The gap between product vision and execution is bridged by how well you communicate the underlying reasoning to the engineering team." — Source: [First Round Review]
  10. On Stakeholder Management: "Managing stakeholders requires providing transparency into the tradeoffs being made, rather than agreeing to everything." — Source: [First Round Review]

Part 2: Sprint Planning and Estimation

  1. On Estimation Accuracy: "Improving feature delivery estimates requires tracking historical variance rather than simply asking engineers to guess better." — Source: [First Round Review]
  2. On Sprint Cycles: "Sprints should be treated as learning loops, where missed estimations inform the next planning session." — Source: [First Round Review]
  3. On Buffer Time: "Baking buffer time into sprints acts as a realistic acknowledgment of operational overhead, rather than padding." — Source: [First Round Review]
  4. On Task Breakdown: "The most common source of estimation error stems from insufficiently breaking down complex tasks into atomic units." — Source: [First Round Review]
  5. On Velocity: "Velocity serves as a trailing indicator of team health rather than a target to be gamed." — Source: [First Round Review]
  6. On Retrospectives: "Effective retrospectives focus on the system that led to a missed deadline, rather than blaming the individual." — Source: [First Round Review]
  7. On Scope Reduction: "When a sprint runs off track, the first mechanism to use is scope reduction, rather than mandating longer hours." — Source: [First Round Review]
  8. On Delivery Commitments: "Commitments made during sprint planning must be paired with an understanding of the unknowns." — Source: [First Round Review]
  9. On Technical Debt: "Allocating dedicated sprint capacity to technical debt prevents the platform from calcifying over time." — Source: [Software Engineering Daily]

Part 3: Scaling Engineering Organizations

  1. On Organizational Transitions: "The skills required to lead a ten-person engineering team differ entirely from those needed for a hundred-person organization." — Source: [First Round Review]
  2. On Communication Overhead: "As teams scale, communication moves from implicit to explicit, requiring deliberate documentation and structured processes." — Source: [First Round Review]
  3. On Leadership Delegation: "Scaling requires leaders to shift from managing the work to managing the people who manage the work." — Source: [First Round Review]
  4. On Culture Retention: "Maintaining engineering culture during hyper-growth involves actively reinforcing values during the onboarding process." — Source: [First Round Review]
  5. On Cross-Team Dependencies: "The biggest drag on a scaling organization is unmanaged cross-team dependencies." — Source: [First Round Review]
  6. On Mentorship: "A mature engineering organization treats mentorship as a core responsibility rather than an extracurricular activity." — Source: [First Round Review]
  7. On Hiring Standards: "When scaling rapidly, the temptation to lower the hiring bar is strong, yet the long-term cost is immense." — Source: [First Round Review]
  8. On Performance Management: "Clear rubrics for engineering levels remain necessary to prevent bias and ensure fair promotions as the team grows." — Source: [First Round Review]
  9. On Engineering Autonomy: "Teams need autonomy to choose their tools within boundaries, balancing standardization with flexibility." — Source: [Software Engineering Daily]
  10. On Incident Response: "A mature organization views incidents as systemic failures to learn from, driving blameless post-mortems." — Source: [Retool Engineering Blog]

Part 4: The Try, Do, Consider Framework

  1. On Framework Definition: "The try, do, consider framework acts as a mechanism to translate high-level roadmaps into concrete, prioritized engineering tasks." — Source: [First Round Review]
  2. On Do Initiatives: "Do items are the non-negotiable commitments; they form the bedrock of the release cycle." — Source: [First Round Review]
  3. On Try Initiatives: "Try represents highly desirable features where the team will make a concerted effort, while acknowledging the technical risk." — Source: [First Round Review]
  4. On Consider Initiatives: "Consider items remain exploratory; they help map out future roadmaps without derailing current sprint commitments." — Source: [First Round Review]
  5. On Managing Expectations: "Using this framework manages stakeholder expectations by clearly delineating what is guaranteed versus what is aspirational." — Source: [First Round Review]
  6. On Resource Allocation: "It allows engineering managers to allocate resources dynamically, prioritizing Do items while reserving capacity for Try tasks." — Source: [First Round Review]
  7. On Psychological Safety: "Categorizing a task as Try gives engineers the psychological safety to tackle hard problems without the fear of immediate failure." — Source: [First Round Review]
  8. On Framework Flexibility: "The categories are adaptable; a Try in one quarter often becomes a Do in the next after risk is retired." — Source: [First Round Review]
  9. On Product Synergy: "This framework forces product managers and engineers to have honest conversations about feasibility early in the cycle." — Source: [First Round Review]

Part 5: Enterprise vs. Consumer Engineering

  1. On Differing Constraints: "Building for enterprise involves accommodating vast configuration needs, whereas consumer software requires intense focus on immediate reliability." — Source: [Software Engineering Daily]
  2. On the End User: "In enterprise platforms, your user is often another developer; the API and the UI must both be treated as primary products." — Source: [Software Engineering Daily]
  3. On Platform Extensibility: "A development platform succeeds only if engineers can break out of the GUI and use raw code when necessary." — Source: [Software Engineering Daily]
  4. On Scale Dimensions: "Consumer scale involves concurrent requests; enterprise scale often involves the complexity of the data models and permissions." — Source: [Software Engineering Daily]
  5. On Shipping Speed: "While consumer apps might ship continuously, enterprise platforms often require more deliberate release trains due to customer change management." — Source: [First Round Review]
  6. On Abstraction Layers: "Providing high-level GUI components while allowing JavaScript injection represents the delicate balance of an internal tooling platform." — Source: [Software Engineering Daily]
  7. On Shared Principles: "Despite the differences, the core principles of building reliable, testable software apply equally to consumer and enterprise domains." — Source: [First Round Review]
  8. On Customer Feedback: "Enterprise customers will state exactly what they need, leaving it up to the product team to generalize that into a platform feature." — Source: [Software Engineering Daily]
  9. On Real-Time Systems: "Managing real-time geospatial state instills a rigorous discipline around latency." — Source: [Software Engineering Daily]
  10. On Empowering Developers: "The goal of internal tooling is to reduce the time spent on boilerplate so engineers can focus on core business logic." — Source: [Software Engineering Daily]

Part 6: Security and Authentication

  1. On Deepfake Threats: "The rise of deepfake voice technology in vishing attacks represents a major shift in social engineering sophistication." — Source: [Retool Engineering Blog]
  2. On Degraded MFA: "What we had originally implemented was multi-factor authentication. But through this Google update, what was previously multi-factor-authentication had silently... become single-factor-authentication." — Source: [Retool Engineering Blog]
  3. On Cloud Sync Risks: "When an authenticator app syncs OTPs to the cloud, a compromised email account grants immediate access to all associated two-factor tokens." — Source: [Retool Engineering Blog]
  4. On the Illusion of Security: "Features designed for consumer convenience, like cloud syncing, can inadvertently undermine enterprise security models." — Source: [Retool Engineering Blog]
  5. On IT Helpdesk Vulnerabilities: "Helpdesks operate on the front lines; if an attacker can socially engineer the helpdesk, they bypass technical controls." — Source: [Retool Engineering Blog]
  6. On Dark Patterns in Security: "Silently altering the security posture of an authentication app without explicit administrator consent operates as a dangerous dark pattern." — Source: [Retool Engineering Blog]
  7. On Hardware Tokens: "The incident underscored the need to move toward hardware-backed authentication like FIDO2 for critical infrastructure." — Source: [Retool Engineering Blog]
  8. On Incident Transparency: "Publishing a detailed post-mortem after a breach serves as a responsibility to the broader security community." — Source: [Retool Engineering Blog]
  9. On Phishing Resilience: "Training employees on phishing is required, yet the ultimate goal must be to design systems where falling for a phish avoids a total compromise." — Source: [Retool Engineering Blog]

Part 7: Hitch and the Evolution of Ridesharing

  1. On the Genesis of Hitch: "The original vision for Hitch was to make ridesharing truly shared, reducing costs while increasing urban mobility." — Source: [Business Insider]
  2. On Social Ridesharing: "Today when you talk about rideshare ultimately it's a one to one service, it operates the same way as a cab. You don't get those rich interactions that you'd get if you put two people in the vehicle." — Source: [Business Insider]
  3. On Market Consolidation: "Joining Lyft was a strategic recognition that scaling a marketplace requires massive liquidity that was better achieved together." — Source: [Forbes]
  4. On Algorithm Complexity: "Routing multiple passengers with different destinations into a single vehicle dynamically stands as a complex mathematical challenge." — Source: [Business Insider]
  5. On Urban Transportation: "Shared rides serve as a required evolution to alleviate city congestion." — Source: [Forbes]
  6. On Founder Transitions: "Moving from a founder to a director within a larger acquirer requires a shift from survival mode to scaling mode." — Source: [First Round Review]
  7. On Early Stage Product: "At the seed stage, the product acts as an experiment to prove liquidity; architecture takes a back seat to iteration speed." — Source: [Software Engineering Daily]
  8. On the Rideshare Economy: "The shift from single-occupancy cabs to pooled rides fundamentally alters the unit economics of transportation." — Source: [Business Insider]
  9. On Building Lyft Line: "Integrating Hitch's technology into Lyft Line accelerated the deployment of true carpooling at scale." — Source: [Forbes]

Part 8: Petual and AI in Auditing

  1. On the State of Audit: "The traditional internal audit function relies heavily on manual, process-heavy workflows that are ripe for automation." — Source: [Petual Blog]
  2. On Agentic AI: "Agentic models allow software to move beyond simple summarization into executing multi-step reasoning tasks for compliance." — Source: [Petual Blog]
  3. On Elevating Human Work: "The goal of AI in auditing is to shift the auditor's focus from data collection to high-level judgment, rather than replacing them." — Source: [Petual Blog]
  4. On SOX Compliance: "Sarbanes-Oxley testing demands heavy labor; automating it unlocks significant enterprise value." — Source: [Petual Blog]
  5. On Evidence Collection: "Gathering evidence often acts as the bottleneck in compliance; AI agents can interface with systems to retrieve this autonomously." — Source: [Petual Blog]
  6. On Speed to Insight: "By automating the testing phase, organizations can gain compliance insights in minutes rather than waiting months for manual reviews." — Source: [Petual Blog]
  7. On Workpaper Generation: "Standardizing workpaper generation through AI ensures consistency and reduces the friction of regulatory scrutiny." — Source: [Petual Blog]
  8. On Building Petual: "Applying the engineering scaling lessons from consumer and enterprise companies has been instrumental in architecting Petual’s platform." — Source: [Petual Blog]
  9. On the Future of Compliance: "In the future, compliance will be continuous and programmatic, mediated by intelligent agents monitoring systems in real-time." — Source: [Petual Blog]