The hottest Engineering Management Substack posts right now

And their main takeaways
Category
Top Technology Topics

Earn *And* Learn

Software Design: Tidy First? • 2010 implied HN points • 18 Feb 26
🕹 Technology Engineering Management
  1. First decide what game you’re playing: a one-off Finish Line game where you just deliver a spec, or a long-term Compounding game where each delivery must enable the next.
  2. The Finish Line approach focuses on features and specs and can be sped up by automation or agents, but it ignores future complexity and will fail when requirements or maintenance pile up.
  3. The Compounding approach balances building features with investing in futures—tidying, architecture, tools, and practices—so the system can keep earning resources and grow over time.

Slow down to speed up

The Engineering Manager • 41 implied HN points • 13 Mar 26
🕹 Technology Engineering Management
  1. When execution gets cheap and fast, getting requirements and design right matters more; slow down to clarify the problem, success criteria, and constraints before you build.
  2. Fast AI-generated work can look finished but still be solving the wrong problem, creating technical debt and costly rework; only unleash speed once you’re confident the direction is correct.
  3. Make deliberate slowness practical: timebox a clarification phase, run pre-mortems and inverted questions (even using AI), build throwaway prototypes, and share artifacts so you catch mistakes cheaply and make later execution faster.

Why Does Development Slow?

Software Design: Tidy First? • 2143 implied HN points • 19 Nov 25
🕹 Technology Engineering Management
  1. Software seems fast at first because the codebase starts with lots of options, but each feature you add burns options and over time complexity, bugs, and compatibility needs make progress slow.
  2. Every feature gives immediate value but also reduces optionality for future work, so shipping more features makes later changes harder and costlier.
  3. To keep momentum, alternate shipping features with deliberate work to restore or increase optionality—tidying, refactoring, or redesign between features so future work stays easier.

AI productivity gains are 10%, not 10x

Engineering Enablement • 23 implied HN points • 11 Mar 26
🕹 Technology Engineering Management
  1. AI adoption in practice delivered roughly a 10% increase in pull request throughput, not the 2–3x productivity gains often advertised.
  2. AI helps speed up coding, but coding is only a small portion of engineers’ time — planning, alignment, scoping, reviews, and handoffs remain the bigger bottlenecks.
  3. Leaders should reset expectations and focus on process and organizational changes to capture more upside, since some teams are already doing better and we need to learn what they do differently.

Explore *Then* Expand *Then* Extract

Software Design: Tidy First? • 684 implied HN points • 04 Dec 25
🕹 Technology Engineering Management
  1. Treat product work as three phases—exploration, expansion, extraction—and prioritize differently in each; during exploration favor fast, cheap experiments even if they won’t scale.
  2. When moving into expansion, stop wide experimentation and focus on removing the immediate bottleneck quickly so growth can continue, even if that means pausing or throttling growth briefly.
  3. Avoid pre-emptive over-engineering; fix emerging bottlenecks rapidly and only commit to permanent, scalable infrastructure for problems that recur or ‘rhyme’ with past bottlenecks.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

TBM 400: Strategic Portfolio Management Meets Product-Centricity

The Beautiful Mess • 396 implied HN points • 09 Jan 26
🕹 Technology Engineering Management
  1. Software products and teams aren’t like stocks — they’re tightly entangled, slow to change, and hard to reallocate without big, lasting consequences.
  2. Lean and centralized portfolio approaches can restore flow and stabilize teams, but they often still assume capacity and flow are more liquid and reversible than they really are.
  3. In product-led tech organizations, portfolio decisions naturally live with product leadership and require organizational design choices (team topology, hiring, platform investment) rather than just a separate PMO doing prioritization.

Announcing The Engineering Manager Survival Guide

Tech and Tea • 115 implied HN points • 06 Feb 26
🕹 Technology Engineering Management
  1. A new course helps engineering managers learn to handle the people side of the job and avoid burnout by teaching clearer mindsets and practical tradeoffs.
  2. It’s an 8-week, 4-module asynchronous program you can do in about 60–90 minutes a week, with frameworks, audio conversations, exercises, and personal feedback on your submissions.
  3. A cohort starts March 13, there’s early-bird pricing through the end of February, and there are options for corporate group discounts.

Preparing for a world where humans don’t write code

Brick by Brick • 72 implied HN points • 09 Feb 26
🕹 Technology Engineering Management
  1. AI agents will increasingly write production software autonomously, making human code writing and review a bottleneck and causing many current development practices to stop scaling.
  2. Trust should come from continuous validation, observability, scenarios, and invariants rather than relying on humans to read code, and code should be treated as disposable when generation is cheap and continuous.
  3. Organizations should create small AI-first teams that build real production systems under strict constraints (no human-written or human-reviewed code) to learn what breaks, then let successful practices spread while humans focus on intent, constraints, and outcomes.

How I code going into 2026

