Ripping off the Band Aid (Hope its not a Tourniquet!!)
Software Development organizations in today’s industry are having to move fast and adapt to the landscape that says you need to get out first or get left behind. While this is largely true some of the “Bigs” are knee jerking with strong adjustments to engineering (including quality assurance) 1) without entirely thinking through what is necessary to navigate the change or 2) cutting too deep too fast to induce a culture change that can/should take years to develop; unless you are willing to replace the entire organization. During the time period to let the change mature, it can (will) be rough; on the product, team, and customers.
Recovery
Leadership is key to getting this change right. You need leaders who have the stomach to resist the urge to appeal to everyone in order to keep everyone. They also need to be able to clearly articulate the activities that will be rewarded that promote end user quality and good hygiene practices to keep code flowing. Whatever those rewarded activities are you will find the engineers doing them. If you leave a fundamental out of your reward system you will find yourself hurting at the worst possible time, the end game.
Ben, stop talking so cryptically; what are you really saying??
As we all know there has been a big push to get Developers to own more of the product quality and this is a righteous and good thing. The days of relying on a Test Organization to test your code for you are long gone because guess what? Yep, they got rid of those test organizations or moved them into Data Insights teams. The testers who could stick it out coding moved into developer roles; but, those previous testers/SDETs received test lobotomies because test/QA activities were no longer rewarded by the Old Guard dev managers. So, what we ended up with was either whole dev teams still acting like testers for their org or product quality went totally downhill because there was no longer any QA leadership in positions of influence (remember – they either became dev leads or data science managers).
I get it. What can be done differently?
First and foremost you need to maintain QA leadership in your organization when you decide to introduce culture change to Dev Owned Quality. This does not mean you have to have quality teams headed by QA leaders. It means that your Engineering Leadership needs to surround themselves with Quality Leaders in the same way we lean on Release Management to navigate and guide us through shipping; Those Engineering Leaders also must mandate that Development Managers will be evaluated on the quality of their product code. QA leaders can help define the success metrics and activities necessary to be successful through the development cycle as well as the plan for tracking quality post initial ship. There are fundamentals (Accessibility, Localization, Globalization, Perf/Stress, Privacy, etc) that Development Managers just won’t know how to do properly and the QA Leaders can be there to create the plan and guide the engineering team through what needs to be done. What will then happen is that the Development teams will become better and better at building and ensuring the quality of the checkin and build process. I want to stop at calling these quality leaders QA Architects or Czars. They need to help strategize/plan and should be seen more as a resource than a quality gate keeper, again, that is the responsibility of each Engineering Leader/Development Manager.
Finally
Culture change is good when it supports the business goals of the organization. Keep influential quality leaders in prominent places in the organization to help guide Engineering in QA while the culture change is maturing. As an Engineering Leader, seek the counsel of your QA Leaders and act; even better, set the example in any way you can. As you hire new talent make sure there is a QA component to your interview process so that you are bringing in people with a quality mindset in place. Communicate broadly and often reinforcing the goals and values supporting Quality Engineering Practices. Embrace telemetry. Move your test VERIFICATION methods out of your automation and into your Telemetry Measures that are implemented right in the code, this way your VALID and INVALID paths are tracked all the way into the field. Establish audience appropriate (leadership will want to see different data than the Individual Contributor or Lead) dashboards to track KPIs in your Engineering Processes, Quality, and Customer Sentiment.