Article of the Week ⭐

How workplace influence really works

Ethan Evans left Amazon in 2020 as a VP over 800 people across Prime Video, gaming, and Twitch. Before that, two startups laid him off from VP-level roles because his style created more friction than his output was worth. This interview covers the parts of corporate life nobody documents: the polite fictions, the back-channeling, the warning signs that appear months before HR gets involved.

• Visibility beats quality in most promotion decisions. One engineer does strong technical work quietly; another does decent work and publicizes it. A busy manager hears more about the second one. Engineers define “best” as technically superior. Managers reward what’s easy to see and easy to work with.

• By the time a PIP starts, the manager has already run out of options. Warning signs arrive months earlier as soft feedback. Managers deliver them gently; engineers hear them as routine growth notes. Recovery almost never happens.

• Influence and manipulation use the same tactics; motive separates them. Reframing, back-channeling, pre-wiring a decision: all legitimate if you’re genuinely helping. Manipulation is the same moves, executed while indifferent to the harm they cause.

• “Brilliant and blunt” is a choice. Ethan was that engineer. Two layoffs changed him. His read: engineers who claim this as a fixed trait usually enjoy being right more than they care about working relationships. Social skills can be learned, and he is evidence.

• To find out whether you’re an umbrella or a funnel manager, ask former employees, specifically ones who left the team a year or more ago and are safely elsewhere. They’re the only ones who will tell you the truth.

At director, senior manager and staff level you’re inside this system from both sides: making promotion calls and being subject to them.

Evans is rare in admitting that even as VP, he made decisions based on who he wanted to work with over who was most qualified.

Tech World with Milan

Other highlights 👇

How to Use AI to Onboard Into a Codebase Faster

If you're opening a codebase for the first time without AI, you're losing hours you don't need to spend. Jeff Morhous at CoverMyMeds shares a 4-step framework: run /init with Opus (not Sonnet — reasoning upfront saves correction later) to generate an architecture map, prompt for the test pyramid, then get a reproducible local setup based on actual repo files. He includes the exact prompts for each step. The habit worth adding even on familiar codebases: ask for a change plan before writing any code, so the agent names files, tests, and risks before it starts editing.

Engineering Leadership

Anthropic Launches Claude For Small Business

Anthropic launched Claude for Small Business on May 13. 15 pre-built agentic workflows and connectors to QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, Microsoft 365, and Slack. Human approval is required before anything executes; Claude reads and drafts, you sign off.

Karo Zieminski's breakdown covers the decision tree for picking your first workflow and the trust-boundary model (Claude inherits your existing permissions, so it can't touch data you can't touch).

For engineering leaders, the distribution play is worth watching: Canva has $500M+ in B2B revenue and PayPal has tens of millions of sellers. Anthropic is shipping inside the tools SMBs already open every day.

Product with Attitude

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - (w. ), (w. ),

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

DORA metrics are lying to you and AI is making it worse

Paul LaPosta’s piece from LeadDev delivers a practically useful writeup about engineering metrics in the AI era. It explains precisely where the improvement framework’s contract breaks down and what to do about it. If you’re a director, staff engineer or DevOps specialist using delivery metrics to make decisions about team health, system risk, or promotion, this is required reading.

DORA measures flow, comprehension is your responsibility

Deployment frequency, lead time, change failure rate, MTTR: these four numbers tell you how work moves through the pipe. They tell you nothing about whether anyone on the team can explain what’s in it. LaPosta opens with a story that will feel eerily familiar: a junior engineer leaning on AI to generate tickets and code, appearing productive, until a critical project exposed that there had been throughput without understanding. At the org level, the same failure mode scales quietly. Your dashboards look healthy. Your systems are becoming illegible.

AI has made the gap orders of magnitude worse

The legibility problem isn’t new, dashboards have always been able to look green while the underlying system became unmanageable.

What AI has done is accelerate the rate at which this happens. It seems that code is shipping faster than it’s being understood, or at least those are the claims of people who observe this process from the outside.

Changes are occurring outside your traditional SDLC entirely in AI vendor consoles, identity providers, AI agents with delegated authority. None of that shows up in your DORA review. MTTR can look excellent because rollback is fast, even when nobody on the incident call can explain why the rollback worked. LaPosta describes exactly this scenario: a dark service deployment that disrupted a live critical path, with the team insisting they couldn’t possibly have caused it, right up until the rollback fixed everything instantly.

The signals your metrics are lying

Incidents that take longer to diagnose even when metrics are green. System behavior that changes without anything appearing in review. Teams that can produce a polished architecture slide but depend on two people carrying the real mental model in their heads. If fewer than two people can walk you through the critical path end-to-end in plain language in under five minutes (or need time verify an AI’s hallucination’s), then the needle hasn’t moved much, if at all.

The fix is adding scope

LaPosta isn’t arguing for a new framework.^{Thank goodness, we don’t need another one!} He’s arguing for honesty about what DORA was built to do.

His practical recommendation:

• Attach a detailed scope note to every DORA review for a critical system. Explicit metric definitions, dependency chain, known out-of-band change risks, and at least one recent incident narrative.

• Pick one critical system, run the tighter review pattern for a quarter. Ask whether leaders are making better decisions about ownership and risk not just whether the charts improved.

DORA is not the problem; managers using it as a silver bullet so they can pretend it tells the whole story is.

LeadDev

Other highlights 👇

Your AI tools are speeding up the wrong things

Eliyahu Goldratt’s The Goal (1984) has a useful insight for today’s AI constraints: improve anything that isn’t your bottleneck and you’ve improved nothing. You’ve just built up inventory in front of it. Forty years later, engineering teams are doing exactly this with AI, and the LinkedIn screenshots of 47-feature sprints are the evidence.

The pattern is consistent across every workflow:

• Code generation: 3x more PRs, same reviewers, same deployment pipeline. You haven’t tripled throughput. You’ve tripled the review queue.

• Documentation: AI-generated PRDs look like thinking happened. The thinking didn’t happen. The bottleneck was never “produce more documents,” it was “make better decisions.”

• Performance reviews, feedback, mentoring: these aren’t bottlenecks to eliminate. The slow, difficult work of articulating your thoughts is the value. AI pointed at thinking work is lobotomy with a nice interface.

What can we learn from this?

• Toil: repetitive, mechanical, nobody gets smarter doing it. Should be automated ruthlessly.

• Thinking work is slow because the slowness is the mechanism. Remove it and you remove the understanding.

Where AI does work: legacy codebase comprehension, incident response synthesis, onboarding acceleration, and offloading the mechanical work from your scarcest senior engineers so their judgment goes further.

What is your actual bottleneck — and does your AI vendor address it?

If you can’t answer the first part, you’re not ready for the second. You’ll just move faster in the wrong direction. Goldratt figured this out in a manufacturing novel. The lesson hasn’t changed.

Scramble IT

Symptoms of Bad Software Design

🧨 “If doing things right is slower than doing them wrong, your architecture has already lost.”

The four classic symptoms of bad software design show up everywhere:

• Rigidity: a two-day change becomes two weeks because everything is coupled to everything. The fix: Strategy Pattern and Open/Closed Principle so adding a new carrier means a new class, not touching existing code.

• Fragility: you fix payments and break payroll. The fix: Interface Segregation so each module only sees the config slice it needs, not a global object everyone can mutate.

• Immobility: you can’t reuse a validation function without dragging along the database and the UI. The fix: Clean Architecture so business logic lives in pure components with no knowledge of frameworks or persistence.

• Viscosity: the sneakiest one. When the hack takes 5 minutes and the right path takes an hour, the hacks win. Every time. At scale. The fix is automation and tooling that collapse the gap.

The underlying principle across all four: make the right thing the easy thing. If your architecture punishes correctness, developers will opt towards survival.

These signals don’t self-resolve, merely get triaged and tolerated. The bad outcomes compound. Identifying them is the first step; the second is making clean design the path of least resistance.

The Optimist Engineer

Choosing the Right AI Coding Tool

AI coding tools are beginning to shape how teams think, review, debug and even structure engineering work. But the real differences are less about features and more about workflows. Some optimise for speed inside existing habits, while others reshape development around deeper AI collaboration and reasoning.

What’s becoming clear is that teams are no longer looking for one universal assistant. They’re starting to match tools to different kinds of work, from rapid iteration to large-scale refactoring and architectural thinking. This piece breaks down those trade-offs in a practical, grounded way.

AI Coding Showdown

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - Paul LaPosta, ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Full Walkthrough: Workflow for AI Coding — Matt Pocock

We’re changing up this format for this week as we found an interesting workshop video that all you AI enthusiasts will find very practical!

Matt Pocock has spent the last six months stress-testing AI coding workflows: using battle-tested old school principles and tacking it onto AI / claude workflows. In his hands-on workshop from a live conference, he walks through his full development lifecycle end-to-end, from a vague Slack message to production-ready code shipped by an autonomous agent.

1. The smart zone is finite, design around it.

LLMs degrade in quality as context grows. Pocock puts the reliable ceiling at around 100k tokens regardless of advertised context window size, and every workflow decision he makes is optimised around staying inside it. That means short, focused sessions with clean context resets rather than endlessly compacted threads. The 1 million token context window doesn’t change this as it merely ships you more “dumb zone”. Teams that ignore this are burning tokens and wondering why output quality is inconsistent. The fix isn’t a better model. It’s smaller, cleaner tasks.

2. Get alignment instead of planning with the “grill me” skill.

His most distinctive move is refusing to let the AI produce a plan until it has interrogated you thoroughly first. His /grill-me skill forces the agent to interview you relentlessly — sometimes 40 to 80 questions — before anything is written down.

The goal is to produce what he calls a shared design concept: getting on the same wavelength as the agent that will implement your work.

He draws on Frederick Brooks here (the author of the Mythical Man-Month and The Design of Design), the idea that everyone building something together needs to hold the same mental model of what they’re making. Skipping this step and going straight to specs-to-code is, in his words, vibe coding by another name. You’re ignoring the code and hoping the document saves you. It doesn’t.

3. Vertical slices, not horizontal layers.

Left to its own devices, AI codes layer by layer, e.g. database first, then API, then frontend.

That means you get no integrated feedback until the very end of the plan. Pocock structures work instead as thin tracer bullets that cut across all layers from the start, so the agent can run a full feedback loop after every issue rather than after phase three.

This also unlocks parallelisation: once issues are structured as a directed acyclic graph with explicit blocking relationships, multiple agents can work simultaneously on independent branches and merge cleanly. A sequential multi-phase plan can only be picked up by one agent. A well-structured kanban board can be picked up by several.

4. Deep modules are the ceiling on agent quality.

Drawing on John Ousterhout’s A Philosophy of Software Design, Pocock argues that the structure of your codebase is the single biggest lever on agent output quality. Shallow modules with lots of small, tightly-coupled files are hard for agents to navigate and nearly impossible to test well.

Deep modules with small interfaces and rich internals give agents a clear surface to work against and draw clean test boundaries around. If your AI is consistently producing mediocre output, the problem is probably that you’ve handed an agent a codebase that experienced human engineers also struggle to work in cleanly.

The planning frameworks senior engineers already know translate almost directly into better agent output. The teams struggling with AI are skipping the discipline that made good software before the agents arrived.

Watch on YouTube

Other highlights 👇

The Critical Shift In What Differentiates Great Leaders

Being the smartest person in the room used to be a career strategy. Yue Zhao’s brings a delightful perspective on how most senior leaders are dangerously over-invested in the one type of intelligence AI just made cheap.

Her framework splits human intelligence into three centers: Head, Heart, and Gut. Most high-performing leaders have spent their entire careers developing exactly one. AI just made that one the table stakes.

1. The Head is now a commodity. AI has read more case law, medical literature, and financial filings than any human ever will. Intellectual horsepower, ie. the thing that got most senior engineers into the room, is now available to everyone on an instant. Well, mostly.

2. The Heart is where humans still have the edge. AI can fake empathy. It cannot feel it. When a team is demoralized after a reorg, when two opinionated people are locked in conflict, when someone needs a hard truth delivered in a way they can actually hear are the moments that require a human who is genuinely in touch with what’s happening emotionally and skilled enough to do something useful with it.

3. The Gut is the final frontier. Ethical judgment in genuinely novel situations. Where no published framework quite fits and someone has to stand for something. AI can reflect the ethics humans have written down. It cannot tell you what is right when the rules run out.

The skills that got you to staff or director are still necessary. They’re just no longer sufficient. But the skills that will define your next decade as a leader have nothing to do with how well you can out-think a machine and everything to do with what only a human can do.

The Uncommon Executive

3 constraints before I build anything

Products fail when they lack a forcing function to stay honest about what they were building. Jordan Lord shares his practical framework on how to triage his idea economy with a tight, practical rulebook that maps cleanly onto how engineering leaders should be evaluating what their teams take on.

1. One page or it doesn’t get built. If you can’t describe the idea in a single page you’re not ready to build it. The one-pager is the north star: non-negotiable, precise, and lean.

It also becomes the tie-breaker for every conflict that surfaces during development. If the thing you’re arguing about isn’t in the one-pager, it’s either not worth fighting over or the one-pager needs to be updated. Critically, if you can’t fill the page without padding it with fluff, that’s a signal to stop and do more research; not to start building.

2. The core tech must be separable from the product. Every idea worth building should produce a reusable piece of technology that outlives the product itself. A method, a library, a tool, a methodology. The examples here are instructive: Linus Torvalds built Git to improve the Linux kernel workflow. HashiCorp built HCL. Google built Kubernetes. Products pivot constantly. Core tech compounds. If your idea doesn’t generate separable leverage, it probably isn’t high enough value to justify the investment.

3. One defining constraint must shape the product. Every product needs a constraint that is visible to the user at all times: something that gives the product its identity and limits scope by design. Minecraft is made of blocks. IKEA is flat-pack. The constraint is a filter that collapses the decision space and forces the team to solve the problems in novel ways. Without a deliberate constraint products tend to bloat out of control or worse: seek constraints from market factors after having been built.

