I was brought into an organisation that had no dedicated quality function and tasked with improving quality engineering to support faster releases. This is a review of the things that I did to help build a culture of quality to help others to understand what’s needed (as they might have to go through this themselves as a first quality person at a company).

The organisation was a mature SAAS product organisation with four product teams working on an established code base with real customers, meaning real business risks related to revenue and reputation. The organisation wasn’t broken, features were being shipped, but quality and testing were immature which could impact the speed of releases. The lack of maturity in quality processes meant that people generally didn’t know what good looked like or what their options were in terms of testing processes and informed decision making related to quality.

1. Establish quality engineering ( first 4 months)

After having reviewed the situation I found that we had multiple engineering teams working within an organisation with no shared view or vocabulary for quality and testing. Without understanding the foundations people didn’t know the art of the possible and so couldn’t create a pull for quality information.

1.01 Actions

Ran intro to quality sessions across the organisation (What is quality, what are bugs, quality principles, non-functional quality, what is testing) as lunchtime drop in presentations.

Created a shared reference wiki of concepts, terminology and processes for people to self serve and learn from / use as they needed.

Set out a small set of quality principles (bug vs. escaped defect, shift left, non-functional testing, what is good enough) which were repeated consistently in team ceremonies and through coaching rather than just mandated once.

Create structured artefacts (path to production testing, creating a test strategy for a significant platform change) primarily documenting and codifying what exists now rather than a to be state.

Introducing some new processes (Three Amigos, Definition of Done) which were seeded through being involved with teams and coaching on the processes, these were opt in and not mandatory or enforced. Uptake on these were partial and not universal across all teams / team members.

1.02 Culture

Met with stakeholders across engineering, product and other business teams to introduce quality engineering and myself, to build rapport and start to become a trusted advisor (i.e. I’m new but I’m not scary and I’m here to help).

Regular visible messaging drumbeat on organisation level channels for quality topics (sharing infographics, asking people what they thought quality means, sharing joke quality reports like the best bits of a roast dinner: by a professional quality expert).

Sharing wider quality topics with engineering teams through sharing blog posts and videos from other quality experts.

1.03 takeaway

You cannot mandate a culture across an organisation and teams immediately, it’s something you have to grow over time by seeding ideas. I reviewed how much teams were able to take on from a cognitive load capacity and scaled up or down my coaching to make sure people were not being overwhelmed.

As people take about 3 months to really embed ideas in and for them to become natural focus on a few things that get seeded and repeated to build understanding is better. I knew this was working when after four months people were parroting back my catchphrases of “good enough” and “the art of the possible” in conversations.

2. Embed (Months 5-12)

After establishing some ideas about quality engineering, enough to be able to talk to people across the company about them, I then looked to start embedding these ideas more deeply. Teams had ideas about what the art of the possible could be but needed coaching and mentoring on how to actually enact those things, so I attached quality to high visibility work by embedding into the flagship product team.

2.01 Actions

Hands on testing support to teams that needed help (fixing broken tests, building automated testing capabilities, implementing and widening test tooling) by doing this myself or working with other engineers to do this.

Running the first company wide bug bash to start bringing the wider business teams into engineering and using their domain knowledge to inform quality. Signalling that quality is a whole business concern, not just an engineer only thing.

Creating cross team quality KPIs through a monthly dashboard of basic metrics (stories been through Three Amigos, test coverage, number of artefacts in place, defect numbers) framed as a conversation starter.

Building processes that the teams identified that they needed (defect triage, risk based release meetings with quality narratives, retrospectives) and supporting their adoption by running them with the team.

Advisory work and coaching across platform level concerns and tricky quality problems (pipeline health, static analysis for code health, path to production improvements) by supporting teams in discussions as they needed / initiated them.

2.02 Culture

Humanising myself through organisation wide talks on non-quality subjects (diversity and pride month) as well as being involved in general office and messaging conversations / banter.

Introducing Ramone the Testing Otter as a quality mascot as an emoji, in messages and in content related to quality engineering.

Bring present and engaged in meetings and stand ups sharing how I’m feeling, adding jokes and bringing my authentic self into discussions.

2.03 takeaway

Embedding quality means attaching to the work that leadership cares about (the biggest projects) to make quality visible rather than creating new passion projects that risk being invisible.

