Why AI Makes Bad Engineering Teams Worse | Laura Tacho, CTO, DX
My Dialog guest this week is Laura Tacho, Chief Technology Officer at DX, a leading developer intelligence platform. Laura is a co-author of the DX Core 4 framework, a unified approach to measuring developer productivity that combines DORA, SPACE, and DevEx.
Before joining DX, she led engineering teams at CloudBees, Aula, and Nova Credit. She has coached engineering leaders at companies including GitHub and Pfizer.
Laura shares her research and insights on developer productivity at lauratacho.com and through her course on measuring team performance. She has also been a key speaker in conferences like LeadDev and Craft Conference.
Takeaways
Being stuck in engineering details as a CTO or VP signals you need to delegate more or build skills in your eng leadership team.
Your first team is your peers at your level, not your direct reports. Moving strategic projects forward requires coordinating with people who have your same influence.
AI amplifies whatever system you already have. Teams with solid practices see fewer production failures after adopting AI, while dysfunctional teams see more failures.
AI tools focus on optimizing code authoring, but research shows the real bottlenecks are meetings, context switching, and CI wait times, where AI investment could actually move the needle.
Yassine: You are CTO at DX, while also coaching other engineering leaders. Has there ever been a time when you made a decision that went against the advice you normally give leaders?
Laura: This happens regularly, which might be surprising for some folks to hear. Even at the exec leadership level, the answer to most questions is a nuanced “it depends.” There are a couple rules that I typically don’t break regardless of the situation—like no “shit sandwich” feedback, be clear and direct, and giving enough detail isn’t the same as micromanagement—but for complex strategic decisions, we need to tailor our approach to the specifics of the situation, and sometimes that means making a totally different choice.
In my work at DX and in my exec coaching, we rely on data to make decisions as much as possible. I might make a choice that doesn’t line up with my typical approaches, but I always make sure there are data points so I can quickly see if I’m getting the result I intend to.
Yassine: You’ve said you had to stop thinking “I’m an engineering leader” and start thinking “I’m a business leader.” What does that shift mean in practice?
Laura: Most engineering leaders make the mistake of only looking down into their engineering teams, when they should be looking outward to their peers. Your “first team” are those people who are solving problems at the same level as you. If you’re a manager, that means your first team is your fellow eng managers, not the people who report to you. I’m not suggesting that you ignore your own team, but to move forward with strategic, cross-cutting projects, you need to coordinate with other folks at your level with your same level of influence.
This just amplifies as you move up in seniority. As a CTO or VP, you should be spending the majority of your time with your partners in product and on the go-to-market side, figuring out engineering’s role in hitting company goals. Then take that information and go back to your own eng leadership team and work on execution.
If you’re stuck in engineering details all day, that’s a signal that you either need to delegate more effectively or you’re missing skills on your eng leadership team that you need to coach up. You can’t have a business impact if you’re not working across the business—and VP and CTO roles are business leadership roles, not operational engineering roles.
Yassine: You argue that AI rewards teams that invested in developer experience (DevEx) early. What’s the biggest gap you see now between companies that made this investment and those that didn’t?
Laura: AI is an amplifier. Companies and teams that had solid engineering practices prior to AI are seeing better results because they already have resilient systems that can handle the increased volume and frequency of changes, and they can detect anomalies (and fix them) before they become customer-facing issues. On the other hand, organisations that had a lot of dysfunction and bottlenecks are seeing those problems get worse with AI.
For example, in terms of quality, we are seeing some organisations cut down customer-facing failures by half. At the same time, there are some companies that now have twice the amount of failures in production with AI. The same goes for code maintainability. AI impact is largely a factor of the system where it’s introduced, and it’s not a silver bullet.
Yassine: In light of all conversations around AI in engineering, what aspects do you think we are not talking about enough?
Laura: It makes sense that we started on code authoring as the first surface area for AI. Copilot was on the scene early, and now we’ve got a broad selection of tools for AI-assisted authoring. At DX, we have millions of data points about what really causes friction in the development process. It’s almost never the code authoring process. Meetings, interruptions, context switching, poor build and test tooling, CI wait times—these are the real bottlenecks.
Some companies are aiming AI at these problems to solve them, and they’re seeing great results. For example, using AI during feature planning, and then getting AI tools in the hands of designers and PMs so they can do prototyping independently and much faster. This drastically accelerates development workflows in some companies.
The same goes for build, test, and running prod systems. As we start to mature in adoption of AI coding assistants, we’re going to see the conversation refocus around other parts of the SDLC, and I’m really interested to see how this takes shape.
📚 Laura Tacho’s Go-To Resources:
3 people you follow and recommend:
Andrew Boyagi, Customer CTO at Atlassian. He’s the person I go to for deep conversation on DevEx.
Lani Assaf from Anthropic for her real practical advice on AI outside of just coding.
Jennifer Riggins for keeping a pulse on what’s happening in the industry.
A podcast I make time for:
Engineering Enablement. Focused on developer productivity and leading high-performing teams. I always listen, even if I’m the host.
Newsletters I rarely skip:
Books that shaped my thinking:
An Elegant Puzzle by Will Larson is my go-to when I need the right vocabulary to explain why something is happening in an org. Orgs are systems, and he explains it so well.
Thank you Laura for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.