Eiso Kant has spent the last decade building companies at the intersection of artificial intelligence and software engineering, including source{d}, Athenian, and Poolside. He is best known for arguing that software development is the fastest path to artificial general intelligence, and for teaching engineering leaders how to manage their teams using actionable data rather than complex jargon. This profile collects his mental models on everything from reinforcement learning on code to the daily mechanics of running high-functioning engineering teams.

Visual summary of operating lessons from Eiso Kant.

Part 1: AI, AGI, and Poolside

  1. On AGI’s proving ground: "Software development is the ideal proving ground for Artificial General Intelligence because code provides a deterministic environment for verification." — Source: Poolside Vision
  2. On Reinforcement Learning from Code Execution: "Instead of training models purely on text prediction, models must learn by writing code, executing it in a sandbox, and receiving real-time compiler feedback." — Source: Machine Learning Street Talk
  3. On agentic development: "The future of engineering tooling is moving rapidly from passive autocomplete copilots to autonomous agents that can plan and execute complex code migrations." — Source: Air Street Capital
  4. On synthetic training data: "Human-written code on the internet is a finite resource. Scaling frontier models requires generating synthetic coding challenges, verifying them through execution, and training on the successful paths." — Source: Eye on AI
  5. On the AI model factory: "Building effective software models requires a factory approach—automating the lifecycle from data ingestion to model ablation across tens of thousands of GPUs." — Source: Machine Learning Street Talk
  6. On embodied intelligence: "Taking intelligence and embodying it in the real physical world will happen much slower than the advancements occurring strictly behind a screen in software environments." — Source: Developing Leadership
  7. On the AI gap: "Software development could be the first major economically valuable capability where the gap between humans and AI is fully closed." — Source: Air Street Capital
  8. On decoupling headcount from output: "As AI models advance, organizations will experience a permanent divorce between their engineering headcount and their aggregate software output." — Source: Developing Leadership
  9. On the developer's new moat: "In an AI-driven coding world, an engineer's true moat is asymmetry of information—the specific, private context of their business that foundation models have never seen." — Source: Eye on AI
  10. On researcher qualifications: "Every AI researcher building foundation models must also be a strong engineer; the ability to move a theoretical idea to production-scale implementation is non-negotiable." — Source: Air Street Capital

Part 2: Engineering Metrics and DORA

  1. On the limits of DORA metrics: "DORA metrics are an industry standard but they are lagging indicators; they tell you what happened in the past but not where your daily bottlenecks reside." — Source: Refactoring.fm
  2. On data as a conversation starter: "Metrics should never be used as a dogmatic true north; they are simply telemetry designed to start valuable conversations and drive cultural change." — Source: Athenian Blog
  3. On gaming the system: "Metric-driven cultures inevitably lead to people gaming the system. Organizations must aim for a data-informed culture instead." — Source: Developing Leadership
  4. On organizational visibility: "For teams under thirty engineers, hardcore metrics are often overkill. But as you scale past 250, visibility drops, making metrics essential sensors for organizational speed." — Source: Athenian Blog
  5. On tracking outcomes: "Beyond velocity and quality, leaders must measure outcome—understanding the ratio of effort invested in new features versus technical debt and maintenance." — Source: Refactoring.fm
  6. On single-metric focus: "Rather than tracking dozens of KPIs, pick one leading metric and review it consistently to build organizational momentum." — Source: Athenian Blog
  7. On the internal product: "Engineering leaders have two core responsibilities: delivering the external product to customers and building the internal product—the engineering organization itself." — Source: Developing Leadership
  8. On dashboards and management: "Visibility into development should be provided to the teams themselves so they can self-optimize, rather than being weaponized by management for top-down control." — Source: Athenian Blog
  9. On the goal of telemetry: "Metrics are a means to an end. The goal is to gain insights into the developer experience so leaders know exactly what needs their attention." — Source: Refactoring.fm
  10. On evaluating quality: "Quality metrics should focus intensely on what actually impacts the end user, prioritizing change failure rates and the speed of recovery over arbitrary internal benchmarks." — Source: Athenian Blog

