A mistake I see often is treating frameworks as answers. Their real value is helping people think when the system is complex, and the path forward isn’t obvious.

“Shift left” keeps failing for a simple reason. It’s treated as a slogan instead of a change in how teams learn, collaborate, and make decisions.

Conferences are great for inspiration. But the real value comes afterwards, when you slow down and ask what actually changed your thinking and why.

One of the strongest signals this year wasn’t about tooling or AI. It was role clarity. People aren’t asking “what level am I?” They’re asking, “What does good look like in practice?”

A pattern that keeps showing up: most problems with quality engineering don’t start with tools or skills. They start with misconceptions. If teams can’t agree on what quality engineering actually is, everything downstream becomes harder: roles, expectations, investment, and outcomes.

Critical thinking is becoming a core skill AI is amplifying the gap between people who think critically and people who don’t. The tool is not the differentiator. The thinking is. Quality engineering increasingly depends on this skill. See Linky: qualityeng.substack.com/p/linky-no-21

Errors of omission are invisible Most organisations only track mistakes people make. They rarely track the work that *never happened* but should have. Yet errors of omission often do more damage to quality than the obvious failures. See Linky: qualityeng.substack.com/p/linky-no-21

Paper cuts matter Most users will tolerate one rough edge. But ten small paper cuts feel like a broken product. Quality often erodes quietly, long before anything “critical” breaks. More in this week’s Linky: qualityeng.substack.com/p/linky-no-21

Speed comes from certainty Teams do not go faster by skipping testing. They go faster because they are certain enough to change code without fear. Quality is speed. More in this week’s Linky: qualityeng.substack.com/p/linky-no-21

Blame kills learning Every time a post incident review stops at “human error”, the learning stops too. The mistake is still waiting in the system. Quality improves when we ask: what made this mistake possible? More in this week’s Linky: qualityeng.substack.com/p/linky-no-21

Quality is a side effect Most of the quality we experience in software is a side effect of how our organisations think and learn. Not tools. Not tests. Behaviour. If you want better quality, change the conditions, not the checklist. qualityeng.substack.com/p/linky-no-21

Hats random stuff you find in the office. I remember collecting these when I was a kid and cheated by buying a full set for 3quid 😆

Well if you’re locked in what else you going to do? 😂 youtube.com/shorts/-DqNM...

One of the best parts of working in MediaCity is that I can walk to work on the canal

Tell you what really annoys me. When you go out for coffee, sit in and they give it you in a takeaway cup. If I’d known that I would have gone somewhere else

And if you click through to the second day you can see pictures of me making weird facial expressions on stage 😂

Today is the last day to submit a session proposal for next year's Agile Manchester conference: agilemanchester.net/call-for-ses... The event will take place from 13-14 May Tickets now available. Discount for freelancers.

Really enjoyed listening to @jitgos.bsky.social talk about managing uncertainty in complex systems - and how to handle this. @oredev.org

I was just asked if I’m over 25, and I’m like, 'Get in!' But then I thought, hold on, there’s a trade-off to this. But I can’t think what Any ideas?

Whether it’s team safety, neurodiversity, or delivery speed, the pattern is the same: the system sets the limits. People do their best work when the environment makes good outcomes the most likely outcome. Improving quality isn’t about finding better people; it’s about building better systems.

We often use metrics to prove progress, but they can just as easily hide the real story. The best metrics act as signals. Clues about how healthy the system is, not scorecards to optimise. The goal isn’t to “fix the number”, it’s to understand what the number is trying to tell you.

Some of these cats are interesting 😂 via Substack notes substack.com/@coolstories...

Yep this happened 😆 via Benedict Evans newsletter: Donald Trump posted an AI-generated video in which he flies in a jet over US cities and bombs anti-Trump protests with excrement. You get what you voted for - a shitposter-in-chief news.sky.com/video/donald...

The best teams don’t avoid failure, they learn from it. They talk openly, analyse fairly, and improve deliberately. Experience becomes knowledge.

I don’t usually get sucked in, but this site does it so well. By the time I’d scrolled to the end, I just wanted to know where I could get one from 😆 www.firebellytea.com/pages/autowh...