Constraints aren’t the enemy of good work. They’re often what makes it possible.

Jordan Lord

Choosing the Right AI Coding Tool

AI coding tools are beginning to shape how teams think, review, debug and even structure engineering work. But the real differences are less about features and more about workflows. Some optimise for speed inside existing habits, while others reshape development around deeper AI collaboration and reasoning.

What’s becoming clear is that teams are no longer looking for one universal assistant. They’re starting to match tools to different kinds of work, from rapid iteration to large-scale refactoring and architectural thinking. This piece breaks down those trade-offs in a practical, grounded way.

AI Coding Showdown

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - (c. AI Engineer, youtube), , Jordan Lord

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

AI Infrastructure Roadmap: Five frontiers for 2026

Bessemer just published their 2026 AI infrastructure roadmap, and it’s a useful forcing function for any engineering leader currently deciding where to place bets on tooling and platform investment.

We’ve crossed from “can AI do this?” to “can AI do this reliably, continuously, and in production?” and the infrastructure gap between those two questions is enormous.

The five frontiers they’ve identified:

• Observability is broken for AI systems. An estimated 78% of AI failures are invisible with no error signal, no complaint or no thumbs-down. The failure modes (confidently wrong answers, gradual topic drift, plausible-but-wrong responses) don’t surface in traditional monitoring. You need semantic metrics and LLM-as-judge evaluation, not just latency dashboards.

• Memory and context management is becoming its own infrastructure category. Basic RAG solved retrieval. What compound AI systems actually need is cross-session context, long-term memory, and user preference persistence. What used to require custom vector DB work is now a plug-and-play layer. And it’s where differentiation is moving as models commoditise.

• Inference now rivals training in economic weight. Jensen Huang called it at GTC 2026: the inference inflection point has arrived. The cost and performance of running AI continuously matters as much as building it. This is reshaping the infra stack around throughput, heterogeneous compute, and edge deployment.

• Reinforcement learning is becoming table stakes for complex agents. Static labeled datasets can’t teach multi-step decision-making with delayed consequences. RL platforms — environments, simulators, preference models — are the emerging primitive for teaching agents how to behave, not just what to know.

• World models are the next foundational layer below LLMs. For physical AI (robotics, autonomous systems, industrial ops), the bottleneck is its physics intuition. World models trained on video and sensor data are starting to solve the simulation data problem that’s blocked physical AI for years.

If you’re building or buying AI tooling right now then last year’s playbook of ‘pick a model, bolt on RAG, ship’ is already dated. The teams that will outperform in 2026–2027 are investing in evaluation infrastructure first, then in memory/context layers that make agents actually reliable across sessions.

The RL and world model frontiers are earlier-stage, but worth tracking for platform roadmap decisions if you’re in an industry with physical processes or complex multi-step workflows.

Next Big Teng

Other highlights 👇

Why I Don’t Like When Teams Do Things Like Dedicate 20% Of The Roadmap to “Tech Debt”

🚨 Hot take: your “20% tech debt” agreement is a peace treaty, not a solution.

The fix papers over a skills gap on both sides of the Product/Engineering table. Product doesn’t price in long-term technical health. Engineering can’t make the business case for why it matters. So you negotiate a number, shake hands, and both sides quietly stop learning from each other where Product gets to ignore the tech, Engineering gets to ignore the customer.

The tell: if your team still has two separate roadmaps, one “real” and one “engineering” then you haven’t solved prioritization problem yet, merely normalised the bits that don’t work well.

The endgame is a single unified roadmap where tech debt competes on Value like everything else. That only happens when PMs understand enough about technical health to sponsor it, and engineers can articulate tradeoffs in business terms, not just complexity scores.

So yes: negotiate the 20% if you need to. It beats the alternative of zero.

But no: don’t let it become permanent furniture. It’s scaffolding. The building should eventually hold itself up.

If you’re still defending a dedicated engineering bucket in 2026, ask yourself: is your roadmap budget a working agreement, or merely a ceasefire?

dot txt

The New Engineering Stack: Specs, Context, and Agents

AI doesn’t fix weak thinking.

A clear divide is forming across teams where senior engineers are the ones who already know how to define intent, set constraints, and think in systems and are moving faster than ever while everyone else is shipping plausible-looking vibe code that quietly misses the mark.

The new stack that’s separating the two:

• 📄 Specs (SPEC.md) that anchor intent before a single line is written

• 🧠 Context files (CLAUDE.md, AGENTS.md) that guide execution and constrain agent behavior

• 🔒 Guardrails that define evals, access limits, feedback loops, human checkpoints to narrow down and signal the confident drift

This is what Spec-Driven Development looks like in practice: active scaffolding that shapes what the agent does. Have you noticed that agentic code assistance moves the bottleneck from coding pressure to reviewing pressure? It’s the automation of that loop closer to the source of change that sets apart low- from high-performing AI integrators.

Cloud Article Digest

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Using Data Contracts as a Value Assessment Framework for Data or AI Initiatives

Animesh Kumar opens with a definition for AI-related data contracts: a contract is a promise with consequences. An enforceable commitment between a producer and a consumer, where breaking it triggers something real.

Quality metrics measure the data and contract metrics measure whether someone kept their word. A 3% null rate is either a violation or acceptable operating noise, you cannot know which without knowing what was actually promised and to whom.

The four components he breaks contracts into:

• The Promise: what the producer commits to: schema, semantics, delivery frequency, permitted failure rate

• The Parties: both producer and consumer, each with explicit obligations (many pipeline failures start not at production but at undeclared consumer assumptions)

• The Terms: observable, verifiable SLAs written before data flows, not reverse-engineered after

• The Consequence: automatic incident triggers, team notifications, impact signals; without this, the contract is decoration

Data-Product Management

A feature is not done until it passes acceptance criteria agreed on before development starts. A data product is not done until its contract is honoured. That framing shifts the conversation from engineering metrics to product accountability and makes failure attributable.

Kumar also draws on API design to make a systems argument: API contracts let teams deploy services independently without collision. Data contracts do the same for data producers and consumers.

They contain blast radius: a broken contract should alert a bounded, known set of downstream systems, not send unexplained anomalies rippling through dashboards and models for days.

Model-as-contract

In a right-to-left engineered data product, the data model is not a representation of the contract but rather is the contract. SQL tests, various nuances of integration tests, integrity constraints, quality thresholds, and semantic definitions embedded in the model make it a machine-executable commitment.

Every clause is a contract term. The model runs; the contract is audited automatically without manual periodic review. This also encodes semantics, which Kumar treats as the thing that separates trustworthy data products from well-labelled datasets.

“Revenue” means recognised revenue after refunds. “Customer” means an entity with at least one completed transaction. These definitions are not stored in a wiki. They are enforced at execution.

Postel’s Law

A data product is not done until its contract is honoured, the same logic as acceptance criteria in product development. That framing makes failure attributable rather than diffuse.

Postel’s Law applied to data: be strict about what you emit, tolerant within the bounds you have agreed to absorb. In practice:

• A producer never changes a field name, drops a column, or shifts delivery cadence without a contract amendment

• A consumer never quietly relies on a field outside the agreed terms

• When either side drifts without declaration, the contract has already broken, ready to be audited and fixed

The model is the contract. In a right-to-left engineered data product, SQL tests, integrity constraints, and semantic definitions embedded in the model make it machine-executable. The model runs and the contract is audited automatically. Semantics are enforced at execution, ie. “revenue” means recognised revenue after refunds, not whatever the upstream system happened to send.

The same fidelity signal serves two audiences:

• Engineering teams: breach rates, mean time to recovery, instrumented contract surface

• Business stakeholders: which decisions were made during a degradation period, and whether those outputs have been audited

Most teams report only to the first audience, which is why they struggle to justify the investment. The contract framework makes both readable from the same source of truth.

Modern Data 101

Other highlights 👇

The unwritten laws of software engineering

Every engineer learns these rules the hard way. Here are seven that nobody puts in the onboarding docs. Thank you, Anton!

1. It’s always related. When production breaks after a deploy, your first instinct is to defend your PR. It’s wrong. Roll back immediately, stabilise, then debug.

2. Backups aren’t real until you’ve restored from them. Not “I know the option exists”, actually run the restore, confirm the data, time how long it takes. Do you know who has permission to trigger one? Do you know where to click during an outage, or are you figuring it out under pressure?

3. You’ll always hate your own logs. Too sparse when an incident hits, too verbose when AI writes them. The balance of all needed info, shared request IDs across services, nothing extraneous is harder to hit than it looks.

4. Always have a rollback plan. Always. Adding a column, inserting rows, changing a constraint, etc. every data touch needs a tested reversal path. Untested rollback plans have roughly 50/50 odds of making things worse.

5. Every external dependency will fail. A 3rd-party API with 99.9% uptime added to your own 99.9% SLA doubles your potential downtime. Know the rate limits, test what actually breaks when it goes down, and have a fallback before you need one.

6. If there’s any doubt, use four eyes. Senior permissions plus solo late-night changes is how databases get destroyed. If you’re hesitant to ask someone because it’s a weekend, that hesitation is the signal to stop.

7. Nothing is more permanent than a temporary fix. V2 rarely arrives. Push instead for a minimal solution you can stand behind, simple and limited is not the same as held together with duct tape.

Manager.dev

Axios hack exposes AI-coding’s dependency problem

There’s something quietly brilliant about AI-coding tools: you describe what you want, and working software appears almost like magic. Entire products are being built faster than ever, by more people than ever. But… there’s always a catch.

This week’s catch came in the form of a major security breach targeting Axios, one of the most downloaded JavaScript libraries in the world. Hackers compromised its npm account, slipped malicious code into a new release, and watched it spread across millions of projects before anyone noticed. Days earlier, the same thing happened to LiteLLM’s PyPI package, this time delivering a credential stealer into any project that pulled it in.

Let’s talk about a structural vulnerability that’s been quietly building:

• AI tools tend to over-engineer solutions, bundling in far more dependencies than a project actually needs

• Most developers, especially newer “vibe coders” using AI to build without formal training have little visibility into what those dependencies do or how to secure them

• Attackers have figured this out and compromise one popular package to reach hundreds of millions of downloads in a single move

• Defense strategies haven’t kept pace with how fast AI is changing who builds software and how

None of this means AI-coding tools are bad, or that open-source dependencies should be avoided. They have their merit. But speed without scrutiny is a risk multiplier, and right now the industry is heavy on the former and light on the latter.

LeadDev

The Hard Part About Proving Copilot’s ROI

Everyone agrees tools like GitHub Copilot feel faster, but turning that feeling into something measurable is where things break down. Output goes up, yet it’s unclear how much of that translates into real value versus added review effort or hidden rework.

The piece unpacks why ROI can’t be judged on usage or speed alone. It needs a more grounded view across delivery, quality and developer effort. The focus shifts to understanding where Copilot actually saves time, where it shifts effort downstream, and how those trade-offs show up over time. If you’ve ever tried to justify AI spend with shaky metrics, this gives a more practical way to think about it.

Copilot ROI

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , , Chris Stokel-Walker (c. LeadDev)

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

No More Code Reviews: Lights-Out Codebases Ahead

Philip Su has a provocative claim: code reviews are becoming impractical to the point of being outright irresponsible. And he’s not being hyperbolic for effect. Let’s look into the math and ideas that he used to back up his claim.

AI assistance produces 5-20x leaps in the production of code changes that leaves the human reviewers as a rather obvious bottleneck. The process becomes a fiction and no amount of “@codex fix this,” makes the quality gate that was meant to teach the author something new rather tedious and dangerous.

Su’s framing reaches back to his early career. As a 22-year-old at Microsoft in 1998, he was code review’s biggest evangelist. Scheduling meetings with senior managers to pitch mandatory reviews, arguing for the knowledge transfer, the error-catching, the shared understanding of the codebase.

He didn’t win that argument then and his point now is that the argument has become moot in the opposite direction: not that code review was never valuable, but that the volume of AI-generated code has made it structurally impossible to sustain.

His vision for what comes next is what he calls a lights-out codebase. Named after lights-out data centers, fully automated facilities where no human ever walks the floor and lighting isn’t even necessary. In a lights-out codebase, no human ever sees the code. Not as a distant aspiration. As the logical endpoint of dynamics already clearly in motion. Sounds too good to be true. Is it?

His two most recent apps were built entirely without him viewing or editing a single line of code. From creating the GitHub repo all the way through releasing to production, the experience hasn’t made him entirely comfortable, but it’s a sign in the right direction. The AI reviewers caught a surprise amount of bugs in code he’d already pre-reviewed and signed off on himself.

Not only can AI can keep up with AI-generated code, but he and his team may have been worse at reviewing code than they were prepared to admit. Afterall, humans can get biased, get put under time pressure or have to triage their attention. Something an AI reviewer does not suffer from, as long as it receives reasonable care and maintenance from human operators. And we’re only finding out now that there’s something better to compare against.

What replaces human review? A layered system of AI checks:

• TDD-style component boundaries: testable seams that force structure and accountability before a line of code is written

• AI reviewing AI: pre- and post-action reviews, once before a plan executes and again after coding completes

• Multiple LLMs cross-checking each other: different models with different strengths covering each other’s blind spots

• Dedicated specialist agents: a security agent that only looks for security issues, rather than a generalist reviewer trying to catch everything

• CI/CD protections and pre-commit hooks: automated gates that enforce quality standards before anything lands. The bread and butter, though not new for AI-era software.

None of this is entirely new, Su acknowledges. TDD, automated testing, CI/CD pipelines have been known best practices for years. What’s changed is their urgency. When AI is producing code at a volume no human team can manually review, the layered safety net stops being a nice-to-have and becomes the only viable architecture for quality assurance.

