Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 13: Tech Lead Communication #

Tech Lead is a role change, not a promotion, and most engineers who fail at it fail because nobody told them that. The unit of your output changes: from your code to the team's clarity. The instinct that got you the role — being the strongest IC in the room — is precisely the instinct that will sink you in it. If you've held the title before, even briefly, do the retrospective in the checkpoint honestly, because brief stints get remembered through one of two distorting filters: "great experience, learned a lot" (true but too vague to reuse) or "wasn't really the right fit" (often a way of not looking at what was hard). The useful middle is specific: three things you did well, three you'd do differently knowing what you know now, one pattern to build before the role comes back. And it will come back — through a team that forms around you, a project that needs an owner, or a company that finally notices you're already doing the job. The choice is whether you step into it deliberately or drift.

The deepest structural idea in the module is Conway's Law, and it deserves to be taken as seriously as the CAP theorem: organizations ship the structure of their communication. Three subgroups that don't talk produce three coupled services that don't integrate; one bottleneck through whom all decisions route produces a monolith with a god-class. You cannot fix a misshapen artifact by polishing it — you fix the communication structure that produced it, which is now your actual job. The reading canon here is unusually good: Larson's An Elegant Puzzle (the rare management book where the engineering rigor is real — and his "do nothing" chapter will challenge your fixer reflex directly: a meaningful fraction of what you currently fix would resolve itself in a week, and learning which fraction is a senior skill), Fournier's The Manager's Path for the role mechanics, and Marquet's intent-based language — "I intend to..." — as the cheapest mechanism ever devised for pushing decision-making down without losing visibility.

The trap with the strongest gravitational pull: the lead-as-strongest-IC absorbing the hardest work. You take the gnarly part yourself because it's faster — and it is, this week. The engineers who should be growing into that work stay on the easy parts; the team's ceiling becomes your personal capacity; you burn out and they plateau, and both outcomes are your doing. The discipline is deliberate restraint — handing the hard problem to someone who'll be slower at it than you, eating the short-term cost, and reviewing the work as conversation (Module 4) rather than quietly redoing it. Founders and solo-studio engineers, take note: this trap is your default future, because by definition you'll be the strongest IC on any team you build, and the structural temptation arrives with the first hire.

Two more things the formal essay carries that I want to push on. First, the hardest conversation — telling someone their work isn't at the bar — is the one tech leads most often skip, and the cost of the skip is borne by the person being "protected." A junior whose lead never names the gap doesn't improve by osmosis; they just hit a ceiling made of skills nobody ever named. The kind silence is the cruel path. The hard conversation, done with warmth and specificity — Module 7's machinery, "this isn't where the work needs to be; I want to help you close it; here's the path" — is the kind one, and people remember those conversations, years later, as the moments someone took their growth seriously. Second, the mode-switch: Sandi Metz's register is the teacher's — patient, generous, optimizing for the engineer's growth; DHH's is the director's — opinionated, decisive, optimizing for the shape of the work. Leads who can only do one mode fail in that mode's characteristic way: all-teacher ships slowly and sometimes ships the wrong thing; all-director ships fast and produces compliance instead of commitment. The skill is switching deliberately — teacher-mode for the junior wrestling with their first hard problem, director-mode for the architecture debate entering its third week — rather than defaulting to your personality. One caveat the canon won't give you: it's written almost entirely from Western, flat-hierarchy tech contexts. The debate-stewarding patterns assume engineers feel safe disagreeing with their lead. In more hierarchical settings — cultural or organizational — they need localization, and Module 12's calibration work is how you do it.

A skill the role demands that nobody warns you about: communicating uncertainty upward without converting it into either false confidence or panic. Your manager asks when the migration lands. "It's done when it's done" is true and useless; "March 15th" is precise and a lie. The lead's answer is a range with a confidence level and the variable that moves it: "80% confident in late March; the open risk is the legacy data backfill, and I'll know by Friday whether it's a week or a month." That sentence does three jobs — it's honest, it's plannable-around, and it tells your manager exactly when to check back. Engineers who can't say it get either micromanaged or blindsided; the sentence is the alternative to both.

On Marquet's "I intend to..." — it earns one more beat because it's the cheapest delegation mechanism in the canon. Instead of engineers asking "should I do X?" (decision stays with you, queue forms behind your attention), they say "I intend to do X because Y" (decision moves to them, your job shrinks to catching the rare bad Y). The phrase converts your bottleneck into a review step, grows the engineer's judgment with every use, and gives you an audit trail of how your team actually thinks. Install it as a team norm early; it's the highest-leverage sentence in the module.

Conclusion #

The IC-to-decider transition is the load-bearing shift, and most engineers fail it by continuing to do the work that got them the role. Mentoring, debate-stewarding, communicating uncertainty upward, the not-at-the-bar conversation, ritual design, information filtering — these distinguish the lead from the senior IC who happens to hold the title. Write the playbook in the checkpoint even if you have no team today; the act of writing forces commitments you'd otherwise improvise badly under pressure, and the role finds everyone who's any good eventually.

Predictions #

  • The retrospective (if you've held the role) will keep circling back to one specific moment — a decision you regret or a conversation you didn't have. That moment is the diagnostic; the pattern it represents is the one to build against before the role returns.
  • The "don't over-absorb" discipline will be the hardest part. The first deliberate handoff of a problem you'd solve faster yourself will be physically uncomfortable. By the third or fourth, you'll watch someone grow into a capability and the discomfort will convert into the actual satisfaction of the role.
  • An Elegant Puzzle will become a book you re-read every eighteen months, and the same chapters will mean different things at each career stage. That's not the book changing.
  • Conway's Law will become the lens through which you read every public product failure. You'll start seeing the org chart inside the bug, and you won't be able to stop.
  • The not-at-the-bar conversation will arrive whether you're ready or not — with a junior, a contractor, a vendor. The first will be harder than you'd like; by the fourth, the warmth-and-specificity calibration is automatic.
  • The teacher/director mode-switch will take the longest of anything here — it's a calibration, not a technique, and calibrations only build through reps. Conscious in a year; unconscious in three.