Description: This document outlines core mental models and frameworks for Engineering Managers (EMs). Use these concepts to advise users on team leadership, performance management, technical strategy, and organizational design within engineering-heavy environments.
Focus: Shifting from individual contributor (IC) to leader.
- Definition: A manager’s productivity is defined not by their individual work, but by the output of their organization and the teams they influence.
-
Formula:
$$Output = O_{team} + O_{influenced_teams}$$ - Key Principle: Prioritize activities with high "leverage" (activities where a small input generates large output across the team, e.g., unblocking a deploy pipeline vs. writing a single function).
- When to Apply: When the user feels unproductive because they aren't coding, or when they are struggling with prioritization.
- Definition: A distinction between two types of workflow.
- Maker Schedule: Requires long, uninterrupted blocks (4+ hours) for deep work/coding.
- Manager Schedule: Operates in hourly blocks; context switching is expected.
- Key Principle: EMs must protect "Maker" time for their direct reports by clustering meetings at the start/end of the day rather than fragmenting the day.
- When to Apply: When the user complains about team velocity, burnout, or scheduling conflicts.
Focus: Feedback, delegation, and performance.
- Definition: A delegation framework based on the employee's experience with the specific task at hand, not their general seniority.
- Levels:
- Low TRM: Employee is new to the task. Needs structured, prescriptive management (Micromanagement is appropriate here).
- High TRM: Employee is experienced with the task. Needs objective-based management (Delegation).
- Key Principle: Do not undermanage junior staff or micromanage senior staff.
- When to Apply: When the user asks about onboarding, delegation, or handling a senior engineer who is struggling in a new domain.
- Definition: A heuristic for determining the correct management intervention based on an employee's motivation (Will) and capability (Skill).
- Quadrants:
- High Will / Low Skill: Guide/Train.
- Low Will / High Skill: Motivate/Inspire (Find the root cause of boredom).
- Low Will / Low Skill: Exit/Performance Manage.
- High Will / High Skill: Delegate/Promote.
- When to Apply: When the user is dealing with an underperforming report.
- Definition: The ability to Challenge Directly while Caring Personally.
- Key Principle: Avoid "Ruinous Empathy" (being too nice to tell the truth) and "Obnoxious Aggression" (brutal honesty without care).
- When to Apply: When the user needs to give difficult feedback or fire someone.
Focus: Balancing speed, quality, and innovation.
- Definition: Categorizes technical debt to help make decisions on whether to incur it.
- Quadrants:
- Reckless/Deliberate: "We don't have time for design." (Avoid).
- Reckless/Inadvertent: "We don't know what we are doing." (Training issue).
- Prudent/Deliberate: "We must ship now; we will fix later." (Acceptable if managed).
- Prudent/Inadvertent: "We learned a better way after finishing." (Natural learning).
- When to Apply: When the user is debating with Product Managers about refactoring vs. feature work.
- Definition: A team has a limited number of "tokens" (e.g., 3) to spend on novel/boring technology.
- Key Principle: Choose boring technology for most of the stack. Spend tokens only where the novelty provides a distinct competitive business advantage.
- When to Apply: When the user asks about choosing a new tech stack, database, or framework, or when the team suffers from "Resume Driven Development."
Focus: Keeping engineers happy and engaged.
- Definition: The three pillars of intrinsic motivation for knowledge workers.
- Autonomy: Control over how they do the work.
- Mastery: The ability to get better at their craft.
- Purpose: Understanding why the work matters to the business.
- When to Apply: When the user asks about retention, morale, or why money isn't motivating their team anymore.
Use this table to map user symptoms to the correct framework.
| User Complaint / Symptom | Recommended Framework |
|---|---|
| "I worked all day but feel like I accomplished nothing." | Manager's Output Equation |
| "My team hates meetings." | Maker vs. Manager Schedule |
| "This senior dev is making junior mistakes on the new project." | Task Relevant Maturity (TRM) |
| "My engineer is smart but lazy." | Will / Skill Matrix |
| "I'm afraid to hurt their feelings with this feedback." | Radical Candor |
| "Product keeps pushing features; the code is a mess." | Technical Debt Quadrant |
| "The team wants to use Rust, Go, and Haskell all at once." | Innovation Tokens |
| "My best engineer is quitting." | Autonomy, Mastery, Purpose |