The analogy he reaches for is autonomous driving. Waymos cause five times fewer injuries than human drivers on the same urban roads. And yet adoption remains slow, because it doesn’t feel believable at a gut level. We move goalposts. We reach for edge cases. We find what-about-isms. And in the meantime, more accidents happen than necessary.

Su thinks software is heading the same direction, on a similar timeline. The rational case is already there. The gut feeling hasn’t caught up. But one day, he argues, people will be genuinely aghast to learn that their mission-critical cloud platform “lets humans touch the code.”

Molochinations

Other highlights 👇

AI can write code. That was never the bottleneck.

Software organizations were never primarily limited by how fast engineers write code. The real constraints fall onto product decisions, business trade-offs, organizational structure, and engineering judgment among others. AI dramatically accelerates code production, which was already the cheap part.

Emmanuel Valverde Ramos explores some of the frictions with agentic software:

• Product decisions: understanding real user problems, especially prioritizing under uncertainty

• Business trade-offs: ROI versus reliability versus long-term quality

• Organizational structure: Conway’s Law in action; fragmented teams produce fragmented architecture

• Decision latency: code takes minutes to write, but the decision justifying it can take weeks, and validation months

His evidence is pointing at the 2025 DORA report which found AI increases delivery throughput and delivery instability simultaneously.

Another benchmark called SWE-CI tested AI agents on 100 real codebases across 233 days each. They failed to maintain system integrity over time.

Amazon held mandatory internal briefings about high-blast-radius incidents linked to AI-assisted changes.

An Anthropic study sharpens the concern: developers using AI scored 50% on a debugging quiz versus 67% in the hand-coding group. The skill most impaired was exactly the one needed to handle outage-related incidents.

The broader implication draws on Bainbridge’s Ironies of Automation: humans remain responsible for the hardest moments even as automation absorbs routine work. The skills required during incidents are built through wrestling with systems and their complexities, not through approving generated output.

When implementation gets cheaper any bad decision scale their output into the downstream bottlenecks, making them more expensive to optimise. AI amplifies whatever engineering culture already exists, with a vocal majority echoing concerns and weak discipline in equal measures.

Crafting Software

Claude Code told me what tools it needs to work faster. Oh boy I was missing so many things.

The tools available in your PATH directly affect what your AI coding assistant can produce. Most engineers haven’t optimised that environment for the agent, prioritising ergonomics mostly for themselves.

Derosiaux tested this by asking Claude Code directly: “What tools are you missing to work effectively on my machine?”

The agent spun up parallel subagents, swept through every binary in PATH, parsed Homebrew packages, inspected shell aliases, and returned a prioritized report.

The recommendations split into four categories:

• Speed and navigation — ripgrep (gitignore-aware grep), fd (modern find), fzf (interactive filtering). Shorter commands mean fewer syntax errors and less wasted context window.

• Structured output — git-delta makes diffs parseable with line numbers and clean section boundaries. xh separates headers, status codes, and response body when testing APIs.

• Automation — watchexec reruns commands on file changes, eliminating polling loops. just replaces Makefile boilerplate for task running.

• Deterministic analysis — semgrep shifts security review from “the AI thinks this looks like SQL injection” to a flagged rule with a specific line. That distinction matters when you’re validating AI output.

The surprise entry was DuckDB: a 30MB binary that lets the agent run SQL directly against CSV, Parquet, or JSON files. Without it, data analysis means writing throwaway Python scripts. With it, one query.

We set up laptops for new engineers with IDE, extensions, credentials, environment files. Nobody questions that, but the same logic applies to the agent writing code alongside them. Their tooling requirements just happen to be different and sharing the same environment.

If you use Nix flakes or dev containers, this setup can be version-controlled and shipped with the project. The AI’s preferred environment becomes a first-class artifact.

The Technical Executive

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

One list to rule them all

Prioritisation can drive anyone up the wall. With so many frameworks and more moving parts than we care to count it often becomes a necessary evil to put up with ‘whatever works for now’. But what if you designed for a single focus, an overarching outcome. Is there a way to shrink an ever-growing list to one? That’s what James Stanier successfully wrote about this week.

Today most engineering organisations run multiple roadmaps, parallel P0 lists, and initiatives with sponsors all claiming equal urgency. Don’t worry, nobody is lying. Everyone genuinely believes their thing matters most. And that’s exactly the problem: because a world where everything is first is a world where nothing is.

Stanier’s will be uncomfortable at first for many: a single prioritised list, stack ranked with no ties, is one of the most powerful forcing functions available to a leader.

Not because the list itself is magic, but because you cannot build it without having the conversations you’ve been avoiding.

The discomfort of forcing a ranking is the same discomfort you’ve been deferring by letting everything stay equally important. That’s the point:

• List everything first. Capture every project and initiative currently in flight, no filtering, no categorising, just get it all down

• Force a single ranking. One to n, no tiers, no categories, no ties allowed

• Notice where you hesitate. The moments it feels impossible to choose are precisely where the real prioritisation work lives

• Name who decides. If you can’t rank it alone, the conversation you’ve been avoiding just became visible

• Share it. Put the list in front of your peers, your team, or your manager; let the debate be about the list, not about individuals

The companies that move fastest are the ones that know what comes first so they can put their limited resources to the highest impact first, rather than effective utilization to keep everyone busy.

The Engineering Manager

Other highlights 👇

Perfectly Designed for These Results

There’s a phrase that sounds obvious until you sit with it long enough to feel uncomfortable:

Organizations are perfectly designed to get the results they get.

It’s not merely a metaphor, and often closer to a diagnosis. Persistent outcomes of missed deadlines, recurring quality failures, repeated safety incidents are more than just bad luck or bad people. The system of an org is working exactly as it was built to work, follow its natural incentives and constraints. What leaders often don’t want to hear is that wanting different results without changing the system steeped in denial.

Mike Fisher builds his case around two examples from known companies whose outcomes couldn’t be more different, and yet both were entirely predictable from their org design.

Amazon deliberately broke itself into small, cross-functional, end-to-end accountable teams. It forced APIs over meetings, explicit ownership over shared dependencies, and autonomous deployment over coordinated releases. The technical architecture evolved to mirror the org structure: Amazon leaned into Conway’s Law rather than fighting it, taking a strong stance on social constraints and engineering products independently in parallel. They were what the system was built to produce.

Boeing is the harder story. Not a villain, but a cautionary tale about drift. Over time, engineering authority eroded which caused financial and schedule pressures. Communication with regulators and pilots became more constrained. MCAS — the system at the centre of the 737 MAX crashes that killed 346 people — didn’t emerge from negligence. It emerged from an organisation where tradeoffs were consistently resolved in one direction, and where safety signals weakened under structural forces no individual controlled.

Fisher argues the real work of leadership goes beyond motivation or enforcement:

• How does information flow? Not how you intend it to, but how it actually moves; where it gets stuck and filtered

• How are decisions made? Especially the ones no one is officially making

• How are tradeoffs resolved when values collide? What wins when speed and quality are in tension?

• What does the system consistently reward? Culture is what you tolerate, what the system pays out, over and over, when no one is watching

If quality problems recur, the system tolerates them. Innovation is the result of a complex series of decisions that creates a system that does not tax experimentation. If the same incidents repeat, the system has normalised the risk.

You cannot train your way out of misaligned incentives. nor can you hire your way out of a system that punishes the behaviours you claim to value.

Fish Food for Thought

Building Internal Agents

Will Larson (author of that staffeng book) has been quietly publishing one of the most grounded agent-building series available right now. Written as an industry expert without declaring best practices, but rather working through real problems at Imprint, a co-branded credit card company.

He runs engineering at Imprint, a co-branded credit card platform. And yet he has one or two engineers building internal agent workflows and thinks every company should be doing the same.

But the most common question he gets after publishing his internal agent work is the same one engineering leaders everywhere are asking: how do I actually learn this stuff?

His answer is a concrete 8-step progression, just the sequence he’d follow to build real intuition:

1. Read a primer on how LLMs work: you don’t need to build one, just a working mental model of what they’re capable of

2. Build a script that calls a basic LLM API: get something responding to a prompt

3. Add tool calling: something simple like searching files in a local repo

4. Implement a tool_search: a separate context window that selects only the relevant tools for the task at hand

5. Build a virtual file system: so tools can reference files without loading everything into context

6. Add agent skill support: reusable, loadable capabilities the agent can pull in as needed

7. Write post-workflow evals: automated quality checks that run after every workflow

8. Add context window compaction: force yourself to solve the problem by making sure some tool responses are large enough to threaten your limit to get feedback on this sooner.

His broader point: build your own framework first, then throw it away. Existing SDKs are thin wrappers, and you’ll only know what they’re giving you - and hiding - once you’ve felt the underlying problems yourself.

Irrational Exuberance

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , , Will Larson

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Leading an Agentic Development Team

Bryan Finster is a veteran when it comes to DevOps, continuous delivery and elite engineering practices. He was at the forefront of AI-scepticism spearheaded by vibe coding and similar non-engineering practices until the tools became good enough to accelerate the mainstream engineering fields.

Models had improved enough to make him pause. He joined a hackathon, worked in languages he’d never touched, and shipped a working RAG application in a few hours. That was surprising. For him and many of us it changed how we think about AI tools in our pipeline when leading engineering teams.

Leading an agentic team is the same skill set that separates good engineering leaders from bad ones:

• making sure the right information reaches the team at the right time

• clear mission

• defined outcomes

• quality processes that catch problems before they grow

The difference now is that those fundamentals pay compound interest: Strong discipline produces dramatic acceleration. Weak discipline produces the same mess you always had, just faster. And the empirical research backs up those findings.

Here’s his advice for running agentic teams today:

1. Set the mission. Three to five sentences. What you’re building and why, not how.

2. AI Plan with the team. Have the agent generate a plan, give it feedback, and agree on the approach.

3. Define “done” first. Gherkin features. Prune anything that doesn’t belong.

4. Build focused specialists with an orchestrator. Agents from review and architecture to tests, naming, and domain patterns. Coordinated by another agent with context.

5. Let the team code. Define what the code should do and let them deliver it.

6. Validate outcomes, not activity. Ship it when it passes the planned tests.

7. Run your pipeline. Pre-commit checks, all agents, all analysis. Every time.

Bryan Finster

Other highlights 👇

A complete guide to Pair Programming

Most teams think they’re collaborating. But most forms of collaboration in the industry are various forms of scatter-gather and command and control processes to ease project management. Handing work down a chain (backend to frontend to QA) is an assembly line, not a team.

Pair programming is what the Extreme Programming (XP) community defines as real collaboration for the purpose of software engineering: two people, one goal, no handoffs.

Emmanuel Valverde Ramos has spent years practicing and teaching pair programming. The biggest misconception isn’t about the cost of having two employees sitting at one computer, but rather raising the awareness of where cost actually lives.

The time developers spend typing is a rounding error. The real spend is in debugging, rework, waiting for reviews, and context-switching back into code you forgot you wrote. Pair programming attacks all of that directly by turning hand-offs into a continuous form of peer-review, mentoring and refinement in short focus blocks.

His guide covers the full picture:

• the four pairing styles (Driver/Navigator, Ping-Pong, Tour Guide, Backseat Navigator) and when to use each

• how to manage tempo mismatches between fast and slow thinkers

• the Pairing Matrix for rotating knowledge across the whole team

• and the anti-patterns that quietly kill sessions (e.g. silent partner,dictator, …)

Still, done properly, pair programming can be exhausting. Our brains fatigue differently than our bodies, and some teams cap pairing hours for exactly that reason.

If you lead a team — or want to — this is the clearest practical breakdown of pair programming available.

Crafting Software

13 Provocative Questions CTOs Don’t Ask

Most leadership dysfunction that CTO have to solve is self-inflicted, and Yaniv Preiss has thirteen questions designed to make such problems impossible to ignore:

• Who benefits from the way we work today? And who always pays the price? A simple, non-judgemental way to challenge and improve processes.

• What did we normalize that would have shocked us two years ago? If you’re calling it “the new reality,” that’s your answer.

• Which value do we drop first when things get tight? Values only exist when they cost something. Everything else is a poster on the wall.

• If this problem disappeared overnight, what would I stop doing? If nothing, the problem might be serving you more than you admit.

• What part of me is keeping this problem alive? The need for certainty, avoiding conflict, wanting to be needed, hating to be wrong.

• What if this resistance is actually competence? Your best engineers may be pushing back because they see risks you don’t want to face.

• On a scale of 1–10, where are we really? Not the board version. Then ask: what would move us just half a point?

• Where does this problem not happen? Somewhere in your org the desired state already exists. Why are you treating it as an exception?

• What obstacle inside us will block this change? Not the market or tech debt; inside us, collectively.

• If this year were a chapter in a book about your org, what would it be called? Metaphors to bypass politics.

• What’s the smallest experiment we could run and stop? If nothing would make you stop it, it’s not an experiment. Surface beliefs your org is afraid to test.

• Who do we need to be, not just what do we need to do? You may not need more tools or frameworks. You need a clear identity.

• If nothing changes, how long until your best people leave, emotionally or literally? If you can see the timeline then it’s already happening.

Yaniv Preiss

Why Measuring Engineering Productivity Still Feels Hard

Teams talk about productivity all the time, but most measurements miss the point. Counting tickets closed, lines of code, or velocity doesn’t show whether work flowed well, quality improved, or value actually landed. The piece argues that good measurement starts with the questions you’re trying to answer — not the data you happen to have. It lays out meaningful signals like wait times, review load, defect movement and rework patterns, and shows how they connect back to real outcomes engineering leaders care about.

The upshot: better signals make better decisions, not just prettier dashboards. If you want to rethink how you track productivity, this is worth reading.

Engineering Productivity

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Shipping at Inference-Speed

After months of building and maintaining several real projects with agents, Peter Steinberger shares his workflows in working efficiently, and mostly alone with a handful of agents to move key projects forward.

