How to Beat Decision Fatigue | Exec Engineering #182
Also: Why your org structure is making decisions for you, what separates teams that ship from teams that demo, and why the strongest managers are often the hardest to reach.
Hey👋
Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.
I hope this edition brings you value.
The Digest
Using AI to improve developer onboarding (Laurie Barth / LeadDev)
Laurie Barth used AI to onboard herself when she joined a new team. She was contributing faster than she would have been with a classic onboarding, but she hit a wall sooner than expected. AI helped her navigate the codebase without actually understanding it. For hiring managers, that tradeoff is worth thinking about carefully before encouraging new hires to fully self-onboard with AI.
Your Team Structure Is a Constraint (Aviv Ben-Yosef)
You can swap out your processes, your tools, and your rituals. But if the underlying structure stays the same, you’re rearranging furniture in a room with the wrong dimensions. The room is the problem. And the tricky part is that when you’ve always lived in that room, you stop noticing the walls.
Making sure a strategy happens with Coherent Actions and ad hoc teams (Aleix Morgadas / Engineering Strategy)
Aleix frames strategy as a loop, not a waterfall. Most leaders diagnose the problem, set a direction, hand it to the team, and walk away. But execution always surfaces new information that didn't exist in the planning phase. If that never makes it back to the people who set the direction, the strategy keeps running on outdated assumptions until it's too late to fix.
Bias Toward Action (Addy Osmani)
Many people hear "bias toward action" and think it means shipping fast and fixing later. It doesn't. The version worth actually using comes down to one thing. Take the smallest step that produces real feedback, and make sure being wrong is survivable. The teams that actually move fast have feature flags, practiced rollback procedures, and monitoring that catches problems in minutes. They move fast because they've made it safe to move fast, not because they're comfortable with breaking things.
Engineering Maturity is all you need (Govind Krishna Joshi)
Shipping an AI feature takes a weekend. Figuring out why it's falling apart three weeks later can take months. Govind lays out a maturity ladder: start with documentation and repeatable deployments, add tests and evals, then build observability that captures every LLM interaction in full. Each level compounds on the last. The teams that climb it early are the ones that can actually improve their product instead of just restarting the loop.
How to Beat Decision Fatigue (Phil McKinney)
The most underrated leadership skill is knowing when to stop making decisions for the day. Not because you’re lazy, but because the version of you at 8 pm is measurably worse at this than the version of you at 9 am. Pretending otherwise is costing you.
The Unreachable Engineering Managers (Anton Zaides / Manager.dev)
The most technically strong managers are often the hardest to reach. Their opinions matter, their context is irreplaceable, and every hour an engineer waits is an hour of delayed or compromised work. The system the author uses is simple enough to start tomorrow. One hour SLA on direct messages, twice a day on channels, and a habit of asking whether the message should have reached you at all. If the same questions keep coming, that’s a signal to hand that area to someone who can own it.
Should managers become hands-on again? (João Alves / At the Terminal Prompt)
There’s a version of engineering leadership that looks like staying informed. Reading reports, attending briefings, and delegating exploration to a champion inside the company. João argues that’s not enough anymore. The adaptation window is too small, and the speed is too fast. If you haven’t opened a terminal and built something yourself, you don’t actually know what you’re leading your team toward.
Dialog
Meg Adams, Senior Director of Engineering for NYT Cooking at The New York Times, explains why engineers who won’t demo their work aren’t disengaged, they’re responding to culture.
In our latest Dialog, Meg shares why centralization vs. decentralization is a pendulum leaders must guide (not “solve”), how she scaled Etsy’s data team by making everyone responsible for the health of the group, and why demo reluctance is a safety issue, not a motivation problem.
Check it out here:
More reads
9 Observations from Building with AI Agents (Tomasz Tunguz)
Thin Is In (Ben Thompson)
Extremely Lazy and Immensely Curious (Michael Lopp)
How to Work With Anyone (Deb Liu)
Don’t Accomplish Everything (Kent Beck)
This digest is supported by Gemography.
Support your engineering team with remote high-ownership engineers from Africa and LatAm, on demand. Meet precise matches for your stack and culture under 48h.
About Exec Engineering
I’m Yassine 👋 I spend a big chunk of my time digging into engineering management and talent acquisition, especially where the two overlap. I share the most interesting resources I come across in this newsletter, all curated by hand.