Olshansky's Newsletter • 183 implied HN points • 05 Jan 26
🕹 Technology Engineering Management
  1. Most coding is now delegated to AI agents, so engineers spend their time orchestrating agent personalities and guiding work rather than writing code by hand.
  2. Practical workflows matter: use Makefiles as a stable CLI, leave TODOs instead of side quests, maintain prompts/skills, write short copy-paste friendly docs, and review critical diffs on GitHub.
  3. Team roles and skills are shifting: leaders must be hands-on translators of intent into agent-driven work, focusing on system design, taste, and continuously improving agent behavior.

Developer experience at scale – lessons from Dropbox

Engineering Enablement • 14 implied HN points • 25 Feb 26
🕹 Technology Engineering Management
  1. Productivity is a sociotechnical problem. You need to invest in reliable systems and tooling while also changing culture, meeting structures, and leadership alignment so engineers can do deep, uninterrupted work.
  2. Roll out AI alongside developer experience work and make sure build, test, and telemetry systems are strong so developers trust AI-assisted workflows. Use exec-level signals to accelerate adoption, enable fast experiments, offer multiple tools, and build internal platforms when third-party tools don’t scale.
  3. The big unsolved challenge is linking productivity gains to business outcomes. AI frees capacity that often goes to migrations and tech debt, but companies lack the instrumentation to show how that work turns into revenue or faster customer value.

What Meta’s diffs per developer metric revealed about engineering at scale

Dev Interrupted • 42 implied HN points • 15 Jan 26
🕹 Technology Engineering Management
  1. Single-number productivity metrics (like diffs per developer) can stop reflecting real work when codebases, teams, and constraints grow, because a small change today can be a much heavier unit than it was before.
  2. When a metric becomes a target, people naturally optimize the metric instead of value, favoring safe, visible motion over hard, high-leverage work.
  3. Leaders should treat simple metrics as clues not verdicts: investigate flow, risk, and impact, and change what you measure and reward so teams focus on real product and business outcomes.

Just build the tools yourself

The Engineering Manager • 6 implied HN points • 20 Feb 26
🕹 Technology Engineering Management
  1. AI and modern coding assistants make it easy for people with some technical background to build useful internal tools quickly, often in an afternoon.
  2. Small, imperfect tools that automate niche workflows—like auto-summarising issue trackers into a "bragdoc" or a single-priority planning and staffing app—solve real problems without needing production-grade software.
  3. Getting hands-on to build these tools removes the friction between wanting a tool and having one, letting teams be more practical, creative, and time-efficient without turning managers into full-time engineers.

Backstage’s journey from spreadsheets to global IDP standard | Spotify’s Tyson Singer

Dev Interrupted • 14 implied HN points • 20 Jan 26
🕹 Technology Engineering Management
  1. Backstage evolved from spreadsheets into a company-wide developer portal (Portal) that uses golden paths and an AI Knowledge Assistant to scale support and cut internal tickets nearly in half.
  2. New agentic AI tools like Cowork, Gas Town, and Loom are moving AI from giving advice to doing work autonomously, which creates a need for complex orchestration and tiny task decomposition.
  3. The engineer role is shifting from solo coder to conductor of digital workers, so raw output metrics (like diffs per developer) can mislead and teams should focus on judgment, system design, and sustainable processes.

Scaffolding is coping not scaling, and other lessons from Codex | OpenAI’s Thibault Sottiaux

Dev Interrupted • 9 implied HN points • 27 Jan 26
🕹 Technology Engineering Management
  1. Widespread AI adoption comes from engineering for resilience: teams build repo-ready context, rule files, and guardrails so models become reliable teammates across iOS, Android, and backend systems.
  2. The era of humans typing syntax is fading — engineers are shifting from writing code to orchestrating and managing multiple AI agents and the handoffs between them.
  3. Don’t be loyal to one model; treat models as tools in a belt and pick the best model for each task to maximize velocity and capability.

Engineering Management in the Age of Agents

Leading Developers • 100 implied HN points • 12 Aug 25
🕹 Technology Engineering Management
  1. Engineering managers play a crucial role in bridging the gap between technical and business sides. They need to understand what customers want and how the business works to effectively communicate and create roadmaps.
  2. Good communication is key for engineering managers, especially when mentoring new engineers. Clear expectations and understanding of the desired outcomes can help prevent misunderstandings and improve the coding process.
  3. People skills are essential in engineering management. As AI tools become more common, being able to manage relationships and navigate challenges with team members will remain an important advantage.

Engineering Management: Dealing with the Broken Window effect, understanding Resistance and Objections to Quality

🔮 Crafting Tech Teams • 79 implied HN points • 14 Mar 24
🕹 Technology Engineering Management
  1. The bar for quality is defined by influential leaders and can evolve over time based on business needs.
  2. Stakeholders may request changes to either increase or decrease quality based on signals like bugs, morale, and process burden.
  3. Resistance should be considered when changes to quality are ignored to avoid negative impacts.