Agents and AI tools are evolving quickly and require shifts in our understanding every few months. Peter shares his observations on having reached a point where the main bottleneck became the inference time–the LLM part where they generate– along with energy and tokens spent on deep thinking. Funny wasn’t that always a bottleneck?

Workflow Lessons Learned

• Structure carries more weight than correctness. Agents tend to do the right thing when folders, boundaries, and responsibilities are obvious. When they aren’t, no amount of prompting fixes the drift.

• Reading less code is normal. Knowing where things live and how data moves matters more than inspecting every function. When the layout is sound, most output holds up.

• Boring choices win. Popular languages, familiar frameworks, and widely used libraries reduce friction. Agents struggle less when the ecosystem is predictable.

• Building beats planning. Features take shape through iteration, so small CLIs, and a core model give fast feedback, and visible behavior reveal more than elaborate upfront designs.

• Humans are still the limit. Attention, judgment, and deciding what matters next. Agents run in parallel; people don’t. Any touch point of supervision becomes a clear bottleneck for the otherwise breakneck-speed of output.

The surprising part is how linear the work becomes. Fewer branches. Fewer checkpoints. Less ceremony. Things move forward unless there’s a concrete reason to stop.

What still slows things down

• Early foundation choices. A weak dependency or awkward framework creates drag that compounds over time.

• System design decisions. Data flow, boundaries, and ownership still need careful thought. Agents execute these choices well, but they don’t reliably invent them.

• Confident wrong turns. Models produce plausible output even when assumptions are off. Catching this requires attention, not tooling.

• Context overlap. Long sessions work better than before, but parallel tasks can still step on each other without discipline.

• Knowing when to interrupt. Letting an agent run long enough to be useful but not long enough to cement a bad direction is a learned skill.

Peter also shared tweaks for his Codex models along with comparison with Claude. More on that on his blog, follow the link below.

Peter Steinberger's Blog

Other highlights 👇

What developers can do to combat the growing threat of rogue AI agents

The way teams are dealing with rogue agents isn’t flashy, and it isn’t new. It’s a return to disciplined API design, with the assumption that machines, notably agents, are now the primary consumers. When agents are in the loop, ambiguity opens the door to dangerous mistakes.

What’s holding up in practice is deliberately unexciting:

• Treat the spec as the product
  Clear contracts, explicit intent, and tight schemas matter more than clever abstractions. Agents don’t read between the lines and benefit from clear intent clear to keep behaviors predictable.

• Boring controls earn their keep
  Rate limits, schema validation, scoped tokens, anomaly detection. These don’t stop agents from acting but do surface small mistakes before they turn into outages.

• Move past shared secrets
  Long-lived API keys don’t hold up in an agentic world. Short-lived, single-purpose identities make behavior traceable and revocable. When something breaks, teams need to know which agent did what, and shut it down quickly.

• Default to least privilege
  Give agents access only to the endpoints and operations they actually need. Narrow scopes make unintended behavior easier to contain and easier to reason about.

• Use AI on defense, not just offense
  The same tools accelerating development can tighten feedback loops in testing and security.

APIs now have to be designed for how machines behave, not how we hope humans are steering them. As much as you’d like to shut your eyes and ignore agents, they are here to stay. We all need to learn how to keep them on the path to be useful rather than risky.

Dev Interrupted

7 Cognitive Biases of Engineering Managers

Most engineering managers go into review season with good intent. But evaluating a full year of work under time pressure pushes the brain into shortcut mode. They care about fairness and want to reward real impact. But as the pressure looms the bias creeps in quietly and often invisibly.

These are seven cognitive biases that show up most often in engineering management, and how they distort feedback:

1. Recency bias
   Recent wins (or mistakes) crowd out the rest of the year. A strong last month can outweigh steady delivery. A fresh misstep can overshadow months of solid work.

2. Visibility bias
   Work that happens in meetings, Slack, or public threads gets more credit than quiet, foundational work. Presence gets mistaken for performance.

3. Hero bias
   Firefighting gets rewarded. Preventive work doesn’t. Over time, teams learn that fixing emergencies matters more than avoiding them.

4. Affinity bias
   Managers evaluate work they understand more generously. Domains that match a manager’s background feel harder and therefore more impressive than unfamiliar ones.

5. Confirmation bias
   Early impressions harden into narratives. New evidence gets filtered to support the story already in your head.

6. The halo effect
   One standout strength like a great presentation, a visible win softens judgment everywhere else, even years later.

7. The horn effect
   One memorable failure becomes the lens for everything. The bar quietly rises for that person alone.

All of these come from mental fatigue and incomplete information. Building habits and systems that catch it before it shapes decisions is what sets accomplished managers ahead of the average. Good performance management doesn’t rely just on memory.

Diary of an EM

Why Measuring Engineering Productivity Still Feels Hard

Teams talk about productivity all the time, but most measurements miss the point. Counting tickets closed, lines of code, or velocity doesn’t show whether work flowed well, quality improved, or value actually landed. The piece argues that good measurement starts with the questions you’re trying to answer — not the data you happen to have. It lays out meaningful signals like wait times, review load, defect movement and rework patterns, and shows how they connect back to real outcomes engineering leaders care about.

The upshot: better signals make better decisions, not just prettier dashboards. If you want to rethink how you track productivity, this is worth reading.

Engineering Productivity

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - Peter Steinberger, (c. Dev Interrupted)

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

From Story Points to Reliable Planning: A Practical Guide for Teams Ready to Stop Guessing

Planning tends to go off the rails when teams mistake numbers for understanding. Story points were supposed to be a thinking tool. In practice, they’ve become a time sink that produces confident-looking numbers and unreliable plans. Teams argue about whether something is a 5 or an 8, then act surprised when the sprint doesn’t land the way the numbers promised.

The uncomfortable part isn’t that story points are imperfect. It’s that teams keep using them even after they’ve stopped helping.

Slicing > Estimates

What changes when teams stop guessing:

• Planning shifts from debate to clarity

• Forecasts come from what gets finished, not what felt reasonable at the time

• The conversation centres on right-sizing, not deadlines

From there, planning starts to feel less like a ritual and more like a decision.

Story points fail for predictable reasons. They mean different things to different people, even on the same team. Velocity gets treated as stable when everyone knows it isn’t. And once those numbers start getting used to judge performance, they quietly inflate. The process grows heavier, but the signal doesn’t improve.

What holds up better is much simpler: counting completed work. Throughput isn’t clever, but it’s at the very least honest and data-driven. It reflects reality instead of aspiration, especially when team members disagree on levels of interpretation or base knowledge.

Teams that look at how many items they usually finish planning starts being useful. When most work fits into one- or two-day chunks, size differences stop dominating the conversation.

This is where many teams hesitate. Slicing that small feels awkward at first. But the discomfort usually comes from framing work as components instead of outcomes. Once the focus moves to something a user can see or react to, thin slices appear more easily than expected.

Planning gets calmer after that. Teams pull work based on what they usually finish. They spend their time checking understanding, surfacing risks, and making sure items are small enough to move. The numbers fade into the background, where they belong.

Predictability doesn’t come from better estimates.
It comes from work that’s small enough to flow.

Andrea's Substack

Other highlights 👇

The 80% Problem in Agentic Coding

AI didn’t stop at helping engineers code faster.
It crossed a line where most of the code now gets written without them.

For some teams, the shift was sudden: from “AI assists my work” to “AI does the work and I supervise.” Output jumped. PRs multiplied. Shipping felt easier than it had in years.

The cost showed up later — not in broken builds, but in understanding.

What changes once agentic coding passes ~80%:

• Errors move from syntax to architecture

• Review effort grows as coding time shrinks

• Code volume increases faster than comprehension

High Volume Agentic Coding Moves Engineering Focus

Teams that struggle treat AI as a faster pair of hands. Teams that succeed redesign their workflow around it. What teams find to work best in practice:

• Define success before execution
  Agents are good at iterating toward a goal. They’re bad at choosing the right one. Clear specs, constraints, and tests matter more than ever.

• Use tests as guardrails, not afterthoughts
  Let agents loop until tests pass. If the same mistake repeats, the fix is a new test.

• Bound autonomy deliberately
  Small tasks. Clear inputs. Explicit stop conditions. Unlimited freedom produces unlimited complexity.

• Review for design, not syntax
  Syntax is cheap now. Architecture, invariants, and intent are not. Reviews should focus there.

• Treat confusion as a signal
  If the team can’t explain how something works, that’s debt. Treat it accordingly.

Agentic coding works best in greenfield systems and small teams, where context is shallow and refactoring is cheap. In large, mature codebases, the bar is higher. The agent doesn’t know the unwritten rules. Someone has to own them.

AI can generate almost unlimited code. The scarce skill now is deciding what deserves to exist and keeping the system understandable once it does.

Elevate

You can code only 4 hours per day. Here’s why.

Most engineers already feel this limit, they just keep working past it.

After a few hours of real coding, progress turns cosmetic. Still, teams plan around eight-hour days and treat the drop in quality as a personal failure instead of a structural one. The mistake isn’t discipline. It’s designing teams as if deep thinking scales with time.

Ignoring this ceiling quietly creates rework, burnout, and an atmosphere of false urgency.

Let’s focus on baseline:

• Deep coding has a hard cognitive cap, usually 3–4 hours

• Meetings and interruptions consume the best hours, not the leftovers

• AI does not extend focus-time, merely shifts it

• Protecting “depth” over hours is what boosts productivity

Flow

Flow is the real multiplier most teams never plan for.

When developers talk about “good days,” they’re rarely talking about hours logged. They’re talking about the stretches where everything clicks just right. The problem holds still long enough to reason about, decisions stack cleanly, and progress feels almost effortless.

Research has been consistent on this for decades: deep, uninterrupted concentration produces outsized results. For software work, the difference is rather dramatic. The same engineer, working on the same problem, can deliver multiples more value when they’re able to stay immersed long enough for context to fully load.

But flow is very fragile. It requires just enough challenge to stay engaged, just enough clarity to avoid thrashing and, above all, protection from interruption. Most engineers rarely reach it not because they lack skill, but because their day never gives them a fair shot.

The Day

That changes how the day gets designed. Focus blocks stop being “nice to have” and start being non-negotiable. The work entering those blocks becomes sharper. Instead of “working on the backend,” the aim is to produce something concrete enough to finish before context decays.

It also changes when hard problems get tackled. Most developers don’t struggle in the afternoon because they’re lazy; they struggle because their best cognitive hours were spent in meetings. When mornings disappear into syncs and ceremonies, the most demanding work gets pushed into the weakest part of the day. The result looks like low productivity, but it’s really poor allocation.

The teams that consistently do well treat attention as a scarce resource. They batch communication. They cluster meetings. They block time for real work and defend it socially, not just individually. They understand that long, uninterrupted sessions beat heroic late-night pushes every time.

Optimal Flow is about creating the conditions where the brain can actually do what it’s good at. When those conditions exist, three focused hours routinely outperform eight distracted ones. And once teams experience that difference, it becomes obvious why productivity problems rarely get solved by adding more time.

Tech World with Milan

When Visibility Becomes the Real Problem

Most engineering teams don’t suffer from a lack of tools. They suffer from a lack of clarity. Work moves fast, data piles up, and yet simple questions remain hard to answer. Where is time actually going? What’s slowing teams down? Which signals can be trusted?

This piece explores why choosing an engineering intelligence platform is less about feature checklists and more about decision-making. It walks through how to think about visibility, signal quality, and trade-offs before committing to any system. If you’ve ever felt that dashboards show activity but not understanding, this is a useful place to start.

SEI Platforms

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

We Fired Jira and Slack. 2/3 of Engineers Said It Changed Our Culture More Than Any Leadership Initiative

Everyone says culture comes from leadership, from vision and values. How managers show up. That’s true, yet incomplete.

Culture is shaped just as much by the systems people work inside every day: The tools they open first thing in the morning. The places where attention is spent, interrupted, or protected.

Change those, and behavior changes with them. That’s what happened in Jari’s organization.

Jira and Slack were replaced because they felt heavy, noisy, and quietly draining; with the practical intent to make work smoother. The outcome of that initiative was refreshingly cultural.

Despite their worst fears: Nothing broke! The leadership team stayed the same. The strategy stayed the same. The people stayed the same. But once the work system stopped demanding constant management, work itself began to feel different:

• Less time spent navigating tickets

• Fewer interruptions disguised as collaboration

• More space for sustained focus

• More ownership

• Less pressure to perform availability (instead of progress!)

This idea isn’t to shine a bad light on productivity tools like Jira or Slack, but to bring awareness that such tools are never benignly neutral.

Tools come with opinions baked in. They assume how work should flow, make some behaviors easy and others painful. And ultimately, they nudge people day after day, toward what the system seems to value.

Heavy workflows push teams toward approval, tracking, and justification with constant notifications pulling everyone into a state of permanent urgency. In contrast, lighter tools make it easier to just do the work and move on with async-first communication giving people permission to focus without exclusive availability.

After a few months, the pattern was obvious for Jari and his team. Engineers were calmer, with lasting longer. When culture doesn’t budge it’s often because the everyday tools are steering behavior in directions nobody explicitly chose. Or perhaps may not even know that such incentives exist, a so-called shadow org.

Change the tools, and you change those moments. Which tools are running your org?

Jari Mattlar

Other highlights 👇

Claude Code AI agent Changes How We Build Software

AI agents shifted where engineers spend their time as code becomes cheaper to produce. Developer attention moves upstream to system design, trade-offs, documentation, and test strategy, making the work feel less like pushing out functions and more like pure engineering intent.

Better decisions getting airtime

The Croz team found that working with Claude Code pushed day-to-day development away from write the next function and toward better design, trade-offs, and alignment. Execution become cheap enough to invest more time into architecture, clearer module boundaries, explicit test strategies, and written decisions that survive beyond a single session.

