The Wiring Problem
11 reads on the connections that decide whether a system, a team, or a chart holds up.
Almost every pick this week traces back to the same question: what’s actually connected to what, and does anyone agree on why.
Coupling, handoffs, context graphs, and messaging systems are just different names for the same problem: a dependency nobody named on purpose always resurfaces later as friction. This week’s ten writers went looking for the wiring worth tracing before it snaps.
1. The Blurring Line Between Forward Deployed and Product Engineering
In this Q&A, Richard MacManus speaks to Natalie Meurer, who leads agent engineering at Sierra.
They discuss how forward deployed engineering is redefined by accountability rather than skill set, emphasizing the convergence of customer-facing roles with technical responsibilities. Natalie Meurer of Sierra highlights its evolving nature in AI industries, blending system integration with customer operations knowledge.
As the lines blur between product and forward deployed engineering, versatile engineers adept in both customer insights and product development gain importance.
Why It Matters:
Understanding the shift towards forward deployed and agent engineering helps leaders anticipate changes in team roles, ensuring organizations remain agile and responsive to customer needs in AI-driven contexts.
Read This If You’re Interested In:
Rethinking how customer-facing and core engineering roles divide up
What “agent engineering” actually means as a discipline
Hiring generalists who can hold both technical and customer context
2. The Wire Between a Manager and the Actual Codebase
Karol Wójciszko tackles the “should managers code” debate with a specific number: 5 to 10 percent of a week, not to ship anything, but to keep a working line to what the team actually deals with day to day.
He backs the number with a full system for picking safe tasks and using AI to close an unfamiliar stack’s knowledge gap. But the real argument is about what a manager’s technical closeness actually is: a dependency like any other, easy to let go of, costly to rebuild once it snaps.
Why It Matters:
Managers who drift completely from the stack lose the ability to ask good questions in planning and to push back credibly on an estimate.
Read This If You’re Interested In:
A concrete, protected weekly system for staying hands-on as a manager
Using AI to learn an unfamiliar stack without pretending to be its expert
What actually gets lost first when a manager drifts from the codebase
3. The Handoff Tax Nobody Puts On a Roadmap
William Cheng talks to Muddassar Shaikh, SVP of Engineering at GoodRx, who envisions a world where the traditional handoffs in engineering – from product specs to design to development – are minimized or even eliminated.
Shaikh’s read is that AI is already diffusing different roles so one person can play multiple parts, and he’s chipping away at specific handoffs at GoodRx one at a time, without letting the bar for product quality slip in the process.
Why It Matters:
The handoffs between roles have always been where information leaks and time disappears. AI’s real payoff shows up when you go after the handoffs directly, not just the typing.
Read This If You’re Interested In:
Identifying which handoffs on your team are pure translation waste
Strengthening review and testing as coding gets faster
Managing a team that now includes both humans and agents
4. How Anthropic Builds Teams Around AI Instead of Bolting It On
Speaking with Gregor Ojstersek, Katelyn Lesse, Head of Platform Engineering at Anthropic, reveals how an AI-native approach seamlessly integrates AI into engineering workflows.
At Anthropic, AI is not merely an additional tool but an integral part of every process, enabling engineers to achieve more with fewer resources while maintaining traditional team structures.
The organization places a strong emphasis on flexible roles and shared responsibilities, like testing, to accelerate development without sacrificing quality.
Why It Matters:
For engineering leaders, understanding how to integrate AI into team workflows can drastically increase efficiency and project throughput. Embracing AI-native methods ensures teams can focus on impactful work rather than being bogged down by implementation bottlenecks.
Read This If You’re Interested In:
What “AI-native” means beyond tool adoption
Why PM headcount might need to grow, not shrink, as coding speeds up
Structuring cross-functional teams for AI-accelerated shipping
5. The Five Kinds of Coupling You’re Probably Not Naming
Coupling isn’t inherently bad, it’s essential for software systems. The issue arises with unstable and unintentional coupling, which can make a system costly and complicated to change.
Dave Farley, drawing on Michael Nygard’s framework, identifies five types of coupling. Understanding these different types allows engineering leaders to strategically manage them, choosing what to accept and where to focus mitigation efforts.
Farley emphasizes the importance of conscious design choices and fast feedback mechanisms to manage the risk of coupling, advocating for approaches like continuous integration.
Why It Matters:
Engineering leaders must understand and manage coupling to maintain adaptable systems, ensuring that software remains flexible and cost-effective over time.
Read This If You’re Interested In:
Naming the specific type of coupling causing your slow changes
Deciding which forms of coupling are acceptable trade-offs
Designing systems around intentional, not accidental, dependencies
6. Product Management’s Value Was Always Episodic, and AI Just Made That Obvious
Despite product management’s global establishment, executives often question its tangible value, stuck between investing heavily and seeing ambiguous returns. Abrar Abutouq reveals that executive stakeholders are skeptical about the exact impact of product management on revenue and ROI, causing persistent dissatisfaction from both sides of the table.
The crux of the issue is that PM’s value tends to be episodic rather than continuous, often peaking during periods of significant change or strategic uncertainty.
AI could reshape the industry by converting traditional product roles into more specialized, fractional ones, forecasting a future where companies employ a few high-level PMs supported by AI. This model could better align PM activities with actual strategic needs, thus clarifying PM’s value in times of organizational change.
Why It Matters:
Understanding AI’s potential to redefine product management offers engineering leaders a way to optimize their teams by focusing on high-impact strategic decisions rather than constant operational tasks, revealing a more efficient and valuable model for organizational design.
Read This If You’re Interested In:
Separating a PM’s coordination work from their genuine strategic value
Reassessing PM staffing as AI absorbs execution tasks
Building judgment, not just output, into how you evaluate product roles
7. Kafka, RabbitMQ, or SQS: The Question Is Never Which One Wins
Ashish Pratap Singh lays out something every backend team eventually runs into: most systems need one service to hand work off to another asynchronously, and Kafka, RabbitMQ, and SQS all move messages from one place to another while being built on fundamentally different ideas about how messaging should actually work.
Kafka provides high throughput with replay capabilities, RabbitMQ excels in flexible routing and low-latency delivery, while SQS simplifies management with AWS handling the infrastructure.
Picking a messaging system by reputation instead of by pattern is how teams end up fighting their own infrastructure a year later.
Why It Matters:
Understanding the strengths and limitations of Kafka, RabbitMQ, and SQS allows engineering leaders to optimize backend architectures, ensuring systems are scalable, reliable, and efficient in handling asynchronous communication tasks.
Read This If You’re Interested In:
Matching messaging patterns to the right underlying tool
Understanding when a hybrid messaging architecture makes sense
Avoiding the cost of an infrastructure choice that fights your use case
8. Why That Beautiful Chart Might Be Lying to You
Michał Poczwardowski examines why correlation does not imply causation, urging leaders to look beyond attractive data visuals and question underlying assumptions.
He critiques the common trap of spurious correlation, using engaging examples to differentiate between evident connections and coincidental patterns. To discern true causality, Poczwardowski advocates for methods like isolation, chronology, and systems thinking, which can map out the intricate web of influences affecting outcomes.
Why It Matters:
Understanding the difference between correlation and causation can prevent misguided decisions driven by misleading data interpretations. Engineering leaders should actively interrogate data narratives to ensure strategic decisions are grounded in reality rather than correlation mirages.
Read This If You’re Interested In:
Spotting spurious correlations before they shape a roadmap
Using systems thinking to find the real driver behind a metric
Building a habit of questioning data before acting on it
9. Who Builds the Judgment When Juniors Skip the Struggle
James Stanier asks a question that’s easy to dodge when AI is shipping so much so fast: if AI is absorbing the small bugs and fixes that used to train junior engineers, who ends up with the judgment senior engineers used to build through years of mistakes. His answer isn’t to pull AI away from juniors. It’s more deliberate than that.
The dynamic of engineering teams is shifting as AI becomes more involved in day-to-day operations. Engineering leaders must be conscious of where judgment gets built and reinforced.
Why It Matters:
This approach matters because it acknowledges the balance between leveraging AI for efficiency and the core need for engineers to develop critical thinking skills. Engineering leaders should ensure that their teams not only meet deadlines but also grow future leaders who possess strong judgment capabilities.
Read This If You’re Interested In:
Protecting low-stakes learning reps for junior engineers in an AI-heavy workflow
Rethinking what mentorship looks like when AI does the first draft
Planning your talent pipeline for the next decade, not just this sprint
10. Your AI Tools Are Only as Smart as What They Write Back Into
Arnab Bose, Asana’s Chief Product Officer, has a blunt diagnosis for why enterprise AI spend keeps producing flat productivity numbers: people are getting access to a genius-level model, but they’re chatting with it individually. None of those decisions make it back into anything that would create a compounding benefit for the team.
The durable advantage isn’t the model underneath your tools. It’s whether your team’s decisions are actually being captured somewhere, instead of resetting every time a chat window closes.
Why It Matters:
Engineering leaders must recognize that AI’s true value comes from system-wide integration rather than isolated usage. Collective intelligence through a shared context graph accelerates learning cycles and delivers lasting productivity gains.
Read This If You’re Interested In:
Designing feedback loops that make your AI tools smarter over time
Choosing shared infrastructure over individual AI productivity hacks
Evaluating AI vendors on context architecture, not just model quality
11. What Basecamp 5 Reveals About Building Fast With AI
David Heinemeier Hansson explains how AI now initiates most tasks, allowing for faster iteration and design autonomy. Despite these benefits, challenges arise with AI’s inability to question assumptions, sometimes leading to technical debt.
As AI progresses, the team navigates the intricacies of balancing productivity with code quality. David highlights that while AI can rapidly generate output, the end result may not always align with long-term architectural goals.
In an industry awash in AI fervor, Jason Fried emphasizes the need to cater to a segment uninterested in AI as the focal point of product design.
Why It Matters:
Fast output and good output aren’t the same thing, and AI is very good at making that distinction harder to see in the moment.
Read This If You’re Interested In:
Where AI actually helps versus where it just moves the mess downstream
Keeping architectural decisions in human hands as generation speeds up
Balancing AI enthusiasm with a product philosophy built on restraint
Good work doesn’t market itself
The founders, engineering leaders, and CTOs I talk to are building something real, and people don’t always know about it.
The work is good. What’s missing is the machinery around it: content strategy, advertising, outreach, brand development.
That machinery is what took Thriving In Engineering from a newsletter to client conversations, speaking engagements, podcast appearances, collaborations with other industry leaders. None of it happened on its own. My team built it.
Now they’re working with others in the same position. If that’s where you are:
Great compilation, thank you for noticing me ⚡️⚡️⚡️
Thanks for the shoutout!
I appreciate the whole compilation.