Visibility of work whilst embedded deeply into teams is important, publicly talking about what you’re doing, sharing quality narratives, running quality sessions for people to attend and creating dashboards all helps people to see the needle moving on the culture of quality.

3. Advise (Months 12-18)

This was a shift from creating and running the processes to being pulled in by teams and individuals to give trusted advisor style support. This allows the teams to drive what they need rather than having me pushing more quality at them and overwhelming them. Because there were multiple teams and wider organisational quality needs there was still a good cadence of work to pick up.

3.01 Actions

Advisory input for new initiatives (new product capabilities, platform migrations) with short term embedding into teams to support these directly and coach team members.

Creating initial quality guardrails for new technology use (AI… what else could it be?) with deliberate experimentation and research to deliver a contextual and pragmatic set of guidelines for the organisation. These were advisory guidelines rather than mandated adoption rules.

Backfilling need where there were gaps by picking up hands on testing for teams (exploratory reviews, performance testing, increasing automated regression coverage) in times of moving fast.

Continued wider business engagements related to quality, such as running training and review drop in sessions for people’s AI prompts to improve quality literacy across the organisation.

Continued review and support for teams through one to ones with tech leads to identify any possible coaching opportunities and using Quality Radars to help teams to identify and visualise further opportunities to build in quality.

3.02 Culture

Bringing my personal advocacy work into the role by sharing my learnings at conferences and speaking engagements. Completing the loop by then sharing my conference talks back into the organisation.

3.03 takeaway

Becoming a trusted advisor and having your opinions asked for is the signal that culture has actually shifted. We get to a point where we don’t have to sell and push quality into teams and start being pulled into problems.

It’s important to remember that the aim should be to make teams self sufficient and not fear this through worrying that you’ll become unneeded. There will always be additional quality matters that the organisation needs advice on, so we shouldn’t feel the need to hoard day to day work in order to feel we have something to contribute.

4. Systemise (Months 18-24)

The aim here is not to just advise but to build tooling that teams can pick up and plug into their workflows to engage in quality thinking. This is especially important for teams that want to go faster with automated pipelines and AI and ensuring quality at pace, they need tools rather than manual processes to engage with.

4.01 Actions

Building review scorecard rubrics that automatically review code and pipelines for quality signals (maintainability, security, test coverage, change failure) and flag issues for team review.

Creating packaged reusable artefacts from quality engineering thinking (Claude skills for Three Amigos, exploratory testing, E2E test creation) for teams to plug into their software development pipelines easily.

Modernising test framework tool usage to something more evergreen (at least for now) that can be hooked more easily into AI development pipelines.

Creating automated quality governance through setting and agreeing the floor for quality appetite at an organisational level with the Exec team and setting pipelines to fail if this was not reached (functional, non functional, maintainability).

4.02 Culture

Continuing on with advocacy across the business through running sessions, training and sharing messages on business channels.

4.03 takeaway

This isn’t about building completely perfect or fully complete systems, it’s about providing some level of tooling that’s good enough for people to pick up and then build on. Teams can be time poor so want trusted tools that they can pick up and plug into their workflows that they know will work and speak to their context.

This makes sure that quality thinking and engineering happens automatically and doesn’t need you to be there pushing for it (or doing it) all of the time.

Outcome & Lessons

The organisation went from having no quality function to having opt in quality engineering based on trusted reviews and tooling to support their testing.

The needle moved from testing and quality being an engineering only concern to being a whole business consideration, with more people being able to speak to and engage with quality meaningfully.

Quality thinking moved from bolted on at the end to more holistic, with shift left and right testing practices embedded into teams to improve feedback loops and inform decisions about product and code quality.

Testing shifted from primarily manual to being automated, meaning it was faster and more consistently applied to releases. Building trust with the wider business teams and helping to ensure that releases didn’t get stalled or slowed down.

The organisation went from having no quality signals to having automated and trusted quality signals that can be used to inform on quality and govern against an established floor for quality appetite.

The culture changed as much as the quality processes did. Quality became something that everyone (design, product, customer services and support) talk about too. This was carried by a steady drumbeat of coaching, talks, weekly clinics, bug bashes, infographics and the running of “quality reports” on everything from Christmas dinners to queer icons.

The direction for furthering the culture of quality is set even where the work is still a work in progress.

Thanks for reading. If this resonated (or if you think that I’ve got it wrong) there’s more to read on the blog… or get in touch via LinkedIn. I’ll talk quality to anyone who wants to listen!