Documentation the highest-leverage tool

They report the biggest productivity gain was keeping docs alive. Architecture Decision Records, project structure notes, conventions, and test strategies stopped being started acting as shared context without going stale upon next iteration.

A bonus upside is the dramatical improvement in AI output quality in addition to being helpful to engineers. ADRs especially help the coding agents to stop guessing on overarching issues. The loop becomes explore → experiment → decide → document, and each pass tightens both human understanding and AI behavior.

Low-cost experimentation

With Claude Code, trying multiple approaches stops being expensive. Designs can be spiked, compared, and discarded without commitment.

Boilerplate testing gets automated, a rather tedious area of engineering that feels like cruft and busywork, leaving humans to focus on edge cases and failure modes.

Over time, strong projects start to look similar:

• clear technical contracts

• well-documented constraints

• reference examples that compress future design work

The pattern is consistent enough such that the teams that benefit most aren’t the ones generating the most code, but the ones investing in clarity so AI can do the mechanical work reliably.

Croz

The Product-Minded Engineer: The importance of good errors and warnings

Product Thinking Shows Up in the Boring Parts

In his latest post, Gergely Orosz digs into The Product-Minded Engineer, a new book by Drew Hoskins. The book explores Product thinking beyond brainstorming features: caring deeply about the parts of the product most engineers ignore especially when things go wrong.

Errors Are the Real Interface

One of the book’s strongest arguments is that error messages and warnings are often the primary way users experience a product. If they’re vague, late, or written from the system’s point of view, users get stuck; or worse, leave. Well-designed diagnostics do the opposite: they reduce confusion, guide action, and quietly earn trust.

Product Thinking Means Knowing Your Audience

Good errors strive beyond the standard code and message combo. They’re written for the right person, at the right moment, with the right level of context. The book breaks this down systematically by elevating frameworks for reasoning about:

• who is seeing the error

• what they were trying to do

• and what they can realistically fix next

That mindset, more than tools or titles, is what separates product-minded engineers from dev stuck in feature factories.

AI Raises the Bar

As teams use more AI to generate code, the cost of poor product thinking rises. Agents and users alike depend on diagnostics to recover from failure or evaluate responses qualitatively. When errors aren’t actionable, iteration slows and costs climb. Engineers who treat failure states as first-class product surfaces become dramatically more valuable.

The Pragmatic Engineer

When Visibility Becomes the Real Problem

Most engineering teams don’t suffer from a lack of tools. They suffer from a lack of clarity. Work moves fast, data piles up, and yet simple questions remain hard to answer. Where is time actually going? What’s slowing teams down? Which signals can be trusted?

This piece explores why choosing an engineering intelligence platform is less about feature checklists and more about decision-making. It walks through how to think about visibility, signal quality, and trade-offs before committing to any system. If you’ve ever felt that dashboards show activity but not understanding, this is a useful place to start.

SEI Platforms

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Differences Between Lead Roles and How to Find Your Right Path

Lead roles aren’t a ladder. They’re a set of different problems to solve.

At some point in a senior engineer’s career, the question stops being “What’s the next title?” and becomes “What kind of problems do I actually want to own?”

That’s where many people get stuck as lead roles look similar from the outside while demanding very different approaches. Despite the inconsistent naming and levels across industries and continents in the tech space, four paths show up consistently:

Tech Lead

This is usually the first step into leadership. You still code but your output is team-wide momentum. You design the approach, align with product, manage tradeoffs, unblock others, and make sure the project lands.

Team Lead

This is where people management enters the picture. Your job shifts toward team health, clarity, prioritization, and coaching. When something is missing be it skills, structure, focus, you either fill the gap or fix the system. Strong generalists thrive here.

Engineering Manager

Now the work is orchestration. You’re designing teams, hiring, setting direction, translating business goals into skill maps with promotion opportunities, and reading signals instead of tasks. Impact shows up in outcomes and people growth.

Architect

Still deeply technical, but operating across teams. You’re thinking in years of maintenance and support, not sprints. Leaders on the architect ladder are rare. They aligning systems, setting standards, anticipating constraints, and shaping long-term decisions. Influence and consistency matter more than authority or speed.

All of the paths are optimized for different kinds of contribution. None is above the others. Ask yourself better questions to gain clarity on your next step:

• Details or direction: What gives me energy?

• Do I enjoy depth or coordination?

• Do I want to lead through expertise, people, or systems?

• Where do I naturally step in when things get messy?

Career paths are neither linear nor permanent. Strong leaders move between these roles over time, carrying skills with them especially communication, judgment, and systems thinking. The goal is to deliberately choose which kind of problems you want to wake up and solve.

If you’re intentional about that, the path tends to reveal itself.

Engineering Leadership

Other highlights 👇

Is Your AI Strategy Only as Good as Your Team Archetype?

The latest DORA research quietly drops the old low/medium/high/elite tiers and replaces them with seven team archetypes. Behavioral profiles instead of ranking to highlight patterns of how delivery, stability, outcomes, and well-being correlate to productivity in real teams.

AI is not a neutral upgrade: For some teams, it genuinely amplifies flow while accelerating the mess they’re already in for others. For example: Teams stuck in survival mode or tangled in legacy bottlenecks don’t suddenly become high performers with better tools.

They get more alerts, more churn, and more burnout. Meanwhile, stable, well-run teams use AI to reinforce quality, speed up learning, and extend practices that already work.

AI tools magnify your team’s current, day-to-day behavioral archetype. Let’s have a look at the team clusters that emerged from the DORA research:

• Foundational Challenges (10% of sampled teams)
  Delivery is fragile leading to high chances of burnout. Such a team is overwhelmed and all energy goes into surviving the week. AI here adds noise to an already overloaded system.

• The Legacy Bottleneck (11%)
  Work is constantly interrupted by instability and unplanned fixes. Progress slow and reactive, which AI tools can make worse by accelerating coding chaos.

• Constrained by Process (17%)
  The systems are stable, but the way work flows is not. Excessive handoffs, approvals, and queues drain momentum. AI can fix the local bandaids but it still takes senior leadership shifts to handle the real org-level bottlenecks.

• High Impact, Low Cadence (7%)
  When these teams ship, it matters. But it happens too rarely, and usually at high risk and batch size. Without stronger safety nets, AI increases the blast radius instead of improving sustainability.

• The Stable and Methodical (15%)
  Quality is high, pace is deliberate, and work is reliable. These teams don’t need AI to save them but used thoughtfully, it can help them deliver the same craftsmanship faster. This is the first “tier” of archetypes where ignoring AI leaves money on the table.

• The Pragmatic Performer (20%)
  The work gets done week after week without drama. AI here becomes a quiet efficiency engine. Useful, but not transformational on its own.

• The Harmonious High-Achiever (20%)
  Low friction, high trust, strong outcomes, and healthy teams reinforce each other. AI in such teams blends naturally into the systems and tools, augmenting what’s already working.

Leaders that make a difference augment “How do we roll out AI?” with asking “What kind of team are we actually running right now?” Until you can answer that honestly, any AI strategy is mostly wishful thinking.

Flow Forward

No management needed: anti-patterns in early-stage engineering teams

Antoine Boulanger is an engineering operator and YC founder, who also writes angel checks for AI, Infra, and Dev Tools companies.

If you’re a Seed or Series A founder worrying about motivation, performance, process, or “managing” engineers, there’s a good chance you’re solving the wrong problem. Early on, most perceived engineering management issues are signals to build product and talk to users rather than structure.

Trying to motivate engineers through hours, rituals, or oversight backfires fast. Great startup engineers don’t need motivation applied to them; they bring it with them. Hire people with intrinsic drive and then stay out of their way. Culture enforced through meetings or pressure is temporary. Lasting change emerges from clarity, trust, and momentum.

Hiring managers too early creates a different kind of drag. When the product is so young that it’s a moving target, management optimizes chaos with little hope of reducing it. Structure before product-market fit masks uncertainty and makes pivots harder.

The practical alternative is deliberately boring leadership. Flat teams. Minimal process. Asynchronous updates. Lightweight docs instead of systems. Radical transparency instead of coordination overhead. The “node & postgres” stack of management: proven, unglamorous, and unlikely to be the reason you fail.

The long-term mission prior to product-market fit is simple but uncomfortable: at the early stage, the highest-leverage move is often restraint. Hire well. Remove friction. Stay close to customers. Let management wait until there’s actually something stable to manage.

Antoine Boulanger

Why Generative AI Has Become Core to Modern Development

Generative AI tools are no longer experimental add-ons — they now sit at the heart of how developers write, refactor, test and understand code. In 2026, capabilities that once felt futuristic — natural language to code, context-aware suggestions, automated test scaffolding and cross-file edits — are everyday aids embedded in major IDEs. These tools help reduce context switching, automate repetitive work, speed debugging and improve flow, but they don’t replace human judgment. Getting real value requires thoughtful selection, seamless integration and ongoing governance so that AI amplifies expertise rather than obscures quality or introduces risk

Gen AI tools

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

Merry Christmas! See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Staff+ engineers are the key to AI adoption

AI adoption fails when it’s treated as a tooling problem and succeeds only when it’s treated as an operating-model redesign. Staff+ engineers are uniquely positioned to make that shift happen.

What makes staff+ engineers uniquely effective

Staff+ engineers combine deep technical credibility with cross-team influence, without relying on formal authority. They connect strategy to execution by translating ambiguity into something teams can safely ship.

They do this by:

• Bridging product, security, data, and engineering concerns

• Asking whether a project is actually ready for AI

• Turning one-off experiments into reusable patterns

Their real value is in making AI operable at scale.

1. Start small and fast

Run constrained pilots designed for learning. Each experiment is small, low-risk, and documented so others can repeat it. The output is a reusable framework that lowers the cost of the next experiment.

2. Build AI literacy across the org

AI only creates value when people understand how and why to use it. Staff+ engineers raise the baseline by creating shared language, safe forums for questions, and common mental models around risk, data, and failure modes. This alignment turns “security said no” into “how do we solve this together?”

3. Decide what to transform

AI exposes weak systems: brittle APIs, poor data quality, missing observability. Staff+ engineers decide where AI meaningfully improves outcomes and where deterministic systems should remain. They apply old lessons of incidents, postmortems, failure patterns, etc. to new tools, designing guardrails and eval systems that keep users safe and systems reliable.

AI integrations still break for the same reasons your systems always have:
bad data, unclear boundaries, missing feedback loops, and decisions made too far from their consequences.

That’s why past incidents, postmortems, and architectural scars are some of your most valuable inputs when designing AI-enabled systems. Exploring and recognizing patterns across AI adoption initiatives is the core ingredient to leveraging adoption beyond experiments.

Create conditions where good solutions can emerge repeatedly:

• Strong observability and fast feedback loops

• Safe sandboxes for experimentation

• Red-team exercises that stress assumptions

• Post-incident reviews to change future designs

You don’t need to have all the answers. Impact comes from designing the technical and cultural environment where the right ideas surface, get tested safely, and improve over time.

LeadDev

Other highlights 👇

The Argument You’re Winning Is the Wrong One

The argument “AI won’t replace engineers” is comforting and mostly irrelevant.

The engineering shift is about how much engineering work one person can now do, and what that does to teams, roles, and leverage. Historically, every wave of automation followed the same pattern: skeptics were right about short-term limits and wrong about long-term impact.

AI assistants, be it agents or augmented workflow, don’t need to understand software in a human sense to change the economics of building it. If AI lets one engineer do the work of several, fewer engineers are needed even if a human still sits in the loop.

The popular augmentation narrative is misleading. Yes, AI augments capability. But augmentation is labor-saving. Tasks get absorbed one by one until the role is technically still there, but materially diminished.

The uncomfortable questions that surface from this argument have more to do with
who benefits, which skills retain leverage, what work disappears quietly, and who gets to shape how this transition plays out? Dismissing the change by arguing against total replacement avoids the reality that replacement happens gradually, economically, and unevenly.

The engineers who fare best won’t be the ones insisting nothing changes, but the ones engaging seriously with how it will.

Andrea's Substack

The difference between Manager and Director

As leaders grow, their center of gravity shifts along three dimensions: What, How, and Why.

• Early in your career, impact is defined by What you deliver: code shipped, bugs fixed, features released.

• As a Manager (or Staff-level IC), How becomes primary. You’re accountable for how work gets done: processes, collaboration, quality, decision-making, and team effectiveness.

• As a Director (or Staff+), Why moves to the foreground. You’re no longer executing strategy but also helping create it. Your job is to shape direction, filter priorities, and ensure teams are aligned to outcomes, not just outputs.

This shift surfaces on multiple levels:

• Your work product moves from features to systems, metrics, org design, and strategy.

• Your power base moves from expertise to influence. Authority matters less; trust, relationships, and communication matter more and you’ll inevitably get dragged into politics.

• Your feedback loop gets longer and more abstract. Impact shows up in business results and organizational capability, not daily tasks.

Many leaders struggle at this transition because they hold on to the old definition of value, ie. staying close to execution, acting as a gatekeeper, or overusing expertise. Such leaders grew and excelled by placing themselves into the critical path where a problem had to be solved. But that creates bottlenecks, erodes trust, and prevents strategic thinking.

The leaders who transition well start early:

• They build context beyond their immediate scope.

• They practice communicating intent, not instructions.

• They engage with Why long before their title requires it.

The title doesn’t change the job overnight, though. At the same time expectations may already have. The smoother the shift from What → How → Why the more effective and sustainable your leadership impact becomes.

Scaling Impact

Seeing Past the Surface of AI-Driven Coding

AI has become part of daily development almost by default. Code moves faster, suggestions appear instantly, and output climbs. Yet many teams sense a mismatch between what the metrics show and how the work actually feels. Reviews get denser. Changes come back for fixes more often. Developers spend more time validating and less time creating, even as velocity looks healthy.

