Linky #32 - The practice is not the principle

This week’s links had me thinking about something that is foundational to a lot of quality engineering work:

Are our practices still serving the principles behind them?

Because it is easy for teams to inherit the practices, rituals, tools, boards, ceremonies, and the language, without always keeping hold of why those things mattered in the first place.

That becomes a problem when the conditions change.

A practice that helped one team learn faster can become a habit that slows another team down. A process that created clarity in one context can create friction in another. A metric that once helped expose a problem can become the thing people optimise around.

Quality is not created by process alone. It is shaped by how people understand the work, how they respond to uncertainty, how they make trade-offs, and how willing they are to adapt when the system around them changes.

This week’s links look at that from a few different angles: the Product Operating Model, first principles, flexible team interactions, change as a social process, AI increasing output, and why understanding the system still matters.

---

Latest post from the QE Newsletter

Over the last couple of months, I’ve been deep diving into the Product Operating Model (POM), which a few software organisations are moving towards.

What stood out to me was that quality engineering could be an incredible enabler for it.

One advantage I see with the POM is that it gets organisations more focused on outcomes rather than outputs. That feels increasingly valuable when AI is accelerating output, but not necessarily helping us understand whether we are creating the right outcomes.

For me, this is where quality engineering has a lot to offer.

Not in testing the thing at the end, but in helping teams ask better questions earlier:

• What are we trying to learn?

• What feedback do we need?

• What risks are we carrying?

• What assumptions are we making?

• How will we know if this is working?

I have a feeling we’ll be hearing more and more about the POM as time goes on, and I think there is a real opportunity for quality engineering to help shape how organisations make that shift in practice.

---

Getting back to first principles

The Agile Manifesto remains the best place to start. Not because it explains everything, it doesn’t, and the world is more complicated than four values and twelve principles.

But it’s first principles. Everything else, the practices, the ceremonies, the tooling, only makes sense in light of it. Without that foundation you’re just copying other people’s answers.

The Agile Manifesto is the foundation you build your agile practices on top of.

But I think this is where a lot of teams can get stuck. They inherit the practices, rituals, boards, ceremonies, and language, but not always the principles underlying them.

So when the environment changes, they struggle to adapt.

The practice becomes the thing to protect, rather than the principle that helped make the practice useful in the first place.

That matters for quality engineering because quality practices are the same. Testing, automation, exploratory testing, pairing, CI/CD, retrospectives, risk conversations, incident reviews, definitions of done. None of these are good just because we do them.

They are useful when they help us learn, reduce uncertainty, surface risk, improve decisions, and build better software.

Continuous improvement is meant to be a core part of the work, but in practice, it is often the thing teams drop when delivery pressure rises.

And that is usually the moment when they need it most. Via Agile Foundation: Beyond Practices to Shared Understanding | Rob Bowley

---

Adapting to the conditions

In Team Topologies, we frequently discuss setting up teams for flow, clarity, and managing cognitive load. It’s not just about picking one structure and sticking to it. Teams need to shift how they interact, depending on what’s happening.

Sometimes you need someone calling the shots, other times, you want to hear from everyone and learn as a group.

The example cited in the post is from the US Navy SEALs.

In the field, they operate with a clear hierarchy because mistakes can lead to serious injury or death. In that context, clear commands and people following through are critical.

But back at base, during debriefs, the dynamic changes. The structure becomes flatter because the purpose has changed. It is no longer about immediate coordination. It is about learning.

That distinction feels really relevant for engineering teams.

During a live incident, the priority is minimising harm to users, the business, and the team. In that moment, a more command-and-control approach can make sense. You need coordination, clarity, and quick decisions.

But during a post-incident review, the purpose is different.

You need to understand what happened, how it happened, what the system made easier or harder, and what you could improve next time. That requires openness, curiosity, and the willingness to hear different perspectives.

The mistake is thinking one way of working should apply everywhere.

Quality is not created by blindly applying the same process to every situation. It is created by understanding what the situation needs and adapting how we work around that.

During an incident, you need coordination.

After an incident, you need learning.

Via Navy SEALs’ Flexible Leadership Approach to Team Dynamics | Matthew Skelton

---

Change happens one conversation at a time

One from me this time:

... change happens person by person. Conversation by conversation. Standard by standard. Not all at once. Not because one heroic person fixes everything. But because enough people keep caring, talking, acting, and nudging the system in a better direction.

We work in big, complex adaptive systems, and trying to change them so quality is built in can feel almost impossible.

But in some ways, maybe that is not what we are trying to do.

We are not trying to fix the whole system in one heroic move. We are trying to change it little by little.

Through conversations, decisions, team habits, better feedback loop and when someone chooses to ask a better question instead of accepting the default.

That might sound small, but I think this is how a lot of quality work actually happens.

Quality engineering is not only about tools, pipelines, automation, or test strategies. It is also about helping people notice what the system is doing and nudging it towards something better.

That kind of change is slow, but it compounds.

And over time, enough small changes can start to move the whole system. Via There are some days when I think, what’s the point? | Jitesh Gosai

---

Quality Engineering Newsletter is reader-supported. If these posts help you think more clearly about quality, teams, systems, and how better software gets built, you can subscribe for free or become a paid subscriber.

