Not to brag, but I put the ‘pro’ in ‘procrastination’.

Ham on Wry

The Finger Is Not the Moon

• 🌕 The core metaphor — The concept stems from a famous Zen proverb warning us not to mistake the finger pointing at the moon for the actual moon. In a leadership and product context, it means we must never confuse our indicators, tools, or processes with the ultimate goal.
• 📊 Metrics are just proxies — A frequent trap is optimizing for a specific KPI while losing sight of actual business health or customer satisfaction. This perfectly illustrates Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”
• 🔄 Processes aren't the product — Frameworks like Agile or OKRs are designed to guide teams toward success, but organizations often get bogged down in perfectly executing the methodology rather than delivering real value. The framework is merely the pointer.
• 👥 Titles do not equal influence — A job title or formal organizational authority is just an indicator of rank. True leadership — the “moon” in this scenario — is about actual influence, empathy, and driving outcomes, regardless of what is printed on your business card.

The Two Abstractions of System Design: Hide or Reduce

• 🧠 Two distinct types of abstraction — The author identifies a key distinction between "modularity abstraction" (traditional CS approach) and "modeling abstraction" (used in formal methods like TLA+), which explains why CS-trained people still struggle with modeling abstraction
• 🔒 Modularity abstraction hides complexity — Traditional CS abstraction focuses on encapsulation, drawing boundaries, and hiding internals through ADTs, APIs, and layered design to make systems easier to use
• ✂️ Modeling abstraction reduces to essence — Mathematical/physics-style abstraction cuts away everything orthogonal to preserve only the minimal, elegant description of the property you care about
• 🚫 Opposite approaches to concurrency — Modularity abstraction tries to hide interleavings and present atomic operations, while modeling abstraction deliberately exposes fine-grained actions and orderings to maximize safe concurrency
• 📐 Cross-cutting vs vertical boundaries — Modularity creates vertical layers, while modeling abstraction slices horizontally across behavioral planes, often looking nothing like the system's actual organization
• 🎯 Distributed systems examples — Lamport logical clocks (keep happens-before, discard wall-clock), Paxos consensus, linearizability, "log is the database" concept, and MapReduce all demonstrate modeling abstraction by preserving essential behavioral skeletons
• 🔄 Well-designed artifacts serve dual roles — The best designs can simultaneously work as specs for refinement (modularity) and skeletons for reasoning (modeling), though the abstraction roles remain distinct

Platform Engineering End-to-End

• 🏗️ Platform engineering is about building internal products — It's not "DevOps with a portal" but rather a team that builds and operates an internal product for other engineers as users
• 🌊 The "over-general swamp" problem — Cloud and OSS gave us infinite primitives, leading to every team reinventing the same infrastructure solutions poorly and inconsistently across organizations
• 🎯 Four core platform functions — Limit developer-facing primitives, reduce per-application glue code, centralize migration costs, and let developers operate without becoming infrastructure experts
• 📋 Five essential pillars — Curated product approach (saying no is part of the job), software-based abstractions (APIs not wikis), OSS customizations with metadata registries, serving median developers not just loud customers, and operating as critical foundations
• 📏 Timing matters for team formation — Don't form platform teams too early (before ~50 engineers) — foster cooperation first, only create dedicated teams when cooperation visibly breaks down
• 👥 Four key platform roles — Software engineers (product surface), systems engineers (deep primitives knowledge), reliability engineers (operational quality), and systems specialists (domain experts like databases/security)
• 🤝 Hire for customer empathy above all — Technical brilliance without empathy produces platforms that are "correct and unused" — engineers must understand frustrated developers' real problems
• 🔄 Treat it as a real product — Internal customers are weird (captive, opinionated, ask for what they want vs. need) — use pilots instead of A/B tests, focus on reducing context-switching
• 🚨 24/7 on-call is non-negotiable — Platforms are foundations — if they're down, the company is down, requiring real SLOs, change management, and sustainable on-call practices
• 📝 Support is the "hidden half" — Formalize support levels, separate non-critical from on-call, and eventually hire dedicated support specialists as volume grows
• 🎯 Long-running projects need proposals — Write problem/scope/success documents before coding to avoid "long slog" failure mode where projects drag on for years
• 🔄 Rearchitect, don't build v2 — v2 projects usually fail — instead rearchitect within existing platform, maintain compatibility, use staged rollouts and factor in 2-3x migration costs

Who Wrote This Crap?

• 🏗️ Traditional code generators were deterministic and domain-agnostic — Tools like CodeSmith, Rails, Entity Framework eliminated tedious CRUD and data access code that was predictable and transferable between projects
• 🎯 Early code generation targeted the right problems — Focused on eliminating "extremely predictable, relatively dumb, utterly tedious code" rather than core business logic that requires human understanding
• 🤖 AI assistants represent a fundamental shift — Unlike previous tools, they're non-deterministic and being used to generate business-specific logic that engineers often don't understand
• ⚠️ Quality concerns are emerging — Production bugs from AI-generated code going undetected for weeks because the committing engineer didn't understand what the code actually did
• 🚨 Knowledge gaps are widening — Engineers accepting AI-generated code in areas they don't understand well (like React patterns), creating potential maintenance nightmares
• 💼 Business pressure prioritizes speed over understanding — First time in the author's career that non-technical leaders are mandating specific development tools, suggesting "quality was just an unintended side effect" that leadership never really valued
• 🔍 Accountability is disappearing — The author's principle: "I will not commit code that I cannot explain" becomes harder to maintain when codebases fill with unexplainable AI-generated logic
• 🌊 Industry trajectory concerns — We may be "hurtling toward a future" where production codebases contain code that no one at the company can definitively explain or maintain

The Shift to Managing Managers

• 🎯 The Core Transition — Moving from managing work directly to managing managers is abrupt and requires fundamentally different skills; behaviors that made you successful before often become liabilities
• ⚖️ Leverage vs. Comfort Tension — The real challenge isn't autonomy vs. control, but choosing leverage over the comfort of staying close to execution work you can directly touch
• 🚫 Over-involvement Kills Ownership — When leaders focus too much on the layer below them, managers become intermediaries instead of leaders, waiting for approval rather than making decisions
• 🧠 Context Beats Direction — Managers don't need more answers — they need better framing and understanding of business constraints, political realities, and broader trade-offs
• 🔄 Decision Delegation vs. Task Delegation — Real growth comes from delegating decisions and ownership, not just tasks; ask "why did you choose this?" instead of "what do you want to do?"
• 🚨 Warning Signs of Overmanaging — Teams schedule work around your presence, decisions escalate unnecessarily, work slows when you're unavailable, and you feel indispensable (which is actually a red flag)
• 📋 Clear Decision Boundaries — Explicitly define with each manager what decisions they make alone, inform you about, consult on, or make together — and gradually shift toward greater autonomy
• 🎪 Expect Messy Transitions — Stepping back initially makes things messier before they improve; inconsistent decisions are part of the calibration process, not failure
• 🔍 Two-Direction Focus — Look down for coaching and execution quality, but increasingly look around for strategy, alignment, and organizational dynamics as you advance
• 🏗️ Building Self-Sustaining Systems — Success means creating teams that make informed, independent decisions and maintain impact even when you're not present

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