The deeper shift is that AI redistributes effort across the lifecycle. It pulls work forward into generation, then pushes cost into review, rework, and long-term quality. Understanding this requires looking beyond adoption or usage stats and paying attention to signals like review depth, bounce-back rates, defect movement, and sustained cognitive load. When these patterns are visible, AI becomes a steady advantage. When they aren’t, speed masks slow erosion.

AI Coding

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

Merry Christmas! See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - Maxime Najim (w/ LeadDev), ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

2025 saw turmoil in engineering orgs across the globe as AI adoption, leaner team structures and heavy focus on productivity and wellbeing metrics rejuvenated the entrenched IT and Product Engineering scene. Lets start with the years’ highlights, the most popular, clicked and shared topics for you to review and connect with the wider community.

The groCTO editorial wishes you happy festivities, a happy new year and a healthy start to 2026.

Most Popular Staff+ Bytes ⭐️

Most Loved Management Bytes ⭐️

Most Useful Typo CTO Guide ⭐️

Honorable Mentions

• Engineering Performance Playbook; Product lessons from N26 CPO; Microsoft’s Copilot Study; Balancing TDD between design and testing 🏅

• Scrum vs. Not-Scrum, A day in the life of “10x Developer” teams, Hard-work Myths 🏅

• Engineering vs Project Management; Improving AI Products; Effective Delegation; Bad Management; Is it “Done”? 🏅

• Insufficient JIRA Dashboards; Aspirational Leadership; Great Code Review Communication; Developers’ Skills Atrophy with AI 🏅

Find yourself 🌻

That’s it for Today! Once again, a Merry Christmas & a Happy New Year 🍾

See you next year. Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Building a skill matrix that actually helps your team

A skill matrix a shared map of real team capabilities that reveals hidden risks, gaps, and opportunities for growth. Sadly far too often in organisations skill maps end up being used merely as a career ladder or performance checklist. But it can be much more than that: a lens on how your team functions as a system. Emmanuel shares his prized experienced on how to build great skill matrixes:

Impact first

• Understand today’s capabilities: who can realistically do what, and where single points of failure live

• Anticipate future needs: what skills the roadmap demands and where your team needs to grow

• Expose real working methods: what people actually do (e.g., how releases happen, how teams collaborate, SOPs)

Leaders who skip this clarification poison the exercise before it starts. People only answer honestly when they know the matrix is a team tool rather than a judgment device.

Your team is a system

Borrowing from systems thinking, teams have feedback loops, bottlenecks, and hidden dynamics that don’t show up when you look at individuals in isolation.

A good skill matrix exposes things like:

• single points of failure

• skills that never spread because the same person always does the work

• areas the team keeps investing in that the business doesn’t actually value

• critical capabilities the strategy depends on but nobody owns

Seen this way, the matrix becomes a diagnostic lens.

Three questions every useful matrix answers

Every effective matrix balances three perspectives at once:

• Where we are now
  Current skills, depth, and distribution, including uncomfortable realities.

• Where we think we’re going
  The roadmap, the tech bets, and what the team wants to grow into.

• Where the organization needs us to go
  Capabilities implied by strategy, regulation, scale, or market pressure.

The tension between these must be made visible to enable leaders to facilitate change and support difficult transition points in future roles and processes.

Levels without turning people into numbers

Emmanuel combines the Dreyfus model and Bloom’s taxonomy to describe growth in a way engineers recognize. Instead of the usual 3/5, it highlights opportunities scoped to:

• what someone can do independently

• what kind of decisions they can make

• how much context they need

• whether they unblock others

This makes calibration conversations grounded and far less political.

Process matters as much as the artifact

How you evaluate depends on trust:

• In high-trust teams, peers evaluate first, then leaders calibrate.

• In lower-trust or newer teams, self-evaluation followed by coaching works better.

In both cases, the matrix only pays off if it feeds back into:

• training plans

• pairing and mentoring

• hiring decisions

• initiative sequencing

A matrix that doesn’t change how work is planned becomes shelfware fast.

What you do after the matrix matters more than the matrix itself.

Used properly, it turns vague instincts into visible data:

• when to slow down

• when to invest in learning

• when a roadmap is unrealistic

• when expertise needs to spread

Investment into an actionable skill matrix helps teams stop relying on heroics and start growing capability on purpose. Seeing your team clearly enough to move forward without guessing is what allows you to keep a steady pace without burning out the same people over and over again.

Crafting software

Other highlights 👇

Why Labeling Relationships Is So Important

John Cutler’s point is deceptively simple for us this week: most “operating system” diagrams fail because they only show boxes, not the meaning between boxes. When you force yourself to label the relationships and the verbs, the whole system gets clearer fast.

He walks through a few common traps:

• Goals ↔ initiatives aren’t one relationship. Different orgs treat goals as anchors, guardrails, post-hoc justification, or reporting buckets. Those are totally different worlds, and they drive totally different behaviors.

• Two companies can draw similar “strategy → execution” charts but run completely different playbooks, depending on whether the edges mean “implements,” “constrains,” “learns from,” “feeds,” “localizes,” etc.

• Hierarchy thinking fails at scale: A lot of “scaling agile” logic comes from copy-pasting team-level patterns upward (epic → program → portfolio, standup → big standup, OKR cascades), even though the dynamics change once politics, translation, and distance show up.

His lesson for us this week: model your org like a network, not a tree. Name the relationship types, ie. flow, accountability, constraints, feedback loops, translation because that’s where the real operating system lives.

The Beautiful Mess

It’s not a principle until it costs you money

Principles only exist when they constrain your choices. If a value never forces you to give something up, it isn’t guiding your behavior. Sergio argues that much of modern tech, especially the current wave of AI tooling, is no longer neutral in practice. It concentrates power, shapes behavior at scale, and quietly embeds values that many practitioners never agreed to.

Companies and individuals are being pulled into adopting and promoting AI tools less out of clear necessity and more out of fear of being left behind. That fear creates a market for easy money: consulting, training, and tooling sold on urgency rather than proven value.

When decisions are driven by panic and hype, principles are usually the first thing to get compromised. Money is leverage. Who you accept work from, what products you buy, and what systems you help scale are the strongest signals of what you actually stand for. For people who feel disoriented or disappointed by where tech is heading, reframing your “values” as everyday economic choices rather than abstract positions and words on the wall. Coordinated refusal may be more powerful than individual critique.

sudo make me a CTO

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

Merry Christmas! See you next week, Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

Taking Over an Engineering Team Without Breaking It

In this week’s feature Gert Lõhmus highlights the predicament tech leads and startup CTOs find themselves in when they fill the shoes of a previous leader who left the team or organization after forming it.

Taking over an existing engineering team is stepping into a system with history: past decisions, bruises, unspoken narratives, insecurities, pride, and dynamics you can’t see on day one. New leaders often rush to prove themselves making quick decisions, proposing improvements, or tightening processes.

Research shows this is exactly the wrong instinct. Teams trust leaders who make it safe to tell the truth, not leaders who show up with answers. But the team first needs the sense that someone sees their context, the constraints they lived with, and the work that’s being nurtured and protected. Until a team feels understood, they interpret every new idea as a threat.

Your first job is to understand.

Understanding over Direction

Keep an eye out and spend time to gain situational awareness on:

Power dynamics
Who people turn to for clarity, who asks hard questions, who sets emotional tone.

Communication habits
Meeting-heavy or async? Does debate thrive or get suppressed? Who gets interrupted?

Technical ownership
Where the fragile areas are, where debt hides, where a single engineer holds critical knowledge.

Motivation
What energizes each member from impact, craftsmanship, stability, recognition, or learning.

Unspoken stories
Teams carry narratives that explain more than any roadmap:
“We tried that before.”
“Leadership doesn’t listen.”
“We’re stretched too thin.”

Two questions shape your early reputation:
Do you understand us?
Will you take care of us?

Trust Is Built Through Small, Visible Actions

The temptation is to fix everything at once. Resist. Change is something you earn.

Practical moves that build credibility:

1. State your intentions early

Tell the team you’re learning before changing. It signals respect and lowers anxiety.

2. Run intentional 1:1s

Use questions that reveal what truly matters:

• “What are you proud of that goes unnoticed?”

• “What shouldn’t we break?”

• “What’s one thing you’d change about how we work?”

• “Where do you want to grow next?”

These questions uncover history, motivations, and quiet frustrations faster than any dashboard.

3. Focus on principles over heavy processes

If something needs improvement, co-create principles instead of imposing frameworks.

4. Praise publicly, coach privately

Public credit accelerates trust. Private correction preserves psychological safety.

5. Learn how the organization actually works

Influence networks, decision pathways, political currents. Every company has them and the understanding of the stakeholders’ lifelines will be your guiding light that keeps the puzzle together. Ignoring this slows you down; understanding it helps you protect your team.

6. Deliver a few fast, low-risk wins

Pick improvements that are:

• visible,

• non-controversial,

• finishable in 30 days.

Small wins compound quickly.

7. Shield the team from chaos

Push back on unrealistic timelines. Negotiate scope. Clarify expectations with product.
Engineers remember the leader who protects them.

The Velocity Curve

Other highlights 👇

So What’s Going to Happen to Product Management Anyway?

AI-native companies are redefining the PM role. Peter Yang predicts there will be fewer PMs, but the remaining jobs will be more impactful and closer to actual product building.

Why PM Roles Are Shrinking

AI-native teams (OpenAI, Anthropic, Cursor, Replit) optimize for talent density, not headcount. They delay PM hires because modern engineers and designers can cover many “old school PM” tasks with AI tooling. The ZIRP-era model of large pods with strict lanes is collapsing. Companies want T-shaped builders over coordinators.

The new: PMs who can build

Rapid prototyping, dogfooding, shortening feedback loops, and shipping daily beats documentation-heavy workflows. AI collapses idea→prototype cycles to hours, so PMs who stay in planning mode get left behind. Certificates get sidelined as proof of work and AI-native hiring amplifies the signals of How fast can you iterate solo?

Higher You Climb, Less You Build

Leadership ladders reduce hands-on time. Many PMs are stepping down from director roles to IC roles at AI-native companies just to stay sharp and relevant. ICs who master AI tools now have more leverage than some managers.

Lifestyle Constraints Will Force Choices

AI-native startups increasingly seek to adopt running at 996 intensity. That pace excludes many parents and caregivers. PMs who find themselves in such setups need to be realistic about the environments they can thrive in and choose accordingly.

Human Skills Become More Valuable

Even as building becomes essential, alignment and influence still differentiate great PMs. AI can draft strategy, but it can’t resolve conflict, recalibrate a team after a failed beta, or steer stakeholders through ambiguity.

The PMs Who Win From Here

Peter calls this “figure it out” energy. Breadth, speed, autonomy, and the willingness to step outside formal lanes. They build prototypes in order to collapse decision cycles while using pre-built prototypes as a way to align teams.

Fewer PM jobs, but better ones for those who adapt: faster-moving, craft-driven, and closer to the product than ever before.

Behind the Craft

Autonomy: The Art of Letting Go Without Losing Control

GitHub ships to production 100+ times a day with no committees, no approval lines, and no centralized scheduling. Their engineering organization has over the years put constraints in the right places so autonomy becomes scalable from day one.

How Autonomy Shines

Progressive Delivery breaks autonomy into four forms:

• Technical autonomy: Teams have the environments and tools to build and ship.

• Decision autonomy: Local ownership of implementation and timing.

• Process autonomy: Teams adapt workflows to their reality.

• User autonomy: Customers choose when and how to adopt change.

Autonomy only works when alignment is strong. Without it autonomy slows you down and increases delivery risks substantially.

How Modern Teams Scale Autonomy

• Git enabled parallel development, shifting control to the edges.

• Radical delegation pushes decisions to the people closest to the outcome.

• Adobe’s AI rollout uses layered autonomy: engineers experiment freely, product teams control exposure, and users choose which AI models they adopt.

Three Levels of Autonomy

• Individual: Engineers can make progress without waiting.

• Team: Small teams own services end-to-end (Amazon-style).

• User: Consumers personalize how and when they adopt features.

The Trust Equation

Trust grows when competence, reliability, and alignment outweigh risk. GitHub’s high-autonomy model works because feature flags, tests, and rollbacks shrink the blast radius of mistakes. This allows them to maximise low-risk, but trust-building initiatives without slowing delivery down with needless gates. This radical approach to ownership fundamentally nurtures psychological safety:

• Mistakes lead to learning, not punishment

• Issues surface early

• Experiments are encouraged
  This is the difference between confident teams and reckless ones.

Where to Start

Look for bottlenecks where autonomy is missing:

• Waiting for infra

• Over-centralized approvals

• Trapped knowledge

• Slow feedback loops

Begin with low-risk areas, broaden autonomy as competence and alignment grow.

IT Revolution

Why Engineering Intelligence Matters More Than Ever in the AI Age

AI is speeding up development while quietly increasing complexity. Code moves faster, reviews get heavier and teams take on far more change than before. In this environment, old signals collapse. Velocity looks high even when rework piles up. Quality issues surface late because no one sees the patterns early enough. This is why engineering intelligence becomes a necessity, not an accessory.

Leaders need a way to see how AI is actually shaping delivery, where it’s reducing effort and where it’s adding hidden drag. They need clarity on flow, stability, review load and the real cost of change across teams. Without a coherent intelligence layer, AI-driven engineering turns unpredictable. With it, teams gain the ability to steer instead of react.

Building Intelligence

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , Leah Brown (c. IT Revolution),

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

How to Measure Engineering ROI: A Practical Guide for SaaS CTOs

When Marketing says “Every dollar brings back three,” and Sales points to closed revenue, engineering is left holding velocity charts and uptime stats. Impressive perhaps, but they don’t answer the question “What do we get for every engineering dollar we spend?”

The shift that unlocks ROI