Part 3: The Midwit Trap and Complexity

  1. On the Midwit curve: "The tech industry is plagued by the Midwit Trap—where leaders use extreme complexity to mask a lack of deep understanding." — Source: Developing Leadership
  2. On enlightened simplicity: "True seniority in engineering is moving past the phase of overcomplication and arriving at enlightened simplicity, where you choose simple paths because you know the hidden costs of complexity." — Source: Developing Leadership
  3. On buzzword leadership: "It is a trap to rely on complex frameworks, jargon, and smart-sounding abstractions to signal competence to your peers." — Source: Developing Leadership
  4. On tool obsession: "Many engineers become overly obsessed with specific tools—like Kubernetes or precise Agile flavors—treating them as ends in themselves rather than means to solve business problems." — Source: Developing Leadership
  5. On institutional rewards: "Corporate environments often reward midwit behavior because complex architectural plans and sophisticated slide decks look better in performance reviews than a simple, fast bug fix." — Source: Developing Leadership
  6. On analysis paralysis: "A surface-level understanding of many complex topics often leads to over-engineering and a deep fear of simple solutions that might appear naive." — Source: Developing Leadership
  7. On true expertise: "True expertise is defined by the ability to simplify a complex problem so that anyone can understand the solution." — Source: Developing Leadership
  8. On avoiding the trap: "To avoid the midwit trap, leaders must prioritize actual output and straightforward problem-solving over the intellectual exercise of architectural analysis." — Source: Developing Leadership
  9. On the cost of sophistication: "Every layer of sophisticated abstraction added to a system carries an ongoing tax on velocity; leaders must weigh that cost against the theoretical benefits." — Source: Developing Leadership

Part 4: First Team Mode and Executive Alignment

  1. On primary allegiance: "An engineering leader's primary allegiance must be to the executive group—their First Team—rather than to the engineering department they manage." — Source: Developing Leadership
  2. On ending lobbyist leadership: "Leaders must stop acting as lobbyists who only fight for their own department's budget or preferences, and start making trade-offs for the good of the whole company." — Source: Developing Leadership
  3. On siloed execution: "Without a First Team mindset, departments naturally become tribal and competitive, leading to siloed execution and a toxic organizational culture." — Source: Developing Leadership
  4. On radical alignment: "When the leadership team operates in First Team mode, they present a unified front, ensuring that technical decisions remain fully grounded in broader business strategies." — Source: Developing Leadership
  5. On scaling bottlenecks: "As a company grows, the single biggest bottleneck is almost always a lack of alignment at the very top of the organization." — Source: Developing Leadership
  6. On healthy peer conflict: "Operating in First Team mode requires leaders to engage in difficult, honest debates with their peers to reach strategic decisions, rather than avoiding conflict to keep a false peace." — Source: Developing Leadership
  7. On the Second Team: "Your functional department is your Second Team. You manage them, but your strategic priorities come from the commitments made with the First Team." — Source: Developing Leadership
  8. On resource allocation: "Decisions regarding headcount and tooling must be viewed through the lens of company-wide ROI, not engineering-specific empire building." — Source: Developing Leadership
  9. On cultural foundations: "First Team alignment is the absolute prerequisite for building a high-performing engineering culture; without it, downstream teams will constantly work at cross-purposes." — Source: Developing Leadership

Part 5: Hiring, The Mom Test, and Finding Outliers

  1. On the 100+ interviews rule: "To truly understand the distribution of talent and identify right-tail outliers, founders should be prepared to interview over a hundred candidates for a single critical role." — Source: Traction Interview
  2. On non-biased interviewing: "Applying the principles of The Mom Test to hiring ensures that interviews gather objective, historical evidence of competence rather than just confirming the interviewer's biases." — Source: Traction Interview
  3. On finding outliers: "A company's trajectory is disproportionately impacted by the top one percent of engineers; the hiring process must be calibrated specifically to catch them." — Source: Developing Leadership
  4. On mutual fit: "Interview processes should be humane and focused on mutual fit, moving away from arbitrary, stress-inducing algorithmic tests." — Source: Developing Leadership
  5. On hiring owners: "The best candidates are owners who not only understand the technical mission but can clearly articulate how their specific work will advance business goals." — Source: Developing Leadership
  6. On idea validation: "Before hiring or writing a single line of code, use Mom Test principles to validate ideas with customers to avoid building things no one will pay for." — Source: Traction Interview
  7. On identifying the holy shit product: "Customer interviews must dig past polite feedback to uncover the holy shit idea—the specific pain point they feel must be solved immediately." — Source: Traction Interview
  8. On the SMB ladder: "When validating a product, start by talking to the smallest possible customers, learn rapidly, and progressively move upmarket rather than jumping straight to enterprise sales." — Source: Traction Interview
  9. On the value of deep relationships: "Cultivating deep, trusting relationships with early users is the only way to get the raw, honest feedback required to iterate effectively." — Source: Traction Interview
  10. On treating internal teams as customers: "Engineering leaders should apply customer discovery techniques internally, treating their own developers as customers to uncover their true daily pain points." — Source: Developing Leadership

