If AI helps teams build faster, who helps them build better?
Notes from LDX3 on leadership pressure, principles, culture, incidents and the future of quality engineering.
A few weeks back, I was lucky to attend LDX3 in London, hosted by LeadDev. It is an engineering conference for engineering leaders, including team leads, engineering managers and senior individual contributors.
As with most engineering conferences at the moment, AI was a major theme.
But what stood out to me was not simply that AI helps teams build faster. It was that the challenge of building high-quality products may become greater.
Teams can now create more output more easily. But do they have the principles, feedback loops and learning systems in place to make that output valuable?
These are the five talks in particular that helped me think this through.
For paid subscribers, I’ve also shared the work behind it: The notes behind “If AI helps teams build faster, who helps them build better?”. That includes the fuller notes from the talks that informed this post.
If you find this kind of Quality Engineering thinking useful, you can subscribe for free to get future posts in your inbox. Paid subscriptions help me spend more time turning notes, talks and messy ideas like this into practical reflections for testers, quality engineers and engineering leaders.
AI is increasing leadership pressure
Scott Carey (Editor at LeadDev) shared some interesting insights from 600+ engineering leaders across the industry. A trend that seems to be emerging is managers not only leading people, but also actively contributing to the codebase using AI tooling to help them. With this being framed as the player-manager model.
One example shared was an organisation looking for a manager who would spend 75% of their time on hands-on development and 25% on leading the team.
I can see how this might work if the team is senior, stable and able to manage itself. But the moment people issues appear, especially personal issues that affect someone’s work, that balance changes quickly. Which makes me wonder how realistic that 75/25 split is. If the manager is spending most of their time building, where does the people work go?
AI may make it easier to generate code, tests, documentation or review comments. But it does not remove the need for people who help teams think clearly about risk, uncertainty, trade-offs and system behaviour.
For quality engineering, the role may become less about correcting quality issues after they appear and more about helping teams build the mindset, practices and tools that make better quality more likely.
Principles only matter when they change behaviour
Manogna Machiraju’s talk The shadow culture: Why engineering principles fail under load showed how engineering principles are well-intentioned, but if they don’t change day-to-day decisions, then they are just slogans.
Many people will agree that principles like “quality first” or “disagree and commit” are things they value. But how they actually affect people’s behaviour is less clear. For them to become valuable, they need to influence how people make decisions.
Some people may intuitively understand a principle because they have lived experience of what it means. For example, one person might interpret “quality first” as writing unit tests for the code they change. Someone else might interpret it as prioritising bugs reported by end users. And if someone does not know what “quality first” means in practice, they may simply ignore it.
This is what Manogna found at first. The principles they initially chose had little effect on behaviour because people did not know what they meant in day-to-day work.
To change this, her team applied four lenses to each principle:
Value - Does it reduce risk and improve outcomes?
Usability - Does our business situation allow this?
Viability - Is it easier than the shortcut?
Feasibility - Do we have what it takes to do this?
What this did was help teams stress-test each principle.
It moved the conversation from “do we agree with this?” to “what would this actually look like in our context?”
From a quality engineering perspective, principles like “quality first” or “build quality in” start to become useful when they influence planning, pull requests, testing, release decisions and incident response.
Without that translation into behaviour, they remain abstract.
Productivity gains do not guarantee cultural change
Randy Shoup’s talk We doubled engineering productivity at eBay, but couldn’t change culture described how they used a fairly standard DevOps playbook: removing bottlenecks, reducing build times, adding automation throughout the development pipeline and streamlining processes.
They used DORA metrics to measure progress, and the work doubled engineering productivity. Teams moved from medium performers, releasing less than once every one to six months, to high performers, releasing daily to weekly.
But even with this huge boost in productivity, Randy’s point was that eBay still appeared to struggle to shift its wider business trajectory.
A common assumption is that the main blocker to innovation is speed. If teams could get ideas out more quickly, the organisation would learn faster and grow.
But eBay had improved speed. So why did the wider business trajectory still seem hard to shift?
The problem was not just speed. It was culture, and the culture at eBay is what can be described as pathological, as detailed in Ron Westrum’s A Typology of Organisational Cultures.
A pathological culture is power-oriented. It tends to show up through low cooperation, blame when bad news is shared, avoidance of responsibility, scapegoating after failure and risk avoidance that kills novelty.
This is not a culture where quality can easily be built in. People are too busy protecting their own areas, avoiding blame and reducing risk to themselves.
So this becomes a cautionary tale: just because you get faster, it does not mean you get better as an organisation.
Incidents reveal hidden system conditions
Lyndsay Prewer’s talk Beyond Timelines: Learning from Incidents, introduced me to a new concept called SPoR, or Social Psychology of Risk. SPoR, is something I definitely want to look into more.
It looks like a useful way to think about how we run post-incident reviews more effectively. Not just as a way to understand what happened, but as a way to help people contribute without feeling blamed or having fault attributed to them.
What I particularly like is how it looks beyond the visible sequence of events.
Most incident review processes use a timeline of events to understand what happened and how an incident unfolded. That is a good place to start. It helps everyone involved develop a shared understanding of what led to the outcome. But timelines tend to focus on the visible aspects of the incident: the things that can be seen, reported on and physically observed.
Resolving those visible issues may prevent the same incident from happening again. However, the thinking, assumptions and conditions that led to it may still be present.
What timelines miss is people’s mental and emotional state: what they were thinking, feeling, noticing, assuming or worrying about at the time.
It also misses the shared understanding of the group: what people believed was happening, what was left unsaid, and what knowledge was distributed across individuals and teams.
When combined with the physical aspects of an incident, this gives a much fuller picture of the unseen things. Such as assumptions, culture, emotions, pressure and how group dynamics influenced how people acted.
This not only helps people understand how a particular incident occurred but the culture that led to it and what can be done to address it. From a quality engineering perspective, this is what building quality into the human system can look like. It helps people develop a shared understanding of an incident, from the physical events to the psychological and social conditions around them.
If we only learn from the visible parts of failure, we only improve the visible parts of the system.
The deeper learning often comes from the things people did not say, did not know, could not see, or did not feel safe enough to share.
QE is about helping teams perform when you are not there
Cathy Pank’s Reading the game: Mental skills for high-performing engineering teams was quite a different talk. She is actually from a football coaching background and shared what she’d learned from the sidelines about management.
Cathy shared that once the game is being played, the coach can only influence so much. They can shout instructions from the sidelines, but most of the work is now in the players' hands. The real impact of the coach happens before the match: in training, preparation, conversations, patterns, habits, and the shared understanding built beforehand.
I think this is true for engineering teams, too.
As managers and leaders, we are not always there when the important work happens. People make decisions in meetings, pull requests, incident calls, planning sessions and everyday conversations. How they behave in those moments depends largely on how they have been supported, coached, and mentored before those moments arrive.
A manager’s role is partly to observe how the team plays: the patterns, the energy, the behaviours, the interactions, and not just the outputs or outcomes. Then they can help people build on the behaviours that are useful for the team, the work and themselves, while moving away from behaviours that create friction or hold people back.
In that sense, management is less about constantly directing the work and more about helping people work better with their teammates.
Thinking about quality engineering, most of the decisions that affect quality happen when the quality engineer is not present.
That means QE cannot just be about inspecting the work after it has happened. It has to be about helping teams build the judgement, habits and feedback loops that make better quality decisions more likely while the work is happening.
If a team can only make good quality decisions when the QE is present, then the QE has become the bottleneck.
Conclusion
The theme I keep coming back to is that AI may increase engineering output, but it does not automatically improve engineering judgement.
It may help teams write code faster, generate tests faster, review changes faster and produce more documentation. But it will not automatically help teams understand risk, make better trade-offs, learn from incidents or behave differently under pressure.
That is where quality engineering can still add real value.
If QE is only about inspecting work after it has been produced, then AI will probably make that problem harder. More output means more things to inspect, more changes to understand and more uncertainty to manage.
But if QE is about helping teams build better quality thinking into the way they work, then the role becomes more important, not less.
That means helping teams turn principles into behaviours.
It means helping teams understand the culture and constraints that limit quality.
It means helping teams learn from incidents by looking beyond the visible timeline.
And it means helping teams build the judgement, habits and feedback loops they need to make better decisions when the QE is not in the room.
For me, that was the biggest takeaway from LDX:
AI might help teams build faster, but building better still depends on the human system around the work.
If this helped you think differently about Quality Engineering, consider subscribing or sharing it with someone who is trying to improve how their team makes decisions under uncertainty.
A quick note: I’ll share the fuller LDX notes behind this post later this week. They include my write-ups from the five talks that influenced this post. The first section will be free to read, with the rest available for paid subscribers.