Engineering ROI becomes clear only when you start optimizing for impact and stop optimizing for activity.

• Shipping features does not mean creating value.

• Velocity does not mean effectiveness.

• Delivering what was asked does not mean moving the business forward.

Your work must map directly to business outcomes like churn reduction, expansion, activation, onboarding speed, and revenue per account. That shift gives engineering permission to say no to low-value work and yes to the initiatives that actually move the company.

Work measurable by default

Revenue is lagging. By the time you see it move, three other teams have touched the customer journey. To establish clear ROI, you attach leading indicators to every major engineering initiative.

• Feature usage

• Conversion to “aha” moments

• Drop in support tickets

• Faster time-to-value

• Improved activation rates

The only rule that matters: A feature isn’t done until we can see what it’s doing.

This creates early prediction, clean attribution, and a way to kill failing ideas before they burn quarters of engineering capacity.

Engineering initiatives to demonstrate

Instead of pretending you can isolate exact revenue shares, you build direct causal stories between engineering work and business results.

A simple pattern to follow:

• Identify the business goals.

• Commit engineering to specific, outcome-driven initiatives.

• Deliver and report the impact in business language.

Example:

• Increase ARR by 60%

• Reduce churn from 20% to 10%

• Fix the top churn triggers

• Projected revenue lift: +$10M over 12 months

• Engineering cost: low–mid six figures

Two numbers for a ROI-concrete story

You don’t collapse the whole org into one “ROI number.” Split engineering into two economic functions that every business leader already understands:

• Supporting the base.

• Creating new growth.

You reflect those with two ratios.

Engineering Operating Efficiency
How much existing revenue do you support per KTLO dollar?

You estimate the true cost of keeping the service stable: on-call, infra, debugging, support, a slice of salaries, staging environments. You compare that to revenue from customers who were already paying before the period. This becomes your measure of operational leverage.

Engineering Growth Efficiency
How much new revenue do you enable per new-capability dollar?

You take revenue from newly activated paying customers. You amortize your feature development and product investment over a few years so you don’t distort the current period. This becomes your measure of innovation leverage.

These numbers don’t need perfect precision, merely consistency. They show trends, create accountability and help frame engineering as an economic engine, not a cost center.

The traps you avoid

Full attribution credits everything to Sales or Marketing. Fractional attribution turns into political warfare. Causal attribution collapses under noise and overlapping initiatives.

These models hurt collaboration and distort incentives. Your ROI model must be useful and actionable, especially if they seem unfair due to sales departments individual bonuses.

Useful means it guides decisions, aligns incentives, and helps you win resources without creating cross-functional hostility.

CTO Logic

Other highlights 👇

Startup Engineering Team Organisation

Startups tend to cycle through the same team structures as they scale, not because leaders lack imagination, but because each model collapses under its own constraints. Marc Gauthier walks through that progression using an 18-engineer, post-Series A B2B SaaS as the running example. Every organisational model solves one bottleneck while creating a new one. The real skill is recognising when to pivot.

1. Technical Teams → Fast craft growth, constant cross-team pain

Early on, grouping by stack feels natural: frontend with frontend, backend with backend, mobile with mobile. It works until every project needs all three skills.

Works:

• Strong peer support

• Fast craft growth

Breaks:

• Every feature is cross-team

• PMs can’t get clear ownership

• No deep product context

Which leads us to the obvious next step:

2. Squads → Clear owners, faster product work, rising tech debt

So the company rotates to domain-focused squads. Engineers love solving real business problems with a cross-functional team. PMs finally have a clear partner.

Then the bill arrives:

• “Core” engineering work has no natural home

• Framework upgrades, test flakiness, infra improvements get perpetually deferred

• Engineers feel isolated in their stack, overloaded with feature pressure

You get product velocity today at the cost of delivery stability and unowned infra problems.

3. Chapters → Technical quality rebounds, but planning collapses

Chapters (communities of practice) are introduced to restore engineering standards. And they do:

• Tech debt starts shrinking

• Knowledge spreads

• Consistency increases

But product planning takes a hit:

• PMs can’t rely on engineer availability

• Quarterly commitments become fiction

• Squads fight chapters for headcount slices

The pendulum swings too far: meetings loom as resource-management and trying to split an engineer’s time to allocate them partially introduces friction and visibility concerns. Next!

4. Dedicated Core Team → Clarity returns at the cost of silos

To calm the chaos, the company builds a Platform/Core squad and restores predictable product bandwidth.

Reality check:

• Product squads lose key seniors

• Core engineers get stuck doing unglamorous maintenance

• Product engineers disengage from shared technical responsibility

• Two cultures form: “the builders” vs “the fixers”

This allows a growing company to continue delivering. However, the systems and ownership of code becomes brittle and political.

5. One-Shot Projects → Clean on paper, messy in practice

At this point senior leaders become tired and concerned of constant reorgs. The org tries temporary project teams for big initiatives.

Predictable outcomes:

• Timelines slip

• People rotate in/out mid-project

• Burnout spikes

• Work stranded after the team disbands

Shiny simplicity, painful execution.

6. Staff Engineers + Light Chapter Work → The most stable model so far

The company settles on a hybrid:
• Staff engineers roam to unblock the hardest problems
• All engineers spend ~20% on chapter work (without micromanaging allocation)

This works better:

• Staff engineers amplify squads where it matters

• Big upgrades finally ship

• Chapters regain value without dominating planning

• Shared ownership returns

It’s also fragile staff carry enormous load, and hiring strong ones is brutal. This setup works as long as there is meaningful work, until the lack of energy or direction collapses into one of the previous setups, repeating the cycle.

What cycle are you in right now?

Marc G Gauthier

The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem

Adoption gaps with AI coding agents rarely come from tooling, training, or experience level. The real dividing line is that some engineers can externalize context very well, making it easier to “explain” to the machine agents what it is exactly that they care about and work on.

Why some engineers excel with agents

Engineers who do well with AI tools naturally explain their thinking with clarity, they:

• Provide full context beyond shorthands or shortcuts.

• Describe constraints, past decisions, and edge cases.

• Frame prompts the way they’d onboard a new teammate.

They’ve built the habit of making their mental model explicit, so the agent has everything it needs to produce useful work.

Two patterns show up in contrast, in teams that either cannot apply these techniques at all or get stuck past a few prompts:

They understand their own system but can’t articulate it. Years of pattern-matching and intuition mean they rarely had to explain their reasoning, and that muscle atrophied.

They never built a deep model of the system in the first place. Traditional development allowed people to ship code by copying patterns, following templates, and relying on tribal knowledge. With AI, that falls apart because the agent requires clear, accurate explanations.

In both cases, prompting fails because the underlying understanding or communication isn’t strong enough, practiced enough or precise enough.

Make your context visible

Effective practices include:

• Reading the codebase deliberately to build real understanding

• Pair programming to practice explaining decisions

• Architecture reviews that surface gaps in reasoning

• Coding katas focused on narrating intent, not just producing code

• Book clubs and shared learning to rebuild fundamentals

All these skills are learnable, by the way, the wider software engineering community captured these decades ago in Extreme Programming. And not only that, even if your team does not rely on AI agents, these principles and practices have become essential for modern software development.

Agent-driven Development

Engineering Management vs. Project Management

Many confuse engineering management with project management. The overlap makes it easy to see why.

Both involve leadership, planning, and execution. Both drive projects to completion. But their goals, focus areas, and responsibilities differ significantly.

This confusion can lead to hiring mistakes and inefficient workflows.

A project manager ensures a project is delivered on time and within scope. Project management generally refers to managing a singular project. An engineering manager looks beyond a single project, focusing on team growth, technical strategy, and long-term impact.

Strong communication skills and soft skills are essential for both roles, as they help coordinate tasks, clarify priorities, and ensure team understanding—key factors for project success and effective collaboration. Both engineering and project management roles require excellent communication skills.

Understanding these differences is crucial for businesses and employees alike.

Read Here

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , Marc G Gauthier, Norman (for ADD)

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

The Two Jobs of a CPO

When you take on a Head of Product or CPO role, you run into the problem of doing two jobs that don’t naturally reinforce each other. One is operational and cultural. The other is strategic and deeply personal. And if you’re not careful, you’ll pour your energy into the wrong one and suddenly find yourself on shaky ground.

Day one

Your first job is everything people associate with running product:

• shaping product culture

• tightening design, research, and roadmapping

• aligning cross-functional partners

• putting structure around how ideas become shipped software

This work matters. PMs touch almost every initiative in a company, and without the right rituals and expectations, a product org drifts fast. Ten PMs can end up running ten different micro-companies if you don’t anchor them.

But this isn’t the work that determines whether you stay in the seat.

The hidden leverage is in aligning product direction with the CEO. Understanding their instincts, incorporating their ideas appropriately, elevating the best ideas from your team, and making sure product strategy is locked onto the company’s trajectory.

This part is basically an IC responsibility masquerading as an executive role. You can’t delegate it, and you don’t get second chances.

Tension

The cultural side of product can be improved iteratively. You can adjust processes, refine templates, and slowly raise the bar. Strategy doesn’t offer that patience. If your product direction diverges from the CEO’s, even by a few degrees, the consequences come fast. CEOs and boards tolerate many imperfections, but misalignment isn’t one of them.

That’s why so many CPOs get hired for one skill: the ability to build great product orgs while integrating the ability to match the CEO’s strategic sense.

How you actually balance the two jobs

You start by accepting that strategy is the non-negotiable part. If your direction is solid, you can afford occasional imperfections in culture and process.

Build efficiency into the operational side:

• get the templates right

• define the rituals your PMs need

• set expectations early and make consequences fair

• make hiring and interviewing predictable

Be cautious about delegation. Process can’t be handed to someone who hasn’t built product themselves; the nuances are too deep. Your systems need to match your business’ scale, its constraints, its pricing, its risk profile. Your team can debate how work gets done, but where the product is going needs one clear owner. That’s you. Democracies can work if you reach consensus quickly, but no micro-decision is worth a meeting if it’s not aligned with the strategy.

You strengthen strategic alignment by hiring people who “get the plan.” People who spot opportunities on their own, jump on the right problems, and don’t need hand-holding to stay in sync with company direction. When enough of these people exist, strategy scales without you being inside every decision.

Persist, grow

The two jobs aren’t incompatible, they’re just hard to do simultaneously. Many product leaders fail simply because they don’t realize the asymmetry. Your job is to make that tension explicit, communicate clearly with your stakeholders, and show exactly how far along you are on each front. That clarity keeps everyone on the same page, sane and calm while giving you the room to actually succeed day-to-day.

Stay SaaSy

Other highlights 👇

What process inefficiencies have the biggest impact on developer satisfaction?

Engineering leaders often assume any process cleanup will boost morale. The research says otherwise: a study of 191 agile developers shows that only two types of process debt meaningfully move job satisfaction, and together they explain 33.8% of its variance.

TL;DR: Confusion

1. Misaligned processes do the most damage.
When workflows don’t fit how teams operate, this showed the strongest negative relationship with satisfaction. Developers feel dragged by processes that don’t serve the work.
Examples: outdated ceremonies, rigid templates, unnecessary overhead, ineffective meetings, handoff culture.

2. Unclear roles are the next major hit.
Role debt showed the second-strongest correlation. Ambiguous responsibilities, overlapping duties, and fuzzy ownership drive confusion and frustration.

Everything else, e.g. documentation gaps, shaky tools, coordination issues, etc. matter but none of them predict satisfaction once the big two are accounted for. Developers often compensate for them with workarounds. Something to watch out for in your DevEx surveys.

What this means for your team

Process debt is a de-motivator that erodes the baseline conditions needed for developers to feel effective. If your resources are limited, this order of operations is recommended to move the needle:

Process autonomy
Audit where your current workflows create overhead instead of clarity and adapt them to the way your teams actually deliver, not the way they delivered last year.

Make roles explicit
Clarify responsibilities, decision rights, and ownership boundaries continuously, and make changes visible to adjacent peers. Treat role clarity as ongoing maintenance in addition to one-time onboarding whenever someone gets promoted or hired.

Defer the rest when needed.
Documentation, tools, and sync points matter but they’re not the levers that change how people feel about their jobs. Address them once the core friction is gone.

Research-driven Engineering Leadership

Shadow work in engineering teams

A senior engineer wants to step up, lead a cross-team project, and prove they’re ready for staff. Three months later… nothing’s moving. No tickets closed. No visible progress. You dig in and realize most of their time is disappearing into work no one tracks. And every team has this problem.

Anton Zaides illustrates three flavors of shadow work quietly eating your capacity:

1. Invisible production support

All the stuff that never hits a ticket: alerts, ad-hoc questions, support pings, random slack emergencies.
Cost:

• Miss patterns because nothing’s documented.

• Fast hotfixes create stability risks.

• Team spend more time fixing symptoms than the root causes.

2. Glue work

Reviews, mentoring, context-sharing, documentation and other essential-but-unrewarding work senior engineers get buried under.
Cost:

• Burnout doing invisible labor that doesn’t help promotions

• Late on strategic roadmap work from being stuck reviewing everyone’s code.

3. The shadow backlog

The unofficial workstream of PM side requests, engineer-driven “do it right” fixes, quiet refactors, dreaded rewrites and rolling out custom telemetry instead of using grafana.
Cost:

• Capacity planning collapses is out of touch with reality

• Trust breaks between business and engineering, burying when priorities are being neglected

Remote teams

All this shadow work hides in DMs and micro-calls. You know who’s carrying the load from ad-hoc complaints and questions, but your manager doesn’t. Thus when promo season comes, you have no proof or log without conducting investigation. Tools like gathertown and active pairing help level the information playing field, but require structural changes to be effective.

• Make tracking painless so invisible work shows up by default and spread glue work across the team.

• Rotate production support instead of funneling it to the same person.

• Put your shadow backlog on the real roadmap instead of pretending it doesn’t exist (no one said it’s going to be easy!)

