Future Horizons: What's in Store for Quality Engineering Newsletter in the Coming Year?
A recap on the last 6 months and what next for the quality engineering newsletter
What is this newsletter?
I started the Quality Engineering newsletter in July 2023 to document my thoughts on how quality engineering can help modern software teams build quality into their products and services.
In some ways, it's been about getting my thoughts out into the open and seeing what others thought. The response was way more than I was expecting. I thought I'd get a couple of likes and maybe a few subscribers, and that would be it. While I was right on the likes count, I underestimated the number of subscribers. At this point, I have over 200, which I could not have imagined when I first thought of starting this newsletter just over two years ago. Note: I only started posting in July 2023 - procrastination meant there was always something else more pressing at hand!
What is quality engineering?
Since July 2023, I've posted every two weeks, which amounts to 11 posts. Over that time, I shared why I started this newsletter with why quality engineering. My first post is critical in understanding my thinking. It introduces some key concepts that I will delve into future posts. If I had to sum up Quality Engineering, then this paragraph says it all:
Quality engineering is more than testing earlier in the software life cycle. It's about looking at all the facets of software engineering. From delivering the product to the processes we use to build it and the people involved. It's about taking a holistic approach to quality and understanding how quality is created, maintained and lost throughout the software life cycle. It is then, using this insight, we build quality at the source.
Where do you get started with quality engineering?
I followed up with what I think quality engineering is and began expanding on products, processes and people, creating, maintaining and losing quality and what building quality at the source means. The third post delved deeper into looking at all facets of software engineering in what quality engineers do with how they work, and introduced the idea of creating healthier socio-technical systems - a concept I'll refer to repeatedly.
I then went on a detour to explore why software systems are complex and introduced how we nudge and boost complex systems - you'll find that I come back to nudging and boosting systems quite often.
I used one of my conference talks, Speed Vs Quality: How can you have both, as a concrete example to explain how quality is created, maintained and lost when working in software teams. I went even deeper with the next post. I described how the techniques I shared in my talk build quality into products, processes and people.
I've recently been fleshing out my approach to quality engineering with ideas on how others could create a culture of quality within their teams, departments and organisations using the concepts of quality engineering as a philosophy, a framework and tools. I followed up on that post and expanded it even further by layering on different discipline levels with who should build a culture of quality. For future posts, I want to look deeper into the benefits and trade-offs with this approach and where quality engineers fit into a culture of quality.
What have I learned from writing this newsletter?
I was wondering what would happen when I started this newsletter. In some ways, nothing happened, but in others, everything. My life is pretty much the same, but I now have a fortnightly commitment to write a new post, so I've got less "free" time than I used to. However, what has changed is my understanding of quality engineering and what it can do.
A mental model of quality engineering
One of the most significant changes is more internal to me. By writing these posts, I've slowly fleshed out my mental model of quality engineering. It's like scaffolding for my mind, allowing me to look at teams, departments and organisations and see how quality is created, maintained and lost. It feels like a superpower that allows me to look at the environments where software is being created and, even with the smallest amount of information, see what's working, what isn't and where fruitful avenues of investigation would be.
It's by no means perfect, but when combined with other models, you slowly build up a mental image of the environment that allows you to move around that space with a lot more agility and ability to adapt to the forever-changing landscape we work in.
Sharing these posts with the broader community of others interested in building great software products gives them this same power. It almost feels like this model helps you see in a higher resolution, showing you the breadth and depth of areas where quality can be created, maintained and lost. All of which help you make healthier socio-technical software systems.
A Culture of Quality Model?
But what to call this model?
Well, what have we explored so far? To sum up my last ten posts, we have:
Quality Engineering is the study of how quality is created, maintained and lost.
Quality exists at the levels of product, processes and people.
Quality Engineers help software teams build quality at the source.
A Culture of Quality is one that looks to create healthier socio-technical software systems using quality engineering insights.
A Culture of Quality Model feels like the right name for the moment, but something doesn't sit quite right with me. If you have any comments or suggestions, I would love to hear them. What would be a better name, or does a culture of quality seem right?
What next?
Next year, I'd like to continue developing my culture of quality model and applying it to other companies' engineering practices and see how it holds up. I'd also like to share more techniques that help create and maintain quality within organisations.
For those on the paid tier, I plan to make even more content available next year, such as early access to my talks with full transcripts, slides and background reading. I'm most excited about sharing two talks about my work on psychological safety and how to learn from failure - both focus on building quality into people. So keep an eye out for when they come out. If you'd like to get a flavour of what they will look like, check out my Speed Vs Quality: Can you have both talk.
Thank you
To all who have subscribed, liked, and re-shared my posts, especially those who have become paid-for subscribers - thank you! I've been lucky enough for a few of you to comment and message me directly, and I even met a few of you in real life at conferences. Your comments on how my posts are helping you see things in a different light and navigate your work have been really encouraging. Please keep sharing; it helps me see what’s working and what isn’t.
If you want to continue supporting me and my work, consider becoming a paid subscriber. During the holiday season, you could ask for it as a gift.
Another great way is sharing posts on whatever networks you are active on, especially by saying what you found insightful or what you'll do differently.
Thank you to every subscriber. You are what keeps me going. Have a great break, and I'll see you all in the new year.
Over to you
I would love to hear more from others in and around the quality engineering community. How do these ideas and concepts resonate with people? Are they helping? In what way? What new and existing topics would people like to be examined in more detail? How are you building quality into your teams and organisations? Let me know in the comments or email me directly.