Welcome to the sixth edition of Linky (scroll to the bottom for past issues). In each issue, I highlight articles, essays, or books I've recently enjoyed, with some commentary on why they caught my attention and why I think they're worth your time.
This week's Linky No. 6 explores how we build quality into systems through persistence, perspective, starting small, and paying attention to the decisions and culture that shape our software. You’ll find lessons from leadership failures, insights into AI-enabled development, and frameworks for continuous improvement.
Quality Engineering Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Latest post from the Quality Engineering Newsletter
Being technical isn’t just about automation or writing code. It’s about understanding the technical details of the systems we work in and using that knowledge to design, develop, and solve practical problems.
Google has done some great research on the quality attributes developers care about. What I liked most was how much it aligned with building quality into people, processes and products. It gives QEs a great place to start when defining which quality attributes matter to teams.
Want to be more persuasive? Find common ground
Arguments that sought to highlight common ground and bridge divides with the help of perspective taking and personal narrative were demonstrably persuasive
The next time you're trying to persuade developers to your way of thinking, first find common ground - then explain how your approach supports their goals rather than just adding more work. Learn more from the Better Conflict Bulletin.
PDSA > PDCA: Solve problems by studying them
Here is your regular reminder that the Deming Cycle is Plan-Do-Study-Act (PDSA), not Plan-Do-Check-Act (PDCA).
This reflects that it’s more important to learn and improve from the activity, rather than simply check that it worked.
It’s also not actually the Deming Cycle.
Deming himself called it the Shewhart Cycle, after his mentor Walter Shewhart, the grandfather of statistical quality control. Shewhart created the PDCA cycle at the Bell Telephone Laboratories in the 1920s.
Via Tom Geraghty of the Psychological Safety newsletter. The PDSA cycle is a powerful tool for process improvement and well worth having in your toolbox. Read Tom’s post and explore the cycle in depth at the Deming Institute.
The AI Dev Tools Landscape
From Patrick Debois on LinkedIn:
So we've built this thing ... an overview of the AI Native Dev landscape. No more FOMO on discovering tools. We got you covered !
As we're all trying to keep up, we figured we'd make this list public and we can collaborate on it in the open. There's a lot of lists out there, but we specifically focused on the AI tools in software engineering.
⭐ Mistakes are inevitable - learning is a choice ⭐ Be honest - even when it’s hard ⭐ Perspective is everything ⭐ Tackle the hard stuff first
One leader lost £1M due to a spreadsheet formula. Another accidentally misled an underperforming employee. A team forgot the keys to the office on go-live day. Someone delayed figuring out the hard reports and got hit with a seven-figure fine.
When you share your mistakes, others open up too. We build up our own failures in our heads, but when we talk about them, we realise they’re just part of the journey. Read my LinkedIn post.
The unintended outcomes of only rewarding top performers?
Each year, Steve Jobs would hold an annual meeting with the 100 most important people at Apple.
Crucially, these were not the top 100 executives, but rather the 100 people who were most important to the company that year. Jobs personally chose attendees based on their direct contribution, creativity, vision, and impact within the company, regardless of their official titles or positions.
While I love the idea of recognising impact over title, it makes me wonder: Does this reward individuals over teams? Does it encourage burnout or skew towards those with fewer outside responsibilities? Maybe we should celebrate individuals more quietly and teams more publicly to show that collaboration and learning are truly valued. I would love to hear about your experiences with this.
Estée Lauder on what really drives success
"What makes a successful businesswoman? Is it talent? Well, perhaps, although I've known many enormously successful people who were not-gifted in any outstanding way, not blessed with particular talent. Is it, then, intelligence? Certainly, intelligence helps, but it's not necessarily education or the kind of intellectual reasoning needed to graduate from the Wharton School of Business that are essential. How many of your grandfathers came here from one or another "old country" and made a mark in America without the language, money, or contacts? What, then, is the mystical ingredient?
It's persistence. It's that certain little spirit that compels you to stick it out just when you're at your most tired. It's that quality that forces you to persevere, find the route around the stone wall. It's the immovable stubbornness that will not allow you to cave in when everyone says give up"
Persistence is something we need plenty of when building quality in. As a QE, there will be countless conversations, initiatives, and experiments that don’t make the impact you hoped—but they nudge things forward. Persistence is what makes the difference. Read the full quote at fs.blog
Quality Engineering = Caring about decisions in code
From Simon Wardley:
Vibe wrangling = AI + I don’t care about decisions in code for this thing. Emergent discovery. Deals with more complex spaces. Good for prototypes.
Software engineering = I do care about decisions in code for this thing + AI. Dynamic discovery. Deals with more complicated spaces. Good for running systems.
I love this framing of AI vibe wrangling as not caring about the decisions made in code, as you’re trying to “wrangle” a solution to a problem. This is to say that you’re trying to understand the questions you need to ask, which is where the prototype comes in. In software engineering, you care about the decisions you make in code as you want maintainable systems adaptable to future changes. Essentially, engineering helps you answer those questions. Quality engineering is about learning how quality is created, maintained and lost in complex adaptive systems and to do that, you need to understand what decisions have been made in the code and why. See the original post on LinkedIn.
Quality Engineering Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
All rituals are downstream from culture
All rituals, including ours, are downstream from the culture you want to create.
If quality is value to someone, then what PostHog values is shipping features their users care about. They’ve built communication rituals that support that goal. This hierarchy of communication is an excellent example of aligning socio-technical systems to promote the behaviours you want. Read the full post at PostHog.
Start VERY small with Quality Engineering
The best way to shift behaviour, culture, and ways of working? Start VERY small.
Agile Coach Matt Turner says it best: 'Think big, start small, learn fast.' What’s the smallest step you can take with your team to start building in quality? Read his full post on LinkedIn - well worth a follow, too.
QED: A practical framework to start small
Kat Obring’s QED (Question, Evidence, Develop) Framework:
One problem at a time
2–3 metrics that matter
Two-week experiments
Decisions based on data
This is a brilliant way to start quality improvement in a low-risk, high-learning way. I like how it focuses on problems, data to measure progress, and then wraps it into experimentation to encourage learning. Another great approach to keep in your toolbelt. Read Kat’s post and download the framework from her website.
Balancing Speed vs. Quality: Seven Strategies
Engineers must find the balance between building the right abstractions for a solid foundation. Here are seven strategies to navigate this balance.
Build steel threads
Manage technical debt intentionally
Delay decisions until the last responsible moment
Selectively invest in quality
Use the Strangler Fig pattern
Embrace sacrificial architecture
Use AI
The best staff+ engineers promote a culture of experimentation while also setting up a structure that supports the scalability and durability of systems.
I particularly like the steel threads and selective investment in quality. Both are connected to me in that the steel threads through your system (the end-to-end journey of a core use case) is where you want to invest in quality due to its importance to the business. The post is well worth a read as it also highlights use cases where these strategies have been implemented and how to get started. Read the guide at LeadDev.
Thanks for reading Linky No. 6! Got thoughts or favourites from this edition? Hit reply or leave a comment.