Manager.dev

How “AI-native” Engineering Changes What Productivity Means

When development is built for AI rather than just boosted by it, productivity isn’t about doing more—it’s about doing better. The full lifecycle must be redesigned: architecture made modular, telemetry upgraded, reviews reframed, and metrics reshaped. A CTO’s playbook here starts with diagnosing readiness, defining a north star like stable delivery + low rework + AI-quality code, then reorganising teams and guardrails accordingly. The companies that treat AI as an architectural shift instead of a plug-in win; the rest risk hidden debt, chaos and unpredictability.

CTO Playbook

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , ,

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

“Good engineering management” is a fad

Every few years, the leaders in the industry redefine what good management means and then insist the new definition is a moral truth. Will Larson argues that these shifts aren’t moral at all but merely surface market reactions. What leaders are celebrated or dismissed for depends entirely on the economic climate.

In the late 2000s, managers like Larson’s Yahoo lead focused on opportunity and navigation with light empathy, heavy on delivery.

Then came the 2010s, the hypergrowth era, where hiring and retention were everything.

Managers were told to stop coding and coach more, empowering engineers.

Fast forward to today’s post-ZIRP, AI-heavy reality where those same people are now seen as bureaucrats, out of touch with the hands-on pace of leaner orgs.

Each phase reframes the last as misguided with morality paraded to masquerade financial motives. The end of cheap capital and the rise of automation are reshaping what leadership means again. If you mistake these business cycles for universal truths, you’ll find yourself obsolete when the next wave comes.

What Endures Beyond the Fads

He proposes a model of eight enduring management skills. Split into core and growth layers that outlast every trend, they’re the backbone of effective leadership, regardless of whether the industry worships servant managers, player-coaches, or AI orchestrators.

The foundation of every solid manager, Core skills:

• Execution: Delivering results, shipping work, and solving real problems.

• Team: Building an environment where people thrive and expectations stay clear.

• Ownership: Taking accountability even when the system makes it hard.

• Alignment: Keeping stakeholders, peers, and teams synchronized and informed.

what distinguishes senior leadership, Growth skills:

• Taste: Knowing what “good” looks like, technically and strategically.

• Clarity: Communicating decisions and trade-offs so people trust your direction.

• Navigating ambiguity: Turning messy, undefined problems into forward motion.

• Working across timescales: Balancing short-term urgency with long-term stewardship.

Which of these skills the industry values most changes with every cycle. Execution might be the hot ticket today, but taste and alignment were king a decade ago. The only reliable strategy is breadth in developing all eight so you’re relevant when the pendulum swings again.

Playing the Long Game

First, energy management matters more than theoretical optimization. The best work mix isn’t the most “impactful” on paper. What keeps you motivated enough to sustain a 40-year career?

Second, career strategy is about trade-offs: pace, people, prestige, profit, learning. Your priorities shift with your life stage. Leaning on his example, Larson highlights that early on, he worked brutal hours at Uber for learning and prestige, but today family redefines what’s worth chasing.

The enduring lesson is awareness to know which game you’re playing, and why.

Irrational Exuberance

Other highlights 👇

The CTO’s Necessary Friction

A CTO’s real value comes from creating the right kind of friction in the C-suite. Staying agreeable is expensive and you must be the person who protects the long-term technical health of the company, even when that slows decisions or irritates peers.

Many leaders stay quiet to avoid conflict, destroying engineering’s leverage:

• Technical debt absorbs IT balance sheets.

• Engineers lose their time to debt-driven work.

• Annual impact for an engineering budget: 60%+ in wasted capacity.

Being accommodating masks these costs. It also sidelines the CTO at the exact moment technology is central to strategy. Only disciplined executive behavior keeps this ship afloat:

• Obsessing about clarity on strategy, assumptions, and trade-offs.

• Escalating immediately when sales commitments don’t match engineering reality.

• Speaking up the moment something feels off.

• Making sure technical constraints are visible in every strategic discussion.

Between 40–120 engineers, intuition stops working. Tech debt becomes existential and architectural choices carry multi-million-dollar consequences. In this phase, a CTO must be loud, present, and consistently right about technical implications. This is the season where being “difficult” saves the company.

Your job isn’t to be agreeable. Your job is to expose hidden costs, surface assumptions, force explicit trade-offs, and slow the company down when speed creates future disasters. Yes, over time your teams and department heads will mature to take over aspects of this delegate responsibility. All those long-term healthy structures will be a result of targeted friction preventing disaster.

Your team, your CEO, and your company need that friction.

The CTO Substack

Likeable leaders go further

As software engineers grow from individual contributors to technical leads, they face a fundamental shift: success is no longer measured by their own code output, but by their ability to elevate their entire team. Many new technical leads make the mistake of continuing to prioritize technical prowess alone, missing that the role is really about becoming someone people want to work with.

Great technical leadership goes beyond about guarding your time. Staying open, managing priorities honestly, and always putting your team first are key strategies to adopt:

• Always accept discussion invites, even if you need to defer them a week or ask for an email summary first

• Keep a running list of all project ideas, no matter how ambitious. Priorities shift and impossible task might become easy wins the next day

• Replace “I’m too busy” with honest prioritization conversations about what matters most

• Put your team first every single time. Their questions, code reviews, and blockers are always your top priority.

Clear communication becomes your superpower as a technical lead. By recapping meetings in writing, documenting decisions, and proactively announcing changes, you build trust across the organization:

• End every meeting with a written recap sent to all attendees, capturing key takeaways and next steps

• Get every decision in writing, even from casual coffee chats or informal 1:1s

• Proactively communicate when priorities shift, owning the awkwardness with transparency

Perhaps most importantly, great technical leads redirect credit downward:

• Focus on what “we” shipped, not “my team” or “me and my team”

• Praise team members publicly and pass credit directly to them when it’s offered to you

• Keep bug discussions blameless. Multiple people were involved in design and review

• Provide constructive feedback privately, never in public forums

Technical expertise becomes secondary to approachability as you grow. Your path becomes simpler when your team enjoys working with you and external partners don’t dread engaging with you.

LeadDev

What Productivity Really Means When AI Enters the Room

The moment AI starts writing a meaningful share of your code, the usual signals stop telling the truth. A team can ship more changes and still feel slower. Reviews get heavier, cognitive load goes up, and regression risk quietly rises even as output spikes. The work looks faster on paper but feels harder in practice.

The core idea is straightforward. Productivity is not the volume of code or the number of tickets closed. It is how consistently a team moves work from intent to impact without piling up hidden drag. That drag now comes from AI-generated fragments, uneven review quality, rising complexity and rework patterns that rarely show up in traditional dashboards.

The takeaway is clear. Leaders need to watch flow stability, clarity of changes, reviewer load, rework on AI-assisted commits and how often context breaks. These are the markers that show whether AI is creating leverage or creating churn.

Productivity in AI Era

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - Will Larson, , Jack Franklin (Google, c. LeadDev)

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO

Article of the Week ⭐

The price of mandatory code reviews

In software engineering, “every PR must be reviewed” has become dogma. Anton Zaides challenges that rule with new data from 400+ companies and 3,000 engineers using Weave’s productivity metrics and finds that while code reviews do slow teams down, they’re still worth it if you do them right.

Some high-performing startups, like Pylon, now let engineers merge their own code. Reviews are optional and used only for risky changes or onboarding. Their idea is to hire great engineers and trust them by removing bottlenecks. But it’s not all gold that shines, this approach has clear tradeoffs:

• Teams with reviews: ~31 expert hours per dev/month, 3.7 bugs per dev.

• Teams without reviews: ~59 expert hours per dev/month (1.9× faster) but 8.9 bugs per dev (2.4× buggier).

Even after normalizing for output, skipping reviews leads to roughly 25% more bugs per unit of work. So yes, removing reviews speeds you up, but you pay for it in defect density. That’s not all though… let’s take a closer look.

Diminishing returns

Going from zero to some code review dramatically reduces bugs. After about one review per two PRs, the quality gains flatten. Trivial PRs (like changing a log line) probably don’t need mandatory review. The sweet spot is selective reviews by using judgment to balance speed and safety.

Quality reviews > frequent reviews

Not all reviews are equal. Teams doing high-quality reviews (depth, clarity, actionable feedback) ship 38% slower but with 61% fewer bugs. If you’re going to spend time reviewing, make it count. However, the author of the PR is the main person who benefits from this by learning. If most of the code was authored by an AI or someone unable to respond to it, the review is wasted.

Speed still matters

The costliest mistake is doing reviews slowly.

• PRs reviewed within 3 hours → 2.1× higher productivity

• PRs waiting 8+ hours → steep morale drop and velocity loss

The best teams follow a simple rule: review fast unless you’re in the middle of deep focus work.

Culture compounds quality

Engineers who give thoughtful reviews tend to get thoughtful reviews back. Teams with low-effort reviews rarely escape that gravity. Code review quality, like code quality itself, reflects the culture.

Top 10% teams show the paradox in action: they ship 2.7× faster while keeping their bugs per feature 33% lower than average teams. They optimize reviews by balancing the fine edge of speed and quality: small PRs, fast turnaround, high trust, and high context sharing.

Manager.dev

Other highlights 👇

The speed-versus-stability trade-off is a myth. The best-performing teams (“Pragmatic performers” and “Harmonious high-achievers”) achieve both high throughput and high stability simultaneously, while struggling teams often fail at both dimensions.

What are the seven team profiles of engineering delivery performance?

The DORA metrics tell us what’s happening, not why. Two teams with identical numbers might look equally “high performing” on paper, yet one could be a stable, healthy team and the other an exhausted group barely keeping up.

This new 2025 DORA research dives beneath the surface, clustering data from nearly 5,000 developers to identify seven distinct team profiles that reveal the human and systemic factors shaping delivery outcomes.

The Seven Profiles

1. Foundational Challenges (10%): Teams struggling with basic capability gaps and weak engineering practices.

2. Legacy Bottleneck (11%): Constant firefighting due to brittle systems; burnout and reactivity dominate.

3. Constrained by Process (17%): Technology is fine, but process inefficiency creates friction and exhaustion.

4. High Impact, Low Cadence (7%): Great outcomes and strong product performance, but achieved through unsustainable intensity.

5. Stable and Methodical (15%): Reliable and predictable, but sometimes overly cautious or slow.

6. Pragmatic Performers (20%): Balanced throughput and stability, focused on value and learning.

7. Harmonious High-Achievers (20%): The healthiest cluster: high speed, high stability, low burnout, high satisfaction.

This meta-study shatters the old belief that teams must choose between speed and stability. When a team slows down, the cause isn’t always technical. Legacy drag often disguises itself as reactivity and fatigue. Process inefficiency can quietly erode morale, even when the software itself is stable. And heroic, high-impact cultures might produce strong short-term results while silently draining people’s energy.

Diagnosis before intervention

If deployment frequency is down, don’t rush to rewrite systems or enforce new processes. Instead, ask: Which pattern are we living in? Are you fighting legacy complexity, trapped by process overhead, or running on unsustainable effort?

The seven profiles give teams a shared language to discuss these realities. Saying “we’re process-constrained” or “we’re legacy-bottlenecked” opens clearer conversations than vague complaints about being “too slow.” The real work of improvement starts not by chasing better metrics, but by understanding the shape of your system which enables reshaping it so performance and well-being rise together.

Improvement begins when teams stop optimizing the numbers and start addressing which kind of team they are because metrics describe the outcome, but culture and constraints explain the cause.

Research-Driven Engineering Leadership

Why trust, not speed, defines software leadership in the AI era

For decades, engineering leaders have measured success through output like lines of code, sprint velocity, story points. But as Rahul Chandel discovered leading teams at Twilio and Coinbase, that mindset collapses in the AI era. When code can be generated in seconds by AI’s amplification in speed trust into the generated output becomes a headache for many teams.

AI can speed up delivery but without strong systems of review, observability, and safety, it can just as easily amplify risk. The new job of software leaders is to orchestrate resilience across complex human–AI ecosystems in addition to squeeze out more features out of their existing processes.

From Output to Outcomes

When generative AI took over repetitive coding work, Chandel saw output skyrocket at the cost of plummet. What mattered now was how well the system behaved under pressure. At Twilio, he learned to anchor success to service-level objectives (SLOs) and error budgets acting as concrete indicators of reliability tied to customer trust contrasting with delivery cadence. At Coinbase, he brought the same discipline to trading systems, tracking mean time to resolution (MTTR) as the new pulse of engineering health.

Reframing Leadership

AI’s acceleration comes with cognitive overhead. It creates more output to review, more complexity to reason about, and more opportunities for silent failure. Chandel introduced three cultural practices to absorb that complexity without losing safety:

• Tiered review standards for AI-generated code on critical paths raising scrutiny on hot spots.

• Critical inquiry coaching to teach engineers how to interrogate AI output by asking what assumptions it made and where it might break.

• Psychological safety so engineers feel free to question both each other and the machine.

The New Bottleneck: Trust

When his team considered migrating from Redis to Valkey, the technical migration wasn’t nearly as challenging as the orchestration risk. AI could rewrite code, but it couldn’t assess latency trade-offs or plan rollback strategies. The leader’s role was to underwrite trustworthiness: designing phased rollouts, setting risk thresholds, validating monitoring.

CIO.com

Are your code reviews missing the story behind the code?

Most code reviews miss the bigger picture. Reviewers see diffs, not context—why a change was made, what it impacts, or how risky it is. That lack of narrative turns reviews into guesswork and slows teams down. AI can close that gap by generating contextual summaries that explain intent, highlight dependencies, and surface hidden issues before humans even start reading the code. It makes reviews faster, cleaner, and more focused. Typo’s new AI-generated PR summaries bring exactly that context into your workflow

Learn more

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - , , Rahul Chandel (for CIO)

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

Subscribe now

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.

Share groCTO