Free subscriptions help more people find the newsletter. Paid subscriptions help me keep making time for the reading, writing, reflection, audio versions, and practical resources that go into it.

---

Quality is not proportional to quantity

AI is very focused on more output…

Producing a garbage product faster benefits nobody; never has. It’s good outcomes (e.g., happy customers, painless improvements) that we need, not more output.

Which is a good point.

Just producing more does not mean producing more quality.

But I also think there is a useful nuance here. More attempts can create more opportunities to learn, try things, test assumptions, and find what might work.

The problem is when organisations confuse that activity with value.

More ideas, more prototypes, more code, more documentation, and more tests are not automatically useful. They become useful when they help us learn something, make a better decision, or move closer to an outcome that matters.

Then, once you have found something valuable, the work changes.

You need to productionise it. Make it scalable, performant, maintainable, and suitable for your context. You need to understand the risks. You need to build the feedback loops that tell you whether it is still working.

So quantity can help, but only if the system around it is good at learning.

Otherwise, all you have done is create more stuff to manage. I wrote about this in When quantity leads to quality.

Quote via Value Is Not Proportional to Quantity | Allen Holub

AI is increasing inventory, not value

AI is reducing the cost of creating inventory. And inventory is only valuable when it helps us learn, validate, deliver, or change customer and business outcomes. Until then, it is potential value at best. At worst, it is risk.

As Jacob mentions in his post, inventory can be things like code, tests, documentation, designs, tickets, and ideas.

AI makes it easier to create more of all of that.

But more inventory does not mean more value. We can do things faster, but that does not mean we are creating better outcomes faster.

This is where the system matters.

If your organisation is optimised for output, then that is what you are going to get. More code, tickets, PRs, documents and more visible signs of activity.

But if your organisation has built strong practices for learning and validation, then AI could be used very differently. It could help teams explore, compare options, surface risks, improve understanding, and test assumptions more quickly.

The difference is not the tool but what the surrounding system rewards, notices, and learns from.

So maybe the question is not simply “how much more can AI help us produce?”

Maybe the better question is:

What kind of learning does all this extra output create?

Via AI has made output cheap, moving the constraint from production to validation. | Jacob Clark

It’s never been about speed, but building quality in

I don’t usually post two posts from the same person, but Rob’s been on fire these last few weeks.

He’s been looking back as far as the 1940s, showing that the bottleneck in software has never really been about speed...

Maurice Wilkes, one of the pioneers of stored program computing, later reflected in Memoirs of a Computer Pioneer his realisation in the late 1940s, that “a good part of the remainder of my life was going to be spent in finding errors in my own programs.” From the very beginning, debugging and verification, not writing code, dominated effort.

Rob cites another seven examples showing that speed has rarely been the real issue.

The harder work has always been making sure what we have built actually does what we thought it would do.

That is quality work and its about reducing uncertainty in how our software systems behave.

This is why building quality in matters. It can feel slower at first because you are investing in the system around the work: better tests, better feedback loops, clearer design, smaller changes, stronger collaboration, more testable systems, and earlier conversations about risk.

But over time, that investment changes what the team is capable of.

You spend less time being surprised by the system, on finding issues, on untangling problems you could have made visible earlier.

So building quality in is not really about slowing down to be careful.

It is about creating a system that can move with more confidence because it is better at learning. Via Coding has never been the bottleneck | Rob Bowley

Are we heading for an AI disaster?

...whole swath of software engineers have forgotten why we ever cared about good code in the first place. It’s fine if your prototype is slop, but good code compounds over time so slop only really becomes a problem over time in a compounded nature, when it’s far too late.

This feels like one of the bigger quality engineering challenges we might be walking into with AI.

Not because AI is bad, but because AI may make it much easier to create software faster than we can understand it.

Metrics like MTTR are useful. They help teams embrace failure, detect problems, minimise harm, and recover from production incidents.

Throughput metrics like cycle time and deployment frequency are useful too. They help teams understand whether work is flowing.

But there is a potential trap here.

A team can be shipping frequently, recovering quickly, and still slowly losing comprehension of the system.

They might understand less about:

• how the system actually works

• why certain decisions were made

• where the dependencies are

• how components interact under stress

• what assumptions the system is relying on

The system keeps evolving, but fewer people understand it deeply.

That is dangerous because some problems do not show up straight away. They accumulate quietly. Complexity, coupling, weak assumptions, and messy boundaries can sit unnoticed for a long time because everything still appears to be working.

Until one day, the conditions line up in just the wrong way.

The CrowdStrike outage is a good example of how a relatively small issue can cascade into something much larger when systems are deeply interconnected.

I think we are going to need better ways of noticing whether our understanding of a system is increasing or decreasing over time.

That’s quality engineering work to me.

Not just checking whether the system works today, but helping teams stay close enough to the work that they can understand, question, adapt, and intervene when things go wrong.

Because if AI helps us produce more while quietly reducing our shared understanding, then we may be improving output while weakening the system’s ability to learn. Via Software Engineers Forget Good Code at Their Own Risk | Christopher Grounds

---

As always, I’d love to know what you think. You can reply directly to one of my emails, leave a comment, or message me on socials.

And if this post made you think of a team conversation you need to have, send it to someone and use it as a starting point.

Maybe ask them:

Which of our practices are still helping us, and which ones are we just carrying forward out of habit?

---

Past Linkys