Everything New Has Bugs

Fish Food for Thought • 23 implied HN points • 03 Dec 25
🕹 Technology Engineering Management
  1. When you speed up releases or adopt new systems, bugs and incidents will usually rise at first — it’s a natural tradeoff between velocity and stability.
  2. Give teams slack and real ownership so they can fix problems, learn, and improve quality instead of just reacting to fires.
  3. Invest in supporting systems and feedback loops like CI/CD, observability, error budgets, and postmortems so you can absorb turbulence and restore quality faster.

The Measurement Problem in Software Engineering

Maestro's Musings • 17 implied HN points • 15 Dec 25
🕹 Technology Engineering Management
  1. Counting artifacts like lines of code, story points, or PR counts has repeatedly failed; these proxies miss real value, are easy to game, and can harm organizations.
  2. AI both breaks traditional metrics—making code volume meaningless and often increasing churn and bugs—and widens perception gaps where developers feel faster than measured results show.
  3. A promising path is semantic, context-aware measurement that uses AI to understand what changes actually do and synthesize those findings into simple narratives for leaders, aiming for "good enough" insight that’s harder to game.

DevProd headcount benchmarks, Q1 2026

Engineering Enablement • 10 implied HN points • 07 Jan 26
🕹 Technology Engineering Management
  1. Most companies dedicate about 2–6% of engineering headcount to centralized developer productivity, averaging roughly 4.7%, and that percentage tends to shrink as organizations grow past ~1,000 engineers because tooling, automation, and leverage reduce headcount needs.
  2. The benchmark counts only narrowly-defined DevProd teams (internal developer platforms, DevEx/Productivity, build & release, test infra, and developer education/support) and excludes SRE, general cloud, security, and product-facing platform teams.
  3. Treat these numbers as a guideline, not a quota: use them to set initial headcount for a center of excellence and pair them with measurement (for example, the Core 4) to confirm the team is actually reducing developer friction.

Quality Engineering Basics: Incident Reports

QUALITY BOSS • 39 implied HN points • 05 Apr 24
🕹 Technology Engineering Management
  1. Incident reports help us learn from mistakes without blaming anyone. By understanding what went wrong, we can improve processes and avoid future issues.
  2. Writing incident reports takes time but leads to fewer problems later. They keep everyone informed and help prioritize important improvements.
  3. To make incident reports effective, clear criteria and responsibility are needed. It's important to track action items so that lessons learned actually lead to real changes.

From Kubernetes to AI maximalism | Stacklok's Craig McLuckie

Dev Interrupted • 14 implied HN points • 25 Nov 25
🕹 Technology Engineering Management
  1. Treat AI like engineering — insist on reproducibility, audit trails, and measurable quality so models aren’t just probabilistic parrots.
  2. Use AI to amplify good habits, not hide gaps — have models critique your solutions Socratically and keep humans in charge of architecture to avoid accelerating technical debt.
  3. Replace the "glue person" with composable AI workflows and agent-assisted cleanup, and measure adoption and impact so you can reclaim focus and reduce coordination toil.

A TPM’s Field Guide to Annual Roadmap Planning

Building Rome(s) • 11 implied HN points • 02 Dec 25
🕹 Technology Engineering Management
  1. Tie every proposal back to company OKRs and use clear metrics and smart questions to influence priorities even if you don’t own the product decision.
  2. Use simple capacity math (engineers × weeks) to make feasibility obvious, label stretch goals as aspirational, and protect teams from overcommitment.
  3. Manage dependencies with simple shared docs, secure soft commits with dates, document decisions clearly, and escalate through defined levels when blockers threaten the roadmap.

Being an Engineering Manager at Meta

Leading Developers • 100 implied HN points • 14 Jan 25
🕹 Technology Engineering Management
  1. At Meta, managers are there to support their engineers, who have the freedom to choose their projects and set goals. This leads to a culture where trust and autonomy help engineers excel.
  2. Managers at Meta are evaluated based on the impact of their team and how they help individual contributors grow. It's important for managers to realize their role in coaching and supporting their engineers, rather than taking credit for their success.
  3. Meta encourages a fast-paced environment where developers can easily set up their work and start contributing quickly. This focus on efficiency comes from long-term investments in tools that make working faster and smoother.

Measuring developer productivity: A clear-eyed view

Engineering Enablement • 21 implied HN points • 05 Feb 25
🕹 Technology Engineering Management
  1. Metrics for developers should help improve their work experience, not just measure their output. Goodhart's Law reminds us that once metrics are tied to rewards, they can become misleading.
  2. Developer experience is more about effectiveness than happiness. Measuring how developers feel needs to focus on the frustrations they face, and not just on making them comfortable.
  3. Using benchmarks is important but context is key. Just like medical tests, numbers need interpretation to make sense; comparing different teams requires understanding their unique challenges.