Don’t mess with this train 😆 but who is she!?!

As systems get more AI-driven, our job shifts from control to observation. Quality comes from noticing patterns, behaviours, and surprises — not just checking for pass/fail.

Good engineering rarely comes from speed or certainty. It comes from curiosity, experimentation, and learning through experience. Slow down, ask better questions, and quality follows.

Not those types of gays and not those types of balls 😆

@jitgos.bsky.social Sharing more info on the crowstrike bug and how to improve #quality in multiple ways in complex social technical systems #testing #testbash

Spent the day sightseeing in Edinburgh before LAScot tomorrow. After 33k steps covering approx 15ml I’ve managed to see quite a lot 😅

Best YouTube comment of the day 😂 🐻 🎧

Psychological safety isn’t about comfort. It’s about safety in discomfort - in dissent, in conflict, in being “wrong” while striving for “right”. More reflections in this week’s Linky: qualityeng.substack.com/p/linky-no-15

Incidents in complex systems rarely have a single cause. That’s why blameless postmortems beat root cause analysis, they make sense of failures in context instead of chasing one neat answer. I wrote more about this in this week’s Linky: qualityeng.substack.com/p/linky-no-15

One idea I’ve been exploring: 🛠 Tools build quality into products (teams) 📐 Frameworks build quality into processes (managers) 💡 Philosophy builds quality into people and culture (leaders) When these align, you get a healthier system. ❓Where’s the biggest gap in this chain?

A culture of quality isn’t built from the top down. It needs: 🔼 Leaders setting values that matter. 🔽 Teams feeding back what works (and what doesn’t). ↔️ Peers sharing learning across silos. ✨ What’s one feedback loop about quality that works well where you are?

We often talk about “quality ownership,” but what if we reframed it? Instead of asking who owns quality, we could ask: ➡️ Where is your greatest influence on quality right now? 🔎 How would your approach to quality shift if you thought less about roles and more about spheres of influence?

💭 Who really owns quality in your organisation? Teams build it into products. Managers into processes. Leaders into culture. Each level matters, but in practice, it’s rarely this neat . Where do you see quality being built or missed?

How do you show empathy when things go wrong? 💔 Production incidents. Missed deadlines. Testing surprises. In those moments, empathy isn’t just nice to have - it’s what helps us move forward. What does it look like in your team?

What slows your team down the most, and how do you work around it? Would love to gather a few examples here. I’m especially interested in the fixes and workarounds people have found.

What helps you stay curious under pressure to deliver? When time is tight, it’s tempting to default to routine. But I find that curiosity often uncovers issues we’d otherwise miss. How do you keep it alive?

How do you frame testing so others see its value? Bug-hunting can be valuable, but if that’s all we talk about, it’s easy to get seen as the adversary. How do you show the value of your work?

What engineering work would you hand over to AI agents? I’ve seen great results with code tidying and refactors, but there are still things I’d want a human brain (and a bit of context) for. Where do you draw the line?

If software could test itself, what would your role look like? I came across a story where an AI swarm built something and generated its own dashboard to prove it worked. It made me wonder: if systems can demonstrate their own quality, where does that leave testers?

When has humility helped improve quality in your team? 🙇 Maybe someone admitted a mistake. Or asked a “silly” question that wasn't silly at all. I think humility is underrated in tech, but essential for learning and improving. Curious if you’ve seen it make a difference.

What does curiosity look like in your work? 🕵️ Is it questions? Pairing? Noticing patterns? I’ve been thinking about how curiosity helps us spot quality risks before they grow. How do you stay curious, especially when deadlines loom?

Spotted above the hand dryers in a Japanese restaurant in Glasgow: The Willy Brush 😆

What behaviours have you seen in great teams that helped quality thrive? 🧠 It’s rarely just process. I’ve been reflecting on what makes quality feel like a shared effort. What’s stood out to you in teams that really nailed it?

I had a day to myself in London, so I decided to be a tourist and visited Tower Bridge, the Bank of England museum, and the Tate. Highlights got to be picking up a real gold brick - 13kg - quite a lot of weight in such a compact size 🧱🌉🎨

Some interesting details on St Paul Cathedral…