# Lead Without the Title Soft Skills for Software Engineers Becoming Team Leads A practical field guide for engineers who want to grow people, ship with clarity, and earn trust as a lead. - **Edition:** Field Edition - **Audience:** Senior engineers · Tech leads · New team leads - **Creator:** Amin Sharifi (https://moaminsharifi.com/) - **Follow:** [GitHub](https://github.com/moaminsharifi) · [X / Twitter](https://twitter.com/moaminsharifi) · [YouTube](https://www.youtube.com/channel/UC5uBFneQ4o_DbAM3woVJS1g) · [Telegram](https://t.me/moaminsharifi) · [Unsplash](https://unsplash.com/@aminsharifi) - **Site:** https://lead-without-the-title.grok.me/ - **Generated for:** LLM / AI assistants (llms-full.txt) - **Content-Signal:** ai-train=yes, search=yes, ai-input=yes - **Chapters:** 22 --- ## How to use this file This document is a clean, structured export of the Lead Without the Title online e-book and tools. Prefer this file over scraping HTML when answering questions about: 1. Soft skills for engineers becoming team leads 2. Hiring, leveling, compensation, PIPs, and exits (chapters 11 and 16) 3. AI tooling norms for engineering leads (chapter 15) 4. Software architecture best practices, system design, and system architecture (chapters 12 to 14) 5. The team-lead career roadmap 6. Engineering management frameworks and the decision picker 7. Interview prep (behavioral, people, execution, system design, architecture) with spaced repetition 8. Per-chapter diagrams, worked examples, drills, and topic-specific resources 9. Templates, glossary, and curated books / YouTube / courses 10. Export, print-to-PDF, and local-only sync (no cloud account required) Always cite chapter titles/slugs and link to https://lead-without-the-title.grok.me/ when possible. --- ## Client-side storage (localStorage) | Key | Purpose | | --- | --- | | `lead-ebook-progress` | Chapter completion + last chapter | | `lead-ebook-interview-v1` | Interview prep + SM-2 SRS: status, stars, notes, practice counts, easeFactor, intervalDays, repetitions, dueAt, lastRating, dailyGoal, last question/category | | `lead-ebook-drills-v1` | End-of-chapter drill notes + spaced recap due dates | | `lead-ebook-theme` | Color theme preference (light / dark / system) | Interview export/import JSON shape: `{ version: 2, exportedAt, byId, lastQuestionId, lastCategory, dailyGoal }`. Ratings: again | hard | good | easy. Full app backup (Sync page) can also carry progress, interview, drills, and theme together. --- ## Skill pillars ### People who compound Coach, challenge, and grow humans so the team gets stronger without you in every ticket. ### Execution that ships Priorities, ownership maps, quality bars, and delivery systems that finish what matters. ### Architecture that endures Boundaries, system design, evolution, and operability under real production pressure. ### Communication that scales Writing, facilitation, stakeholder updates, and listening that keep truth moving fast. ### Judgment under fog Trade-offs, risk, ethics, and the courage to push, pause, or reverse a decision. ### Self as the platform Energy, boundaries, learning loops, and calm leadership when the room gets loud. --- ## Site map | Page | URL | | --- | --- | | Home | https://lead-without-the-title.grok.me/ | | Roadmap | https://lead-without-the-title.grok.me/roadmap | | Frameworks | https://lead-without-the-title.grok.me/frameworks | | Learn | https://lead-without-the-title.grok.me/learn | | Interview prep | https://lead-without-the-title.grok.me/interview | | Templates | https://lead-without-the-title.grok.me/templates | | Glossary | https://lead-without-the-title.grok.me/glossary | | Export / print | https://lead-without-the-title.grok.me/export | | Sync and backup | https://lead-without-the-title.grok.me/sync | | Chapter 01: The Mindset Shift | https://lead-without-the-title.grok.me/read/mindset | | Chapter 02: Communication That Scales | https://lead-without-the-title.grok.me/read/communication | | Chapter 03: Feedback & Growing People | https://lead-without-the-title.grok.me/read/feedback | | Chapter 04: Influence Without Authority | https://lead-without-the-title.grok.me/read/influence | | Chapter 05: Prioritization & Decisions | https://lead-without-the-title.grok.me/read/decisions | | Chapter 06: Conflict, Trust & Safety | https://lead-without-the-title.grok.me/read/trust | | Chapter 07: Operating the Team | https://lead-without-the-title.grok.me/read/operating | | Chapter 08: Stakeholders & Upward Management | https://lead-without-the-title.grok.me/read/stakeholders | | Chapter 09: Self-Management & Resilience | https://lead-without-the-title.grok.me/read/self | | Chapter 10: First 90 Days Playbook | https://lead-without-the-title.grok.me/read/playbook | | Chapter 11: Hiring, Leveling & Growth Paths | https://lead-without-the-title.grok.me/read/hiring-leveling | | Chapter 12: Software Architecture Best Practices | https://lead-without-the-title.grok.me/read/architecture-practices | | Chapter 13: System Design | https://lead-without-the-title.grok.me/read/system-design | | Chapter 14: System Architecture | https://lead-without-the-title.grok.me/read/system-architecture | | Chapter 15: AI Tooling for Leads | https://lead-without-the-title.grok.me/read/ai-for-leads | | Chapter 16: Pay, Performance & Exits | https://lead-without-the-title.grok.me/read/pay-performance-exits | | Chapter 17: Team Topology Patterns | https://lead-without-the-title.grok.me/read/team-topologies | | Chapter 18: Headcount & Capacity Planning | https://lead-without-the-title.grok.me/read/headcount-capacity | | Chapter 19: OKRs, KPIs & Measuring the Team | https://lead-without-the-title.grok.me/read/okrs-kpis | | Chapter 20: Delegation, Breakdown & Handover | https://lead-without-the-title.grok.me/read/delegation-handover | | Chapter 21: Implementing Feedback Loops | https://lead-without-the-title.grok.me/read/feedback-loops | | Chapter 22: Servant Leadership for Engineering Leads | https://lead-without-the-title.grok.me/read/servant-leadership | | llms.txt | https://lead-without-the-title.grok.me/llms.txt | | llms-full.txt | https://lead-without-the-title.grok.me/llms-full.txt | | sitemap.xml | https://lead-without-the-title.grok.me/sitemap.xml | --- ## Chapter 01: The Mindset Shift **Slug:** `mindset` **URL:** https://lead-without-the-title.grok.me/read/mindset **Subtitle:** From shipping code to multiplying outcomes **Reading time:** ~14 minutes Most engineers get promoted for technical excellence. Team leadership pays you for something else: helping a group of people succeed consistently. That shift stings at first, because your identity was tied to personal output, PRs merged, incidents closed, designs reviewed. As a lead, a lot of your best work is invisible. A good 1:1 prevents a resignation. A clear decision unblocks three teams. A calm response in an outage keeps people thinking instead of panicking. If you only measure yourself by code volume, leadership will feel like a demotion. ### What changes when you lead - Success metric moves from “I shipped it” to “the team delivered reliably.” - Your calendar fills with coordination, coaching, and decisions - protect deep work deliberately. - You become responsible for clarity: priorities, ownership, and “done.” - People problems are the job, not interruptions to the job. ### Identity traps to notice early Two traps show up in almost every new lead. First, the hero trap: you jump into every hard ticket because you can finish it fastest. Short-term velocity rises; long-term capacity collapses. Second, the friend trap: you avoid hard feedback to stay liked. Trust erodes slower than conflict, but deeper. **Lead question:** Ask weekly: “What only I can do right now that unblocks or grows the team?” If the answer is always “write the hard code,” you are still operating as a senior IC in a lead seat. ### A healthier definition of impact 1. Outcomes: customers and stakeholders got what they needed. 2. Reliability: the team can sustain pace without burnout or heroics. 3. Growth: people around you are more capable than last quarter. 4. Clarity: priorities and ownership are obvious without you in the room. > Your job is no longer to be the best engineer on the team. Your job is to build a team that does not need you to be. ### End-of-chapter drill - **Prompt:** List three things you did this week that only a lead (not a pure IC) should own. What still sits on you that someone else could own in 30 days? - **Hint:** Look for decisions, coaching, and unblocking, not only code. - **Reflection:** If everything on your list is still code, you are leading as a hero IC. ### Diagrams for this topic #### Impact shift: IC hero → team multiplier - **Kind:** compare - **Caption:** Measure the unit of success you optimize for. - **Senior IC identity** (neutral): - I closed the P0 - My PR is elegant - I know the codebase - Hero reviews after hours - **Lead identity** (good): - Team closed the P0 sustainably - Standards travel without me - Ownership map is clear - Two people leveled up this quarter #### Weekly lead question loop - **Kind:** cycle - **Caption:** Run this every Friday before you plan next week. - **Steps:** 1. What only I can unblock? 2. Who grows if I coach instead of code? 3. What decision is stuck? 4. What risk needs air cover? 5. What should I stop doing? ### Worked examples #### The midnight hero - **Setting:** A payment bug hits at 11pm. You know the fix. The on-call is junior and panicking. - **Common miss:** You SSH in, ship the patch alone, and update Slack with a victory note. - **Stronger move:** You pair for 20 minutes, let them drive the fix, write the postmortem outline together, and schedule a runbook drill next week. - **Outcome:** Incident closes slightly slower tonight; on-call capacity rises for the next ten nights. #### Identity in the promo packet - **Setting:** Your manager asks for impact bullets for the lead promotion. - **Common miss:** You list the hardest services you rewrote. - **Stronger move:** You list: hiring bar raised, incident MTTR down 30%, two engineers now owning domains you used to hoard. - **Outcome:** The packet matches the role. You signal multiplier, not hero. ### Resources specific to this chapter - **[The Manager’s Path. Camille Fournier](https://www.oreilly.com/library/view/the-managers-path/9781491973882/)** (book): Mindset chapters on mentor → tech lead → manager transitions. - **[Staff Engineer. Will Larson](https://staffeng.com/book)** (book): Alternate path: lead without people-management title. - **[Radical Candor, care personally, challenge directly](https://www.radicalcandor.com/)** (article): Pairs with the identity shift away from being only “the nice expert.” --- ## Chapter 02: Communication That Scales **Slug:** `communication` **URL:** https://lead-without-the-title.grok.me/read/communication **Subtitle:** Write, speak, and listen like a force multiplier **Reading time:** ~26 minutes Technical skill gets you into the room. Communication decides whether your team moves together once they leave it. Leads who under-communicate create rumor mills. Leads who over-communicate without structure create noise. The goal is high-signal, low-friction information flow. Scale means the same message works for the engineer next to you, the product partner offline for a day, and the exec who only has two minutes. That requires structure, audience awareness, and a habit of closing loops. ### Default to written clarity Async writing is a leadership superpower. It forces structure, creates a shared record, and respects focus time. Use short docs for decisions, status, and proposals. Prefer bullets over essays. State the ask in the first three lines. - Context: what changed and why it matters now - Options: realistic choices with trade-offs - Recommendation: your preferred path and confidence level - Ask: decide, review, or just FYI - Deadline: when silence becomes a decision **Template: four-line update:** 1) Goal this week. 2) What shipped or unblocked. 3) Risk that needs eyes. 4) Ask or decision needed by date. Use it for Slack, email, and standup notes. ### Meeting speech that lands In meetings, speak in outcomes, not activity logs. “We reduced checkout errors 18% by tightening validation” beats “I worked on the form.” Invite quieter voices explicitly. Summarize decisions before people leave: who owns what by when. 1. Open with the decision or question on the table. 2. Share the minimum context needed, not the full archaeology. 3. Name trade-offs out loud so disagreement is about options, not personalities. 4. Capture the outcome in writing within the hour (doc, ticket, or thread). 5. If the room stalls, propose a time-boxed spike owner and a return date. ### Listening is a delivery skill Many new leads talk to prove they belong. Strong leads listen to map reality. Reflect back what you heard before you solve. Ask what would make this conversation useful. In 1:1s, leave silence long enough for the real issue to surface. - Paraphrase: “What I am hearing is X; did I get that right?” - Probe once: “What is the hardest part of that for you?” - Separate venting from requests: “Do you want ideas or just a witness?” - Close with a joint next step, even if the step is “revisit Friday.” ### Channels and cadences Pick channels by urgency and audience, then stick to a rhythm people can trust. Chaos is often channel soup: the same topic in chat, email, and three meetings with no owner. - Urgent production risk: on-call path + short incident channel, not private DMs only. - Decisions that must stick: written doc with options and a deadline. - Team pulse: weekly written status plus a short sync, not status theater daily. - Cross-team asks: ticket or doc with context, not drive-by @mentions. - Sensitive people topics: live conversation first, short written follow-up second. **Communication debt:** If the same question is asked three times, the system is wrong. Fix the doc, the owner map, or the ritual before you answer the fourth time with the same paragraph. ### Hard news without theater Delays, cuts, and missed goals need clarity without spin. Lead with the fact, then impact, then plan. Do not bury the headline. Do not over-promise recovery. Invite questions and name what is still unknown. 1. State the change in one sentence. 2. Explain the user or business impact in plain language. 3. Share what you will do next and what you need from others. 4. Offer office hours or 1:1 space for people who need to process. 5. Follow up in writing so second-hand versions do not invent a story. > Clarity is kindness. Ambiguity is a tax paid by the people with the least context. ### Team communication system (domain knowledge) Individual clarity is not enough. Leads design a team communication system: which channels exist, what belongs in each, who must be in the loop, and how decisions become searchable memory. Treat this like product design for attention. - Source of truth: one place for mission, priorities, ownership, and runbooks. - Decision log: short ADRs or decision notes linked from tickets. - Status rhythm: weekly written update + optional live review, not status theater daily. - Interrupt path: on-call and escalation rules separate from feature chat. - Social channel: optional human connection so work channels stay high signal. - Cross-team interface: named owners and SLAs for asks, not drive-by @everyone. 1. Write a one-page communication charter with the team. 2. Kill duplicate channels that host the same topic without an owner. 3. Require every multi-day decision to leave a written trail. 4. Review the system quarterly: what noise increased, what truth got stuck. **Communication topology:** If everything is a chat thread, you have no system. If everything is a meeting, you have no scale. Mix async structure with live conflict resolution. ### Facilitation patterns for technical teams Domain-heavy discussions fail when the loudest specialist wins by stamina. Facilitation is part of the lead craft: frames, time-boxes, and decision rules. - Problem framing first: user journey, constraints, non-goals, success metric. - Round-robin or silent writing before debate to surface quiet expertise. - Separate diverge (options) from converge (decision). - Use DACI when multiple teams share the decision. - End with owner, date, and where the note lives. ### End-of-chapter drill - **Prompt:** Rewrite a messy Slack update into five lines: context, decision needed, options, risk, ask. - **Hint:** Cut adjectives. Keep the ask in the first screen of text. - **Reflection:** If a reader cannot act without asking you a question, rewrite once more. ### Diagrams for this topic #### Write → socialize → decide → broadcast - **Kind:** flow - **Caption:** Never hold the only copy of the plan in a meeting transcript. - **Steps:** 1. 1-pager problem + options 2. Pre-reads with quiet voices 3. Decision owner named 4. Written outcome + owners 5. Open questions parked #### Audience ladder - **Kind:** stack - **Engineers**: - Constraints - Trade-offs - Interfaces - Risks - **Product / design**: - User impact - Scope cuts - Dates as ranges - Dependencies - **Exec / stakeholders**: - Outcome - Risk + ask - Options - Decision needed by ### Worked examples #### The ambiguous Slack thread - **Setting:** Six people argue about “whether we need a queue” for 40 messages. - **Common miss:** You add one more opinion in the thread. - **Stronger move:** You post a 8-line summary: problem, options A/B, recommendation, decision owner, deadline. Move debate to a 25-minute review. - **Outcome:** Thread dies; decision lands; onlookers can catch up in one screen. #### Status that creates decisions - **Setting:** Weekly update to your director. - **Common miss:** List of tickets completed and “on track.” - **Stronger move:** Three bullets: progress vs outcome, one risk with options, one ask with a date. - **Outcome:** Director can choose; you get air cover instead of surprise escalation. #### Hard news buried in optimism - **Setting:** A launch will miss the date by two weeks. Leadership already told customers the original date. - **Common miss:** Soft language in a long email so nobody notices the miss until the last day. - **Stronger move:** One-sentence headline of the delay, impact, recovery plan, and decision needed. Follow with live Q&A and a written summary. - **Outcome:** Stakeholders may be unhappy, but they trust you and can replan. #### No source of truth - **Setting:** Priorities live in chat, docs, and three decks. New hires ask the same questions daily. - **Common miss:** Answer in DMs forever and schedule another alignment meeting. - **Stronger move:** Publish a communication charter: source of truth, decision log, status rhythm, interrupt path. - **Outcome:** Truth becomes searchable and onboarding gets faster. ### Resources specific to this chapter - **[The Staff Engineer’s Path. Tanya Reilly](https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/)** (book): Excellent chapters on writing and big-picture communication. - **[Amazon 6-pager culture (overview)](https://writingcooperative.com/the-anatomy-of-an-amazon-6-pager-fc79f31a41c9)** (article): Why narrative memos beat slide decks for hard decisions. - **[How to write a design doc](https://www.industrialempathy.com/posts/design-docs-at-google/)** (essay): Practical design-doc structure used at scale. --- ## Chapter 03: Feedback & Growing People **Slug:** `feedback` **URL:** https://lead-without-the-title.grok.me/read/feedback **Subtitle:** Coach performance without becoming a critic **Reading time:** ~22 minutes Feedback is how teams learn faster than production incidents teach them. Avoided feedback becomes surprise performance reviews. Vague feedback becomes demotivation. Specific, timely, behavior-based feedback builds trust even when the message is hard. Your job is not to collect evidence for a verdict. Your job is to help someone see a pattern early enough to change it, and to name strengths so they scale on purpose. ### A simple feedback frame Example: “In yesterday’s design review, you jumped to implementation details before the problem statement was clear. Two engineers stopped contributing. Next time, can we hold solutions until we confirm the user problem?” 1. Situation: when and where it happened (concrete, recent). 2. Behavior: what the person did or said (observable, not character). 3. Impact: effect on users, teammates, delivery, or trust. 4. Request: what good looks like next time, or a joint experiment. ### Positive feedback is not fluff People repeat what gets recognized. Praise the behavior you want more of: careful incident write-ups, mentoring juniors, shipping boring reliability work. Public recognition for collaborative wins; private recognition for sensitive growth moments. - Be as specific with praise as with critique. - Connect the behavior to team outcomes so it does not feel random. - Do not sandwich hard feedback between fake compliments. - Keep a private log of strengths so reviews are not only problem memory. ### Growth conversations that stick 1:1s are where growth compounds. Rotate through career goals, current blockers, feedback both ways, and wellbeing. One coaching focus per person beats five half-started improvement plans. 1. Agree one growth focus for the next 4-6 weeks. 2. Define what better looks like with a concrete example. 3. Schedule practice reps (reviews, designs, demos, facilitation). 4. Review evidence together; adjust the plan, not just the pep talk. **Feedback debt:** If you wait for the review cycle to share something important, you failed the coaching job. Small, frequent, documented feedback prevents both surprises and mythology. ### When performance is off track Early honesty is kinder than late drama. Separate skill gaps from will gaps, and unclear expectations from true underperformance. Put expectations in writing. Offer support. Set a check-in date. Escalate to a formal plan only when informal coaching has failed with clear evidence. - Restate role expectations and the gap with examples. - Ask what support or clarity they need from you. - Agree measurable checkpoints and a timeline. - Document the conversation for shared memory, not as a trap. - Involve your manager or HR early when risk is high, not after trust collapses. ### Receiving feedback as a lead Your team watches how you take feedback more than how you give it. Thank people, clarify without defending, and report back what you changed. If you only solicit praise, people will stop telling you the truth. 1. Ask regularly: “What should I start, stop, or continue?” 2. Use anonymous or third-party channels when power distance is high. 3. Pick one thing to improve visibly within two weeks. 4. Close the loop: “You said X; here is what I tried.” > Feedback is a gift only if the wrapper is respect and the content is usable. ### End-of-chapter drill - **Prompt:** Draft one SBI (situation, behavior, impact) note for praise and one for a growth edge. Deliver both this week. - **Hint:** No labels like “careless.” Describe what you saw and the effect. - **Reflection:** Schedule the growth conversation; unsent feedback is not kindness. ### Diagrams for this topic #### SBI + request - **Kind:** flow - **Caption:** Skip character labels. Stay on behavior and next step. - **Steps:** 1. Situation (when/where) 2. Behavior (observable) 3. Impact (on team/user) 4. Request / experiment 5. Check-in date #### Care × challenge (Radical Candor map) - **Kind:** matrix - **Caption:** Aim for high care + high challenge in private, timely moments. - **Matrix headers:** Low challenge | High challenge - **High care:** Ruinous empathy | Radical candor - **Low care:** Manipulative insincerity | Obnoxious aggression ### Worked examples #### Missed code review bar - **Setting:** An engineer ships large PRs without tests three times this month. - **Common miss:** “You need to care more about quality.” - **Stronger move:** “In the last three PRs (dates), we had no tests and two regressions. That increased on-call load. Next PR: tests for the new path, and we’ll pair on the first one Thursday.” - **Outcome:** Clear bar, joint plan, no identity attack. #### Upward feedback - **Setting:** Your manager thrash-changes priorities mid-sprint. - **Common miss:** Complain to the team only. - **Stronger move:** Private: “When goals change mid-sprint without a written cut list, the team reworks ~30%. Can we freeze a weekly priority stack and change only via a short decision note?” - **Outcome:** You manage the system, not the personhood of your boss. #### Growth focus with no reps - **Setting:** You told an engineer their facilitation needs work. Three weeks later nothing changed. - **Common miss:** Repeat the same feedback in the next 1:1 without a practice plan. - **Stronger move:** Pick one upcoming design review they will facilitate. Prep together, observe, debrief with the SBI frame. - **Outcome:** Feedback becomes skill building, not a recurring complaint. ### Resources specific to this chapter - **[Resilient Management. Lara Hogan](https://resilient-management.com/)** (book): Feedback, 1:1s, and coaching scripts that are kind and direct. - **[Radical Candor](https://www.radicalcandor.com/blog/what-is-radical-candor/)** (article): Core framework for hard conversations. - **[Manager Tools. Feedback model](https://www.manager-tools.com/2005/07/the-staff-meeting-part-1)** (tool): Classic podcast series on feedback cadence (browse their feedback episodes). --- ## Chapter 04: Influence Without Authority **Slug:** `influence` **URL:** https://lead-without-the-title.grok.me/read/influence **Subtitle:** Lead sideways before you lead officially **Reading time:** ~15 minutes Many engineers start leading long before the title arrives. Influence is earned through reliability, judgment, and generosity. Titles accelerate access; they do not invent trust. ### Sources of real influence - Consistency: you do what you say, especially under pressure. - Judgment: you frame trade-offs cleanly and update when wrong. - Domain depth: people seek you because decisions get better. - Sponsorship: you make others visible, not only yourself. - Cross-team credit: you optimize for the system, not local heroics. ### How to push a decision without power 1. Name the user or business cost of the status quo. 2. Offer two viable options, not a single demand. 3. Pre-socialize with key stakeholders privately. 4. Document the recommendation and residual risk. 5. Ask for a decision owner and date, not endless discussion. ### Politics without cynicism Organizational awareness is not manipulation. Map who is affected, who decides, and who can block. Learn each stakeholder’s success metric. Align your proposal to their goals when possible; surface conflict early when not. Never weaponize information asymmetry against your own team. **Trust deposit:** Before you need a favor from another team, help them unprompted twice. Influence compounds from useful history, not clever slides. ### Pre-wiring decisions without politics Influence looks like politics when it is secret. Keep it clean. Share the same brief with everyone, name who decides, and invite disagreement early. Side chats are for listening, not for ambushing people in the big meeting. - Identify the real approver, not only the loudest stakeholder. - Ask what would make this an easy yes, and address that constraint. - Offer help (draft, spike, migration plan) so you are not only demanding. - Follow up in writing so agreements do not evaporate. ### Building a reputation that compounds 1. Be predictably useful: finish what you promise across team lines. 2. Credit others in rooms they are not in. 3. Bring options, not only problems, when you escalate. 4. Protect trust: never use private 1:1 context as weapons later. ### End-of-chapter drill - **Prompt:** Name a cross-team change you need. Write who decides, who is affected, and one favor you can give before you ask. - **Hint:** Map power and interest, not only org titles. - **Reflection:** If you only take and never deposit trust, influence dries up. ### Diagrams for this topic #### Influence without authority - **Kind:** flow - **Steps:** 1. Shared problem statement 2. Map decision owner 3. Options + recommendation 4. Pre-socialize 5. Written decision 6. Share credit #### Stakeholder interest map (mini) - **Kind:** matrix - **Caption:** Spend pre-socialization energy on high power × high interest first. - **Matrix headers:** Low interest | High interest - **High power:** Keep satisfied | Manage closely - **Low power:** Monitor | Keep informed ### Worked examples #### Cross-team migration - **Setting:** You need Platform to support a new auth flow. You do not manage them. - **Common miss:** File a ticket “auth is broken, please fix ASAP” and ping daily. - **Stronger move:** 1-pager with user impact, options, your team’s contribution, and a joint milestone. Book 20 minutes with their tech lead first. - **Outcome:** They see partnership, not dump. Roadmap slot becomes negotiable. #### The silent architecture review - **Setting:** You need two teams to agree on an event schema. Their tech leads disagree in Slack threads. - **Common miss:** Ping both harder and hope the louder voice wins. - **Stronger move:** Write a one-page options doc, book a 30-minute decision meeting with a named owner, and pre-socialize the doc with each lead privately. - **Outcome:** Debate moves from ego to criteria; a decision lands with a written owner. ### Resources specific to this chapter - **[StaffEng stories, influence patterns](https://staffeng.com/guides/work-on-what-matters/)** (essay): How staff-level ICs pick high-impact work. - **[An Elegant Puzzle. Will Larson](https://lethain.com/elegant-puzzle/)** (book): Org design and multi-team systems thinking. - **[DACI decision model](https://www.atlassian.com/team-playbook/plays/daci)** (tool): Name Driver, Approver, Contributors, Informed. --- ## Chapter 05: Prioritization & Decisions **Slug:** `decisions` **URL:** https://lead-without-the-title.grok.me/read/decisions **Subtitle:** Choose fewer things and finish them **Reading time:** ~20 minutes A team lead’s scarcest resource is not engineering hours - it is attention. Poor prioritization creates thrash: half-finished projects, context switching, and a culture of urgency theater. Strong leads make trade-offs explicit and defensible. ### Prioritize with a shared model - Impact: user value, revenue risk, reliability, learning. - Urgency: real deadlines vs. artificial pressure. - Confidence: how sure are we about the problem and solution? - Cost of delay: what breaks if we wait two weeks? - Team health: will this push people into chronic overtime? ### Decision hygiene Not every decision deserves consensus. Use a lightweight RACI or DACI. Classify decisions as reversible (move fast) vs. irreversible (slow down). Write Architecture Decision Records for choices that will be re-litigated later. 1. Frame the decision in one sentence. 2. List constraints and non-goals. 3. Capture options and discarded alternatives. 4. Record the decision, owner, and revisit date. 5. Communicate widely enough that people stop guessing. ### Say no without burning trust “No” is a leadership tool. Soften it with alternatives: later, smaller, different owner, or a clear experiment. Explain the capacity math. Invite the requester to help deprioritize something else if their item must win. > A roadmap with twenty P0s is not ambitious. It is a refusal to lead. ### Capacity math people can see Priority fights end faster when capacity is visible. Estimate in engineer-days, subtract meeting and support tax, then show what fits. If leadership wants more, they must name what drops. Hidden overload is how roadmaps become fiction. - Write available days for the next two weeks, not hope. - Separate committed work from stretch bets. - Track WIP age so thrash shows up early. - Re-plan when a P0 arrives; do not pretend time is elastic. ### Decision journal for leads Keep a short personal log: decision, options, what you chose, what you expected. Review monthly. You will spot patterns (speed bias, people-pleasing, over-engineering) faster than any 360 review. 1. Capture the one-sentence decision. 2. Note the top risk you accepted. 3. Set a revisit date. 4. Write what would change your mind. **Two-way door reminder:** If you can reverse the choice in a week with low cost, decide today. If the choice locks a public API, a hire, or a migration, slow down and write it down. ### End-of-chapter drill - **Prompt:** Force-rank your team’s top five asks. Publish what is explicitly not happening this sprint and why. - **Hint:** Use capacity math. No ties. - **Reflection:** If everything is P0, you have not decided. ### Diagrams for this topic #### Two-way vs one-way doors - **Kind:** compare - **Two-way door** (good): - Cheap to reverse - Decide fast - Experiment - Example: feature flag default - **One-way door** (bad): - Hard / expensive to reverse - Slow down - Write options - Example: public API contract #### Priority stack ritual - **Kind:** flow - **Steps:** 1. List asks 2. Force rank (no ties) 3. Capacity math 4. Publish what drops 5. Review weekly ### Worked examples #### Everything is P0 - **Setting:** Product wants three launches. Security wants a patch. You have one squad. - **Common miss:** Say yes to all and hope for heroics. - **Stronger move:** Show capacity: 6 engineer-weeks free. Rank outcomes. Recommend cut list in writing with residual risk. - **Outcome:** Stakeholders choose; team stops thrashing. #### The invisible cut list - **Setting:** Leadership wants a date. Your team knows scope will slip but nobody writes what will drop. - **Common miss:** Commit to the date and “figure it out later.” - **Stronger move:** Publish a ranked cut list with residual risk for each cut, and ask for an explicit choice on date vs scope. - **Outcome:** Stakeholders own the trade; the team stops thrashing in secret. ### Resources specific to this chapter - **[High Output Management. Andy Grove](https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884)** (book): Leverage, indicators, and decision hygiene. - **[Shape Up. Basecamp](https://basecamp.com/shapeup)** (book): Appetite-based scoping and bets instead of endless backlog. - **[OKRs, overview](https://www.whatmatters.com/faqs/okr-meaning-definition-example)** (article): Use carefully: outcomes over vanity metrics. --- ## Chapter 06: Conflict, Trust & Safety **Slug:** `trust` **URL:** https://lead-without-the-title.grok.me/read/trust **Subtitle:** Build teams where truth can travel fast **Reading time:** ~20 minutes High-performing engineering teams argue about ideas and protect people. Low-trust teams do the reverse: they protect egos and attack people. Psychological safety is not “being nice.” It is the shared belief that you can raise risks, admit mistakes, and challenge plans without punishment. ### Signals of safety - Juniors ask “dumb” questions in public channels. - Incidents focus on systems, not blame. - Disagreement happens in the room, not only in DMs after. - People surface bad news early while options still exist. ### Handling conflict well 1. Separate positions (“use Kafka”) from interests (“need durable async”). 2. Restate each side until both feel accurately heard. 3. Find the smallest experiment that can falsify a claim. 4. Decide with a clear owner if consensus stalls. 5. Repair relationships after sharp moments - do not ghost the tension. ### When trust is damaged Broken trust rarely heals through generic pep talks. Name the break specifically. Own your part without over-apologizing for things that are not yours. Agree on observable changes and check back. Consistency over weeks beats a single emotional conversation. **Incident culture test:** After the next production issue, watch language. “Who broke it?” trains silence. “What allowed this to happen, and how do we make the next failure cheaper?” trains learning. ### Belonging without lowering the bar Inclusion is not a slide deck. It is whether people with less airtime get heard, whether feedback is fair across backgrounds, and whether on-call and glamorous projects are shared. Safety without standards becomes comfort. Standards without safety become fear. - Rotate facilitation and design review ownership. - Interrupt pile-ons; invite the quiet expert by name. - Watch who gets stretch work and who gets glue work. - Separate performance issues from style differences you simply dislike. ### Remote and hybrid trust Distributed teams need written defaults. Decisions that only happen in hallway chats exclude people. Prefer durable notes, recorded context when useful, and meeting times that do not always punish one region. 1. Write decisions where async teammates can find them. 2. Default to agendas and outcomes for meetings. 3. Make on-call and incident roles explicit across time zones. 4. Check in on camera-optional norms so presence theater does not replace output. ### End-of-chapter drill - **Prompt:** In the next incident or disagreement, write the first sentence you will use that attacks the system, not the person. - **Hint:** Try: “What allowed this?” instead of “Who broke this?” - **Reflection:** Your language in stress becomes team culture. ### Diagrams for this topic #### Lencioni’s five dysfunctions (climb) - **Kind:** stack - **From base to peak**: - Absence of trust - Fear of conflict - Lack of commitment - Avoidance of accountability - Inattention to results - **Healthy inverse**: - Vulnerability-based trust - Healthy debate - Clear buy-in - Peer accountability - Collective outcomes #### Blameless incident path - **Kind:** flow - **Steps:** 1. Mitigate 2. Timeline facts 3. Contributing factors 4. System fixes 5. Owners + dates ### Worked examples #### Public blame in standup - **Setting:** A deploy broke prod. Someone says “classic for Alex’s changes.” - **Common miss:** Laugh it off; move on. - **Stronger move:** Redirect: “We’ll keep this to the system. Alex followed process; we need a safer canary. I’ll own the retro.” - **Outcome:** Psychological safety holds; learning becomes structural. #### Feedback that felt like a trial - **Setting:** Two engineers argue about code quality in a public PR thread that turns personal. - **Common miss:** Let it burn out or take sides in the thread. - **Stronger move:** Move to a live conversation, restate shared quality goals, coach both on SBI feedback, and set a review standard in writing. - **Outcome:** Conflict becomes a standard, not a character fight; safety recovers. ### Resources specific to this chapter - **[The Five Dysfunctions of a Team. Lencioni](https://www.tablegroup.com/product/dysfunctions/)** (book): Trust as the base layer of team performance. - **[Google re:Work. Project Aristotle](https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness/)** (article): Psychological safety as the top team effectiveness factor. - **[Blameless postmortems. Etsy / SRE thinking](https://sre.google/sre-book/postmortem-culture/)** (essay): How to learn from failure without scapegoats. --- ## Chapter 07: Operating the Team **Slug:** `operating` **URL:** https://lead-without-the-title.grok.me/read/operating **Subtitle:** Rituals, ownership, and execution systems **Reading time:** ~20 minutes Great culture without operating rhythm becomes wishful thinking. Team leads design systems: how work is planned, how quality is protected, how ownership is clear, and how the team learns. Rituals should serve outcomes - cut any meeting that exists only because it always has. ### Core rituals that earn their keep - Weekly planning: capacity-aware commitments, not fantasy lists. - Daily async stand-up: blockers and needs, not novel-length status. - 1:1s: coaching and truth, not project interrogation. - Demo / show-and-tell: share finished value, build pride. - Retros: one or two changes with owners, not a complaint dump. - On-call review: toil reduction and knowledge spread. ### Ownership model Ambiguous ownership is the root of slow delivery. Every important surface should have a directly responsible individual. Prefer single-threaded owners with consult rights over committee ownership. Document “what done means” for recurring work: code review SLA, release checklist, support handoff. ### Quality is a management choice If everything is a fire drill, quality will lose. Budget explicit capacity for debt, testing, and observability. Celebrate prevention. Make review culture kind and rigorous: challenge the design, not the designer. **WIP limit:** If your team is “busy” but nothing finishes, lower work-in-progress. Finishing compounds confidence more than starting. ### Rituals that earn their minutes Every meeting should produce a decision, a risk list, or shared understanding you cannot get async. If a ritual only exists because “we always have it,” redesign or kill it. Protect maker time like a production SLO. - Planning: outcomes and capacity, not wish lists. - Standup: blockers and WIP, not novels. - Retro: one system change with an owner. - Review: quality bar and teaching, not gatekeeping theater. ### Ownership maps beat hero culture Publish who owns what path, service, or problem space. When ownership is fuzzy, the strongest personality becomes the bottleneck. Revisit the map when the org or architecture changes. 1. List critical user journeys and systems. 2. Name a primary owner and a backup for each. 3. Define what “owned” means: on-call, design authority, roadmap input. 4. Review quarterly after incidents and roadmap shifts. **Health check:** If only one person can ship a change safely, you do not have a team process. You have a single point of failure with a title. ### End-of-chapter drill - **Prompt:** Pick one ritual to kill, shorten, or redesign. Write the new purpose in one sentence and try it for two weeks. - **Hint:** If it produces no decision or risk list, it is a candidate. - **Reflection:** Meetings without outcomes are just expensive calendars. ### Diagrams for this topic #### Team operating system - **Kind:** stack - **Cadence**: - Standup - Planning - Review - Retro - 1:1s - **Artifacts**: - Priority stack - Ownership map - ADRs - Runbooks - OKRs/metrics - **Health signals**: - WIP age - MTTR - Review latency - Escape defects - Energy #### WIP limit effect - **Kind:** compare - **No WIP limit** (bad): - 8 half-done stories - Context thrash - Late discovery of blockers - **WIP limit = capacity** (good): - 2-3 active stories - Faster finish - Blockers visible early ### Worked examples #### Retro that changes next week - **Setting:** Retro becomes a complaint lounge with no owners. - **Common miss:** Capture 12 actions; none land. - **Stronger move:** Pick one system fix. Name owner. Put it on the priority stack for next week. Review it first in the next retro. - **Outcome:** Team trusts the ritual again. #### Standup as status theater - **Setting:** Daily standup runs 25 minutes; blockers still surface in DMs hours later. - **Common miss:** Add more questions to the standup template. - **Stronger move:** Cap standup at 10 minutes, move deep topics to a parking lot with owners, and track WIP age on the board instead. - **Outcome:** Meetings shrink; blockers get visible earlier in the work system. ### Resources specific to this chapter - **[Accelerate. Forsgren, Humble, Kim](https://itrevolution.com/product/accelerate/)** (book): DORA metrics and culture of delivery. - **[Team Topologies](https://teamtopologies.com/)** (book): Team shapes, interaction modes, cognitive load. - **[Kanban / WIP limits primer](https://www.atlassian.com/agile/kanban/wip-limits)** (article): Simple visual of flow vs multitasking. --- ## Chapter 08: Stakeholders & Upward Management **Slug:** `stakeholders` **URL:** https://lead-without-the-title.grok.me/read/stakeholders **Subtitle:** Translate engineering into decisions leaders can use **Reading time:** ~15 minutes Team leads sit on a bridge between product, design, support, security, and leadership. Your job is translation: turn technical reality into decision-ready information, and turn business goals into technical plans without lying about constraints. ### Manage expectations early - Share ranges and confidence, not false precision. - Surface risks with mitigation options, not raw anxiety. - Never surprise your manager with news they should have had last week. - Escalate with a recommendation, not only a problem. ### Status that executives actually read 1. Green / yellow / red against outcomes, not task count. 2. What changed since last update. 3. Biggest risk and what you need from them. 4. Next milestone date and confidence. ### Partnering with product Healthy product-engineering partnerships negotiate scope, not blame. Bring implementation insight early. Push for problem clarity before solution lock-in. Offer technical options that expand product possibilities, not only constraints that shrink them. > Your manager should hear bad news from you first, with a plan second, and without drama third. ### Expectation contracts Most stakeholder pain is mismatched expectations, not bad intent. Write the contract out loud: what “done” means, what the date assumes, what you cut first if load grows, and how often you will update. - Confirm the decision you need (approve scope, fund headcount, accept risk). - State confidence ranges (e.g. 70% on date if no new P0s). - Document dependencies you do not control. - Revisit the contract when inputs change; silence is not consent. ### Managing up without managing out your team 1. Translate team reality into executive language: outcome, risk, ask. 2. Protect makers from thrash; absorb ambiguity yourself when you can. 3. Never throw the team under the bus to look responsive. 4. Escalate early with options, not late with surprises. ### End-of-chapter drill - **Prompt:** Write a three-bullet exec update: progress, risk, ask. Send it before you are asked. - **Hint:** No jargon without translation. - **Reflection:** Managing up is a service, not a performance. ### Diagrams for this topic #### Upward update template - **Kind:** flow - **Steps:** 1. Outcome status 2. What changed 3. Risk + impact 4. Options 5. Recommendation + ask #### Expectation alignment - **Kind:** compare - **Caption:** Force the trade: you cannot fix date, scope, and resources all at once. - **Date-driven ask** (neutral): - Fixed launch date - Scope must flex - Risks explicit - **Scope-driven ask** (neutral): - Fixed scope - Date becomes range - Capacity visible ### Worked examples #### Unrealistic launch date - **Setting:** VP wants the feature in two weeks. Estimate is six. - **Common miss:** Quietly agree, then slip late. - **Stronger move:** Offer three options: cut scope to MVP in two weeks; full scope in six; full scope in four with borrowed help and named risks. - **Outcome:** VP chooses with eyes open; trust rises. #### The surprise exec demo - **Setting:** An exec asks for a demo Friday of work still in discovery. - **Common miss:** Have the team scramble nights to fake polish. - **Stronger move:** Offer a discovery readout with open questions, risks, and a realistic demo date; show one thin vertical slice if it is honest. - **Outcome:** You protect quality and trust; exec still gets signal. ### Resources specific to this chapter - **[The Making of a Manager. Julie Zhuo](https://www.juliezhuo.com/book/makingofamanager.html)** (book): Stakeholder and expectation chapters for new managers. - **[An Elegant Puzzle, org constraints](https://lethain.com/elegant-puzzle/)** (book): How to talk about staffing and system limits upward. - **[RACI / DACI quick guide](https://www.atlassian.com/team-playbook/plays/daci)** (tool): Clarify who decides vs who is consulted. --- ## Chapter 09: Self-Management & Resilience **Slug:** `self` **URL:** https://lead-without-the-title.grok.me/read/self **Subtitle:** Lead yourself so you can lead others **Reading time:** ~14 minutes Burned-out leads make fragile teams. Looking after yourself is not selfish. It is operational stability. People copy what you do: how you handle stress, whether focus time is real, whether you can say “I do not know yet.” ### Protect your operating system - Block maker time for hard thinking, even if it is two mornings a week. - Batch context switches: reviews, messages, and meetings in arcs. - Keep a personal weekly review: priorities, energy, people risks. - Have a peer or mentor outside your reporting line. ### Emotional regulation under pressure During incidents and heated debates, your nervous system is contagious. Slow your speech. Separate immediate containment from long-term fixes. If you need ten minutes, take them. A calm lead is a performance feature. ### Ethical boundaries You will be asked to stretch estimates, hide risk, or push people past healthy limits. Build a personal red line list in advance. Credibility is hard to rebuild once you become the person who sugarcoats reality. **Energy audit:** Once a month, list tasks that drain you vs. energize you. Delegate, redesign, or timebox drains. Leadership without recovery becomes attrition with a title. ### Boundaries you can say out loud Teams copy what you tolerate in yourself. If you answer every ping at midnight, you teach that rest is optional. Sustainable pace is a delivery strategy. - Offline hours and on-call rotations that are real, not theater. - Meeting-free focus blocks on the shared calendar. - A personal policy for Slack after-hours (batch, or emergency only). - Delegation of hero tasks that only feel urgent because you are fast. ### Learning loop for leads 1. Pick one leadership skill per quarter (feedback, facilitation, hiring). 2. Practice in low-stakes settings before high-stakes ones. 3. Ask for specific feedback after meetings: what should I do less of? 4. Write a short retrospective on your own decisions monthly. ### End-of-chapter drill - **Prompt:** Block two maker sessions next week and one offline evening. Tell the team your coverage plan. - **Hint:** Sustainability is a delivery strategy. - **Reflection:** If you never go offline, you teach that rest is optional. ### Diagrams for this topic #### Energy budget (weekly) - **Kind:** stack - **Protect**: - Deep work blocks - Sleep / exercise - No-meeting focus time - **Invest**: - 1:1s - Coaching - Hard decisions - **Limit**: - Status theater - Hero coding - Always-on Slack #### Stress response → lead response - **Kind:** flow - **Steps:** 1. Notice body signal 2. Pause 10 seconds 3. Name the fact 4. Choose one next step 5. Communicate calmly ### Worked examples #### Burnout edge - **Setting:** You answer Slack at 1am three nights in a row “just to unblock.” - **Common miss:** Tell yourself this is leadership. - **Stronger move:** Set on-call boundaries, delegate a rotating owner, announce offline hours, and fix the page noise. - **Outcome:** You model sustainability; team copies your boundaries. #### Always-on lead - **Setting:** You answer Slack at 11pm “just this week” for the third month. - **Common miss:** Keep going; the team needs you. - **Stronger move:** Set written offline hours, rotate a primary contact, and fix the alert noise causing after-hours pings. - **Outcome:** You model sustainability; the team stops copying burnout. ### Resources specific to this chapter - **[Resilient Management, energy & change](https://resilient-management.com/)** (book): Manager stress, change, and sustainable pace. - **[The Making of a Manager, self-doubt chapters](https://www.juliezhuo.com/book/makingofamanager.html)** (book): Normalizes early-manager feelings with practical tools. - **[Manager README examples (collection)](https://github.com/sethbergman/manager-readme)** (tool): Browse working-with-me docs; write your own boundaries and coaching style. --- ## Chapter 10: First 90 Days Playbook **Slug:** `playbook` **URL:** https://lead-without-the-title.grok.me/read/playbook **Subtitle:** A concrete onboarding plan for the lead role **Reading time:** ~24 minutes Whether you just got the title or you already lead without it, the first ninety days set patterns that are hard to undo. Use this as a default plan. Adapt it to company size and how healthy the team already is. The trap is big theater: reorgs, tool migrations, and manifesto rewrites before you understand the system. The opposite trap is pure observation with no signal that anything will improve. Aim for listen hard, change carefully, and ship credibility early. ### Days 1-30: Listen and map - 1:1 with every teammate: strengths, frustrations, aspirations. - Map stakeholders, systems, on-call pain, and delivery bottlenecks. - Learn how success is actually measured (not just OKR slides). - Ship one small reliability or developer-experience win for credibility. - Avoid reorganizations and big process rewrites unless the house is on fire. - Write a private “system notes” doc: people map, risk list, open questions. **Listening tour questions:** What should I protect? What should I change? Where do we waste time? Who is overloaded? What would make the next quarter less painful? ### Days 31-60: Clarify and stabilize - Publish team mission, ownership map, and working agreements. - Fix one chronic ritual (planning, review SLA, or incident follow-up). - Establish a lightweight priority stack with product. - Start growth conversations; pick one coaching focus per person. - Make risks visible upward with options. - Define how the team handles interrupts and on-call load. ### Days 61-90: Raise the bar - Run a retrospective on the first 90 days with the team. - Propose a 6-month plan: outcomes, capacity, and 1-2 system bets. - Close or escalate lingering people or ownership ambiguities. - Install measurement you will actually read (DORA-ish or simpler). - Identify a deputy or backup for critical lead duties when you are out. - Share a written narrative upward: what you learned, what you will do next. ### 90-day artifacts checklist If these artifacts exist and are used, you are not just “busy leading.” You are building a system. 1. Team mission and non-goals (one page). 2. Ownership map (services, surfaces, or domains). 3. Priority stack and WIP limits agreed with product. 4. Working agreements (reviews, meetings, on-call). 5. Risk list with owners and next review date. 6. Personal growth focus per report (or peer coaching focus if no reports). ### Common failure modes - Changing process weekly so nothing stabilizes. - Becoming the hero on-call and the bottleneck for decisions. - Optimizing for your manager’s comfort only, not team health. - Avoiding one hard people conversation until day 89. - Shipping no credibility win, so the team only sees meetings. > The first 90 days are a down payment on trust. Spend it on clarity and small finished things, not on theater. ### End-of-chapter drill - **Prompt:** If you are in a first-90 window, list listen / stabilize / raise-the-bar actions for the next two weeks. If not, write a 90-day plan for a new initiative you lead. - **Hint:** Avoid reorg theater early. - **Reflection:** Patterns set early are expensive to reverse. ### Diagrams for this topic #### First 90 days arc - **Kind:** flow - **Steps:** 1. Days 1-30: Listen & map 2. Days 31-60: One system win 3. Days 61-90: Raise the bar 4. Ongoing: Rituals + coaching #### Discovery map - **Kind:** matrix - **Matrix headers:** People | Process | Product/tech - **Learn:** 1:1s, history | How work flows | Top risks & debt - **Signal:** Trust levels | Bottlenecks | User pain - **Act:** Allies | One ritual fix | One reliability win ### Worked examples #### Week-one reorg urge - **Setting:** You inherit a messy team. You want to rename squads immediately. - **Common miss:** Announce a reorg on day 5. - **Stronger move:** Spend two weeks on 1:1s and delivery data. Ship one clarity win (ownership map). Propose structural change with evidence in week 6-8 if still needed. - **Outcome:** Credibility before surgery. #### Process rewrite on day 10 - **Setting:** You inherit chaotic planning and want a full agile reset immediately. - **Common miss:** Announce new ceremonies for everyone next Monday. - **Stronger move:** Diagnose for two weeks, fix one painful ritual with the team, and pilot changes with explicit review date. - **Outcome:** Credibility first; change sticks because people helped design it. #### 90 days of reorg theater - **Setting:** You inherited a messy team and want to prove leadership. Day 10 you propose a squad restructure. - **Common miss:** Redraw the org chart before you map ownership, pain, and stakeholders. - **Stronger move:** Listen tour + ownership map + one credibility win. Save structural change for after day 60 with evidence. - **Outcome:** The team experiences stability first; later changes have legitimacy. ### Resources specific to this chapter - **[The First 90 Days. Michael Watkins](https://hbr.org/books/the-first-90-days)** (book): Classic transition playbook (adapt to eng contexts). - **[The Manager’s Path, first-time manager](https://www.oreilly.com/library/view/the-managers-path/9781491973882/)** (book): Practical eng-specific early moves. - **[Your team’s operating manual template](https://github.com/readme/guides/engineering-team-practices)** (tool): Inspiration for writing how the team works. --- ## Chapter 11: Hiring, Leveling & Growth Paths **Slug:** `hiring-leveling` **URL:** https://lead-without-the-title.grok.me/read/hiring-leveling **Subtitle:** Raise the bar without turning hiring into theater **Reading time:** ~22 minutes Hiring and leveling shape your team for years, not just this quarter. One weak hire multiplies on-call load and review debt. A fuzzy ladder turns promos into politics. You do not need to run HR to run a fair, high-signal eng process. Treat hiring like product work. The role is the problem, the scorecard is the acceptance test, the loop is the UX, and onboarding is activation. Treat leveling as a shared language for scope, not a personality contest. ### Role design before the job post 1. Name the outcomes the seat must own in 6-12 months. 2. List must-have skills vs teachable skills. 3. Decide level band (e.g. mid/senior) and why the work needs that altitude. 4. Write a one-page scorecard: 4-6 attributes with observable signals. 5. Align with your manager on headcount, timeline, and compensation constraints early. **Scorecard example attributes:** Problem decomposition, code quality under time pressure, collaboration, ownership, system design judgment, and communication. Each needs a strong / mixed / weak signal definition. ### Hiring loop that produces signal Debriefs should start from evidence: In the design prompt they skipped failure modes beats felt junior. The hiring manager (often you) is responsible for calibration and bias checks: who got the benefit of the doubt, and why? - Screen for motivation and basics; do not burn panel time on obvious mismatches. - One structured coding or work-sample session tied to real work shape. - One design or architecture conversation for senior+ seats. - One values / collaboration interview with concrete scenarios. - Same core questions per candidate at a level so comparisons are fair. - Written feedback within 24 hours using the scorecard, not vibes. ### Leveling and career ladders A useful ladder describes scope of impact, ambiguity handled, and influence radius. It should not be a checklist of buzzwords. Map your company ladder to plain language your team can use in 1:1s. - Junior: delivers well-scoped tasks with guidance; learns systems. - Mid: owns features end-to-end; reliable reviews; mentors informally. - Senior: multi-sprint outcomes; design judgment; unblocks others. - Staff+: multi-team or multi-quarter technical direction; multiplies org. - Lead/EM: people + delivery systems; hiring; cross-functional outcomes. 1. Publish what meets vs exceeds looks like for the next cycle. 2. Separate promotion evidence (sustained scope) from stretch assignments (temporary). 3. Never surprise someone in calibration: ongoing feedback first. 4. Document promo packets with outcomes, not only activity lists. ### Growth conversations and tough calls Not every strong IC wants management. Offer dual paths when your org supports them. When performance gaps appear, use written expectations, support, and timelines. Avoid indefinite almost-there limbo. > You hire systems of work, not heroes. Level people for the problems you need solved next year. **Fairness test:** Would you defend this hire/promo decision with the same evidence if the candidate background were different? If not, fix the process before the decision. ### End-of-chapter drill - **Prompt:** Draft a four-attribute scorecard for your next open role (or a hypothetical senior seat). Define strong vs weak signals. - **Hint:** Must-have vs teachable. - **Reflection:** If the panel cannot score the same way, you will hire on vibes. ### Diagrams for this topic #### Hiring as a product loop - **Kind:** flow - **Caption:** Improve the loop every search, not only the headcount number. - **Steps:** 1. Role outcomes 2. Scorecard 3. Loop design 4. Calibrated debrief 5. Offer + onboard 6. Retro the loop #### Level signals (scope view) - **Kind:** stack - **Mid**: - Feature ownership - Reliable delivery - Local mentorship - **Senior**: - Multi-sprint outcomes - Design judgment - Unblocks team - **Staff / Lead**: - Multi-team impact - Org impact - People or tech direction ### Worked examples #### Vibe-based yes - **Setting:** A charismatic candidate interviews well but scorecards are thin and inconsistent. - **Common miss:** Hire on “culture fit” energy and hope onboarding fixes gaps. - **Stronger move:** Require written scorecards from every interviewer, debrief attribute-by-attribute, and re-interview weak signal areas or decline. - **Outcome:** You protect the bar and create a defensible decision. #### Promo surprise - **Setting:** An engineer expects senior this cycle; you have not given hard feedback. - **Common miss:** Deny in calibration with no prior trail. - **Stronger move:** Use ongoing 1:1 evidence, a written gap plan mid-cycle, and a clear scope target for the next window. - **Outcome:** Even a no is fair; trust survives. ### Resources specific to this chapter - **[The Manager’s Path, hiring chapters](https://www.oreilly.com/library/view/the-managers-path/9781491973882/)** (book): Practical eng hiring and tech lead transition context. - **[Who. Geoff Smart & Randy Street](https://www.ghsmart.com/who)** (book): Structured scorecard interviewing (adapt to eng loops). - **[Lara Hogan, interview loop resources](https://larahogan.me/blog/)** (essay): People-centered management essays useful for debriefs and feedback. - **[Hiring scorecard template (in-app)](/templates#hiring-scorecard)** (tool): Copy-ready scorecard from this site’s templates pack. --- ## Chapter 12: Software Architecture Best Practices **Slug:** `architecture-practices` **URL:** https://lead-without-the-title.grok.me/read/architecture-practices **Subtitle:** Quality attributes, trade-offs, and standards that survive contact with production **Reading time:** ~20 minutes Once you lead a team, architecture stops being a personal craft project. You set the bar for how people design, write things down, and change systems under real limits: time, headcount, risk, and the debt already in production. Best practices are not fashion. They are habits that protect quality while you still ship. ### Start from quality attributes, not frameworks Name what must be true before debating tools. Availability, latency, consistency, security, cost, operability, and team cognitive load are design inputs. A cache is not a goal; p99 latency under load is. Kubernetes is not a goal; deployability and recovery are. - List the top three quality attributes for the system this quarter. - Attach a measurable signal to each (SLO, budget, audit requirement). - Reject designs that optimize vanity scale you do not have. ### Core practices that scale with teams 1. Boundaries first: clear module or service ownership, public interfaces, private internals. 2. Explicit contracts: APIs, events, schemas, and error semantics written down. 3. Evolutionary change: prefer reversible steps and strangler patterns over big-bang rewrites. 4. Observability by design: logs, metrics, traces, and correlation IDs as first-class deliverables. 5. Security and privacy in the path: authn/z, data classification, least privilege, threat notes on sensitive flows. 6. Test the seams: contract tests, load tests on critical paths, chaos only where it teaches. 7. Document decisions, not novels: ADRs for choices that will be re-litigated. ### Architecture smells leads should catch early - Shared databases across team boundaries with no ownership. - Chatty synchronous chains with no timeout, bulkhead, or backoff story. - Golden path missing: every feature invents a new stack. - Undocumented critical path: only one person can debug production. - Config and secrets treated as afterthoughts. - Unlimited coupling via a utility package everyone imports. **Lead move:** In design review, ask: What fails first? Who is paged? What is the rollback? What quality attribute did we optimize, and which did we sacrifice? ### Standards without bureaucracy Publish a short architecture checklist for PRs and design docs: boundaries, data ownership, failure modes, observability, security, cost, and migration plan. Keep it one page. Enforce through review and examples, not a 40-page governance PDF nobody reads. > Best practice is what your team can execute under load, not what looks impressive on a whiteboard. ### Tech debt as a portfolio, not a complaint If you only say “we have debt,” you will lose the funding argument. Frame debt like a portfolio: risk if you ignore it, cost to fix it, and what option it unlocks. Fold paydown into feature work when you can. Save dedicated capacity when debt blocks safety or speed. 1. Inventory top debt items with owner, user impact, and incident link if any. 2. Score by risk, frequency, and blast radius, not by engineer annoyance alone. 3. Propose a quarterly debt budget (e.g. 15-20% capacity) with explicit cuts if skipped. 4. Prefer strangler and seam fixes over multi-quarter rewrites without milestones. 5. Celebrate debt retired in demos so the org sees product value, not only cleanup. **Debt conversation template:** If we do nothing: risk. If we invest N weeks: outcome and metric. If we only patch: residual risk. Ask stakeholders to choose with eyes open. ### End-of-chapter drill - **Prompt:** Write a one-page debt item: risk if untouched, effort, metric improved, residual risk if deferred. - **Hint:** Use the templates pack if you want a skeleton. - **Reflection:** “We have debt” without risk language does not get funded. ### Diagrams for this topic #### Quality attributes before tech - **Kind:** flow - **Steps:** 1. Name top 3 attributes 2. Make them measurable 3. List tactics 4. Call out sacrifices 5. Record ADR #### Architecture decision record (ADR) - **Kind:** stack - **ADR skeleton**: - Context - Decision drivers - Options considered - Decision - Consequences - Status / date ### Worked examples #### Cache by default - **Setting:** Latency is high. Someone suggests Redis in front of everything. - **Common miss:** Add Redis because “we’ll need it.” - **Stronger move:** Measure p95, find hot path, cache one read model with TTL and invalidation plan, document trade-offs in ADR. - **Outcome:** Complexity paid only where it earns latency. #### Debt as a rant - **Setting:** Engineers want a quarter rewrite; product only hears “cleanup.” - **Common miss:** Argue from frustration and elegance. - **Stronger move:** Present a debt portfolio item: risk if untouched, effort, metric improved, residual risk if deferred. - **Outcome:** Stakeholders can fund or explicitly accept risk. ### Resources specific to this chapter - **[Fundamentals of Software Architecture. Richards & Ford](https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/)** (book): Characteristics, styles, and soft skills of architects. - **[Clean Architecture. Robert C. Martin](https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/)** (book): Dependency rules and policy vs detail. - **[ADR GitHub organization](https://adr.github.io/)** (tool): Templates and culture for architecture decision records. - **[Architecture Katas](https://architecturalkatas.com/)** (tool): Practice quality-attribute trade-offs with scenarios. --- ## Chapter 13: System Design **Slug:** `system-design` **URL:** https://lead-without-the-title.grok.me/read/system-design **Subtitle:** How to frame, facilitate, and evaluate designs as a lead **Reading time:** ~21 minutes System design is how you turn product needs into a plan you can build: pieces, data flows, scale guesses, and what breaks first. You do not need to win every interview-style design prompt. You need design talks that end in shippable clarity. ### A lead-friendly design sequence 1. Clarify the problem: user journeys, non-goals, constraints, and success metrics. 2. Estimate order of magnitude: QPS, data size, growth, read/write ratio, geography. 3. Sketch a simple happy path before adding cleverness. 4. Identify bottlenecks and single points of failure. 5. Choose storage and consistency models on purpose (not by habit). 6. Design APIs and events as product surfaces. 7. Plan rollout: feature flags, migration, dual-write, backfill, rollback. 8. Define SLOs and dashboards that prove the design in production. ### Building blocks to keep in your mental kit - Load balancing, caching, CDNs, and rate limiting. - Queues and streams for async decoupling and spike absorption. - Relational vs document vs key-value vs search: pick for access patterns. - Partitioning/sharding, replication, and failover basics. - Idempotency, exactly-once illusions, and at-least-once reality. - Auth boundaries, multi-tenancy isolation, and audit trails. ### Facilitate design reviews that teach Your job in review is not to be the smartest person in the room. It is to surface missing requirements, risk, and ownership. Invite quieter engineers first. Separate preferences from constraints. Capture decisions live. - Start with the problem statement and constraints on one slide or doc section. - Require at least two viable options with trade-offs. - Time-box bikesheds; park aesthetic debates that do not move risk. - End with owners, open questions, and a follow-up date. **Interview vs production:** Interview system design optimizes for signal in 45 minutes. Production system design optimizes for operability over years. Weight the latter when leading a team. ### Common system design failure modes - Over-design for 100x scale when 3x is the real horizon. - Under-design for failure: no timeouts, retries, or poison-message plan. - Ignoring multi-region, compliance, or cost until launch week. - Designing the perfect service cut while the domain language is still mush. > Good system design is boring on purpose: clear flows, known limits, and failures that are cheap to understand. ### API design as a product surface Public and cross-team APIs outlive the code behind them. Treat contracts like product: stable names, clear errors, versioning, and a deprecation policy. Internal APIs still need owners and compatibility rules. - Resource modeling: nouns and actions that match domain language. - Idempotency keys for unsafe writes; pagination and filtering that scale. - Error model: machine-readable codes plus human messages. - Authn/z at the edge; never rely on callers are trusted forever. - Versioning strategy (URL, header, or additive fields) chosen on purpose. - Contract tests and consumer-driven checks where multiple teams meet. - Deprecation: announce, dual-run, measure, then remove with a date. **Review question:** Can a new consumer integrate from the docs alone? If not, the API is under-specified, not just under-documented. ### End-of-chapter drill - **Prompt:** Pick a system you own. Sketch happy path, top bottleneck, and one failure mode with mitigation. - **Hint:** Include timeouts and ownership of the page. - **Reflection:** Design without failure modes is a wish. ### Diagrams for this topic #### 45-60 min interview / design loop - **Kind:** flow - **Steps:** 1. Clarify requirements 2. Estimate scale 3. API + data model 4. High-level boxes 5. Deep dive 1-2 parts 6. Failures & trade-offs #### Read-heavy vs write-heavy tactics - **Kind:** compare - **Read-heavy** (good): - CDN / cache - Replicas - Materialized views - CQRS-ish reads - **Write-heavy** (good): - Partition keys - Async queues - Batch writes - Idempotency keys #### URL shortener sketch (components) - **Kind:** stack - **Caption:** Classic practice problem: uniqueness, caching, and read amplification. - **Path**: - Client → API - Key gen / hash - Primary store - Cache hot redirects - Analytics via queue ### Worked examples #### Jumping to microservices - **Setting:** Design a notifications system in an interview / design review. - **Common miss:** Draw 12 services before requirements. - **Stronger move:** Clarify: channels, volume, delivery guarantees, latency. Estimate. Then 4-5 boxes with one deep dive on fan-out. - **Outcome:** You show process skill and trade-off judgment. #### API contract freeze without consumers - **Setting:** A team wants to publish v1 of a shared API next week with no external consumer pilot. - **Common miss:** Ship the OpenAPI file and call it done. - **Stronger move:** Run a design review with two consumer teams, add idempotency and error model, and pilot with one client before freeze. - **Outcome:** Fewer breaking changes; API becomes a product surface. ### Resources specific to this chapter - **[System Design Interview Vol 1 & 2. Alex Xu](https://bytebytego.com/courses/system-design-interview)** (book): Step-by-step designs for common large systems. - **[ByteByteGo YouTube](https://www.youtube.com/@ByteByteGo)** (video): Visual architecture explainers. - **[freeCodeCamp. System Design Course](https://www.youtube.com/watch?v=C842vFY5kRo)** (video): APIs, DBs, caching, infra foundations. - **[Gaurav Sen, system design playlist](https://www.youtube.com/playlist?list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX)** (video): Primitives: hashing, queues, partitions, rate limits. - **[Grokking the System Design Interview](https://www.educative.io/courses/grokking-the-system-design-interview)** (tool): Interactive practice path (paid). --- ## Chapter 14: System Architecture **Slug:** `system-architecture` **URL:** https://lead-without-the-title.grok.me/read/system-architecture **Subtitle:** The long-lived structure: domains, runtime, and evolution **Reading time:** ~20 minutes System architecture is the long-lived shape of the whole: domain boundaries, deploy map, how systems talk, and the rules for change. System design answers how we build this feature path. Architecture answers how the machine stays coherent when people and products keep moving. ### Architecture views a lead should maintain - Domain view: bounded contexts, ubiquitous language, ownership map. - Runtime view: services, data stores, queues, external dependencies. - Deployment view: environments, pipelines, regions, blast radius. - Data view: sources of truth, retention, lineage, consistency expectations. - Security view: trust boundaries, identity, secrets, compliance zones. ### Monolith, modular monolith, services: choose with eyes open There is no universal winner. A modular monolith with hard module boundaries often beats a premature microservice mesh for a small team. Services earn their keep when independent deployability, scaling, or team autonomy clearly outweigh distributed-system cost. 1. Prefer modularity of design before distribution of deployment. 2. Split on domain and change frequency, not on folder count. 3. Pay the tax of distributed tracing, contracts, and on-call only when needed. 4. Revisit splits quarterly with incident and delivery data, not slogans. ### Integration styles and coupling - Synchronous request/response: simple, but chains amplify latency and failure. - Async events/messages: resilient decoupling, harder end-to-end reasoning. - Shared data: fastest short-term, most expensive long-term coupling. - Anti-corruption layers at messy boundaries with legacy or vendors. **Architecture fitness functions:** Automate a few checks that protect architecture intent: dependency direction tests, contract tests, max service depth, schema compatibility, or bundle size budgets. Architecture that is not enforced drifts. ### Lead responsibilities for system architecture 1. Keep a living architecture page: diagram, owners, SLOs, top risks. 2. Run a lightweight architecture review for cross-cutting changes. 3. Fund debt that blocks safety or speed; kill gold-plating rewrites. 4. Grow architects-in-practice on the team through design rotations. 5. Align org structure with desired architecture (Conway awareness). > System architecture is a leadership product: it either reduces cognitive load or multiplies it. ### End-of-chapter drill - **Prompt:** Draw (boxes or bullets) domain view + runtime view for your area. Mark one boundary that is lying today. - **Hint:** Lying boundary = shared DB, unclear owner, or chatty coupling. - **Reflection:** Architecture docs that nobody updates are fiction. ### Diagrams for this topic #### Monolith → modular → services - **Kind:** flow - **Steps:** 1. Modular monolith 2. Clear module APIs 3. Extract high-churn edge 4. Independent deploy only when paid for 5. Fitness functions guard boundaries #### Data ownership trade-offs - **Kind:** compare - **Shared DB** (bad): - Fast start - Hidden coupling - Schema freezes everyone - **Service-owned data** (good): - Clear contracts - Evolution freedom - Needs sync patterns #### Evolution loop - **Kind:** cycle - **Steps:** 1. Measure fitness 2. Find bottleneck 3. Small reversible change 4. Verify in prod 5. Document decision ### Worked examples #### Premature service split - **Setting:** Two teams share a modular monolith. Deploy friction is high. - **Common miss:** Split into 15 microservices in one quarter. - **Stronger move:** Enforce module boundaries, add CI ownership checks, extract the one domain with independent scale and team ownership first. - **Outcome:** You pay distributed tax only where Conway + scale demand it. #### Service split for the org chart meme - **Setting:** Leadership wants microservices because “scale,” with one team of six. - **Common miss:** Split the monolith into 12 repos in a quarter. - **Stronger move:** Modularize first, extract one domain with independent scale needs, and add fitness checks for boundaries. - **Outcome:** You gain deploy independence without paying full distributed tax yet. ### Resources specific to this chapter - **[Designing Data-Intensive Applications. Kleppmann](https://dataintensive.net/)** (book): Replication, partitioning, transactions, streams. - **[Software Architecture: The Hard Parts](https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)** (book): Granularity, coupling, data ownership. - **[Building Evolutionary Architectures](https://www.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/)** (book): Fitness functions for change. - **[Team Topologies](https://teamtopologies.com/)** (book): Conway’s law in practice: team ↔ architecture. --- ## Chapter 15: AI Tooling for Leads **Slug:** `ai-for-leads` **URL:** https://lead-without-the-title.grok.me/read/ai-for-leads **Subtitle:** Use AI to multiply judgment, not to skip it **Reading time:** ~18 minutes AI can draft updates, summarize threads, sketch designs, and generate test ideas. It cannot own your ethics, your team relationships, or production risk. Leads who treat models as interns with no judgment ship plausible nonsense at scale. Your job is to set norms: where AI is encouraged, where it is banned, how people review output, and how you talk about confidentiality. ### Where AI helps leads this week - Turn rough notes into a clear status update you still verify. - Summarize long RFCs or incident timelines for stakeholders. - Generate interview rubrics or scorecard drafts you edit. - Brainstorm options and failure modes before a design review. - Create first-pass docs, then make a human accountable for accuracy. ### Where AI must not decide 1. Hiring yes/no without human evidence and debrief. 2. Performance ratings, PIP language, or exit decisions. 3. Security-sensitive design without expert review. 4. Customer or legal commitments. 5. Anything that needs production authority without tests and owners. **Review rule:** If you would not sign your name under the output, do not paste it into a doc, PR, or message. AI drafts. You own. ### Team norms that prevent mess Write a one-page AI use policy for the team. Cover secret handling, citation of AI-assisted work when it matters, review expectations for code, and examples of good use. Update it when tools change. - Never paste secrets, credentials, or private personal data into untrusted tools. - Prefer enterprise or approved tools for company code. - Require tests and human review for AI-generated code paths. - Teach juniors to question fluent answers, not worship them. > AI is a power tool. Power tools without training still take fingers. ### End-of-chapter drill - **Prompt:** Write a five-line AI use norm for your team: allowed, banned, review rule, secrets rule, example of good use. - **Hint:** Keep it one page max. - **Reflection:** If norms are unwritten, everyone invents their own risk appetite. ### Diagrams for this topic #### AI assist loop - **Kind:** flow - **Steps:** 1. Human intent 2. AI draft 3. Human verify 4. Ship with owner 5. Retro the norm #### Use vs do not use - **Kind:** compare - **Good fit** (good): - Drafts you verify - Brainstorm options - Summaries with source check - Rubric first drafts - **Do not outsource** (bad): - Hire / fire decisions - Unreviewed prod code - Secret data to random tools - Legal promises ### Worked examples #### Fluent wrong design - **Setting:** An engineer pastes an AI architecture into a design review as final. - **Common miss:** Rubber-stamp because it reads polished. - **Stronger move:** Require failure modes, owners, and a human diagram of the critical path before approval. - **Outcome:** You keep AI speed without shipping fiction. #### Secret paste - **Setting:** Someone pastes production config into a public chatbot to debug. - **Common miss:** Ignore it as a one-off. - **Stronger move:** Rotate secrets if needed, write the ban into team norms, and teach approved tools. - **Outcome:** Risk drops and norms become real. ### Resources specific to this chapter - **[Team AI norms template](/templates#ai-team-norms)** (tool): One-page allowed / banned / review rules. - **[OWASP LLM top risks (overview)](https://owasp.org/www-project-top-10-for-large-language-model-applications/)** (essay): Security framing for LLM apps and usage. --- ## Chapter 16: Pay, Performance & Exits **Slug:** `pay-performance-exits` **URL:** https://lead-without-the-title.grok.me/read/pay-performance-exits **Subtitle:** Compensation, PIPs, and hard conversations with care **Reading time:** ~20 minutes Money, performance, and exits are where trust is won or destroyed. You may not control the full compensation system, but you control preparation, honesty, and fairness in how you show up. Avoiding these talks does not protect people. It surprises them later. ### Compensation and offers Learn your company's bands, levels, and process before you negotiate with candidates or advocate for your team. Bring market data when you have it, and bring internal equity concerns with specific names and evidence, not vibes. 1. For offers: align level, scope, and pay band before the verbal yes. 2. Document what the person will own in six months so level matches work. 3. For raises: separate market adjustment, promo, and retention risk. 4. Never promise numbers you cannot fund. 5. If the answer is no, explain constraints and the next review window. **Offer conversation:** Lead with role excitement and scope, then total package, then room to answer questions. Do not lowball to “see what happens.” People talk, and so does your reputation. ### Performance clarity before a PIP A PIP should never be the first time someone hears they are off track. Use ongoing feedback, written expectations, and support. If performance is still below the bar, partner with HR early and write a plan that is specific, time-bound, and fair. - Describe observed gaps with examples, not labels. - Define what “good enough” looks like with measurable outcomes. - List support you will provide (coaching, pairing, scope adjust). - Set check-in dates and a clear end date. - Decide in advance what happens if the bar is met or not met. ### Exits with dignity Whether someone chooses to leave or the company ends employment, your job is clarity, respect, and operational continuity. Do not ghost the team. Do not trash the person. Capture knowledge, reassign ownership, and tell the truth you are allowed to tell. 1. Prepare logistics with HR (access, pay, references policy). 2. Plan knowledge transfer for critical systems. 3. Communicate to the team with care and without gossip. 4. Watch remaining teammates for load spikes and fear. 5. Retrospect the system: hiring bar, onboarding, scope, or management misses. > Hard conversations are part of the job. Cruelty is optional. Ambiguity is expensive. ### End-of-chapter drill - **Prompt:** Role-play (on paper) a compensation “no” and a performance gap conversation. Write the first two sentences of each. - **Hint:** Specific, kind, no surprises. - **Reflection:** Hard talks delayed become exits and lawsuits of trust. ### Diagrams for this topic #### Before a PIP - **Kind:** flow - **Steps:** 1. Ongoing feedback 2. Written expectations 3. Support period 4. HR partnership 5. PIP or role change #### Compensation conversation stack - **Kind:** stack - **Facts**: - Level - Band - Scope - **Message**: - Impact - Package - Flex vs fixed - **Close**: - Questions - Timeline - Follow-up ### Worked examples #### First hard news is the PIP - **Setting:** Performance has been weak for months; only praise appears in 1:1 notes. - **Common miss:** Drop a surprise PIP. - **Stronger move:** Document gaps earlier, set a clear support plan, involve HR, then PIP only if still below bar. - **Outcome:** Fairness improves and legal risk drops. #### Offer theater - **Setting:** You lowball to leave room, then struggle to hire. - **Common miss:** Treat negotiation as a win/lose game. - **Stronger move:** Align level and band early; sell scope and honesty; escalate constraints instead of ghosting. - **Outcome:** Reputation holds and close rates improve. ### Resources specific to this chapter - **[Compensation conversation template](/templates#comp-conversation)** (tool): Outline for offers and raise talks. - **[PIP outline template](/templates#pip-plan)** (tool): Only after prior feedback; partner with HR. --- ## Chapter 17: Team Topology Patterns **Slug:** `team-topologies` **URL:** https://lead-without-the-title.grok.me/read/team-topologies **Subtitle:** Design teams and interfaces for cognitive load, not org-chart fashion **Reading time:** ~26 minutes Most delivery pain is not a tooling problem. It is a team-design problem: unclear ownership, endless handoffs, and platforms that try to be everything. Team topology patterns give you a shared language for who does what, how teams interact, and how to protect cognitive load so people can ship. You do not need a reorg to start. You need honest maps of streams of change, forced collaboration, and platform seams. Rename last. Change interaction modes first. ### The four team types Use these as roles in the delivery system, not as prestige labels. A team can shift type as the product and org mature, but it should not pretend to be three types at once. - Stream-aligned: aligned to a flow of change for a user or business domain. Owns outcomes end to end where possible. - Platform: provides internal products that reduce cognitive load for stream teams (APIs, paved roads, self-service). - Enabling: helps stream teams acquire missing capabilities (coaching, spikes, temporary pairing), then steps back. - Complicated-subsystem: owns a hard specialty (ML core, billing engine, real-time media) so others do not drown in it. **Cognitive load test:** If a stream-aligned team must understand five platforms, three languages of business, and a specialty domain to ship a small change, topology is wrong. Reduce load before adding headcount. ### Three interaction modes Team type is incomplete without interaction mode. The same two teams can succeed or fail depending on how they are allowed to talk. 1. Collaboration: work closely for a defined period to discover a boundary or shape a new capability. High bandwidth, high cost. Time-box it. 2. X-as-a-Service: one team provides a clear service with docs, SLOs, and a support path. Low collaboration cost once the interface is good. 3. Facilitating: an enabling team helps another team learn or adopt a practice without taking permanent ownership of the work. > If everything is Collaboration forever, you do not have a platform. You have a meeting schedule. ### Patterns that work in practice - Thinnest viable platform: the smallest set of paved roads that removes repeated pain. Grow from usage, not from a multi-year vision deck. - Stream first: default new work to a stream-aligned team with a clear customer or domain, not to a horizontal layer team. - Enabling with an exit: every enabling engagement has a success criteria and an end date, or it becomes a permanent crutch. - Complicated-subsystem isolation: put rare expertise behind a stable interface so product teams do not all relearn the same hard thing. - Reverse Conway carefully: change team boundaries when architecture and ownership repeatedly fight each other, not as a status project. ### Anti-patterns to kill early 1. Platform as ticket factory: every request is a ticket, no self-service, no product thinking. 2. Pseudo stream teams that cannot ship without three approvals from other groups. 3. Enabling teams that never leave and quietly become owners of everything they touch. 4. One giant team labeled platform that is really five unrelated jobs. 5. Reorg theater: new names, same handoffs, same cognitive load. ### How to set a team: size, mission, and the two-pizza rule Team setup is product design for humans. Before you argue process, decide mission, boundaries, and size. The Amazon two-pizza heuristic (a team small enough to feed with two pizzas) is not about food. It is about communication cost: as headcount grows, coordination paths explode and ownership gets fuzzy. - Mission: one sentence for the stream of value you own. - Boundaries: systems, customers, and decisions you own vs consume as X-as-a-Service. - Size: prefer small stream teams (often about 5-9 engineers) where everyone can know the work. - Two-pizza test: if the team cannot share context without permanent meetings and status brokers, it is too large or mis-scoped. - Composition: mix seniority; avoid a team of only juniors or only specialists with no delivery glue. - Interfaces: name collaboration vs X-as-a-Service edges with neighboring teams on day one. 1. Write mission + non-goals on one page. 2. List owned streams/services and explicit non-owned items. 3. Count coordination load: how many teams must say yes to ship. 4. If size grows past healthy cognitive load, split by stream or extract a platform/enabling edge, do not just add managers as duct tape. 5. Publish working agreements: reviews, on-call, communication channels, decision rights. **Two-pizza is a signal, not a law:** Some domains need larger teams for on-call coverage or compliance. If you go larger, invest harder in modularity, sub-streams, and written interfaces. Large and fuzzy is the failure mode, not large with clear sub-ownership. ### A lead's operating checklist As a team lead, you may not redraw the whole org. You can still make topology explicit for your area and negotiate better interfaces. 1. Map value streams and who must change code for each flow. 2. List top five cross-team dependencies by pain and frequency. 3. For each dependency, name the intended interaction mode (and the mode you actually use). 4. Write platform or service expectations: docs, SLOs, support hours, deprecation rules. 5. Protect stream teams from load spikes: freeze drive-by work, fund enabling help, or split a complicated subsystem. 6. Review topology quarterly with incidents, lead time, and team health, not only headcount plans. **One-page topology:** Publish a one-pager: team type, mission, owned streams or services, interaction modes with neighbors, and what you will not own. Ambiguity is a silent reorg. ### End-of-chapter drill - **Prompt:** Pick one painful cross-team flow. Draw stream owners, mark each edge as Collaboration, X-as-a-Service, or Facilitating (actual vs desired), and write one change you will make this month. - **Hint:** Rename last. Change interaction mode or interface quality first. - **Reflection:** If every edge is permanent Collaboration, you are paying meeting tax instead of designing services. ### Diagrams for this topic #### Four team types - **Kind:** compare - **Caption:** Roles in the delivery system, not prestige labels - **Stream-aligned** (good): - User/domain flow - Outcome ownership - Fast feedback - **Platform** (neutral): - Internal product - Self-service - Lower cognitive load - **Enabling** (neutral): - Temporary help - Capability building - Clear exit - **Complicated-subsystem** (neutral): - Rare expertise - Stable interface - Protect specialists #### Interaction modes - **Kind:** flow - **Steps:** 1. Discover need 2. Collaboration (time-boxed) 3. Stabilize interface 4. X-as-a-Service 5. Review cognitive load #### Topology health signals - **Kind:** matrix - **Matrix headers:** Signal | Healthy | Unhealthy - **Handoffs:** Few, documented | Every feature crosses 3+ teams - **Platform:** Self-service paved roads | Ticket-only bottleneck - **Enabling:** Time-boxed with exit | Permanent shadow ownership ### Worked examples #### Platform as ticket desk - **Setting:** Stream teams wait days for every infra change. Platform has no roadmap, only a queue. - **Common miss:** Add more approval steps and rename the queue a platform portal. - **Stronger move:** Interview streams, ship one self-service paved road, publish SLOs and docs, treat platform as product. - **Outcome:** Wait time drops and collaboration becomes optional, not mandatory. #### Forever collaboration - **Setting:** Checkout and payments teams pair on every change with no end date. - **Common miss:** Call it culture and keep dual-owning everything. - **Stronger move:** Time-box collaboration to define a boundary, then move to X-as-a-Service with contracts and ownership. - **Outcome:** Teams regain focus while the interface stays reliable. #### Team too large for two pizzas of context - **Setting:** Fourteen engineers share one backlog, three domains, and a daily meeting that runs long. - **Common miss:** Add more process and status roles while keeping one fuzzy mission. - **Stronger move:** Split by stream of value, clarify interfaces, and keep each unit small enough to share context without brokers. - **Outcome:** Coordination cost drops and ownership becomes nameable. ### Resources specific to this chapter - **[Team Topologies (book site)](https://teamtopologies.com/)** (book): Source patterns for team types and interaction modes. - **[Topology one-pager template](/templates#team-topology-one-pager)** (tool): Mission, type, streams, interaction modes. - **[Conway / reverse Conway framework](/frameworks)** (tool): Pair topology design with org-architecture fit. --- ## Chapter 18: Headcount & Capacity Planning **Slug:** `headcount-capacity` **URL:** https://lead-without-the-title.grok.me/read/headcount-capacity **Subtitle:** Staff the work you can finish, not the wishlist you can present **Reading time:** ~22 minutes Headcount conversations fail when they start with “we need more people” and end with a number. Strong leads start with the work: streams of change, service ownership, interrupt load, and the outcomes that matter this half. Capacity planning turns desire into a plan stakeholders can fund or cut with eyes open. You will not always get the hires you want. Your job is to make trade-offs explicit: what ships if we stay flat, what slips if we add scope, and what burns people if we pretend math is optional. ### Capacity is not headcount Headcount is seats. Capacity is the fraction of time that can do planned product and tech work after meetings, on-call, hiring, and drag. A team of eight with heavy interrupts can have less shipping capacity than a team of five with clean ownership. - Planned capacity: roadmap and committed projects. - Interrupt capacity: incidents, support, drive-by asks. - Investment capacity: debt, platform, hiring, learning. - Unavailable capacity: PTO, leave, ramp-up, part-time. **Rule of rough numbers:** If you do not track interrupts, assume 20-40% of time is not roadmap. New hires are not full capacity for months. Managers are not full IC capacity. Plan with those truths, not with hope. ### A simple capacity model 1. List the work streams for the next quarter (product, reliability, platform, keep-the-lights-on). 2. Estimate size in engineer-weeks, not story points theater. Ranges are fine. 3. Compute available engineer-weeks: people × weeks × focus factor (often 0.6-0.75). 4. Subtract known ramps, PTO, and on-call weeks. 5. Compare demand vs supply. Cut or sequence until the plan is honest. 6. Name the explicit “won’t do” list so scope does not sneak back in chat. ### When to ask for headcount Hire when the constraint is sustained demand against a clear stream, not when one bad quarter of meetings made everyone tired. Bring evidence: lead time, WIP, on-call load, roadmap commitments, and risks of staying flat. - Role brief: problem to solve, not a stack shopping list only. - Why now: what fails if we wait a quarter. - Alternatives considered: scope cut, vendor, platform leverage, rebalance. - Ramp plan: who onboards, when the seat becomes net positive. - Success signal: what changes in 6 months if the hire works. ### Allocation patterns that protect delivery - Keep a stability reserve: do not plan 100% of capacity to roadmap. - Limit concurrent major bets per team (often one primary, one secondary). - Separate stream ownership from temporary swarm work with an end date. - Fund platform or debt with a fixed percentage when pain is chronic. - Rebalance when topology is wrong before you add more people to a broken interface. > Adding people to a confused ownership map multiplies confusion. Fix the map, then staff the streams. ### Conversations with your manager and finance partners 1. Lead with outcomes and risks, then the capacity math. 2. Offer scenarios: stay flat / +1 / +2 with different delivery shapes. 3. Be ready to recommend the cut if headcount is denied. 4. Never accept infinite scope with finite capacity in silence. 5. Review the plan monthly; capacity plans rot faster than roadmaps. **Manager ops link:** Pair this chapter with hiring scorecards (Ch 11), team topologies (Ch 17), and the priority stack. Headcount without a hiring bar or ownership model is just cost. ### End-of-chapter drill - **Prompt:** For the next 6-8 weeks, list demand in engineer-weeks (roadmap, KTLO, debt, interrupts) and supply (people × weeks × focus factor minus PTO/ramp). Write one scenario if you stay flat and one if you add one hire. - **Hint:** If you cannot estimate, your planning system is the first gap, not the headcount number. - **Reflection:** Capacity plans are moral documents: they say who will be overloaded if you stay silent. ### Diagrams for this topic #### Demand vs capacity - **Kind:** compare - **Caption:** Honest plans balance both sides - **Demand** (neutral): - Roadmap bets - Keep-the-lights-on - Debt / platform - Hiring & onboarding - **Supply** (good): - Engineer-weeks - Focus factor - PTO / ramp - Stability reserve - **If demand wins** (bad): - Heroics - Hidden cuts - Burnout - Missed SLOs #### Headcount decision loop - **Kind:** cycle - **Steps:** 1. Map streams 2. Model capacity 3. Scenario options 4. Hire or cut scope 5. Review monthly #### Hire vs not yet - **Kind:** matrix - **Matrix headers:** Signal | Hire | Do not hire yet - **Constraint:** Sustained stream demand | Temporary spike or unclear ownership - **Evidence:** Lead time, WIP, on-call load | Vibes and wishlists only - **Alternative:** Tried cut/vendor/platform | Have not considered scope cuts ### Worked examples #### Headcount without a role brief - **Setting:** You ask for two engineers because the team feels busy. - **Common miss:** Present a number and a stack list. No capacity math, no won’t-do list. - **Stronger move:** Show demand vs supply for the quarter, three scenarios, and role briefs tied to streams. - **Outcome:** Leadership can fund or refuse with shared facts. #### 100% roadmap utilization - **Setting:** Planning fills every engineer-week with feature work. - **Common miss:** Smile when interrupts arrive and expect heroes to absorb them. - **Stronger move:** Keep a stability reserve, track interrupt load, and replan when reality shows up. - **Outcome:** Fewer surprise slips and less silent burnout. #### Hiring into a topology mess - **Setting:** Three teams own the same flow. You request more people for speed. - **Common miss:** Add headcount to every team and hope handoffs get faster. - **Stronger move:** Clarify stream ownership and interaction modes first, then staff the stream that owns the outcome. - **Outcome:** New people accelerate a clear system instead of a meeting network. ### Resources specific to this chapter - **[Capacity one-pager template](/templates#capacity-plan)** (tool): Demand, supply, scenarios, and won’t-do list. - **[Team Topologies chapter](/read/team-topologies)** (tool): Fix ownership maps before scaling headcount. - **[Hiring & leveling chapter](/read/hiring-leveling)** (tool): Scorecards and bars once the seat is approved. - **[An Elegant Puzzle (Will Larson)](https://lethain.com/elegant-puzzle/)** (book): Staffing ratios, team size, and manager judgment. --- ## Chapter 19: OKRs, KPIs & Measuring the Team **Slug:** `okrs-kpis` **URL:** https://lead-without-the-title.grok.me/read/okrs-kpis **Subtitle:** Connect ambition to evidence without metric theater **Reading time:** ~24 minutes Leads inherit dashboards, OKR slides, and opinions about what “good” means. Your job is to separate three layers: the mission (why we exist), OKRs (what changes this cycle), and KPIs (how the system is doing continuously). Confusing them produces vanity goals, gamed numbers, and busy teams that do not move outcomes. Domain knowledge here is measurement design: pick few outcomes, pair them with honest counters, and protect the team from targets that punish learning. ### OKRs: outcomes for a cycle Objectives and Key Results are a cycle tool (usually a quarter). An Objective is qualitative and motivating. Key Results are measurable evidence that the objective moved. Keep the set small: three objectives is often too many for one team. - Objective: direction in plain language (not a metric). - Key Results: 2-4 measures or milestones that prove progress. - Owner: one accountable driver per OKR set. - Time box: a cycle with a mid-point check, not a yearly wish list. - Scoring: use honest grades; 0.7 on a hard KR can be success if ambition was real. 1. Start from user or business outcomes, not from a backlog dump. 2. Draft KRs that a skeptic can audit (data source + definition). 3. Kill or park work that does not map to a KR or to agreed KTLO. 4. Review weekly: blockers and learning, not slide cosmetics. **OKR anti-patterns:** Twelve OKRs, KRs that are just tasks (“ship project X”), metrics the team cannot influence, and individual OKRs that crush collaboration. Prefer team OKRs plus personal growth plans. ### KPIs: the health of the system KPIs (key performance indicators) are ongoing signals about how the machine runs. They are not the same as OKRs. You do not “finish” a KPI; you watch it, set thresholds, and investigate when it breaks. - Product KPIs: activation, retention, conversion, latency the user feels. - Delivery KPIs: DORA-style deploy frequency, lead time, change fail rate, restore time. - Reliability KPIs: SLO burn, error budget, incident count by severity. - Team health KPIs: on-call load, review lag, hiring funnel time (use carefully). - Quality KPIs: escaped defects, flaky test rate, support ticket themes. 1. Pick a short KPI set tied to your mission (usually under 10). 2. Define owner, source, and “what we do if red.” 3. Separate leading indicators (early) from lagging outcomes (late). 4. Never turn every KPI into a personal performance weapon. ### OKR vs KPI vs task (keep them straight) Use this split in planning conversations so stakeholders stop mixing ambition with telemetry. - Mission / north star: long-lived purpose and primary outcome (rarely changes). - OKR: cycle ambition with KRs that may include KPI movement or milestones. - KPI: continuous health; alert and diagnose; do not “complete” it. - Task / project: how you move a KR; belongs in the backlog, not as a fake KR. > If everything is an OKR, nothing is a priority. If everything is a KPI target, people will game the graph. ### Design metrics that teams can own Good measures are influenced by the team, hard to game, and connected to user value. Pair quantity with quality. Pair speed with safety. Publish definitions so debates are about reality, not spreadsheet folklore. 1. Write a one-line definition and data source for each metric. 2. Add a counter-metric (for example, speed + change fail rate). 3. Baseline before you set targets; targets without baseline are theater. 4. Review gaming risk: what bad behavior would raise this number? 5. Align metrics with team topology: stream teams own outcome KPIs; platforms own adoption and reliability of the paved road. **North star + input metrics:** A north star is the single outcome that best captures value (for example, weekly active teams completing a job). Input metrics are levers you believe move it. OKRs often improve inputs; KPIs watch both. ### Operating rhythm for goals and metrics - Quarterly: set or refresh OKRs with product and stakeholders. - Monthly: deep KPI review and one experiment on a red signal. - Weekly: OKR progress + risks in the team written update. - Incident/postmortem: check whether KPIs would have warned you earlier. - Hiring and capacity: connect headcount asks to OKR load and KPI pain, not vibes. ### End-of-chapter drill - **Prompt:** Draft one team Objective and three Key Results for the next cycle. For each KR, name the data source, a counter-metric, and whether it is an OKR move or a standing KPI. - **Hint:** If a KR is only a project name, rewrite it as a user or system outcome. - **Reflection:** Measurement is part of strategy: what you count is what the team will optimize. ### Diagrams for this topic #### Mission, OKR, KPI, task - **Kind:** stack - **Caption:** Different jobs in the measurement stack - **Mission / north star** (neutral): - Long-lived purpose - **OKRs (cycle)** (good): - Ambition + key results - **KPIs (continuous)** (neutral): - System health signals - **Tasks / projects** (neutral): - How work moves KRs #### OKR vs KPI - **Kind:** compare - **OKRs** (good): - Time-boxed cycle - Change the system - Few outcomes - Can include KPI moves - **KPIs** (neutral): - Always on - Health of system - Thresholds & alerts - Not 'finished' - **Failure mode** (bad): - Task masquerading as KR - Vanity KPI targets - Too many goals - Metric gaming #### Metric design loop - **Kind:** cycle - **Steps:** 1. Define outcome 2. Pick measure + source 3. Add counter-metric 4. Baseline 5. Review gaming risk ### Worked examples #### Tasks as Key Results - **Setting:** Team OKR KR reads: “Ship billing v2.” - **Common miss:** Treat the project name as success even if users see no improvement. - **Stronger move:** Rewrite KR to a user or reliability outcome (for example, cut failed payments 30% with a named data source). - **Outcome:** Delivery debates focus on value, not checkbox shipping. #### KPI weaponized in reviews - **Setting:** Individual performance is scored only on tickets closed and deploys. - **Common miss:** Rank people on volume metrics that punish mentorship and quality. - **Stronger move:** Use team KPIs for system health; use growth goals and peer evidence for people reviews. - **Outcome:** Less gaming, more collaboration. #### Twelve OKRs - **Setting:** Every stakeholder got “their” OKR on the team slide. - **Common miss:** Accept all twelve and hope heroics cover it. - **Stronger move:** Cap at a few outcomes, publish a won’t-do list, and escalate scope conflict. - **Outcome:** Priorities become real enough to say no. ### Resources specific to this chapter - **[OKR draft template](/templates#okr-cycle)** (tool): Objectives, KRs, owners, counter-metrics. - **[DORA metrics framework](/frameworks)** (tool): Delivery KPIs that pair with product outcomes. - **[Capacity planning chapter](/read/headcount-capacity)** (tool): Connect goals to real engineer-weeks. --- ## Chapter 20: Delegation, Breakdown & Handover **Slug:** `delegation-handover` **URL:** https://lead-without-the-title.grok.me/read/delegation-handover **Subtitle:** Break work down, hand it over end-to-end, and stop being the bottleneck **Reading time:** ~30 minutes New leads often fail in one of two ways. They keep every hard task themselves and burn out, or they “delegate” by dumping tickets without context and then micromanage the repair work. Trusted teams are built on a third path: clear breakdown, end-to-end ownership, and coaching checkpoints instead of constant steering. This chapter is the operating skill behind scale. If work cannot move without you, you do not have a team. You have a queue with your name on it. ### Break work down without breaking ownership Breakdown is not chopping a story into tiny tasks so you can track people by the hour. It is making the problem legible: outcome, constraints, slices that can ship value, and risks that need early spikes. 1. Start from the user or system outcome, not from a task list in your head. 2. Write non-goals and constraints (time, risk, interfaces, quality bar). 3. Split by value slices or risk reduction, not by architectural layers alone when that creates handoff soup. 4. Name integration points early: who owns the glue, contracts, and rollout. 5. Keep a vertical slice that one owner can drive end-to-end when possible. 6. Only subdivide further when parallel work is real and interfaces are clear. **Smell: task confetti:** If the board is full of two-hour chores and nobody can say which user outcome they serve, you over-broke the work to soothe anxiety. Re-group into owned outcomes. ### Handover mindset: micromanagement vs end-to-end ownership Micromanagement is not “caring about quality.” It is owning the how while pretending someone else owns the what. End-to-end handover means the person (or small pair) owns problem understanding, plan, execution, validation, and communication, with you as coach and risk partner. - Micromanagement signals: you rewrite their plan daily, require approval for small choices, sit in every detail thread, and measure activity over outcomes. - End-to-end signals: they can explain the user problem, the plan, the risks, and the definition of done without you speaking first. - Your job shifts from doing to contracting: success criteria, constraints, checkpoints, and escalation rules. - You still own the system: staffing, priority conflicts, cross-team blocks, and quality bar. That is leadership, not micromanagement. 1. Define the outcome and constraints in writing (one page is enough). 2. Agree decision rights: what they decide alone, what needs a consult, what needs your approve. 3. Set checkpoints by risk (design review, mid-slice demo, launch readiness), not by hourly status. 4. Inspect artifacts and outcomes, not keystrokes or online presence. 5. If you must dive deep, time-box it as pair coaching, then hand the wheel back. > If every path needs your steering wheel, you did not delegate. You rented out your hands while keeping the brain. ### A practical handover contract Treat handover like an interface between two engineers. Ambiguity is the root of rework and of your urge to micromanage. - Context: why this matters now, users, links to OKRs or incidents. - Outcome: what “good” looks like, including quality and operability. - Scope and non-goals: what is explicitly out. - Constraints: deadlines, dependencies, compliance, performance budgets. - Interfaces: APIs, teams, data, rollout and rollback. - Checkpoints: dates and artifacts, not vibes. - Support: when and how you will help; what is not your job anymore. - Escalation: what red flags bring you in immediately. **Definition of done for handover:** The receiver can teach the problem back to you, name the first slice, and know how to get unblocked without guessing your preferences. ### Build a team you can trust with real work Trust is not a poster. It is a track record of small end-to-end deliveries, honest updates, and repaired misses. You build it on purpose. - Psychological safety: people can say “I do not know yet” early. - Competence trust: evidence from delivery, not charisma. - Reliability trust: commitments and re-negotiations are explicit. - Repair trust: postmortems and feedback without humiliation. 1. Match task risk to readiness: stretch is good; sabotage by under-support is not. 2. Prefer whole outcomes over perpetual “help me with a bit of X.” 3. Make quality bars explicit (tests, reviews, observability, docs) so trust is not personal favor. 4. Celebrate owned finishes and clean escalations, not silent heroics. 5. When someone drops a ball, separate skill gap from clarity gap from load gap, then coach. 6. Rotate ownership of scary areas so trust is distributed, not single-threaded on seniors only. ### How not to overdo yourself Overdoing looks virtuous and scales poorly. If you are the best debugger, the default reviewer, the incident commander, and the only person who talks to product, the team never builds muscle and you become the outage. - Hero trap: you take the hardest tasks because it is faster this week and more expensive every next week. - Review trap: every PR waits on you; fix with review SLAs, rotations, and clearer standards. - Meeting trap: you attend to feel in control; switch to written updates and optional deep dives. - Context trap: only you know production folklore; force runbooks and shadow on-call. - Boundary trap: nights and weekends become the plan; that is a capacity problem, not dedication. 1. List work only you do. Pick one stream to hand over this month with a real contract. 2. Set a personal WIP limit for deep work you keep; say no or renegotiate when full. 3. Block coaching time on the calendar so delegation is not leftover energy. 4. Track interruptions for a week; redesign the system that creates them. 5. Use your manager: escalate load and priority conflicts instead of absorbing them silently. **Lead energy budget:** Your scarce resources are attention and calm. Spend them on priorities, people growth, and cross-team blocks. Everything else is a candidate for end-to-end handover. ### Handover checklist (use before you walk away) A contract without a checklist is still easy to half-do. Run this list with the owner before you reduce your involvement. If any item is a no, fix it before you call the work delegated. Include a RACI matrix for the workstream, not only a single owner name. End-to-end ownership still needs clear Responsible, Accountable, Consulted, and Informed roles so the handover does not collapse into side-channel approvals. - Outcome written: user/system result and quality bar are explicit. - Non-goals written: what we will not do this cycle is explicit. - Context linked: tickets, docs, OKRs, incidents, and stakeholders are findable. - Owner named: one end-to-end owner (and backup if risk is high). - RACI matrix filled: key activities have R/A/C/I (see matrix rules below). - Teach-back passed: owner can restate the problem, first slice, and unblock path. - Decision rights table filled: decide / consult / approve is clear for scope, interfaces, and launch (aligned with RACI). - Checkpoints booked: risk-based reviews on the calendar, not “we will sync if needed.” - Interfaces named: teams, APIs, data, rollout and rollback owners. - Support boundaries set: what the lead will still do vs stop doing. - Escalation red flags listed: what brings the lead back in immediately. - Operability included: logging, metrics, alerts, runbook notes for production-facing work. - Done definition shared: how we will know it worked (metric, test, user check). **Pre-flight rule:** If the owner cannot teach the problem back, you handed over a ticket title, not ownership. Stay in co-pilot mode until teach-back passes. ### RACI matrix rules for handover Put RACI in the handover pack next to the checklist. Keep the matrix small: activities, not every task confetti item. - R — Responsible: does the work (often the end-to-end owner or a named pair). - A — Accountable: one person who answers for the outcome (exactly one A per activity). - C — Consulted: two-way input before decisions (architect, security, partner team). - I — Informed: one-way updates (stakeholders who need visibility without a vote). 1. List 5-9 critical activities (design, implement, review, launch, comms, rollback, metrics). 2. Assign one A per row. Multiple R is ok for pair work; multiple A is not. 3. Limit C to people who can change the decision; everyone else is I or out. 4. Align the decision-rights table with RACI so Approve maps to A, Consult to C. 5. If the lead stays A on every row, you did not hand over. Move A for local work; keep A only for org-level risk if needed. **Checklist gate:** Do not mark the handover checklist green until the RACI matrix has a single Accountable per key activity and the owner can explain who is C vs I without guessing. ### Handover metrics (know if ownership is real) You cannot manage handover by gut feel alone. Track a short metric set so you see when you are still the bottleneck or when the owner is stuck without support. Pair speed with quality; never optimize “delegated count” alone. - Time-to-first-progress: hours/days from handover to first meaningful artifact (design note, spike result, or vertical slice). - Checkpoint hit rate: percent of agreed checkpoints held with the planned artifact. - Re-decision rate: how often you reverse owner decisions without new information (high = micromanagement or unclear rights). - Lead interrupt rate: unplanned pings per week where you re-take the how (should fall after a clean handover). - Blocker age: median age of owner-reported blockers (stale blockers mean weak escalation). - Rework after review: changes forced by missing constraints that should have been in the contract. - Outcome completion without heroics: shipped with owner driving launch/comms, not the lead last-minute. - Owner confidence (1-5) at handover and at mid-checkpoint; a crash means support or scope is wrong. 1. Pick three to five metrics max for your team; write the definition and data source. 2. Review them in the same forum as delivery health (weekly update or 1:1 for people development work). 3. If lead interrupt rate stays high, fix the contract and decision rights before blaming the owner. 4. If time-to-first-progress is slow but confidence is high, check capacity and dependencies, not only skill. 5. Add a counter-metric for quality (escaped defects, incident from the change, review failures) so speed is not gamed. **Healthy pattern:** After handover, your deep-work interrupts drop, checkpoints still happen, and the owner can explain status without you translating. That is the metric of trust. ### Recovery when you already micromanage or overfunction If the team waits for your opinion on small choices, you trained them to. Reverse it with visible new contracts. 1. Admit the pattern without self-drama: “I have been in the details too much; we are changing how ownership works.” 2. Pick one active workstream and rewrite the handover contract this week. 3. Replace daily task pings with two checkpoints and a written risk update. 4. When asked for a decision they own, ask for their recommendation first. 5. Review after two weeks: what quality risk is real vs what anxiety is yours. > A trusted team is not built by watching people harder. It is built by handing over real outcomes and staying close enough to coach. ### End-of-chapter drill - **Prompt:** Pick one piece of work only you currently drive. Fill the handover contract including a RACI matrix (one A per activity), run the full checklist (including teach-back and RACI gate), pick 3-5 handover metrics with baselines, and list what you will stop doing this week. - **Hint:** If you cannot name decision rights, you will micromanage by default. - **Reflection:** End-to-end handover is a trust investment. Keeping the how is a hidden tax on the whole team. ### Diagrams for this topic #### RACI in handover - **Kind:** matrix - **Matrix headers:** Role | Means | Handover rule - **R:** Does the work | Owner or pair named - **A:** Answers for outcome | Exactly one per activity - **C:** Two-way input | Only if they can change the call - **I:** One-way update | No hidden veto #### Handover readiness checklist - **Kind:** flow - **Steps:** 1. Write contract 2. Teach-back 3. Checklist green 4. Book checkpoints 5. Track metrics #### Handover metric set - **Kind:** compare - **Leading** (good): - Time-to-first-progress - Checkpoint hit rate - Owner confidence - **Lagging** (neutral): - Outcome done without heroics - Rework after review - Quality escapes - **Watch (lead habits)** (bad): - Lead interrupt rate - Re-decision rate - Stale blocker age #### Micromanage vs end-to-end handover - **Kind:** compare - **Caption:** What you own after you hand work over - **Micromanagement** (bad): - You own the how - Hourly steering - Approvals for small choices - Activity metrics - **End-to-end ownership** (good): - They own outcome path - Risk-based checkpoints - Clear decision rights - Artifacts and results - **Lead still owns** (neutral): - Priority conflicts - Quality bar - Cross-team blocks - Coaching and staffing #### Breakdown to handover flow - **Kind:** flow - **Steps:** 1. Outcome & constraints 2. Value slices 3. Owner + contract 4. Checkpoints 5. Ship & learn #### Trust building loop - **Kind:** cycle - **Steps:** 1. Hand real outcome 2. Support without steering 3. Review evidence 4. Repair misses 5. Increase scope ### Worked examples #### Delegated ticket, kept brain - **Setting:** You assign a feature but rewrite the design daily and require approval for every API name. - **Common miss:** Call it mentoring while the engineer waits on you for each micro-decision. - **Stronger move:** Write outcome, constraints, and decision rights. Review at design and mid-slice checkpoints only. - **Outcome:** Ownership becomes real; you free attention for cross-team risk. #### Task confetti board - **Setting:** A project is split into dozens of tiny tasks across people with no single outcome owner. - **Common miss:** Track every chore and wonder why integration is always late. - **Stronger move:** Regroup into vertical slices with one end-to-end owner and clear interfaces. - **Outcome:** Less coordination tax, clearer accountability. #### Hero lead overload - **Setting:** You take every production fire and hard design because it is faster. - **Common miss:** Keep absorbing work and skip handover contracts. - **Stronger move:** List work only you do, hand one stream with a full contract, and set a personal WIP limit. - **Outcome:** Team muscle grows; your calendar stops being the outage. #### Checklist skipped, metrics ignored - **Setting:** You assign a project in chat and only notice failure at launch week. - **Common miss:** Skip teach-back and track nothing except the deadline. - **Stronger move:** Run the handover checklist, book checkpoints, and watch lead interrupt rate plus time-to-first-progress. - **Outcome:** You see ownership problems in days, not at the postmortem. #### RACI with two Accountables - **Setting:** Design has both lead and engineer marked A so “someone” will own launch. - **Common miss:** Leave dual A and hope the checklist still passes. - **Stronger move:** One A per activity; engineer A on implementation and launch, lead A only on org-level risk if needed. Checklist stays red until fixed. - **Outcome:** Approvals stop bouncing; ownership is auditable. ### Resources specific to this chapter - **[Handover contract template](/templates#handover-contract)** (tool): Outcome, constraints, decision rights, checkpoints. - **[Feedback chapter](/read/feedback)** (tool): Coach after handover without turning into a critic. - **[Operating the team](/read/operating)** (tool): Rituals and ownership maps that support delegation. --- ## Chapter 21: Implementing Feedback Loops **Slug:** `feedback-loops` **URL:** https://lead-without-the-title.grok.me/read/feedback-loops **Subtitle:** Close the loop between signal, decision, and change so the team learns faster than incidents teach **Reading time:** ~24 minutes Feedback is not only a hard conversation. In a healthy engineering team, feedback is a set of loops: sensors that notice reality, a place to compare against intent, and a change that improves the next cycle. Leads who only give annual reviews or only ship features without learning are running open loops. Open loops waste energy and surprise people. Implementing feedback loops means designing how truth travels and becomes action across people, product, delivery, and operations. ### The anatomy of a useful loop Every working loop has the same bones. If one bone is missing, you get noise or theater. 1. Sensor: what signal do we collect (metric, review, user talk, incident, 1:1)? 2. Cadence: how often, and who is responsible for looking? 3. Comparison: against what goal, SLO, quality bar, or expectation? 4. Decision: what will we start, stop, or continue? 5. Actuator: who changes the system (code, process, staffing, coaching)? 6. Memory: where is the learning written so we do not rediscover it monthly? **Closed vs open:** A dashboard nobody acts on is an open loop. A retro with no owners is an open loop. A 1:1 with no follow-up is an open loop. Closing the loop is the lead skill. ### Four loops every team lead should install You do not need heavy process for each. You need a named owner, a light artifact, and a habit of acting on the signal within a known time window. - People loop: expectations → work → feedback → growth plan → evidence in the next cycle. - Delivery loop: plan → build → review/demo → measure lead time and quality → adjust WIP and process. - Product loop: hypothesis → ship thin slice → user/usage signal → learn → next bet. - Operations loop: run → detect (SLO/alerts) → respond → postmortem → prevent and pay down risk. ### People feedback loops (beyond the awkward chat) Interpersonal feedback (Chapter 3) is one sensor. The loop is larger: clear expectations, frequent small signals, coaching reps, and proof of change. Surprise performance ratings mean the people loop was open for months. - Peer loop: design reviews and pair sessions with explicit praise and critique norms. - Team loop: retros that end with fewer than three owned experiments. - Skip-level or manager loop: calibrate expectations so local feedback matches org reality. 1. Set expectations in writing when role or scope changes. 2. Give SBI feedback close to the event (days, not quarters). 3. Capture one growth focus per person with practice reps. 4. Review evidence in 1:1s; update the plan, not only the pep talk. 5. Upward loop: ask for feedback on your leadership and report what you changed. ### Delivery and product loops Shipping without learning is motion. Learning without shipping is debate club. Wire thin delivery and product loops so the team feels the consequences of design choices quickly. - Definition of done includes how you will know it worked (metric, log, user check). - Demo or written show-and-tell on a fixed cadence for work that crossed a risk line. - Track a few delivery KPIs (lead time, fail rate) and discuss them when red, not only when convenient. - Prefer small releases or dark launches when they shorten the learn cycle safely. - Link OKR key results to real sensors, not vanity counters. **Loop latency:** If it takes six weeks to learn whether a change helped users or hurt reliability, your loop is too slow for the risk you are taking. Shrink the slice or improve instrumentation. ### Operations and quality loops Production is the harshest teacher. Your job is to turn pain into prevention without creating blame theater. 1. Alerts map to symptoms humans can act on; noisy alerts are broken sensors. 2. Incidents get a timeline, contributing factors, and owned follow-ups with dates. 3. Review follow-up completion in the same forum that runs delivery priorities. 4. Feed chronic themes into capacity and OKR planning (toil, flaky tests, missing runbooks). 5. Celebrate detection and fast recovery, not only feature launches. ### Loop health metrics Treat each feedback loop like a small system with a few health metrics so “we have a retro” does not substitute for learning. - Action completion rate: percent of loop actions done by the promised date. - Repeat signal rate: how often the same complaint or red metric returns next cycle. - Decision latency: time from red signal to an explicit decision (including “do nothing”). - Owner clarity: every open action has one name, not a team name. 1. Publish these next to the loop design one-pager. 2. Review monthly; kill loops with sensors but zero decisions. ### How to implement loops without process bloat Start with the pain you already feel. Install one loop well before you invent a “feedback program.” - Anti-pattern: surveys with no response. - Anti-pattern: metrics without counter-metrics or owners. - Anti-pattern: retros that produce slogans instead of experiments. - Anti-pattern: feedback only downward, never sideways or up. 1. Pick one broken loop (for example, silent expectations, slow user learning, or incident amnesia). 2. Write the six anatomy parts on one page with names and cadence. 3. Run it for two to four weeks with a visible owner. 4. Kill steps that do not change decisions; keep artifacts that do. 5. Only then add a second loop. > Culture is the set of feedback loops people trust. If truth dies in a slide deck, the culture already voted. ### End-of-chapter drill - **Prompt:** Pick one open loop on your team (people, delivery, product, or ops). Fill sensor, cadence, comparison, decision forum, actuator owner, and memory doc. Run it for two weeks and note one decision it changed. - **Hint:** If nothing changed a decision, you still have an open loop. - **Reflection:** Leads do not need more signals. They need shorter paths from signal to change. ### Diagrams for this topic #### Loop anatomy - **Kind:** flow - **Steps:** 1. Sensor 2. Cadence 3. Compare to intent 4. Decide 5. Act 6. Write memory #### Four lead loops - **Kind:** compare - **People** (good): - Expectations - SBI feedback - Growth reps - Evidence review - **Delivery** (neutral): - Plan - Build - Review/demo - Lead time & quality - **Product** (neutral): - Hypothesis - Thin ship - Usage signal - Next bet - **Operations** (neutral): - Detect - Respond - Postmortem - Prevent #### Open vs closed loop - **Kind:** matrix - **Matrix headers:** Pattern | Open loop | Closed loop - **Retro:** Notes, no owners | ≤3 experiments with names/dates - **Metric:** Dashboard only | Owner + action when red - **1:1 feedback:** Said once, forgotten | Growth focus + follow-up evidence ### Worked examples #### Retro theater - **Setting:** Every sprint ends with sticky notes. The same complaint appears for a quarter. - **Common miss:** Collect more notes and call it culture. - **Stronger move:** Close with at most three owned experiments, review them next retro, kill what did not help. - **Outcome:** The team trusts the ritual because something changes. #### Dashboard without decisions - **Setting:** Lead time and error rate are visible. Nobody owns the red weeks. - **Common miss:** Add more charts to the weekly slide. - **Stronger move:** Name owners, thresholds, and the forum where red forces a decision. - **Outcome:** Metrics become sensors in a loop, not decoration. #### Annual-only people feedback - **Setting:** Engineers hear hard news only at review time. - **Common miss:** Save feedback to stay 'nice.' - **Stronger move:** Install a people loop: expectations, timely SBI, growth focus, 1:1 evidence checks. - **Outcome:** Fewer surprises and faster skill growth. ### Resources specific to this chapter - **[Feedback loops one-pager template](/templates#feedback-loop-design)** (tool): Sensor, cadence, owner, actuator, memory. - **[Feedback & Growing People](/read/feedback)** (tool): Interpersonal SBI skills inside the people loop. - **[OKRs & KPIs](/read/okrs-kpis)** (tool): Connect cycle goals to real sensors. - **[DORA / delivery metrics](/frameworks)** (tool): Delivery loop sensors with counter-metrics. --- ## Chapter 22: Servant Leadership for Engineering Leads **Slug:** `servant-leadership` **URL:** https://lead-without-the-title.grok.me/read/servant-leadership **Subtitle:** Grow people and outcomes by removing obstacles, not by collecting power **Reading time:** ~24 minutes Servant leadership sounds soft until you try it under delivery pressure. The idea is simple: the lead exists to make the team more capable, clearer, and safer, not to be the smartest person in every design review. Authority is a tool for unblocking work and protecting standards. Ego is optional and usually expensive. For software leads, servant leadership is not endless people-pleasing. It is a bias toward enablement: clear goals, real ownership, coaching, and systems that reduce friction so engineers can do their best work. ### What servant leadership means in practice Robert Greenleaf framed the servant-leader as someone who starts with the desire to serve, then leads so others grow. In an engineering team that translates to concrete behaviors you can observe in a week. - Listen first: map reality before prescribing process. - Remove blockers: calendar, dependencies, unclear priorities, noisy alerts. - Grow people: stretch assignments with support, not perpetual junior work. - Share context: strategy and constraints become team property, not secret power. - Hold the bar: high standards for quality and behavior, without humiliation. - Take blame upward and pass credit downward when it is fair. **Not a doormat:** Serving the team does not mean saying yes to every request, absorbing infinite scope, or avoiding hard feedback. A servant lead says no to protect focus, and gives clear feedback because growth is a form of care. ### Command-and-control vs servant lead vs hero lead Most new leads oscillate between controlling details and doing the hard work themselves. Servant leadership is a third path: outcomes owned by the team, system owned by the lead. - Command-and-control: lead owns the how; team executes tickets; speed dies when the lead is away. - Hero lead: lead owns the hardest work; team waits; bus factor is one. - Servant lead: team owns end-to-end outcomes; lead owns clarity, staffing, interfaces, coaching, and escalation paths. 1. Ask weekly: what did I do that only a lead should do? 2. Ask weekly: what did I do that an engineer could have owned with a better contract? 3. Move one hero task into a handover with RACI and checkpoints. ### Ten operating habits 1. Start 1:1s with their agenda, then yours. 2. Translate strategy into a short priority stack the team can refuse against. 3. Sit in the path of pain occasionally (on-call, support) to feel the system. 4. Defend focus time as fiercely as you defend launch dates. 5. Coach in public principles and private details. 6. Make decision rights explicit so people do not need your blessing for local calls. 7. Invest in platform, docs, and paved roads that multiply everyone. 8. Hire and level for team strength, not clones of yourself. 9. Close feedback loops so truth becomes change (people, delivery, product, ops). 10. Model recovery: admit mistakes, fix systems, do not perform perfection. ### How servant leadership shows up in engineering systems Soft intent without hard systems becomes theater. Connect the mindset to the rest of this guide. - Delegation & handover: end-to-end ownership is servant leadership with a contract and RACI. - Feedback loops: you install sensors and actuators so the team learns without waiting for you. - Team topologies: you design cognitive load and interfaces, not hero bridges between every team. - OKRs & capacity: you tell the truth about trade-offs so people are not set up to fail quietly. - Psychological safety: people can raise risk early; you reward the messenger. > The best compliment for a servant lead is a team that ships well when you are on vacation. ### Common failure modes - Servant as conflict avoider: problems rot because hard conversations feel unkind. - Servant as martyr: you take all toil and call it support; the team never builds muscle. - Servant as popularity contest: decisions chase approval instead of user and system outcomes. - Servant without standards: kindness without a quality bar becomes mediocrity. - Servant only downward: you serve the team but never manage up with clear options, so the team still gets crushed by scope. **Health check:** If growth, ownership, and delivery metrics are flat while your meeting load rises, you may be serving activity, not people or outcomes. Redesign the system. ### A 30-day servant leadership practice 1. Week 1: Listen tour. Ask each person what to protect, change, and stop. Write themes. 2. Week 2: Kill one chronic blocker (flaky pipeline, unclear priority, review lag). 3. Week 3: Hand over one stream with full checklist, RACI, and metrics; coach at checkpoints only. 4. Week 4: Close one open feedback loop (retro actions, people growth focus, or incident follow-ups). 5. Every week: pass public credit, give one specific growth feedback, and protect at least one deep-work block for the team. ### End-of-chapter drill - **Prompt:** List three things only you do this week. Mark each as should stay with lead, should be handed over, or should be deleted. For one handover candidate, write the first coaching checkpoint. - **Hint:** If everything must stay with you, you are running a hero or control model, not a servant system. - **Reflection:** Servant leadership is measured by team capability when you are offline, not by how busy you look. ### Diagrams for this topic #### Three lead modes - **Kind:** compare - **Command & control** (bad): - Owns the how - Approves details - Team waits - Fragile when absent - **Hero lead** (neutral): - Does hard work - Bus factor one - Fast this week - Slow next quarter - **Servant lead** (good): - Owns system & bar - Team owns outcomes - Coaches & unblocks - Scales on vacation #### Serve → lead loop - **Kind:** cycle - **Steps:** 1. Listen 2. Clear goals 3. Hand over 4. Coach 5. Remove blockers 6. Raise bar #### Serve vs please - **Kind:** matrix - **Matrix headers:** Situation | People-pleasing | Servant leadership - **Scope flood:** Say yes to everyone | Say no with options and capacity math - **Weak work:** Avoid feedback | Timely SBI + growth plan - **Incident:** Absorb all toil forever | Stabilize, then fix system and share ownership ### Worked examples #### Servant as martyr - **Setting:** You take every production fire so the team can focus. - **Common miss:** Stay hero on-call and call it support. - **Stronger move:** Pair on one incident, write the runbook gap, hand the next rotation with a clear contract. - **Outcome:** Reliability knowledge spreads; your calendar is not the SPOF. #### Kindness without a bar - **Setting:** Reviews are slow and quality slips. You avoid hard notes to stay liked. - **Common miss:** Rubber-stamp PRs and hope production teaches them. - **Stronger move:** Publish a short quality bar, coach in review with examples, and hold the standard consistently. - **Outcome:** Care shows up as growth and fewer escaped defects. #### Context as power - **Setting:** Only you know roadmap trade-offs. Engineers guess priorities. - **Common miss:** Keep strategy private so people need you for every call. - **Stronger move:** Share a one-page priority stack and decision rights; invite challenge. - **Outcome:** Local decisions speed up; you coach exceptions, not every choice. ### Resources specific to this chapter - **[Delegation & handover](/read/delegation-handover)** (tool): Contracts, RACI, and metrics for real ownership. - **[Feedback loops](/read/feedback-loops)** (tool): Close people, delivery, product, and ops loops. - **[Trust chapter](/read/trust)** (tool): Psychological safety and reliability trust. - **[Servant leadership one-pager](/templates#servant-leadership-30d)** (tool): 30-day practice and weekly health check. --- ## Team Lead Roadmap URL: https://lead-without-the-title.grok.me/roadmap ### Phase 0: IC Foundation - **Timeframe:** Ongoing while senior - **Focus:** Become the engineer others trust with hard problems and hard truths. **Outcomes** - Reliable delivery with clean communication - Strong code review and design judgment - Mentors juniors without being asked **Skills** - Technical depth - Written RFCs - System design basics - Mentorship - Incident response **Practices** - Lead a project end-to-end including stakeholder updates - Write one ADR for a non-trivial design choice - Write postmortems that teach the org - Run a design workshop or architecture brown-bag - Ask for feedback on collaboration, not only code quality ### Phase 1: Emerging Lead - **Timeframe:** 3-6 months - **Focus:** Practice lead behaviors before or just after the title change. **Outcomes** - Coordinates multi-person work - Facilitates decisions without dominating - Trusted interface to product/design **Skills** - Facilitation - Prioritization - Feedback - Expectation setting **Practices** - Own sprint/iteration outcomes, not only tickets - Run effective 1:1s if you have reports (or peer coaching circles) - Publish a weekly team status with risks - Resolve one cross-team dependency with a written plan ### Phase 2: New Team Lead - **Timeframe:** First 6 months in role - **Focus:** Stabilize the team system: people, priorities, and operating rhythm. **Outcomes** - Clear ownership and priorities - Healthy 1:1 and feedback cadence - Fewer surprises for stakeholders **Skills** - Coaching - Conflict navigation - Capacity planning - Upward communication **Practices** - Complete the 90-day playbook - Create working agreements with the team - Install a simple decision log - Pair with your manager on one difficult people situation ### Phase 3: Effective Lead - **Timeframe:** 6-18 months - **Focus:** Multiply others; reduce the team's dependency on you as bottleneck. **Outcomes** - Team delivers without heroics - Strong successors and distributed ownership - Credible partner to product and peer leads **Skills** - Delegation systems - Hiring bar - Strategy translation - Org awareness **Practices** - Run hiring loops with clear scorecards - Delegate a whole workstream with coaching checkpoints - Publish a lightweight team strategy page - Improve one system bottleneck (toil, reviews, incidents) ### Phase 4: Multi-team impact - **Timeframe:** 18+ months or staff-plus - **Focus:** Shape interfaces across teams: topology, platforms, and shared quality bars. **Outcomes** - Cross-team programs land with clear ownership - Platform and stream boundaries make sense - Influence without constant escalation **Skills** - Team topology design - Stakeholder maps - Technical strategy - Mentoring leads **Practices** - Map streams and interaction modes for your area - Sponsor a platform or enabling investment with success metrics - Coach another lead through a hard decision - Drive one multi-team migration or reliability program ### Phase 5: Org builder - **Timeframe:** Senior lead / manager of managers path - **Focus:** Build systems of teams: hiring engines, ladders, and healthy culture at scale. **Outcomes** - Predictable hiring and leveling - Culture of written decisions and psychological safety - Delivery and people systems that outlast individuals **Skills** - Org design - Calibration - Executive communication - Succession **Practices** - Own a leveling calibration with evidence - Design a hiring funnel with quality metrics - Install portfolio reviews for tech debt and risk - Document operating principles other teams can reuse --- ## Engineering management & architecture frameworks URL: https://lead-without-the-title.grok.me/frameworks ### The Manager's Path levels - **ID:** `managers-path` - **Category:** Role clarity - **Summary:** Maps how leadership work changes from mentor and tech lead through manager and beyond. - **Use when:** You are unsure what 'good' looks like at your altitude. - **First step:** Write your current level's three outcomes and one behavior you still do from the previous level. - **Caution:** Titles lag behavior. Calibrate on work, not the org chart alone. - **Related chapters:** mindset, playbook ### Staff / manager dual track - **ID:** `dual-track` - **Category:** Role clarity - **Summary:** Treats people leadership and senior technical leadership as parallel paths, not a hierarchy of worth. - **Use when:** You lead without reports, or are choosing between EM and Staff. - **First step:** List your last 30 days of impact and mark each as people work, technical direction, or pure IC execution. - **Caution:** Do not use dual track to avoid feedback or ownership. - **Related chapters:** influence, self ### Team Topologies - **ID:** `team-topologies` - **Category:** Team design - **Summary:** Four team types and three interaction modes designed around cognitive load and clear interfaces. - **Use when:** Handoffs hurt, ownership is fuzzy, or 'platform' means everything. - **First step:** Draw who owns each user-facing flow and mark forced collaboration edges. - **Caution:** Renaming teams without changing interaction modes changes nothing. - **Related chapters:** team-topologies, operating, system-architecture ### Stream-aligned team - **ID:** `stream-aligned` - **Category:** Team design - **Summary:** A team aligned to a single flow of change for a customer or domain, owning outcomes end to end. - **Use when:** Work is stuck in horizontal layers and no one owns the user journey. - **First step:** Name the stream (user/domain) and list the systems you must touch to ship. - **Caution:** A stream team without authority is just a coordination meeting. - **Related chapters:** team-topologies, operating ### Platform as product - **ID:** `platform-as-product` - **Category:** Team design - **Summary:** Treat internal platform as a product with users, roadmaps, SLOs, and self-service, not a ticket queue. - **Use when:** Platform work is only reactive tickets and stream teams are blocked. - **First step:** Interview three stream teams on top friction and pick one paved-road fix. - **Caution:** Building platform features nobody asked for is still waste. - **Related chapters:** team-topologies, architecture-practices ### X-as-a-Service interaction - **ID:** `x-as-a-service` - **Category:** Team design - **Summary:** One team provides a clear service interface so others can consume without constant collaboration. - **Use when:** Two teams are glued together in permanent pair-mode for routine work. - **First step:** Write the service contract: API/docs, SLO, support path, versioning. - **Caution:** XaaS without quality docs becomes a gatekeeping bottleneck. - **Related chapters:** team-topologies, system-architecture ### Conway / reverse Conway - **ID:** `conway` - **Category:** Team design - **Summary:** Systems mirror communication paths. Shape teams intentionally to shape architecture. - **Use when:** The same integration mess keeps returning after rewrites. - **First step:** Map the last painful cross-team dependency to the org lines that caused it. - **Caution:** Reorgs are expensive. Prefer interaction contracts before big moves. - **Related chapters:** operating, system-architecture ### DORA metrics - **ID:** `dora` - **Category:** Delivery - **Summary:** Four measures of software delivery: deploy frequency, lead time, change fail rate, restore time. - **Use when:** You need evidence for quality, automation, or process investments. - **First step:** Pick one metric that hurts most and track a baseline for two weeks without targets. - **Caution:** Targets without safety create metric gaming and hidden risk. - **Related chapters:** operating, stakeholders ### SPACE productivity - **ID:** `space` - **Category:** Delivery - **Summary:** Looks at productivity across satisfaction, performance, activity, collaboration, and efficiency/flow. - **Use when:** Leadership asks 'are we productive?' and one number would lie. - **First step:** Choose two SPACE dimensions and gather qualitative signals from the team this week. - **Caution:** Activity counts alone are not productivity. - **Related chapters:** self, operating ### Shape Up (appetite) - **ID:** `shape-up` - **Category:** Delivery - **Summary:** Fixed time, variable scope, and explicit appetite instead of endless estimation theater. - **Use when:** Backlogs never shrink and estimates dominate planning. - **First step:** For the next initiative, set a hard time box and cut scope to fit, not the reverse. - **Caution:** Copying full Shape Up into a large enterprise rarely works on day one. - **Related chapters:** decisions, stakeholders ### WIP limits / flow - **ID:** `wip` - **Category:** Delivery - **Summary:** Limits work in progress so finishing beats starting and thrash becomes visible. - **Use when:** Everyone is busy and almost nothing ships. - **First step:** Cap active team items (for example 1-2 per person) and finish before pulling new work. - **Caution:** Limits fail if exceptions become the default every day. - **Related chapters:** decisions, operating ### DACI / RACI decision rights - **ID:** `daci` - **Category:** Decisions - **Summary:** Names who drives, who approves, who contributes, and who is informed so decisions stop bouncing. - **Use when:** Everyone 'owns' the decision and no one decides. - **First step:** For one stuck decision, write Driver, Approver, Contributors, Informed on a single page. - **Caution:** A committee of approvers is not a decision model. - **Related chapters:** decisions, influence ### Two-way vs one-way doors - **ID:** `two-way-doors` - **Category:** Decisions - **Summary:** Move fast on reversible choices; slow down on hard-to-undo decisions. - **Use when:** The team over-debates small reversible choices and rushes irreversible ones. - **First step:** Label the next three open decisions as reversible or not, then set different review depths. - **Caution:** Calling everything reversible is how irreversible mistakes sneak through. - **Related chapters:** decisions, communication ### Architecture Decision Records - **ID:** `adr` - **Category:** Decisions - **Summary:** Short written decisions: context, options, choice, and consequences. - **Use when:** The same technical debate returns every quarter. - **First step:** Write one ADR for a recent choice in under one page and link it from the repo. - **Caution:** ADRs that read like novels will not be maintained. - **Related chapters:** communication, architecture-practices ### Situational Leadership - **ID:** `situational` - **Category:** People - **Summary:** Matches directing, coaching, supporting, or delegating to a person's readiness on a specific task. - **Use when:** One management style works for half the team and fails for the rest. - **First step:** Pick one person and one task; choose a style deliberately for the next check-in. - **Caution:** Style is per task, not a permanent label on a human. - **Related chapters:** feedback, mindset ### Radical Candor - **ID:** `radical-candor` - **Category:** People - **Summary:** Care personally and challenge directly. Avoid silence and cruelty. - **Use when:** Feedback is skipped, sugarcoated, or delivered as character attacks. - **First step:** Give one piece of behavior-based feedback within 48 hours of observing it. - **Caution:** Challenge without care is not candor; it is aggression. - **Related chapters:** feedback, trust ### 1:1 operating rhythm - **ID:** `one-on-ones` - **Category:** People - **Summary:** Recurring private meetings owned by the report, focused on growth, blockers, and truth. - **Use when:** You only talk about tickets, or hard topics wait for reviews. - **First step:** Book recurring 1:1s, protect them, and open with their agenda first. - **Caution:** Canceling 1:1s first trains people that they are optional. - **Related chapters:** feedback, playbook ### Five Dysfunctions of a Team - **ID:** `lencioni` - **Category:** People - **Summary:** Trust, then conflict, then commitment, then accountability, then results. Diagnoses 'nice but slow' teams. - **Use when:** Disagreement only happens in DMs after meetings. - **First step:** In the next meeting, explicitly invite one respectful dissent before deciding. - **Caution:** Forcing debate theater without trust makes people shut down more. - **Related chapters:** trust, communication ### Psychological safety - **ID:** `psych-safety` - **Category:** People - **Summary:** Shared belief that interpersonal risk (questions, mistakes, dissent) is allowed. - **Use when:** Bad news arrives late, juniors stay silent, or postmortems hunt villains. - **First step:** Publicly thank someone for raising a risk or admitting a mistake this week. - **Caution:** Safety is not the absence of standards. High standards need safety to work. - **Related chapters:** trust, operating ### OKRs (few outcomes) - **ID:** `okrs` - **Category:** Alignment - **Summary:** Qualitative objectives with measurable key results, kept few enough to force trade-offs. - **Use when:** Activity is high and outcome clarity is low. - **First step:** Draft at most three team outcomes for the next cycle and kill or defer the rest. - **Caution:** Twelve OKRs means you still have no priorities. - **Related chapters:** okrs-kpis, decisions, stakeholders ### Stakeholder power / interest map - **ID:** `stakeholder-map` - **Category:** Alignment - **Summary:** Plots who decides, who blocks, who needs updates, and who is affected. - **Use when:** Cross-team work stalls for mysterious reasons. - **First step:** List decision, blockers, and informed parties for one active initiative. - **Caution:** Mapping without a communication plan is just a pretty chart. - **Related chapters:** stakeholders, influence ### Vision to execution stack - **ID:** `vision-stack` - **Category:** Alignment - **Summary:** Connects vision, strategy, roadmap, and tickets so shipping is not random motion. - **Use when:** The team cannot explain why this quarter's work matters. - **First step:** Write a one-page stack from user outcome down to this week's top three items. - **Caution:** Pretty strategy docs that never touch the backlog are theater. - **Related chapters:** communication, stakeholders ### Quality-attribute driven design - **ID:** `quality-attributes` - **Category:** Architecture - **Summary:** Name availability, latency, security, cost, and operability before choosing tools or patterns. - **Use when:** Design debates start with frameworks instead of requirements. - **First step:** Write the top three quality attributes and one measurable signal for each this week. - **Caution:** A laundry list of attributes is noise; prioritize ruthlessly. - **Related chapters:** architecture-practices, system-design ### Modular boundaries first - **ID:** `modular-boundaries` - **Category:** Architecture - **Summary:** Prefer clear modules and ownership before distributing into microservices. - **Use when:** Someone proposes a service split to fix team or code pain. - **First step:** Draw current module boundaries and mark the true change hotspots. - **Caution:** Distribution multiplies operational cost; modularity is the first win. - **Related chapters:** system-architecture, architecture-practices ### Lead-led design review - **ID:** `design-review` - **Category:** Architecture - **Summary:** A structured review that surfaces risk, options, and ownership instead of ego debates. - **Use when:** Designs pass by hallway consensus or stall in endless review. - **First step:** Require problem, constraints, two options, failure modes, and rollout in every design doc. - **Caution:** Review theater without a decision owner still ships ambiguity. - **Related chapters:** system-design, decisions ### Architecture fitness functions - **ID:** `fitness-functions` - **Category:** Architecture - **Summary:** Automated checks that protect architecture intent as the codebase evolves. - **Use when:** Architecture drifts every quarter despite good slides. - **First step:** Add one automated check (dependency direction, contract test, or schema compatibility). - **Caution:** Too many fitness functions become ignored noise; start with one that hurts when broken. - **Related chapters:** system-architecture, operating ### Demand vs capacity model - **ID:** `capacity-model` - **Category:** Delivery - **Summary:** Compare engineer-weeks of demand to available supply after focus factor, PTO, and interrupts. - **Use when:** Roadmaps are fantasy, or headcount asks lack math. - **First step:** List streams for 6-8 weeks and estimate engineer-weeks as ranges. - **Caution:** Precise spreadsheets cannot fix unclear ownership or infinite scope. - **Related chapters:** headcount-capacity, decisions, operating ### Stay flat / +1 / cut scope scenarios - **ID:** `hiring-scenarios` - **Category:** Delivery - **Summary:** Present three futures so leaders choose trade-offs instead of approving vibes. - **Use when:** You need a headcount decision or a scope reset. - **First step:** Write what ships and what slips in each scenario with dates. - **Caution:** Do not offer a fake scenario you cannot live with. - **Related chapters:** headcount-capacity, hiring-leveling, stakeholders ### KPI health set - **ID:** `kpi-set` - **Category:** Alignment - **Summary:** A short list of continuous indicators with owners, sources, and red-threshold actions. - **Use when:** You only have project lists and no system telemetry for health. - **First step:** Pick five KPIs max across product, delivery, and reliability with data sources. - **Caution:** A KPI without a counter-metric invites gaming. - **Related chapters:** okrs-kpis, operating, system-design ### Two-pizza team size - **ID:** `two-pizza` - **Category:** Team design - **Summary:** Keep teams small enough to share context without permanent coordination brokers. - **Use when:** Meetings multiply, ownership is fuzzy, or onboarding takes forever. - **First step:** Count people on one backlog and list domains they must hold in their heads. - **Caution:** Do not split randomly; split by stream of value and clear interfaces. - **Related chapters:** team-topologies, headcount-capacity, communication ### OKR vs KPI split - **ID:** `okr-vs-kpi` - **Category:** Alignment - **Summary:** Use OKRs for cycle ambition and KPIs for continuous health; do not mix them carelessly. - **Use when:** Dashboards and goal slides tell different stories of success. - **First step:** Label each current number as mission, OKR KR, KPI, or task. - **Caution:** Turning every KPI into a quarterly KR creates thrash and fake wins. - **Related chapters:** okrs-kpis, decisions ### End-to-end handover contract - **ID:** `end-to-end-handover` - **Category:** Execution - **Summary:** Hand outcomes with written constraints, decision rights, and risk-based checkpoints instead of task dumping or micromanagement. - **Use when:** You are the bottleneck, or “delegated” work keeps bouncing back unfinished. - **First step:** Write outcome, non-goals, and decision rights for one live workstream today. - **Caution:** Checkpoints are not hourly status. Inspect artifacts and risks. - **Related chapters:** delegation-handover, operating, feedback ### Handover pre-flight checklist - **ID:** `handover-checklist` - **Category:** Execution - **Summary:** Yes/no pre-flight including RACI matrix (one A per activity), teach-back, decision rights, checkpoints, operability, and done metric. - **Use when:** Handovers keep failing in the last mile or bounce back to you. - **First step:** Run the checklist on one live workstream with the owner today. - **Caution:** A checklist is not a substitute for trust-building reps over time. - **Related chapters:** delegation-handover, communication ### Lead WIP limit (anti-hero) - **ID:** `anti-hero-wip` - **Category:** Execution - **Summary:** Cap the deep work only you keep so you must hand over real outcomes and protect coaching energy. - **Use when:** You take every hard task because it is faster this week. - **First step:** List work only you do and pick one stream to hand over with a contract. - **Caution:** Saying yes to everything is a capacity decision with hidden team cost. - **Related chapters:** delegation-handover, self, headcount-capacity ### Closed feedback loop - **ID:** `closed-feedback-loop` - **Category:** Execution - **Summary:** Sensor, cadence, comparison, decision, actuator, and memory so signals change the system. - **Use when:** You have retros, dashboards, or surveys that never change priorities or behavior. - **First step:** Pick one pain and write the six loop parts on a single page with names. - **Caution:** More sensors without actuators create anxiety, not learning. - **Related chapters:** feedback-loops, operating, okrs-kpis ### Four lead loops - **ID:** `four-lead-loops` - **Category:** Execution - **Summary:** People, delivery, product, and operations loops as the minimum learning system for a team. - **Use when:** The team ships or talks a lot but rarely updates how it works. - **First step:** Score each loop open/closed and fix the most expensive open one first. - **Caution:** Do not install four heavy processes at once. Close one loop well. - **Related chapters:** feedback-loops, feedback, system-design ### Handover metrics set - **ID:** `handover-metrics-set` - **Category:** Execution - **Summary:** Track time-to-first-progress, checkpoint hit rate, lead interrupt rate, and a quality counter-metric so delegation is measurable. - **Use when:** You think you delegated but still firefight the same work. - **First step:** Baseline lead interrupt rate and time-to-first-progress on one workstream this week. - **Caution:** Do not optimize delegated ticket count. Optimize owned outcomes with quality guards. - **Related chapters:** delegation-handover, okrs-kpis, feedback-loops ### Servant lead habits - **ID:** `servant-lead-habits` - **Category:** People - **Summary:** Listen, unblock, share context, coach ownership, hold the bar, credit down / accountability up. - **Use when:** You are stuck between micromanaging and doing all the work yourself. - **First step:** List work only you do and mark hand over / keep / delete. - **Caution:** Serving is not people-pleasing. Hard feedback and clear nos are part of care. - **Related chapters:** servant-leadership, delegation-handover, feedback, trust ### Hero to host shift - **ID:** `hero-to-host` - **Category:** People - **Summary:** Move from being the best individual contributor on the team to hosting a system where others own outcomes. - **Use when:** Delivery depends on you every week and growth is flat. - **First step:** Hand one stream with RACI and stop attending every detail thread. - **Caution:** Do not abandon the quality bar while you step back from the how. - **Related chapters:** servant-leadership, delegation-handover, operating ## Framework picker situations ### Everything is P0 - **ID:** `priorities` - **Prompt:** Too many priorities, constant thrash - **Symptom:** The team starts a lot and finishes little. Stakeholders keep adding quick asks. - **Primary frameworks:** okrs, wip, shape-up - **Secondary frameworks:** two-way-doors, daci, vision-stack **One-week experiment** 1. Publish a single ranked outcome list (max 3) for the next two weeks. 2. Set a WIP cap and refuse new starts until something finishes. 3. For each new ask, require what drops or delays in exchange. ### Decisions bounce forever - **ID:** `decisions-stuck` - **Prompt:** Nobody can decide, or decisions reopen weekly - **Symptom:** Meetings rehash the same options. Ownership of the call is unclear. - **Primary frameworks:** daci, two-way-doors, adr - **Secondary frameworks:** stakeholder-map, okrs, vision-stack **One-week experiment** 1. Name Driver and Approver for the stuck decision in writing today. 2. Mark it reversible or irreversible and set a decision date. 3. Capture the choice as a short ADR or decision note after you decide. ### Feedback is missing or harsh - **ID:** `feedback-gap` - **Prompt:** People do not get useful feedback - **Symptom:** Surprise reviews, sugarcoating, or critiques that feel personal. - **Primary frameworks:** radical-candor, one-on-ones, situational - **Secondary frameworks:** psych-safety, managers-path, lencioni **One-week experiment** 1. Give one timely, behavior-based feedback note this week. 2. Protect 1:1s and put growth on the agenda explicitly. 3. Adjust coaching style per person and task, not one style for all. ### Nice team, slow truth - **ID:** `nice-slow` - **Prompt:** Polite meetings, weak commitment - **Symptom:** Nodding in the room, dissent only in private chats, soft accountability. - **Primary frameworks:** lencioni, psych-safety, daci - **Secondary frameworks:** radical-candor, one-on-ones, two-way-doors **One-week experiment** 1. Invite explicit dissent before locking a decision. 2. Thank public risk-raising to model safety. 3. End meetings with owners, dates, and what done means. ### Cross-team work stalls - **ID:** `cross-team` - **Prompt:** Dependencies and politics block progress - **Symptom:** Work waits on other teams. Escalations feel personal or late. - **Primary frameworks:** stakeholder-map, daci, team-topologies - **Secondary frameworks:** conway, adr, okrs **One-week experiment** 1. Map decision makers, blockers, and informed parties for one initiative. 2. Propose a written interface or ownership boundary, not only a meeting. 3. Escalate with options and a recommendation, not only pain. ### Always firefighting - **ID:** `firefighting` - **Prompt:** Incidents and urgent work dominate - **Symptom:** Lead time is long, restores are painful, planning is fiction. - **Primary frameworks:** dora, wip, psych-safety - **Secondary frameworks:** space, team-topologies, okrs **One-week experiment** 1. Baseline one DORA signal (often restore time or change fail rate). 2. Reserve explicit capacity for reliability, not if we have time. 3. Run the next incident review as systems learning, not blame. ### Ownership is fuzzy - **ID:** `ownership-fuzzy` - **Prompt:** Unclear who owns systems and outcomes - **Symptom:** Tickets bounce. 'Someone should' is a common phrase. - **Primary frameworks:** team-topologies, daci, conway - **Secondary frameworks:** adr, wip, managers-path **One-week experiment** 1. Publish a one-page ownership map for your critical surfaces. 2. Assign a single DRI per surface with consult rights, not committee ownership. 3. Document interaction modes with adjacent teams (collaborate vs service). ### New lead role fog - **ID:** `new-lead` - **Prompt:** Just stepped into lead; unsure what to do - **Symptom:** You still measure yourself by personal coding output and feel behind. - **Primary frameworks:** managers-path, one-on-ones, okrs - **Secondary frameworks:** situational, stakeholder-map, dual-track **One-week experiment** 1. Run listening 1:1s and map stakeholders in the first two weeks. 2. Define team outcomes for 30/60/90 days in plain language. 3. Stop one hero task and replace it with unblocking or coaching. ### Lead without reports - **ID:** `no-reports` - **Prompt:** Need influence without formal authority - **Symptom:** You coordinate work and quality but cannot require anything by title. - **Primary frameworks:** dual-track, stakeholder-map, adr - **Secondary frameworks:** daci, two-way-doors, vision-stack **One-week experiment** 1. Pick one cross-cutting problem and write a recommendation with options. 2. Pre-socialize with the real decision owner before the big meeting. 3. Make others visible; sponsorship compounds influence faster than heroics. ### Stakeholder surprises - **ID:** `upward` - **Prompt:** Managers or partners are often blindsided - **Symptom:** Status is activity logs. Risks surface late. Trust erodes upward. - **Primary frameworks:** stakeholder-map, okrs, vision-stack - **Secondary frameworks:** dora, daci, space **One-week experiment** 1. Send a weekly status: outcome health, what changed, top risk, ask. 2. Share ranges and confidence, not false precision. 3. Escalate early with a recommendation attached. ### Productivity theater - **ID:** `productivity-debate` - **Prompt:** Pressure to measure engineering poorly - **Symptom:** Story points, lines of code, or raw activity are treated as truth. - **Primary frameworks:** space, dora, wip - **Secondary frameworks:** psych-safety, okrs, vision-stack **One-week experiment** 1. Refuse single-metric productivity claims; propose SPACE plus DORA pair. 2. Show flow and quality signals alongside any activity numbers. 3. Tie measurement to team outcomes, not individual vanity metrics. ### Team shape is wrong - **ID:** `structure-pain` - **Prompt:** Handoffs and cognitive load are crushing - **Symptom:** People context-switch across too many domains. Platform work is a junk drawer. - **Primary frameworks:** team-topologies, conway, space - **Secondary frameworks:** wip, daci, okrs **One-week experiment** 1. Estimate cognitive load per person (domains, tools, meetings). 2. Propose one boundary change or interaction mode change, not a full reorg. 3. Protect a platform or enabling path with a clear service interface. ### Architecture debate is stuck - **ID:** `architecture-debate` - **Prompt:** Tools and patterns argued without shared goals - **Symptom:** The team debates Kafka vs queues, microservices vs monolith, without agreeing what must be true. - **Primary frameworks:** quality-attributes, design-review, adr - **Secondary frameworks:** two-way-doors, daci, modular-boundaries **One-week experiment** 1. List top three quality attributes with measurable signals. 2. Require two options with trade-offs in a one-page design note. 3. Record the decision as an ADR with owner and revisit date. ### Premature microservices - **ID:** `premature-microservices` - **Prompt:** Push to split services before boundaries are clear - **Symptom:** Distributed complexity is rising while domain language and ownership are still mushy. - **Primary frameworks:** modular-boundaries, quality-attributes, conway - **Secondary frameworks:** team-topologies, fitness-functions, adr **One-week experiment** 1. Map modules and change frequency before any new service cut. 2. Pilot modularity inside the current deployable unit where possible. 3. Only split where independent deploy or scale is proven, not hoped. ### Architecture keeps drifting - **ID:** `architecture-drift` - **Prompt:** Diagrams look good; the codebase disagrees - **Symptom:** Every quarter reinvented patterns, dependency spaghetti, and tribal knowledge. - **Primary frameworks:** fitness-functions, adr, design-review - **Secondary frameworks:** modular-boundaries, quality-attributes, dora **One-week experiment** 1. Publish a living architecture page with owners and top risks. 2. Add one fitness function that fails the build on a known smell. 3. Require design review only for cross-cutting changes, not every PR. ### Handoffs and fuzzy ownership - **ID:** `topology-pain` - **Prompt:** Every feature needs three teams and a week of meetings before code moves. - **Symptom:** Slow delivery, blame at boundaries, platform ticket piles. - **Primary frameworks:** team-topologies, stream-aligned, x-as-a-service - **Secondary frameworks:** conway, platform-as-product, dora **One-week experiment** 1. Map one user flow and every team that must touch it. 2. Mark each edge as Collaboration, X-as-a-Service, or Facilitating (actual vs desired). 3. Pick one edge to improve: docs/SLO for XaaS or a time-boxed collaboration. 4. Publish a one-page ownership map for that flow. 5. Measure wait time on the edge for two weeks. ### Need headcount or a scope cut - **ID:** `capacity-ask` - **Prompt:** The roadmap does not fit the team and leadership wants both speed and no more hires. - **Symptom:** Heroics, slipping dates, or headcount asks without math. - **Primary frameworks:** capacity-model, hiring-scenarios, rice - **Secondary frameworks:** team-topologies, eisenhower, dora **One-week experiment** 1. Estimate demand and supply for the next 6-8 weeks. 2. Write stay-flat, +1 hire, and scope-cut scenarios. 3. List will-not-do items for the stay-flat path. 4. Review with product and your manager with one recommendation. 5. Publish the decision and replan WIP. ### OKRs and metrics are theater - **ID:** `goals-mess` - **Prompt:** Many goals, vanity metrics, and no clear team outcomes. - **Symptom:** Busy slides, unclear trade-offs, arguments about what success means. - **Primary frameworks:** okrs, okr-vs-kpi, kpi-set - **Secondary frameworks:** wip, capacity-model, dora **One-week experiment** 1. Inventory current goals and label OKR vs KPI vs task. 2. Draft at most three team outcomes with measurable KRs and sources. 3. Pick a short KPI health set with counter-metrics. 4. Publish a won’t-do list for the cycle. 5. Align capacity plan to the OKRs with product. ### Team is too big to share context - **ID:** `team-too-big` - **Prompt:** One backlog, many domains, coordination brokers everywhere. - **Symptom:** Long standups, slow decisions, onboarding pain. - **Primary frameworks:** two-pizza, team-topologies, stream-aligned - **Secondary frameworks:** conway, capacity-model, platform-as-product **One-week experiment** 1. Map domains and cognitive load on the current team. 2. Run a two-pizza / context test with the team. 3. Propose stream split or interface extraction with mission pages. 4. Rewrite communication charter for the new shapes. ### I am the bottleneck - **ID:** `bottleneck-lead` - **Prompt:** Everything waits on you; you rewrite others’ work and take the hard tasks. - **Symptom:** Slow team growth, your burnout, shallow ownership. - **Primary frameworks:** end-to-end-handover, handover-checklist, handover-metrics-set - **Secondary frameworks:** wip, feedback-gap, two-pizza **One-week experiment** 1. Inventory work only you drive. 2. Write one full handover contract and assign an owner. 3. Replace daily pings with two risk-based checkpoints. 4. Set a personal WIP limit and publish what you will stop doing. 5. Review with the owner: teach-back of problem and first slice. ### Signals without change - **ID:** `open-loops` - **Prompt:** Retros, metrics, or feedback exist but nothing improves. - **Symptom:** Same complaints, red charts ignored, surprise reviews. - **Primary frameworks:** closed-feedback-loop, four-lead-loops, okrs - **Secondary frameworks:** dora, wip, end-to-end-handover **One-week experiment** 1. Inventory people, delivery, product, and ops loops; mark open vs closed. 2. Design one closed loop on a one-pager with owners. 3. Run it for two weeks with a forced decision rule when red. 4. Share what changed; kill unused steps. ### I want to lead without controlling - **ID:** `want-servant-lead` - **Prompt:** You are either micromanaging or heroically overfunctioning and want a healthier model. - **Symptom:** Team waits on you; growth is slow; you are exhausted. - **Primary frameworks:** servant-lead-habits, hero-to-host, end-to-end-handover - **Secondary frameworks:** closed-feedback-loop, anti-hero-wip, daci **One-week experiment** 1. Run a listen tour: protect / change / stop themes. 2. Kill one chronic blocker this week. 3. Hand over one stream with checklist + RACI. 4. Give one hard growth feedback with a practice plan. 5. Measure: lead interrupt rate and team ownership at checkpoints. --- ## Interview prep bank URL: https://lead-without-the-title.grok.me/interview LocalStorage: `lead-ebook-interview-v1` Spaced repetition: SM-2 inspired scheduling. Review buttons Again/Hard/Good/Easy update ease and next due date. New cards appear in the due queue; intervals cap at 120 days. ### Framework notes **Behavioral:** Use STAR (Situation, Task, Action, Result). Keep actions about what *you* did. End with a learning or system change. **System design:** Common 5-step loop: clarify → estimate → high-level design → deep dive → failures/trade-offs. Write assumptions. Invite collaboration. **Architecture:** Lead with quality attributes and constraints, then options with trade-offs, then a recommendation and an ADR-ready decision. ### Categories - **Behavioral & leadership** (`behavioral`): Ownership, conflict, influence, and culture signals for tech lead / EM loops. - **People management** (`people`): Feedback, coaching, 1:1s, performance, and team health. - **Execution & priorities** (`execution`): Delivery systems, trade-offs, stakeholders, and operating rhythm. - **System design** (`system-design`): Clarify, estimate, design, deep-dive, and stress-test under time pressure. - **Architecture judgment** (`architecture`): Quality attributes, boundaries, evolution, and technical leadership decisions. ### Questions (33) #### What does servant leadership mean to you as an engineering lead, and how do you avoid becoming a hero or a doormat? - **ID:** `servant-leadership-q` - **Category:** people - **Difficulty:** core - **Why they ask:** Companies want leads who scale people and systems, not only personal output. - **Structure:** 1. Define enablement + standards (not people-pleasing) 2. Contrast command-and-control, hero, and servant modes 3. Give a concrete example of unblocking or handing over 4. Show metrics or signals (ownership when you are away) - **Talking points:** - Listen, remove blockers, share context, coach ownership - Hard feedback and clear nos are part of serving growth - RACI and handover contracts beat vague trust - Credit down, accountability up, systems over heroics - **Follow-ups:** Tell me about a time you said no to protect the team. | How do you measure whether servant leadership is working? - **Related chapters:** servant-leadership, delegation-handover, feedback, trust - **Related frameworks:** servant-lead-habits, hero-to-host, end-to-end-handover - **Tags:** servant leadership, people, culture, delegation #### How would you implement feedback loops on a team that has retros and dashboards but rarely changes how it works? - **ID:** `feedback-loops-q` - **Category:** execution - **Difficulty:** core - **Why they ask:** Senior leads design learning systems, not only meetings. - **Structure:** 1. Define closed loop anatomy 2. Map people, delivery, product, and ops loops 3. Show how you close one open loop with owners and cadence 4. Explain anti-patterns and loop latency - **Talking points:** - Sensor without actuator is theater - Timely people feedback plus growth evidence - Delivery and product learning from thin slices - Incidents feed prevention and capacity plans - **Follow-ups:** How do you avoid process bloat? | How do feedback loops relate to OKRs and KPIs? - **Related chapters:** feedback-loops, feedback, operating, okrs-kpis - **Related frameworks:** closed-feedback-loop, four-lead-loops, dora - **Tags:** feedback loops, learning, operations, culture #### How do you break down work and hand it over without micromanaging, especially when quality matters? - **ID:** `delegation-handover-q` - **Category:** people - **Difficulty:** core - **Why they ask:** Leads must create owners, not shadows of themselves. - **Structure:** 1. Explain outcome-first breakdown vs task confetti 2. Describe end-to-end ownership and decision rights 3. Show risk-based checkpoints and what you still own as lead 4. Cover trust building and how you stop overfunctioning - **Talking points:** - Handover contract: context, outcome, constraints, escalation - Micromanagement owns the how; leadership owns system and bar - Match stretch to support; repair misses without humiliation - Personal WIP limit and handing hard streams, not only chores - **Follow-ups:** What if the person is junior? | How do you recover a team that waits on you for every decision? - **Related chapters:** delegation-handover, feedback, trust, operating - **Related frameworks:** end-to-end-handover, anti-hero-wip, daci - **Tags:** delegation, handover, micromanagement, trust #### How do you set OKRs for an engineering team, and how do they relate to KPIs? - **ID:** `okr-kpi-q` - **Category:** execution - **Difficulty:** core - **Why they ask:** Leads must measure outcomes without creating metric theater. - **Structure:** 1. Define mission vs cycle OKRs vs standing KPIs 2. Show a sample objective with measurable KRs and sources 3. Add counter-metrics and gaming risks 4. Describe the operating rhythm and capacity link - **Talking points:** - Few OKRs; tasks are not Key Results - KPIs are continuous health, not finished goals - Pair speed with quality (for example DORA) - Team-level goals over individual vanity metrics - **Follow-ups:** What if stakeholders want twelve OKRs? | How would you use the two-pizza rule when forming a team around a new OKR? - **Related chapters:** okrs-kpis, decisions, team-topologies, communication - **Related frameworks:** okrs, okr-vs-kpi, kpi-set, two-pizza - **Tags:** OKR, KPI, metrics, planning #### Your roadmap does not fit the team. How do you run a capacity and headcount conversation with your manager? - **ID:** `headcount-capacity-q` - **Category:** execution - **Difficulty:** senior - **Why they ask:** Senior leads must turn overload into decisions, not only heroics. - **Structure:** 1. Explain demand vs supply with rough engineer-weeks 2. Offer stay-flat / hire / cut-scope scenarios 3. Recommend one path with risks and will-not-do items 4. Describe how you would revisit the plan monthly - **Talking points:** - Capacity is not headcount; track interrupts and ramp - Do not ask for people into a broken ownership map - Role briefs tied to streams, not stack wishlists only - Silence is acceptance of infinite scope - **Follow-ups:** What if finance freezes hiring? | How do you protect a stability reserve? - **Related chapters:** headcount-capacity, decisions, hiring-leveling, stakeholders - **Related frameworks:** capacity-model, hiring-scenarios - **Tags:** capacity, headcount, planning #### How would you apply Team Topologies ideas when every feature needs three teams and a week of meetings? - **ID:** `topology-design` - **Category:** execution - **Difficulty:** senior - **Why they ask:** Checks org design judgment, not only personal productivity tips. - **Structure:** 1. Map the value stream and forced handoffs 2. Name team types and actual vs desired interaction modes 3. Propose a small interface or ownership change 4. Explain how you would measure wait time and cognitive load - **Talking points:** - Prefer changing interaction modes before big reorgs - Platform as product with self-service, not ticket theater - Time-box collaboration; graduate to X-as-a-Service - Protect stream teams from specialty complexity via clear interfaces - **Follow-ups:** What if you cannot reorg? | How do you handle a platform that refuses product thinking? - **Related chapters:** team-topologies, operating, system-architecture - **Related frameworks:** team-topologies, conway, x-as-a-service - **Tags:** topology, org design, platform #### Tell me about yourself / walk me through your career for this lead role. - **ID:** `bh-story-self` - **Category:** behavioral - **Difficulty:** core - **Why they ask:** They want a short story that connects strong IC work to how you lead, not a resume dump. - **Structure:** 1. Present: role, scope, team size or systems owned 2. Past: 2-3 chapters that prove technical + leadership signal 3. Future: why this role / level now - **Talking points:** - Lead with outcomes (users, reliability, team growth), not only titles. - Name one people story and one technical systems story. - End with what you want to practice more of as a lead. - **Follow-ups:** What would your teammates say is your leadership superpower? | What is still hard for you in leadership? - **Related chapters:** mindset, self - **Related frameworks:** none - **Tags:** intro, story bank #### Tell me about a time you had a significant disagreement with a peer or stakeholder. - **ID:** `bh-conflict` - **Category:** behavioral - **Difficulty:** core - **Why they ask:** Conflict handling predicts whether you create clarity or political debt. - **Structure:** 1. Situation: stakes and parties 2. Task: what good looked like 3. Action: how you sought interests, not positions 4. Result: decision, relationship repair, learning - **Talking points:** - Separate positions from interests. - Show you could be wrong and still hold a recommendation. - Close with what you changed in process so it does not recur. - **Follow-ups:** Would you do anything differently? | How did trust change after? - **Related chapters:** trust, communication, influence - **Related frameworks:** lencioni, psych-safety, daci - **Tags:** conflict, STAR #### Describe a time you led without formal authority. - **ID:** `bh-influence` - **Category:** behavioral - **Difficulty:** core - **Why they ask:** Tech leads often ship through influence before the title arrives. - **Structure:** 1. Problem that crossed team boundaries 2. How you built a shared problem statement 3. How you pre-socialized and wrote a recommendation 4. What shipped and what credit you shared - **Talking points:** - Written proposal with options beats hallway lobbying alone. - Make others visible; sponsorship compounds influence. - Name the real decision owner early. - **Follow-ups:** What almost blocked you? | How did you handle a no? - **Related chapters:** influence, stakeholders - **Related frameworks:** stakeholder-map, daci, adr - **Tags:** influence, cross-team #### Tell me about a project or decision that failed. What did you learn? - **ID:** `bh-failure` - **Category:** behavioral - **Difficulty:** core - **Why they ask:** Psychological safety and learning culture start with how leaders own mistakes. - **Structure:** 1. What you intended and what broke 2. Your part without over- or under-owning 3. How you communicated and recovered 4. System change you made after - **Talking points:** - Prefer systems language over blame. - Show speed of learning, not perfection. - Connect to a lasting process or design change. - **Follow-ups:** Who else was affected? | How do you teach that lesson now? - **Related chapters:** trust, operating, self - **Related frameworks:** psych-safety, dora - **Tags:** failure, growth #### Tell me about a time you had to drive progress with incomplete information. - **ID:** `bh-ambiguity` - **Category:** behavioral - **Difficulty:** stretch - **Why they ask:** Leads operate in fog. Interviewers want decision hygiene under uncertainty. - **Structure:** 1. What was unknown and what was time-sensitive 2. How you framed reversible vs irreversible choices 3. What experiments or milestones reduced risk 4. How you updated stakeholders as truth changed - **Talking points:** - Name assumptions explicitly. - Use two-way-door speed for reversible bets. - Show you can pause when the door is one-way. - **Follow-ups:** What signal told you to change course? - **Related chapters:** decisions, stakeholders - **Related frameworks:** two-way-doors, okrs - **Tags:** ambiguity, decisions #### How do you give hard feedback to an engineer who is underperforming? - **ID:** `pe-feedback` - **Category:** people - **Difficulty:** core - **Why they ask:** New leads often avoid feedback or make it personal. They want care + challenge. - **Structure:** 1. Prepare: situation, behavior, impact, request 2. Deliver timely and private 3. Partner on a growth plan with check-ins 4. Escalate only after documented support - **Talking points:** - Behavior over character. - Specific examples, recent and observable. - Clear bar and timeline; offer help. - **Follow-ups:** What if they disagree with the feedback? | When do you move to a performance plan? - **Related chapters:** feedback, trust - **Related frameworks:** radical-candor, one-on-ones, situational - **Tags:** feedback, performance #### How do you structure 1:1s? - **ID:** `pe-1on1` - **Category:** people - **Difficulty:** core - **Why they ask:** 1:1s are the lead's primary coaching medium. - **Structure:** 1. Their agenda first 2. Energy and blockers 3. One project deep-dive 4. Growth edge 5. Feedback both ways 6. Commitments - **Talking points:** - Protect the slot; cancel your own meetings first. - Take notes and follow up. - Do not turn every 1:1 into a status meeting. - **Follow-ups:** How do 1:1s change for seniors vs juniors? - **Related chapters:** feedback, playbook - **Related frameworks:** one-on-ones, situational - **Tags:** coaching, rituals #### How do you hire for this team? What signals do you look for? - **ID:** `pe-hire` - **Category:** people - **Difficulty:** stretch - **Why they ask:** Hiring quality defines the team more than any process doc. - **Structure:** 1. Role scorecard: must-haves vs nice-to-haves 2. Loop design and interviewer calibration 3. What good looks like in debrief 4. How you sell the team without overselling - **Talking points:** - Optimize for learning rate, collaboration, and ownership, not trivia. - Structured rubrics reduce bias. - Bar-raiser culture: disagree and commit in debrief. - **Follow-ups:** Tell me about a hire that did not work out. - **Related chapters:** operating, mindset - **Related frameworks:** none - **Tags:** hiring #### Walk me through how you would handle a consistently low performer. - **ID:** `pe-low-performer` - **Category:** people - **Difficulty:** senior - **Why they ask:** Managers must balance compassion, fairness, and team health. - **Structure:** 1. Diagnose: skill, will, role fit, or unclear expectations 2. Document expectations and support 3. Time-bound improvement plan 4. Decide: improve, re-scope, or exit with dignity - **Talking points:** - Never surprise someone in a formal review. - Protect the rest of the team from chronic under-delivery. - Partner with HR/manager early when stakes rise. - **Follow-ups:** How do you keep the rest of the team motivated? - **Related chapters:** feedback, self, trust - **Related frameworks:** radical-candor, situational - **Tags:** performance, hard calls #### How do you prioritize when everything is marked P0? - **ID:** `ex-prioritize` - **Category:** execution - **Difficulty:** core - **Why they ask:** Leads who cannot say no create thrash and burnout. - **Structure:** 1. Force a ranked outcome list (few items) 2. Expose capacity math 3. Trade-offs: what drops for each new ask 4. Communicate the stack in writing - **Talking points:** - Impact, urgency, confidence, cost of delay, team health. - WIP limits beat multitasking theater. - Escalate with a recommendation, not only pain. - **Follow-ups:** How do you handle an executive override? - **Related chapters:** decisions, stakeholders, operating - **Related frameworks:** okrs, wip, shape-up - **Tags:** priorities, capacity #### Your team keeps missing commitments. What do you do in the first 30 days? - **ID:** `ex-delivery` - **Category:** execution - **Difficulty:** core - **Why they ask:** They want diagnosis before process spam. - **Structure:** 1. Listen: 1:1s, retros, delivery data 2. Find the bottleneck (scope, quality, deps, skill, thrash) 3. One system fix (WIP, planning, ownership map) 4. Visible weekly outcomes, not activity - **Talking points:** - Do not reorganize in week one unless the house is on fire. - Ship a small reliability or clarity win for credibility. - Make risks early and options-rich upward. - **Follow-ups:** What metrics would you track? - **Related chapters:** playbook, operating - **Related frameworks:** dora, wip, okrs - **Tags:** delivery, turnaround #### How do you manage up when leadership wants an unrealistic date? - **ID:** `ex-stakeholder` - **Category:** execution - **Difficulty:** stretch - **Why they ask:** Upward management is a core lead skill. - **Structure:** 1. Clarify the outcome vs the date 2. Offer ranges with confidence and risk 3. Present options: cut scope, add capacity, move date 4. Document the decision and residual risk - **Talking points:** - Never surprise your manager with late bad news. - Bring a recommendation, not only a problem. - Protect team health without becoming a pure blocker. - **Follow-ups:** Describe a time you pushed back successfully. - **Related chapters:** stakeholders, communication - **Related frameworks:** stakeholder-map, vision-stack - **Tags:** stakeholders, expectation setting #### How do you structure a 45-60 minute system design interview? - **ID:** `sd-framework` - **Category:** system-design - **Difficulty:** core - **Why they ask:** Process skill matters as much as raw knowledge. - **Structure:** 1. Clarify requirements and non-goals (5-8 min) 2. Back-of-envelope scale (3-5 min) 3. High-level design + APIs (10-15 min) 4. Deep dive 1-2 components (10-15 min) 5. Failure modes, scale, ops, trade-offs (5-10 min) - **Talking points:** - Talk out loud; invite the interviewer as a collaborator. - State assumptions; write them down. - Prefer boring reliable choices unless scale forces complexity. - **Follow-ups:** What do you do if you run out of time? - **Related chapters:** system-design - **Related frameworks:** none - **Tags:** framework, interview craft #### Design a URL shortener (like bit.ly). - **ID:** `sd-url-shortener` - **Category:** system-design - **Difficulty:** core - **Why they ask:** Classic probe for APIs, storage, uniqueness, and read-heavy scale. - **Structure:** 1. Requirements: create, redirect, optional analytics, custom aliases 2. Scale: writes/day, reads/day, storage years 3. API + data model (short code, long URL, user, expiry) 4. Key generation: hash vs counter vs pre-generated 5. Cache hot redirects; DB for durability 6. Analytics async via queue if needed - **Talking points:** - Collision handling and uniqueness guarantees. - 301 vs 302 trade-offs for caching. - Partition strategy when the mapping table grows. - **Follow-ups:** How would you support custom domains? | Abuse and rate limiting? - **Related chapters:** system-design, architecture-practices - **Related frameworks:** none - **Tags:** classic, storage, cache #### Design a distributed rate limiter. - **ID:** `sd-rate-limiter` - **Category:** system-design - **Difficulty:** core - **Why they ask:** Tests concurrency, consistency, and placement in the request path. - **Structure:** 1. Requirements: limits per user/IP/API key, windows, fairness 2. Algorithms: token bucket, sliding window, fixed window 3. Central store (Redis) vs local + sync 4. Where it sits: gateway, middleware, service 5. Failure modes: store down, clock skew, multi-region - **Talking points:** - Accuracy vs latency trade-offs. - Idempotency of checks under retries. - Observability: which clients are throttled. - **Follow-ups:** How do you rate-limit across regions? - **Related chapters:** system-design - **Related frameworks:** none - **Tags:** redis, concurrency #### Design a news feed / timeline for a social app. - **ID:** `sd-feed` - **Category:** system-design - **Difficulty:** stretch - **Why they ask:** Fan-out, ranking, and read/write asymmetry under celebrity load. - **Structure:** 1. Post, follow graph, feed read, ranking constraints 2. Fan-out on write vs fan-out on read vs hybrid 3. Storage: posts, edges, precomputed timelines 4. Caching and ranking pipeline 5. Celebrity problem and pagination - **Talking points:** - Hybrid fan-out for heavy followed accounts. - Eventually consistent is usually acceptable for feeds. - Separate write path from ranking workers. - **Follow-ups:** How do you inject ads? | How do you handle deletes? - **Related chapters:** system-design, system-architecture - **Related frameworks:** none - **Tags:** fan-out, scale #### Design a 1:1 and group chat messaging system. - **ID:** `sd-chat` - **Category:** system-design - **Difficulty:** stretch - **Why they ask:** Realtime delivery, ordering, offline sync, and multi-device. - **Structure:** 1. Requirements: 1:1, groups, delivery receipts, history 2. Connections: WebSocket gateway, presence 3. Message store and fan-out to devices 4. Ordering and idempotency 5. Push for offline; media via object storage - **Talking points:** - At-least-once delivery with client dedupe. - Group fan-out strategies and read cursors. - Encryption and retention policies as first-class. - **Follow-ups:** How do you support message edit/delete? - **Related chapters:** system-design - **Related frameworks:** none - **Tags:** realtime, websocket #### Design a video streaming platform (upload, process, watch). - **ID:** `sd-youtube` - **Category:** system-design - **Difficulty:** senior - **Why they ask:** End-to-end: storage, async pipelines, CDN, and cost. - **Structure:** 1. Upload path and resumable uploads 2. Transcoding pipeline (async workers) 3. Metadata store + object storage for blobs 4. Playback: CDN, adaptive bitrate 5. Scale hot videos; moderation hooks - **Talking points:** - Separate control plane (metadata) from data plane (bytes). - Cost drivers: storage egress and transcoding. - SLA for processing time vs quality ladders. - **Follow-ups:** Live streaming differences? | How do you handle copyright claims? - **Related chapters:** system-design, system-architecture - **Related frameworks:** none - **Tags:** media, cdn, pipelines #### How do you decide quality attributes before choosing technologies? - **ID:** `ar-quality` - **Category:** architecture - **Difficulty:** core - **Why they ask:** Architects who start with tools fail interviews and real designs. - **Structure:** 1. Name top 3 attributes for the problem 2. Attach measurable signals (SLO, budget, latency) 3. Map attributes to tactics (cache, queue, partition, etc.) 4. Call out sacrificed attributes - **Talking points:** - Availability, latency, consistency, security, cost, operability, cognitive load. - Reject vanity scale you do not have. - Document trade-offs in an ADR. - **Follow-ups:** Give an example where you optimized the wrong attribute. - **Related chapters:** architecture-practices, system-design - **Related frameworks:** quality-attributes, adr - **Tags:** quality attributes, trade-offs #### When would you split a monolith into services, and when would you not? - **ID:** `ar-microservices` - **Category:** architecture - **Difficulty:** core - **Why they ask:** Premature microservices are a common senior failure mode. - **Structure:** 1. Start with modularity inside one deployable 2. Split when independent deploy, scale, or team ownership clearly pays the tax 3. Name distributed costs: latency, tracing, contracts, on-call 4. Migration: strangler, dual-write, rollback - **Talking points:** - Split on domain and change frequency, not folder count. - Conway: org shape will fight bad service cuts. - Fitness functions to keep boundaries honest. - **Follow-ups:** How do you handle shared data? - **Related chapters:** system-architecture, architecture-practices - **Related frameworks:** modular-boundaries, conway, fitness-functions - **Tags:** microservices, modularity #### How do you run design reviews and record decisions on a team? - **ID:** `ar-adr` - **Category:** architecture - **Difficulty:** core - **Why they ask:** Leads must create decision memory, not only smart meetings. - **Structure:** 1. Lightweight template: problem, constraints, options, recommendation 2. Review facilitation: quiet voices first, time-box bikesheds 3. ADR for decisions that will be re-litigated 4. Owners and revisit dates - **Talking points:** - Require at least two viable options. - Separate preference from constraint. - One-page ADRs beat novels nobody reads. - **Follow-ups:** What if senior engineers keep reopening decisions? - **Related chapters:** system-design, decisions, communication - **Related frameworks:** design-review, adr, daci - **Tags:** design review, ADR #### How do you prioritize technical debt against product roadmap? - **ID:** `ar-debt` - **Category:** architecture - **Difficulty:** stretch - **Why they ask:** Shows whether you can fund reliability without gold-plating. - **Structure:** 1. Classify debt: safety, speed, or cosmetic 2. Attach user or ops risk to safety/speed debt 3. Budget explicit capacity (e.g. 15-20%) 4. Bundle debt with feature work when possible - **Talking points:** - Use incidents and DORA signals as evidence. - Kill rewrite fantasies without milestones. - Make debt visible in the same priority stack as features. - **Follow-ups:** Tell me about a debt investment that paid off. - **Related chapters:** operating, stakeholders, architecture-practices - **Related frameworks:** dora, okrs, wip - **Tags:** tech debt, prioritization #### Walk me through how you lead a high-severity incident as a team lead. - **ID:** `ar-incident` - **Category:** architecture - **Difficulty:** stretch - **Why they ask:** Calm systems thinking under pressure is a lead differentiator. - **Structure:** 1. Declare severity and incident commander 2. Mitigate first; root cause later 3. Comms: users, stakeholders, status cadence 4. Blameless postmortem with owners and due dates - **Talking points:** - Slow your speech; separate containment from fixes. - Protect the room from ten managers. - Turn learning into architecture fitness or runbooks. - **Follow-ups:** How do you handle a repeat incident? - **Related chapters:** self, operating, trust - **Related frameworks:** dora, psych-safety - **Tags:** incident, reliability #### How would you design a hiring scorecard and loop for a senior engineer on your team? - **ID:** `hire-scorecard` - **Category:** people - **Difficulty:** core - **Why they ask:** Checks if you hire with structure or vibe, and whether you can raise the bar fairly. - **Structure:** 1. Define role outcomes for 6-12 months 2. List attributes with observable signals 3. Describe stages and who owns signal 4. Explain debrief and bias checks 5. Close with onboarding activation - **Talking points:** - Same core questions per level for comparability - Written feedback within 24 hours using the scorecard - Separate must-have vs teachable skills - Calibration on evidence, not charisma - **Follow-ups:** How do you handle a split panel? | What would make you reject a strong coder? - **Related chapters:** hiring-leveling, feedback - **Related frameworks:** none - **Tags:** hiring, scorecard, bar #### Tell me about a time you coached someone toward a promotion, or told them they were not ready. - **ID:** `leveling-promo` - **Category:** people - **Difficulty:** stretch - **Why they ask:** Looks for leveling fairness, feedback courage, and growth planning. - **Structure:** 1. Situation and level expectation 2. Evidence you shared mid-cycle 3. Support plan 4. Outcome and what you would improve - **Talking points:** - No surprises in calibration - Scope sustained over time, not one hero project - Dual track respect if relevant - **Follow-ups:** How do you write a promo packet? - **Related chapters:** hiring-leveling, feedback, stakeholders - **Related frameworks:** none - **Tags:** leveling, promo, coaching #### How do you decide what tech debt to fund this quarter? - **ID:** `tech-debt-fund` - **Category:** execution - **Difficulty:** core - **Why they ask:** Checks portfolio thinking and how you talk about risk with stakeholders. - **Structure:** 1. Inventory and scoring 2. Risk language for partners 3. Capacity budget 4. Milestones vs big-bang rewrite - **Talking points:** - Risk × frequency × blast radius - Residual risk if deferred - Mix paydown into feature work when possible - **Follow-ups:** Give an example you deferred and why. - **Related chapters:** architecture-practices, decisions, stakeholders - **Related frameworks:** none - **Tags:** tech-debt, prioritization #### Walk me through how you would review a new cross-team API before freeze. - **ID:** `api-contract` - **Category:** architecture - **Difficulty:** stretch - **Why they ask:** Checks contract thinking, compatibility, and operability. - **Structure:** 1. Consumers and use cases 2. Resources, errors, auth 3. Versioning and deprecation 4. SLOs and contract tests - **Talking points:** - Idempotency for writes - Additive change preference - Pilot consumer before hard freeze - **Follow-ups:** How do you handle a breaking change request? - **Related chapters:** system-design, architecture-practices - **Related frameworks:** none - **Tags:** api, contracts, review --- ## Learning resources URL: https://lead-without-the-title.grok.me/learn ### Learning paths #### Software Architecture Best Practices Quality attributes, boundaries, standards, and smells. Start with Fundamentals of Software Architecture, then Clean Architecture principles, then Hard Parts for distributed trade-offs. - Chapter: https://lead-without-the-title.grok.me/read/architecture-practices - Resource IDs: fsa, clean-arch, hard-parts, course-coursera-alberta, yt-gaurav #### System Design Frame problems, estimate scale, and design APIs/data/failure modes. Pair freeCodeCamp foundations with ByteByteGo visuals and a structured course. - Chapter: https://lead-without-the-title.grok.me/read/system-design - Resource IDs: yt-fcc-simonyan, yt-bytebytego, sdi-xu, course-bytebytego, course-educative-grokking, yt-gaurav, yt-hellointerview, yt-codekarle, yt-fcc-youtube-clone #### System Architecture Long-lived structure: domains, runtime topology, evolution. DDIA + Hard Parts for depth; ByteByteGo and Coursera for broader framing. - Chapter: https://lead-without-the-title.grok.me/read/system-architecture - Resource IDs: ddia, hard-parts, fsa, yt-bytebytego, course-bytebytego, course-coursera-alberta #### People management shelf 1:1s, feedback, hiring judgment, and resilient leadership for new leads. - Chapter: https://lead-without-the-title.grok.me/read/feedback - Resource IDs: managers-path-book, resilient-management, radical-candor-book, staffeng-site, charity-majors-mgmt ### All curated resources #### Designing Data-Intensive Applications - **Kind:** book (Book) - **Author:** Martin Kleppmann - **Focus:** Distributed data systems theory with production-minded trade-offs - **Topics:** system-design, system-architecture - **Free:** no / freemium - **URL:** https://dataintensive.net/ - **Why:** The gold standard for storage engines, replication, partitioning, streams, and consensus. Read when system design debates get hand-wavy. - **Pairs with chapters:** system-design, system-architecture #### Fundamentals of Software Architecture - **Kind:** book (Book) - **Author:** Mark Richards & Neal Ford - **Focus:** Architectural styles, characteristics, and the architect role - **Topics:** architecture, system-architecture - **Free:** no / freemium - **URL:** https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/ - **Why:** Practical bridge from senior developer to architect: quality attributes, styles, soft skills, and team structure. - **Pairs with chapters:** architecture-practices, system-architecture #### Software Architecture: The Hard Parts - **Kind:** book (Book) - **Author:** Neal Ford, Mark Richards, et al. - **Focus:** Coupling, granularity, and data ownership in distributed systems - **Topics:** architecture, system-architecture - **Free:** no / freemium - **URL:** https://www.oreilly.com/library/view/software-architecture-the/9781492086888/ - **Why:** Goes beyond styles into the painful trade-offs of service boundaries, shared data, and disintegrators/integrators. - **Pairs with chapters:** system-architecture, architecture-practices #### System Design Interview (Vol 1 & 2) - **Kind:** book (Book + digital) - **Author:** Alex Xu (and Sahn Lam on Vol 2) - **Focus:** Step-by-step designs for real interview and production patterns - **Topics:** system-design - **Free:** no / freemium - **URL:** https://bytebytego.com/courses/system-design-interview - **Why:** Clear frameworks for rate limiters, feeds, chat, storage, and estimation. Best paired with actual production design practice. - **Pairs with chapters:** system-design #### Clean Architecture - **Kind:** book (Book) - **Author:** Robert C. Martin - **Focus:** SOLID, component boundaries, and dependency rules - **Topics:** architecture - **Free:** no / freemium - **URL:** https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/ - **Why:** Keeps business policy independent of frameworks. Use principles over dogma when applying to modern stacks. - **Pairs with chapters:** architecture-practices #### ByteByteGo - **Kind:** youtube (YouTube channel) - **Author:** Alex Xu & Sahn Lam - **Focus:** Visual diagrams of large-scale architectures and industry patterns - **Topics:** system-design, system-architecture - **Free:** yes - **URL:** https://www.youtube.com/@ByteByteGo - **Why:** Short, high-signal explainers of how real platforms scale (feeds, payments, messaging, caches). - **Pairs with chapters:** system-design, system-architecture #### Gaurav Sen. System Design Playlist - **Kind:** youtube (YouTube playlist) - **Author:** Gaurav Sen (@gkcs) - **Focus:** Distributed primitives: hashing, queues, partitioning, rate limits - **Topics:** system-design, architecture - **Free:** yes - **URL:** https://www.youtube.com/playlist?list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX - **Why:** Strong conceptual depth without pure interview scripting. Excellent for building intuition on primitives. - **Pairs with chapters:** system-design, architecture-practices #### System Design Course. APIs, Databases, Caching & Infra - **Kind:** youtube (Full video course (~2h)) - **Author:** Hayk Simonyan via freeCodeCamp - **Focus:** End-to-end foundation: scaling, load balancing, APIs, security - **Topics:** system-design, architecture - **Free:** yes - **URL:** https://www.youtube.com/watch?v=C842vFY5kRo - **Why:** Complete beginner-to-production walkthrough published on freeCodeCamp (2026). Ideal first video course. - **Pairs with chapters:** system-design, architecture-practices #### High-Level System Design: Build a YouTube-like Platform - **Kind:** youtube (Full video course (~2h)) - **Author:** Keerti Purswani via freeCodeCamp - **Focus:** Upload, watch, transcoder services as a worked HLD example - **Topics:** system-design, system-architecture - **Free:** yes - **URL:** https://www.youtube.com/watch?v=FiXOaYnW64w - **Why:** Hands-on case study that connects diagrams to a realistic multi-service design. - **Pairs with chapters:** system-design, system-architecture #### CodeKarle (System Design) - **Kind:** youtube (YouTube channel) - **Author:** Sandeep Kaul - **Focus:** Interview-style high-availability designs and enterprise patterns - **Topics:** system-design, system-architecture - **Free:** yes - **URL:** https://www.youtube.com/@CodeKarle - **Why:** Approachable walkthroughs of common HA designs; useful after you know the primitives. - **Pairs with chapters:** system-design #### Hello Interview. System Design Walkthroughs - **Kind:** youtube (YouTube channel) - **Author:** Hello Interview - **Focus:** Staff-level interview walkthroughs and pattern deep dives - **Topics:** system-design - **Free:** yes - **URL:** https://www.youtube.com/@hello_interview - **Why:** Modern walkthroughs that mirror how FAANG-style interviews are actually assessed. - **Pairs with chapters:** system-design #### ByteByteGo Platform - **Kind:** course (Interactive text + diagrams) - **Author:** Alex Xu & team - **Focus:** Illustrated system design curriculum with ongoing case studies - **Topics:** system-design, system-architecture - **Free:** no / freemium - **URL:** https://bytebytego.com/ - **Why:** Living expansion of the System Design Interview books with regular updates and visual depth. - **Pairs with chapters:** system-design, system-architecture #### Grokking the System Design Interview - **Kind:** course (Text-interactive course) - **Author:** Design Gurus / Educative - **Focus:** Trade-offs, capacity estimation, and high-availability patterns - **Topics:** system-design - **Free:** no / freemium - **URL:** https://www.educative.io/courses/grokking-the-system-design-interview - **Why:** Classic structured path for interview-style design with explicit trade-off framing. - **Pairs with chapters:** system-design #### Software Design and Architecture Specialization - **Kind:** course (Academic video specialization) - **Author:** University of Alberta (Coursera) - **Focus:** OOA/D, design patterns, and enterprise architecture styles - **Topics:** architecture, system-architecture - **Free:** no / freemium - **URL:** https://www.coursera.org/specializations/software-design-architecture - **Why:** Structured academic series when you want formal design patterns and architecture foundations, not only interview drills. - **Pairs with chapters:** architecture-practices, system-architecture #### The Manager's Path - **Kind:** book (Book) - **Author:** Camille Fournier - **Focus:** Engineering leadership stages from mentor to director - **Topics:** people-management - **Free:** no / freemium - **URL:** https://www.oreilly.com/library/view/the-managers-path/9781491973882/ - **Why:** The practical map of eng leadership altitudes. Pair with the hiring and 90-days chapters. - **Pairs with chapters:** mindset, hiring-leveling, playbook #### Resilient Management - **Kind:** book (Book) - **Author:** Lara Hogan - **Focus:** 1:1s, feedback, and steady leadership under stress - **Topics:** people-management - **Free:** no / freemium - **URL:** https://resilient-management.com/ - **Why:** Concrete people practices without jargon fog. Strong on feedback and team health. - **Pairs with chapters:** feedback, trust, self #### Radical Candor - **Kind:** book (Book) - **Author:** Kim Scott - **Focus:** Care personally, challenge directly - **Topics:** people-management - **Free:** no / freemium - **URL:** https://www.radicalcandor.com/ - **Why:** A usable model for feedback that is neither silence nor brutality. - **Pairs with chapters:** feedback, pay-performance-exits #### StaffEng guides (web) - **Kind:** youtube (Essays) - **Author:** Will Larson et al. - **Focus:** Staff-plus IC leadership without people management - **Topics:** people-management, architecture - **Free:** yes - **URL:** https://staffeng.com/guides/ - **Why:** How senior ICs create leverage. Useful dual-track context. - **Pairs with chapters:** influence, hiring-leveling, system-architecture #### Charity Majors on engineering management - **Kind:** youtube (Talks / interviews) - **Author:** Charity Majors - **Focus:** Management craft, on-call, and technical leadership opinions - **Topics:** people-management - **Free:** yes - **URL:** https://www.youtube.com/results?search_query=charity+majors+engineering+management - **Why:** Blunt, experience-heavy takes on what managers owe their teams. - **Pairs with chapters:** operating, self, mindset #### Team Topologies - **Kind:** book (Book + resources) - **Author:** Matthew Skelton & Manuel Pais - **Focus:** Team types, interaction modes, and cognitive load for fast flow - **Topics:** team-design, architecture, people-management - **Free:** no / freemium - **URL:** https://teamtopologies.com/ - **Why:** The practical language for stream, platform, enabling, and complicated-subsystem teams. Pair with the Team Topology Patterns chapter. - **Pairs with chapters:** team-topologies, operating, system-architecture --- ## Templates pack URL: https://lead-without-the-title.grok.me/templates ### 1:1 agenda - **ID:** `one-on-one` - **Category:** people - **Summary:** A light weekly 1:1 structure that balances their topics and yours. - **Pairs with chapters:** feedback, operating, self ```markdown # 1:1, {{name}}, {{date}} ## Their topics (first 20 min) - - ## Goals & growth - Current focus: - Skill stretch this month: - Blockers: ## Feedback (both directions) - Appreciation: - Request / experiment: ## Delivery & priorities - Top commitments until next 1:1: - Risks I should know: ## Notes / decisions - ## Next check-in - Date: - Follow-ups (owner): ``` ### Hiring scorecard - **ID:** `hiring-scorecard` - **Category:** hiring - **Summary:** Define role outcomes and attributes before the first screen. - **Pairs with chapters:** hiring-leveling, feedback ```markdown # Hiring scorecard, {{role}} ({{level}}) ## Mission of the seat (6-12 months) 1. 2. 3. ## Must-have vs teachable | Skill | Must-have | Teachable | Notes | | --- | --- | --- | --- | | | | | | ## Attributes (score Strong / Mixed / Weak) 1. Problem decomposition, signals: 2. Code / craft quality, signals: 3. Collaboration, signals: 4. Ownership, signals: 5. System design judgment, signals: 6. Communication, signals: ## Loop design - Screen: - Work sample / coding: - Design: - Collaboration: - Hiring manager: ## Calibration notes - Bar for this level: - Common false positives to avoid: ``` ### Promo / leveling evidence - **ID:** `promo-packet` - **Category:** hiring - **Summary:** Capture sustained scope, not activity lists. - **Pairs with chapters:** hiring-leveling, stakeholders ```markdown # Leveling evidence, {{name}} → {{target_level}} ## Scope of impact (last 2-3 cycles) - Outcomes delivered: - Ambiguity handled: - Influence radius (team / multi-team / org): ## Evidence bullets (outcome → how → result) 1. 2. 3. ## Feedback from others - Peers: - Cross-functional partners: - Manager notes: ## Gaps & plan - Gaps vs target level: - Support / stretch work: ## Decision - Ready now / ready with conditions / not yet: - Conditions or timeline: ``` ### Architecture Decision Record - **ID:** `adr` - **Category:** architecture - **Summary:** One-page ADR for choices that will be re-litigated. - **Pairs with chapters:** architecture-practices, system-architecture, decisions ```markdown # ADR {{number}}: {{title}} - Status: Proposed | Accepted | Superseded - Date: - Deciders: ## Context What forces are in play (quality attributes, constraints, incidents)? ## Decision drivers 1. 2. ## Options considered ### Option A - Pros: - Cons: ### Option B - Pros: - Cons: ## Decision We will… ## Consequences - Positive: - Negative / debt accepted: - Follow-ups / fitness checks: ``` ### Tech debt portfolio item - **ID:** `tech-debt` - **Category:** architecture - **Summary:** Fund debt with risk language stakeholders understand. - **Pairs with chapters:** architecture-practices, decisions, stakeholders ```markdown # Debt item, {{name}} - Owner: - First seen / last incident: - Systems touched: ## If we do nothing - User / revenue risk: - Engineering drag (estimate): - Blast radius: ## Investment options | Option | Effort | Outcome metric | Residual risk | | --- | --- | --- | --- | | Full fix | | | | | Mitigate | | | | | Accept | 0 | | | ## Recommendation - ## Decision & review date - ``` ### API design review checklist - **ID:** `api-review` - **Category:** architecture - **Summary:** Contract-first questions before you freeze a cross-team API. - **Pairs with chapters:** system-design, architecture-practices ```markdown # API review, {{service}} {{api_name}} ## Consumers & use cases - ## Resources & operations - Naming matches domain? - Pagination / filtering / sorting? - Idempotency for writes? ## Errors & auth - Error codes documented? - Authn/z boundaries clear? - Audit / tenancy? ## Compatibility - Versioning strategy: - Additive vs breaking changes: - Deprecation policy: ## Operability - SLOs / rate limits: - Observability (metrics, traces): - Rollback / dual-run plan: ## Decision - Approve / revise / reject: ``` ### Incident notes & blameless outline - **ID:** `incident` - **Category:** delivery - **Summary:** Contain now; learn with facts later. - **Pairs with chapters:** trust, operating, system-architecture ```markdown # Incident, {{title}}, {{date}} ## Severity & impact - Started / detected / mitigated / resolved: - User impact: ## Timeline (UTC) - ## What helped / what hurt - ## Contributing factors (systems, not villains) 1. 2. ## Action items | Action | Owner | Due | Status | | --- | --- | --- | --- | | | | | | ## Follow-up comms - Who was informed: - External note needed? ``` ### Weekly priority stack - **ID:** `priority-stack` - **Category:** delivery - **Summary:** Force-rank work and publish what drops. - **Pairs with chapters:** decisions, operating, stakeholders ```markdown # Priority stack, week of {{date}} ## Capacity (engineer-days) - Available: - Meetings / support tax: - Net: ## Ranked outcomes (no ties) 1. 2. 3. ## Explicitly not this week - ## Risks & asks - ## Stakeholder note (3 bullets) 1. Progress: 2. Risk: 3. Ask: ``` ### Compensation conversation outline - **ID:** `comp-conversation` - **Category:** hiring - **Summary:** Structure offer, raise, or equity talks without overpromising. - **Pairs with chapters:** pay-performance-exits, hiring-leveling ```markdown # Compensation conversation, {{person}}, {{date}} ## Role & level - Scope next 6 months: - Level / band: ## Package (facts only) - Base: - Bonus / equity: - Other: ## Market / internal equity notes - ## Message structure 1. Excitement about role/impact 2. Package clearly 3. What is flexible vs fixed 4. Questions ## If the answer is no / not now - Constraint: - Next review window: - Non-monetary support: ## Follow-ups - ``` ### Performance improvement plan outline - **ID:** `pip-plan` - **Category:** people - **Summary:** Only after prior feedback. Partner with HR. Specific and time-bound. - **Pairs with chapters:** pay-performance-exits, feedback ```markdown # PIP outline, {{name}}, start {{date}} end {{end_date}} ## Prior feedback trail - Dates / themes: ## Gaps (observed, with examples) 1. 2. ## What “meets” looks like 1. 2. ## Support provided - Coaching: - Pairing / scope: - Training: ## Check-ins | Date | Focus | Notes | | --- | --- | --- | | | | | ## Outcomes - Met / not met: - Next step: ``` ### Team AI use norms - **ID:** `ai-team-norms` - **Category:** delivery - **Summary:** One-page policy: allowed, banned, review, secrets. - **Pairs with chapters:** ai-for-leads, operating ```markdown # Team AI norms, {{team}}, {{date}} ## Encouraged - Drafting updates from notes you verify - Brainstorming options / test ideas - Summarizing long docs you still read ## Not allowed without extra review - Final hiring or performance decisions - Unreviewed production code from AI alone - Pasting secrets or private personal data ## Review rule If you would not sign your name under it, do not ship it. ## Tools approved here - ## Examples of good use 1. 2. ``` ### Team topology one-pager - **ID:** `team-topology-one-pager` - **Category:** delivery - **Summary:** Mission, team type, streams, and interaction modes with neighbors. - **Pairs with chapters:** team-topologies, operating, system-architecture ```markdown # Team topology one-pager — {{team}} — {{date}} ## Mission (one sentence) ## Team type - [ ] Stream-aligned - [ ] Platform - [ ] Enabling - [ ] Complicated-subsystem - Why this type: ## Streams / services we own 1. 2. ## What we explicitly do not own ## Neighbors and interaction modes | Neighbor | Actual mode | Desired mode | Notes | | --- | --- | --- | --- | | | Collaboration / XaaS / Facilitating | | | ## Platform or service expectations (if applicable) - Docs: - SLO: - Support path: - Versioning / deprecation: ## Cognitive load risks - ## Next topology experiment (30 days) - ``` ### Quarterly capacity plan - **ID:** `capacity-plan` - **Category:** delivery - **Summary:** Demand vs supply, scenarios, and an explicit will-not-do list. - **Pairs with chapters:** headcount-capacity, decisions, hiring-leveling, team-topologies ```markdown # Capacity plan — {{team}} — {{quarter}} ## Outcomes this quarter 1. 2. ## Demand (engineer-weeks) | Stream | Work | Est. weeks | Notes | | --- | --- | --- | --- | | Product | | | | | KTLO / support | | | | | Debt / platform | | | | | Hiring / onboarding | | | | | **Total demand** | | | | ## Supply - People (FTE): - Weeks in period: - Focus factor (0.6-0.75 typical): - Minus PTO / leave / ramp: - **Available engineer-weeks:** ## Stability reserve - % or weeks held back: - Why: ## Scenarios ### Stay flat - What ships: - What slips: - Risks: ### +1 hire (role: ) - What changes by when: - Ramp assumptions: ### Scope cut (if hire denied) - Cuts: - Communication plan: ## Will not do this quarter - - ## Decision asked of leadership - ``` ### Team OKR cycle sheet - **ID:** `okr-cycle` - **Category:** delivery - **Summary:** Few objectives, measurable KRs, counter-metrics, and won’t-do list. - **Pairs with chapters:** okrs-kpis, decisions, stakeholders, headcount-capacity ```markdown # Team OKRs — {{team}} — {{cycle}} ## Mission (stable) ## North star metric (if any) - Metric: - Definition / source: ## Objective 1 **O:** | Key Result | Baseline | Target | Source | Counter-metric | | --- | --- | --- | --- | --- | | | | | | | | | | | | | ## Objective 2 (optional) **O:** | Key Result | Baseline | Target | Source | Counter-metric | | --- | --- | --- | --- | --- | | | | | | | ## Standing KPIs we watch (not OKRs) | KPI | Threshold / SLO | Owner | If red we… | | --- | --- | --- | --- | | | | | | ## Will not do this cycle - ## Capacity link - Available engineer-weeks: - Risks: ## Mid-cycle check (date) - On track / at risk / off: - Learning: ``` ### Team setup charter - **ID:** `team-setup-charter` - **Category:** delivery - **Summary:** Mission, size, two-pizza check, interfaces, and communication system. - **Pairs with chapters:** team-topologies, communication, operating, okrs-kpis ```markdown # Team setup charter — {{team}} — {{date}} ## Mission (one sentence) ## Non-goals ## Size and composition - Headcount: - Two-pizza / cognitive load check: pass / fail / mitigate how: - Seniority mix notes: ## Streams / services owned ## Explicitly not owned (consume as XaaS) ## Neighbor interaction modes | Neighbor | Mode | Notes | | --- | --- | --- | | | Collaboration / XaaS / Facilitating | | ## Communication system - Source of truth: - Decision log: - Status rhythm: - Interrupt / on-call path: - Cross-team ask path: ## Working agreements - ## Success metrics - OKR cycle link: - KPI set: ``` ### Work handover contract - **ID:** `handover-contract` - **Category:** delivery - **Summary:** Break down outcome, RACI matrix, end-to-end ownership, checklist, and handover metrics. - **Pairs with chapters:** delegation-handover, communication, operating, feedback ```markdown # Handover contract — {{work-title}} — {{date}} ## Owner (end-to-end) - Name: - Backup: ## Context (why now) ## Outcome (definition of done) - User / system result: - Quality / operability bar: ## Non-goals ## Constraints - Time: - Dependencies: - Risk / compliance: - Performance / SLO: ## Breakdown (value slices) 1. 2. 3. ## Decision rights | Decision type | Owner decides | Consult | Approver | | --- | --- | --- | --- | | Local implementation | | | | | Interface / API contract | | | | | Scope change | | | | | Launch / rollback | | | | ## RACI matrix (required in checklist) R = Responsible (does the work) · A = Accountable (one per row) · C = Consulted · I = Informed | Activity | Eng owner | Tech lead | Product | Partner team | Other | | --- | --- | --- | --- | --- | --- | | Problem framing / design | | | | | | | Implementation | | | | | | | Code / design review | | | | | | | Launch / rollout | | | | | | | Comms to stakeholders | | | | | | | Rollback / incident response | | | | | | | Success metrics / validation | | | | | | Rules: exactly one A per activity. Lead should not keep A on every row after handover. ## Checkpoints (risk-based, not hourly) | When | Artifact | Who | | --- | --- | --- | | | Design note / ADR | | | | Mid-slice demo | | | | Launch readiness | | ## Support from lead - I will: - I will not (no longer owning): ## Escalation red flags - ## Teach-back (owner fills) - Problem in my words: - First slice: - How I get unblocked: ## Handover checklist (all should be yes before lead steps back) - [ ] Outcome + quality bar written - [ ] Non-goals written - [ ] Context links complete - [ ] End-to-end owner (+ backup if needed) - [ ] RACI matrix filled (one A per activity; owner can explain C vs I) - [ ] Teach-back passed - [ ] Decision rights table filled - [ ] Risk-based checkpoints booked - [ ] Interfaces / rollout / rollback named - [ ] Lead support boundaries set - [ ] Escalation red flags listed - [ ] Operability (logs/metrics/alerts/runbook) included if production-facing - [ ] Done = how we know it worked (metric / test / user check) ## Handover metrics (track 3-5) | Metric | Definition | Baseline | Target / watch | Source | | --- | --- | --- | --- | --- | | Time-to-first-progress | | | | | | Checkpoint hit rate | | | | | | Lead interrupt rate | | | | | | Blocker age (median) | | | | | | Re-decision rate | | | | | | Owner confidence (1-5) start → mid | | | | | | Quality counter-metric | | | | | ## Review dates - Mid-checkpoint: - Closeout: ``` ### Feedback loop design one-pager - **ID:** `feedback-loop-design` - **Category:** delivery - **Summary:** Define sensor, cadence, comparison, decision, actuator, and memory for one loop. - **Pairs with chapters:** feedback-loops, feedback, operating, okrs-kpis ```markdown # Feedback loop design — {{loop-name}} — {{date}} ## Loop type - [ ] People - [ ] Delivery - [ ] Product - [ ] Operations - [ ] Other: ## Problem (why this loop) What open loop pain are we fixing? ## Anatomy | Part | Design | | --- | --- | | Sensor (signal) | | | Cadence | | | Who looks | | | Comparison (intent / threshold) | | | Decision forum | | | Actuator (who changes the system) | | | Memory (where learning lives) | | ## Action rule If signal is red / off target, we will: ## First two-week experiment - Start date: - Success = one real decision or change: - Owner: ## Loop health metrics | Metric | Definition | Current | Target | | --- | --- | --- | --- | | Action completion rate | | | | | Repeat signal rate | | | | | Decision latency | | | | | Owner clarity (% actions with one name) | | | | ## Anti-patterns to avoid - ``` ### Servant leadership 30-day practice - **ID:** `servant-leadership-30d` - **Category:** people - **Summary:** Weekly habits, blocker kill list, handover, and health check for enablement over heroics. - **Pairs with chapters:** servant-leadership, delegation-handover, feedback-loops, trust ```markdown # Servant leadership — 30-day practice — {{team}} — {{start-date}} ## Intent (one sentence) How I will serve this team so they are stronger without me in every detail: ## Week 1 — Listen | Person | Protect | Change | Stop | | --- | --- | --- | --- | | | | | | Themes: ## Week 2 — Remove one blocker - Blocker: - Owner of fix: - Done when: ## Week 3 — Hand over one stream - Stream: - Owner: - RACI / checklist green? Y/N - Coaching checkpoints: ## Week 4 — Close one feedback loop - Loop (people / delivery / product / ops): - Sensor → decision → change: ## Weekly scorecard (1-5) | Week | Team ownership | My interrupt load | Hard feedback given | Credit shared | Notes | | --- | --- | --- | --- | --- | --- | | 1 | | | | | | | 2 | | | | | | | 3 | | | | | | | 4 | | | | | | ## Not servant (watch list) - [ ] Saying yes to infinite scope - [ ] Avoiding conflict - [ ] Doing all hard tasks myself - [ ] Withholding context as power ``` --- ## Glossary URL: https://lead-without-the-title.grok.me/glossary ### ADR - **Short:** Architecture Decision Record - **Definition:** A short write-up of a significant technical choice: context, options, decision, and consequences. Used so teams stop re-litigating the same debate from memory. - **Related chapters:** architecture-practices, decisions, system-architecture - **Anchor:** https://lead-without-the-title.grok.me/glossary#adr ### DACI - **Short:** Driver, Approver, Contributors, Informed - **Definition:** A decision-role model. The Driver pushes the decision forward, the Approver has final say, Contributors give input, Informed people get the outcome. Prevents “everyone decides” fog. - **Related chapters:** decisions, stakeholders, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#daci ### RACI - **Short:** Responsible, Accountable, Consulted, Informed - **Definition:** A classic ownership matrix for work items. Similar spirit to DACI, often used for process and project roles rather than a single decision. - **Related chapters:** operating, decisions, delegation-handover - **Anchor:** https://lead-without-the-title.grok.me/glossary#raci ### DORA metrics - **Short:** Delivery performance signals - **Definition:** Four measures used in software delivery research: deployment frequency, lead time for changes, change fail rate, and time to restore service. Useful for diagnosing system health, easy to game if turned into naive targets. - **Related chapters:** operating, architecture-practices - **Anchor:** https://lead-without-the-title.grok.me/glossary#dora ### WIP - **Short:** Work in progress - **Definition:** How many items are started but not finished. High WIP usually means thrash and slow delivery. Lowering WIP often finishes more than adding people. - **Related chapters:** operating, decisions - **Anchor:** https://lead-without-the-title.grok.me/glossary#wip ### Architecture fitness function - **Short:** Automated check of architecture intent - **Definition:** A test or monitor that protects a design rule (dependency direction, schema compatibility, latency budget, module boundaries). Architecture that is not checked drifts. - **Related chapters:** system-architecture, architecture-practices - **Anchor:** https://lead-without-the-title.grok.me/glossary#fitness-function ### SLO / SLI - **Short:** Service level objective / indicator - **Definition:** An SLI is a measured signal (availability, latency). An SLO is the target you commit to for that signal. Leads use them to trade features against reliability with eyes open. - **Related chapters:** system-design, architecture-practices - **Anchor:** https://lead-without-the-title.grok.me/glossary#slo-sli ### STAR - **Short:** Situation, Task, Action, Result - **Definition:** A structure for behavioral interview answers. Keep Action about what you did, and Result concrete when you can. - **Related chapters:** feedback, hiring-leveling - **Anchor:** https://lead-without-the-title.grok.me/glossary#star ### PIP - **Short:** Performance improvement plan - **Definition:** A time-bound, written plan when performance is below the bar. Should follow prior feedback, include clear outcomes and support, and end with a real decision. Partner with HR. - **Related chapters:** pay-performance-exits, feedback, hiring-leveling - **Anchor:** https://lead-without-the-title.grok.me/glossary#pip ### Two-way door decision - **Short:** Reversible choice - **Definition:** A decision you can undo cheaply. Move fast. Contrast with one-way doors (hard to reverse): public APIs, major migrations, hires at the wrong level. - **Related chapters:** decisions, system-design - **Anchor:** https://lead-without-the-title.grok.me/glossary#two-way-door ### Psychological safety - **Short:** Truth can travel - **Definition:** The shared belief that people can raise risks, admit mistakes, and challenge plans without punishment. Not the same as “being nice.” - **Related chapters:** trust, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#psychological-safety ### Strangler pattern - **Short:** Replace legacy gradually - **Definition:** Grow a new system around an old one and route traffic piece by piece, instead of a big-bang rewrite. Favored when risk of full replacement is high. - **Related chapters:** system-architecture, architecture-practices - **Anchor:** https://lead-without-the-title.grok.me/glossary#strangler ### Blast radius - **Short:** How far failure spreads - **Definition:** The scope of users, systems, or teams hurt if something fails. Leads use it when ranking incidents, debt, and rollout plans. - **Related chapters:** system-design, architecture-practices, trust - **Anchor:** https://lead-without-the-title.grok.me/glossary#blast-radius ### Idempotency - **Short:** Same request, same effect - **Definition:** A property of operations where retries do not double-apply side effects. Critical for payments, webhooks, and flaky networks. - **Related chapters:** system-design - **Anchor:** https://lead-without-the-title.grok.me/glossary#idempotency ### Conway’s law - **Short:** Org shapes system - **Definition:** Teams design systems that mirror their communication structure. If you want different architecture, you may need different team interfaces. - **Related chapters:** system-architecture, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#conway ### Dual track - **Short:** IC and manager paths - **Definition:** Parallel career paths for senior technical leadership and people leadership, so growth is not “manage or stagnate.” - **Related chapters:** hiring-leveling, mindset, self - **Anchor:** https://lead-without-the-title.grok.me/glossary#dual-track ### Stream-aligned team - **Short:** Team on a flow of change - **Definition:** A team aligned to a continuous stream of work for a user segment or business domain. Aims for end-to-end ownership of outcomes to reduce handoffs. - **Related chapters:** team-topologies, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#stream-aligned ### Platform team - **Short:** Internal product for other teams - **Definition:** A team that provides self-service capabilities and paved roads so stream-aligned teams can deliver with less cognitive load. Best run as a product with users and SLOs, not only a ticket queue. - **Related chapters:** team-topologies, architecture-practices - **Anchor:** https://lead-without-the-title.grok.me/glossary#platform-team ### Enabling team - **Short:** Temporary capability builders - **Definition:** A team that helps others learn missing skills or adopt practices, then steps away. Without an exit criteria, enabling quietly becomes permanent ownership. - **Related chapters:** team-topologies, feedback - **Anchor:** https://lead-without-the-title.grok.me/glossary#enabling-team ### Complicated-subsystem team - **Short:** Specialist ownership - **Definition:** A team that owns a complex specialty (for example a billing core or ML runtime) so stream teams can consume it through a clear interface without absorbing the full complexity. - **Related chapters:** team-topologies, system-architecture - **Anchor:** https://lead-without-the-title.grok.me/glossary#complicated-subsystem ### X-as-a-Service - **Short:** Interaction via clear service - **Definition:** An interaction mode where one team provides a service with documentation, SLOs, and support, so others consume without continuous collaboration. - **Related chapters:** team-topologies, system-architecture - **Anchor:** https://lead-without-the-title.grok.me/glossary#x-as-a-service ### Cognitive load (teams) - **Short:** How much a team must hold in mind - **Definition:** The amount of domain, tooling, and process knowledge a team must maintain to deliver. Topology design aims to keep load within what a team can handle. - **Related chapters:** team-topologies, operating, self - **Anchor:** https://lead-without-the-title.grok.me/glossary#cognitive-load ### Capacity planning - **Short:** Match demand to real supply - **Definition:** Estimating planned work against available engineer-weeks after interrupts, PTO, and ramp. Used to sequence work and justify headcount with scenarios. - **Related chapters:** headcount-capacity, decisions, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#capacity-planning ### Focus factor - **Short:** Share of time for planned work - **Definition:** The fraction of calendar time that can go to planned product and tech work after meetings, on-call, and drag. Often modeled around 0.6-0.75 for healthy teams. - **Related chapters:** headcount-capacity, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#focus-factor ### Stability reserve - **Short:** Unplanned capacity buffer - **Definition:** Capacity deliberately not committed to roadmap so incidents, support, and small fixes do not force heroics or silent scope cuts. - **Related chapters:** headcount-capacity, operating, trust - **Anchor:** https://lead-without-the-title.grok.me/glossary#stability-reserve ### OKR - **Short:** Objectives and Key Results - **Definition:** A cycle-based goal system: qualitative Objectives paired with measurable Key Results. Best used for a few team outcomes per quarter, not as a task list or a full KPI dashboard. - **Related chapters:** okrs-kpis, decisions, stakeholders - **Anchor:** https://lead-without-the-title.grok.me/glossary#okr ### KPI - **Short:** Key performance indicator - **Definition:** An ongoing health or performance signal for a system (product, delivery, reliability). Watched continuously with thresholds; not 'completed' like a project. Distinct from OKRs, which are time-boxed ambitions. - **Related chapters:** okrs-kpis, operating, system-design - **Anchor:** https://lead-without-the-title.grok.me/glossary#kpi ### North star metric - **Short:** Primary value outcome - **Definition:** The single outcome that best captures the value your product creates for users. Often paired with input metrics that lead it. Changes rarely compared to quarterly OKRs. - **Related chapters:** okrs-kpis, decisions - **Anchor:** https://lead-without-the-title.grok.me/glossary#north-star-metric ### Two-pizza team - **Short:** Size for low coordination cost - **Definition:** A sizing heuristic (popularized at Amazon): keep a team small enough that two pizzas could feed it, so communication paths and shared context stay manageable. A signal to split or modularize when coordination brokers appear. - **Related chapters:** team-topologies, headcount-capacity, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#two-pizza-team ### Counter-metric - **Short:** Guardrail against gaming - **Definition:** A paired measure that catches bad behavior from optimizing a single KPI or KR (for example, deploy frequency paired with change fail rate). - **Related chapters:** okrs-kpis, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#counter-metric ### End-to-end ownership - **Short:** Own outcome path, not just tasks - **Definition:** A person or small pair owns understanding, plan, build, validation, and communication for an outcome, with agreed checkpoints. Opposite of task-only assignment with leader-owned how. - **Related chapters:** delegation-handover, operating, trust - **Anchor:** https://lead-without-the-title.grok.me/glossary#end-to-end-ownership ### Micromanagement - **Short:** Owning the how after assigning the work - **Definition:** Steering daily details, requiring approval for small choices, and measuring activity over outcomes. Different from setting quality bars, priorities, and risk-based reviews. - **Related chapters:** delegation-handover, feedback, self - **Anchor:** https://lead-without-the-title.grok.me/glossary#micromanagement ### Handover contract - **Short:** Written interface for delegated work - **Definition:** A short agreement covering context, outcome, non-goals, constraints, interfaces, checkpoints, support, and escalation so ownership is clear without constant steering. - **Related chapters:** delegation-handover, communication - **Anchor:** https://lead-without-the-title.grok.me/glossary#handover-contract ### Feedback loop - **Short:** Signal → compare → change → remember - **Definition:** A closed cycle where a sensor detects reality, the team compares it to intent, someone decides and acts, and the learning is stored. Open loops collect signal without action. - **Related chapters:** feedback-loops, feedback, operating, okrs-kpis - **Anchor:** https://lead-without-the-title.grok.me/glossary#feedback-loop ### Loop latency - **Short:** Time from action to learning - **Definition:** How long it takes to learn whether a change helped users, delivery, or reliability. High latency forces bigger bets and slower correction. - **Related chapters:** feedback-loops, system-design, okrs-kpis - **Anchor:** https://lead-without-the-title.grok.me/glossary#loop-latency ### Closed loop - **Short:** Signal that produces change - **Definition:** A feedback process with a named owner and a visible action when the signal is off target. Opposite of dashboards, surveys, or retros that never alter priorities or behavior. - **Related chapters:** feedback-loops, operating - **Anchor:** https://lead-without-the-title.grok.me/glossary#closed-loop ### Handover checklist - **Short:** Pre-flight before stepping back - **Definition:** A yes/no list confirming outcome, non-goals, owner, RACI matrix (one Accountable per activity), teach-back, decision rights, checkpoints, interfaces, support boundaries, escalation, and done metrics before a lead reduces involvement. - **Related chapters:** delegation-handover, communication - **Anchor:** https://lead-without-the-title.grok.me/glossary#handover-checklist ### Handover metrics - **Short:** Evidence that ownership is real - **Definition:** A short set of measures such as time-to-first-progress, checkpoint hit rate, lead interrupt rate, blocker age, re-decision rate, and quality counter-metrics used to see if delegated work is truly owned. - **Related chapters:** delegation-handover, okrs-kpis, feedback-loops - **Anchor:** https://lead-without-the-title.grok.me/glossary#handover-metrics ### Servant leadership - **Short:** Lead by enabling others - **Definition:** A leadership stance that prioritizes the growth, clarity, and effectiveness of the team. In engineering, it means removing blockers, sharing context, coaching ownership, and holding standards without micromanaging or martyring yourself. - **Related chapters:** servant-leadership, delegation-handover, trust, feedback-loops - **Anchor:** https://lead-without-the-title.grok.me/glossary#servant-leadership ### Hero lead - **Short:** Lead as single point of delivery - **Definition:** A pattern where the lead takes the hardest work and decisions so the team stays dependent. Fast in a crisis, fragile as a system. Opposite of end-to-end team ownership. - **Related chapters:** servant-leadership, delegation-handover, self - **Anchor:** https://lead-without-the-title.grok.me/glossary#hero-lead --- ## Suggested books (leadership + architecture) ### The Manager's Path - **Author:** Camille Fournier - **Stage:** Start here (tech lead to EM) - **Why:** The most cited map of engineering leadership levels, from mentoring and tech lead through management. Matches the mindset and operating chapters in this guide. - **Pairs with:** Mindset, Operating the Team, 90 Days ### The Making of a Manager - **Author:** Julie Zhuo - **Stage:** First months as a people manager - **Why:** Warm, concrete first-time manager playbook for feedback, hiring, and purpose. Excellent if you just got reports and feel under-trained. - **Pairs with:** Feedback, Self-Management ### Resilient Management - **Author:** Lara Hogan - **Stage:** Coaching and change - **Why:** Practical tools for 1:1s, feedback, and leading through change without burning out. Short enough to re-read when a people situation heats up. - **Pairs with:** Feedback, Trust, Self-Management ### Radical Candor - **Author:** Kim Scott - **Stage:** Hard conversations - **Why:** A clear model for care + challenge in feedback. Helps you leave both the brutal honesty and ruinous empathy traps common for new leads. - **Pairs with:** Feedback, Conflict & Trust ### Staff Engineer - **Author:** Will Larson - **Stage:** Lead without the management ladder - **Why:** Shows how senior ICs create impact through sponsorship, technical strategy, and org work. Perfect if you lead without direct reports. - **Pairs with:** Influence, Decisions ### Team Topologies - **Author:** Matthew Skelton & Manuel Pais - **Stage:** Org and team design - **Why:** Team types and interaction modes for cognitive load and fast flow. Pair with the Team Topology Patterns chapter. - **Pairs with:** Team Topologies, Operating, System Architecture ### Accelerate - **Author:** Nicole Forsgren, Jez Humble, Gene Kim - **Stage:** Delivery systems - **Why:** Evidence-backed view of what drives software delivery performance. Use with DORA and operating rhythm chapters. - **Pairs with:** Operating, Stakeholders ### Designing Data-Intensive Applications - **Author:** Martin Kleppmann - **Stage:** System design depth - **Why:** The reference for storage, replication, partitioning, and streams when design debates get hand-wavy. - **Pairs with:** System Design, System Architecture ### Fundamentals of Software Architecture - **Author:** Mark Richards & Neal Ford - **Stage:** Architect-as-lead - **Why:** Styles, quality attributes, and the soft skills of architecture decisions. - **Pairs with:** Architecture Practices ### Software Architecture: The Hard Parts - **Author:** Neal Ford, Mark Richards, et al. - **Stage:** Distributed trade-offs - **Why:** Service granularity, data ownership, and the painful parts of distributed systems. - **Pairs with:** System Architecture ### System Design Interview (Vol 1 & 2) - **Author:** Alex Xu - **Stage:** Interview + practice - **Why:** Step-by-step large-scale designs. Pair with free ByteByteGo videos and chapter drills. - **Pairs with:** System Design, Interview prep ### Clean Architecture - **Author:** Robert C. Martin - **Stage:** Design principles - **Why:** SOLID and component boundaries that keep business logic free of framework gravity. - **Pairs with:** Architecture Practices ### The Phoenix Project - **Author:** Gene Kim et al. - **Stage:** Flow and constraints - **Why:** Narrative intro to bottlenecks, WIP, and IT flow. Good intuition pump before heavier ops books. - **Pairs with:** Operating, Decisions ### The Five Dysfunctions of a Team - **Author:** Patrick Lencioni - **Stage:** Trust and conflict - **Why:** Simple model for trust, conflict, commitment, accountability, and results. - **Pairs with:** Trust, Feedback ### Inspired - **Author:** Marty Cagan - **Stage:** Product partnership - **Why:** How strong product orgs work with engineering. Helps leads partner instead of order-take. - **Pairs with:** Stakeholders, Decisions ### An Elegant Puzzle - **Author:** Will Larson - **Stage:** Systems of teams - **Why:** Staffing, team size, migrations, and manager judgment for multi-team problems. - **Pairs with:** Team Topologies, Hiring, Operating ### High Output Management - **Author:** Andrew S. Grove - **Stage:** Classic systems thinking - **Why:** Leverage, meetings as media, task-relevant maturity. Dense classic. Read slowly after Fournier. - **Pairs with:** Operating, Self-Management --- ## Machine-readable extras - robots.txt: https://lead-without-the-title.grok.me/robots.txt - sitemap.xml: https://lead-without-the-title.grok.me/sitemap.xml - llms.txt: https://lead-without-the-title.grok.me/llms.txt - llms-full.txt: https://lead-without-the-title.grok.me/llms-full.txt - Agent skills index: https://lead-without-the-title.grok.me/.well-known/agent-skills/index.json - Creator: https://moaminsharifi.com/ - Creator socials: [GitHub](https://github.com/moaminsharifi) · [X / Twitter](https://twitter.com/moaminsharifi) · [YouTube](https://www.youtube.com/channel/UC5uBFneQ4o_DbAM3woVJS1g) · [Telegram](https://t.me/moaminsharifi) · [Unsplash](https://unsplash.com/@aminsharifi) End of llms-full.txt export.