Less Hype, More Judgement
From product strategy to AI tooling and transitioning to management, and more, in this week’s digest.
AI is reshaping software, but human judgment still anchors the work, and simplicity and restraint beat complexity and hype.
This week I’m sharing ten pieces that each dig into the challenges engineering leaders face, from adapting to AI’s influence on existing practices to navigating the emotional transition from engineer to manager.
It’s getting harder to separate hype from the things that work, and these pieces help make sense of it all, whether that’s redefining workflow automation or understanding what it really means to move into a managerial role.
1. Navigating Post-Acquisition: Mastering the Transition Service Agreement
Sergio Visinoni digs into what happens right after one company buys another, and he zeroes in on something called the Transition Service Agreement (TSA). It spells out what the buyer and seller each owe each other after closing. Visinoni points out that a good TSA needs to nail down four things: what’s covered, how long it lasts, who’s responsible for what, and who pays for it. Get those right, and you avoid a lot of risk and confusion down the road.
He also looks at the Share Purchase Agreement (SPA), which handles the stuff that has to be sorted out before the deal can go through. During due diligence, you tend to uncover problems, and the SPA is where you lay out how those get fixed so the buyer doesn’t end up holding the bag. For engineering leaders, that basically means protecting your team from nasty legal or operational surprises you didn’t see coming.
Why It Matters:
For engineering leaders, mastering these agreements is crucial to managing post-acquisition challenges effectively and ensuring a smooth transition, avoiding costly disruptions and ensuring business continuity.
Read This If You’re Interested In:
Understanding post-acquisition responsibilities and risks
Managing dependencies and integration post-M&A
Crafting detailed agreements to safeguard your company
2. Should We Change The Way We Review Code?
Where do engineers fit in the reality where AI is changing the way we build software? CTO Rachel Laycock asks these questions in this LeadDev video. One of her bigger points is that we need to rethink code review. She argues it might be outdated, since it was originally built for open-source contributions and not for how teams actually work today.
As AI keeps changing how code gets written, Laycock points to a couple of growing problems: cognitive debt piling up, and the fact that a lot of traditional engineering practices just aren’t built to handle the way we work now. She also gets into how the roles of senior and junior engineers are shifting, and why people need to adapt their skills to keep up with what’s being asked of them.
Why It Matters:
In an industry facing rapid AI-driven changes, engineering leaders must reconsider traditional practices like code reviews and adapt to ensure long-term sustainability and innovation in their teams.
Watch This If You’re Interested In:
Rethinking conventional code review methods to suit modern development
Adapting leadership roles as AI becomes integral to development processes
Proactively managing technical debt and cognitive load in fast-paced environments
3. Harness Lab Insights on Workflow Automation
Harness Lab ran a bunch of automated workflow experiments, testing everything from simple single-agent setups all the way up to full swarms. They put each one to work on the same pharmaceutical supply chain task and measured how efficiently it got the job done. What came out of it were some useful insights into how a system’s complexity relates to how precisely it handles a task.
The piece talks about how more complexity doesn’t automatically mean better results. A lot of the time, simpler designs that route tasks cleanly ended up beating the more complicated systems, especially when the task had clear boundaries. The experiments show that being smart about your framework and building workflows that can adapt can really raise the bar for what good automation looks like.
Why It Matters:
Understanding when and where task complexity adds value is critical for engineering leaders aiming to maximize team productivity and scalability. Leaders who grasp this balance can better choose and implement automation strategies that meet their organizational needs.
Read This If You’re Interested In:
Refining automation strategies for efficiency
Understanding complexity in workflow architectures
Leveraging task precision against structural complexity
4. AI Won’t Replace Software Engineers: The Resilient Sandwich Model
You hear and read it everywhere: AI is coming for software engineer jobs. But is it true in real life? Despite all the worry, AI isn’t wiping out these jobs. What the evidence shows is that AI speeds up the execution part of the work, but the decision-making and the delivery still need a lot of human involvement. And the layoffs people keep blaming on AI usually have more to do with business strategy than with what AI can do.
Arvind Narayanan and Sayash Kapoor propose a helpful way to think about this: the “decide-execute-deliver” sandwich. AI makes the coding part faster, sure, but it doesn’t touch the important human work on either side of it. Engineers are still the ones figuring out what to build in the first place, and making sure what ships meets the bar.
As AI keeps getting better, it’s worth remembering that the demand for software keeps growing too, and that tends to mean more engineering roles, not fewer.
Why It Matters:
Understanding AI’s limited effect on job displacement helps engineering leaders focus on leveraging AI for productivity while safeguarding essential human roles, ensuring a seamless balance between automation and human expertise.
Read This If You’re Interested In:
Exploring why AI can enhance coding without reducing engineer demand
Understanding implications of AI on software engineering roles
Aligning AI-driven productivity with strategic human oversight
5. How Should Engineers Navigate AI Opinions and Find the Middle Ground
The conversation about AI’s impact on software development tends to split into two camps: some people see it as a game-changer, while others write it off as just another tool. James Stanier makes the case that engineering managers should find a middle ground. His point is that the real question isn’t whether you’re optimistic or skeptical, it’s whether your opinion comes from actually using the stuff yourself or from just going along with what everyone else is saying.
His advice for leaders is to build an environment where people feel free to stay curious and experiment, without being pushed to take a particular side. When you do that, teams can explore what AI is really capable of in a meaningful way, and decisions end up grounded in evidence and real experience rather than identity or ideology.
Why It Matters:
Understanding the nuanced perspectives on AI helps engineering leaders foster informed discussions and guide their teams through evidence-based exploration. Encouraging a culture of experimentation prevents the pitfalls of unverified enthusiasm or unexamined skepticism.
Read This If You’re Interested In:
Exploring balanced perspectives in AI adoption
Understanding the impact of AI on team dynamics
Fostering a culture of experimentation and informed opinions
6. Adapting to AI: Why Semantic Layers are Crucial Today
Madison Mae talks about how she changed her mind on semantic layers, and now sees them as really important tools in this new AI-driven world. She used to think of them as low-value busywork for data teams, but these days they do something essential: they give AI tools the context they need and make sure metrics get calculated the same way every time, which matters a lot when you’re making real business decisions off that data.
She also points out where the current tools fall short. Things like dbt’s semantic layer, Snowflake Semantic Views, and Cube all have limits when it comes to connecting business knowledge with the underlying data. So Mae introduces ktx, an open-source tool that pulls together different sources like Slack, Notion, and BI tools into one solid context layer for AI agents, which helps with accuracy across the board.
It’s an interesting piece if you’re trying to figure out how to give AI tools the business context they need to produce numbers you can trust.
Why It Matters:
Semantic layers are now indispensable for engineering leaders navigating AI integration, as they ensure precise and consistent definitions across data sources, which is crucial for informed business decisions.
Read This If You’re Interested In:
Exploring AI’s role in improving data-driven decision-making
Bringing together business knowledge and data for AI tools
Understanding the benefits of new open-source semantic tools like ktx
7. The Race to Become the Agent Clearinghouse
Back in the SaaS era, the goal for a lot of companies was to become the system of record. You got woven into people’s workflows and you held onto their critical data. That same idea is now carrying over into the AI era, except the prize has changed. Jamin Ball argues that now it’s about being the clearinghouse for agents. So when you look at companies like Salesforce and Microsoft, they’re not just fighting over whose model is better, they’re fighting over who gets to be the central authority for all these autonomous agents.
The push to become the clearinghouse is really about grabbing strategic real estate, making yourself indispensable when it comes to managing permissions and audit trails. That’s a shift from governing the data to controlling the permissions, and it suggests the battleground in software is going to keep moving. Going forward, it’s the agents and the governance frameworks that will decide who lands that all-important central seat in enterprise software.
Why It Matters:
Understanding the evolution from systems of record to agent clearinghouses provides engineering leaders insight into the future landscape of enterprise software, emphasizing the necessity to adapt strategies to maintain competitive advantage in AI-driven environments.
Read This If You’re Interested In:
Navigating the emerging landscape of autonomous agents in enterprise software
Exploring strategic positioning for startups in AI ecosystems
Understanding the shift from data governance to permissions management
8. Does Vibe Coding Have a Place in Cybersecurity?
With vibe coding, instead of writing everything by hand, you can use plain language to tell an AI system to build, change, or deploy software. Austin Miller talks about vibecoding in the cybersecurity context. In cybersecurity, this can speed up work like vulnerability research and building integrations, but it also raises some real concerns, since it can introduce vulnerabilities and open up new ways for attackers to get in.
So now security teams have a challenge in front of them: finding open-source tools that keep AI-assisted development secure and transparent. A few that fit the bill are OpenHands, Continue.dev, and Aider, which support the kind of collaborative, secure development setups these teams need. They let security folks keep control and visibility while still getting the benefits of AI.
For engineering leaders, the big question is how to fit these tools into a secure development lifecycle.
Why It Matters:
Understanding and leveraging vibe coding in cybersecurity provides productivity gains while maintaining security standards - a critical balance for engineering leaders aiming to optimize modern software development environments.
Read This If You’re Interested In:
Implementing AI in secure development environments
Balancing productivity with cybersecurity needs
Leveraging open-source tools for enhanced software workflows
9. Decoding Product Success: Mark Pincus on Innovation and Knowing When to Let Go
Mark Pincus shares a framework for building products that he credits with Zynga’s success. He calls it “proven, better, new.” The idea is to trust your gut as a human, while still pushing on ideas that genuinely break new ground. His big point is that you’ve got to understand what people actually want and validate your product decisions before you go chasing some grand vision.
He also makes an interesting case for being less ambitious as a way to reach bigger goals, and explains why checking in on your projects regularly can lead to real breakthroughs. Part of that means being willing to kill your “B+” projects and put your energy into the ideas that could turn into something great, even if you have to start embarrassingly small.
Why It Matters:
Mark Pincus’s insights give engineering leaders a fresh lens on product development, balancing instinct with actionable strategy – crucial for fostering innovation and achieving product-market fit.
Watch This If You’re Interested In:
Redefining product development with proven, better, new frameworks
Recognizing when to let go of ‘B+’ projects to focus on genuine innovation
Exploring the delicate balance between ambition and practical iteration in leadership
10. The Hidden Cost of Moving from Engineer to Manager
The move from engineer to manager means letting go of your identity as an engineer, and that’s something people often miss, or mistake for a personal failing. Ryan Murphy points out that while companies tend to frame it as switching tracks rather than getting promoted, they rarely talk about the personal toll that comes with it.
One of the hardest parts is that your wins become a lot less visible. With coding, you get clear proof that you did something. Management wins tend to be quieter, and they don’t give you that instant hit of satisfaction engineers are used to. Murphy makes the case for building yourself a new scoreboard, one that helps you value the behind-the-scenes accomplishments that really count.
And if you skip the grieving process, it tends to catch up with you. Murphy’s advice is to lean into the new role instead, so you don’t turn into the kind of manager people want to get away from, the one who clings to their old expertise at the expense of the team.
Why It Matters:
This insight reveals the emotional challenges behind managerial transitions, showing engineering leaders how to embrace their new role effectively. Understanding this transformation aids in preventing common pitfalls and promotes better team dynamics.
Read This If You’re Interested In:
Navigating the emotional cost of transitioning to management
Rethinking success metrics for managerial roles
Identifying and avoiding technical micromanagement
Good work doesn’t market itself
The founders, engineering leaders, and CTOs I talk to are building something real, and almost no one knows 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 to be referenced - thanks! An interesting article that I’ve shared with our readerships.
Thanks for featuring my article on semantic layers 🙌🏼 everyone will soon know what they are 😉