Part 6: Leadership, Energy, and The Flotilla

  1. On the flotilla analogy: "As an engineering leader, you are not managing a cruise ship that turns as one unit; you are managing a flotilla of independent boats." — Source: Developing Leadership
  2. On autonomous alignment: "Leadership in a flotilla isn't about steering every individual boat; it's about ensuring all vessels share a destination while allowing them autonomy to navigate their own waters." — Source: Developing Leadership
  3. On energy management: "A leader's primary goal is to give people energy, not take it away; you must understand the spoon count of your team to prevent burnout from unnecessary friction." — Source: Developing Leadership
  4. On leading with spoons: "Empathetic leadership means helping others discover and honor their own greatness by setting high standards and providing the loving support to reach them." — Source: Developing Leadership
  5. On managing senior engineers: "Staff and Principal engineers require a distinct management style that values deep work time, scheduled communication, and high autonomy." — Source: Developing Leadership
  6. On psychological safety: "Building a foundation of trust is essential for empowerment; leaders must foster inclusive environments where admitting mistakes is safe." — Source: Developing Leadership
  7. On the introspective leader: "Great engineering leaders must be deeply introspective, constantly evaluating whether their management style is serving the evolving needs of their flotilla." — Source: Developing Leadership
  8. On the executive team: "An effective executive team is one that actively listens, welcomes critical feedback from below, and maintains a continuous desire to grow." — Source: Developing Leadership
  9. On managing managers: "The transition from managing contributors to managing managers requires shifting your focus from reviewing code to reviewing systems of communication and alignment." — Source: Developing Leadership

Part 7: Developer Productivity and PR Cycle Time

  1. On the single biggest bottleneck: "For most software teams, PR Cycle Time—the duration from when a pull request is opened to when it is merged—is the single most impactful metric to optimize." — Source: Refactoring.fm
  2. On Coding Time: "Measuring Coding Time, from first commit to PR creation, helps identify if a developer is suffering from a lack of focus or unclear requirements." — Source: Athenian Blog
  3. On Pickup Time: "High Pickup Time, from PR creation to first review, is usually an indicator of a poor review culture where team members prioritize their own work over unblocking peers." — Source: Athenian Blog
  4. On Review Time: "When Review Time, from first review to approval, is consistently high, it often signals underlying technical debt, high complexity, or misaligned architectural expectations." — Source: Athenian Blog
  5. On PR size: "The most effective way to improve cycle time is enforcing smaller PR sizes; smaller units of work are easier to review, less risky to merge, and flow through the system faster." — Source: Refactoring.fm
  6. On Maker Time: "A healthy engineering organization rigorously protects Maker Time—large, uninterrupted blocks of time that allow developers to achieve deep focus." — Source: Athenian Blog
  7. On Rework Rate: "Tracking Rework Rate—how much code is rewritten shortly after being merged—provides crucial visibility into architectural churn and shifting product requirements." — Source: Athenian Blog
  8. On workflow friction: "Developer productivity is rarely about typing speed; it is almost entirely dictated by the amount of friction in the deployment pipeline and the code review process." — Source: Refactoring.fm
  9. On continuous improvement: "Productivity metrics should be used to build a cadence of continuous micro-improvements rather than setting arbitrary top-down targets." — Source: Athenian Blog

Part 8: Scaling Organizations and Making Bets

  1. On position sizing: "Engineering leaders make hundreds of decisions every day, which amounts to thousands of bets; applying financial position sizing helps optimize these risks." — Source: Developing Leadership
  2. On optimizing resources: "Thinking in terms of position sizing ensures leaders do not over-allocate engineering resources on highly speculative features." — Source: Developing Leadership
  3. On reversibility vs. impact: "Instead of the traditional urgent-versus-important matrix, leaders should evaluate decisions on an axis of reversibility versus impact." — Source: Developing Leadership
  4. On one-way doors: "High-impact, irreversible decisions are one-way doors that demand deep thought, rigorous debate, and executive-level involvement." — Source: Developing Leadership
  5. On reversible decisions: "Low-impact, highly reversible decisions should be delegated entirely to the teams, allowing them to move incredibly fast without bureaucratic overhead." — Source: Developing Leadership
  6. On the limits of intuition: "In early-stage startups, you can rely on intuition and close communication, but as you scale, intuition fails and must be supplemented by structured telemetry." — Source: Athenian Blog
  7. On scaling communication: "As an organization grows, informal communication breaks down; leaders must intentionally design systems for sharing context and strategic intent." — Source: Developing Leadership
  8. On technical debt trade-offs: "Scaling requires making conscious bets on technical debt; taking on debt is acceptable as long as it is a calculated bet to achieve a specific business outcome." — Source: Developing Leadership
  9. On momentum: "The ultimate goal of scaling an engineering organization is to maintain momentum—the feeling that the team is shipping value predictably and without agonizing friction." — Source: Athenian Blog