Your Executives Don't Run Quality (You Do)

Let’s take a fresh look at software quality leadership, especially for folks in the middle management seats. Too often, quality is seen as a tech team problem to be handled somewhere far away from business strategy. That old view misses the mark. These days, software quality is the pulse of every customer’s happiness, how people see your brand, and whether your company sticks around for years. Leading software quality isn’t just about hiring skilled engineers and testers. It’s about being a leader who has real vision, knows how to work with people, and keeps everyone moving together toward something that matters.

Middle managers sit at a particularly interesting crossroads. They feel the pressure from the executive level, hear the frustrations on the front line, and have the influence to pull both sides together. Strong quality leadership at this level can be the difference between a team that is always chasing problems and a team that anticipates them before they grow teeth. This is why senior leadership must be intentional about hiring and nurturing middle managers who understand how to lead quality, not just manage tasks. Once that foundation is solid, it becomes much easier to unite teams around where you want quality to go next.

Crafting a Quality Vision Everyone Gets

You wouldn’t start a cross-country road trip without first deciding where you’re headed. Setting a software quality vision works the same way. If you don’t spell out what “quality” means for your team, you’ll spend half your time going in circles. (And arguing about directions.) Leaders should define quality in everyday language. Does it mean speed, security, reliability, or true usability? All of the above? Some of the above with a strong lean one way or another?? Goals should be clear and connect straight to business results. Use things you can measure, whether that’s customer smiles (NPS), system uptime, or the disappearance of those dreaded bug reports.

Building a True “Quality House” - Ownership for All

Now, here's where things get real: Quality isn’t a one-team or one-group job. It belongs to everyone, from the folks who write the code, to the people who design screens, to the owners of the product vision. Picture one of those group assignments from school. If everyone’s supposed to contribute but nobody knows what they’re on the hook for, you end up with a mess. “Ownership for all” does not mean “ownership for none.” Instead, it’s about being intentional and above all…measurable. It's about making sure each person/team understands their responsibilities, how their contributions drive quality-centered outcomes.

Let me state this again using different words to be very clear:

Leaders must set expectations on purpose, not by accident, and back it up with ways to measure progress.

Set clear responsibilities, give people real tools to make a difference, and talk openly about how their choices hit the quality metrics that matter. Some companies even name “quality champions” or “evangelists” as they were known at one of my previous gigs. Think of them as lifeguards at the pool. They keep an eye out for problems, help people avoid danger, and teach others how to swim better. When the team understands how their efforts show up in the numbers, nobody can hide behind “it’s not my job.”

Leaders need to be Leading.

Leaders need to keep that energy going by making learning part of the everyday routine. Software standards shift constantly. The tools that worked last year might not cut it this year. Good leaders run practical workshops, share new testing frameworks, and nudge teams to experiment with different approaches. Think about test-driven development or fresh automation tricks. Gather everyone for regular retrospectives, filtering lessons specifically through the lens of quality. It lets the group see what really worked and where there’s room to grow.

If you ask team members what inspires them most, it’s rarely the person standing on the sidelines. Real leaders roll up their sleeves and jump in, whether it’s by reviewing code, joining bug triage meetings, or just staying curious enough to learn new things. Teams respect those who put their words into action. There’s a great example of an engineering manager who spent time working directly with testers, not only earning trust but also finding bottlenecks that had been holding up releases. That kind of presence moves the whole group forward.

Next comes the balancing act between speed and quality. Deadlines matter, but charging ahead too quickly always leads to trouble. The trick is setting realistic timelines that leave space for testing and fixes. Baking bread is a fitting analogy; skip the rise and the outcome will leave everyone flat. Instead, split big releases into smaller chunks. That way, you gather feedback sooner and spot trouble before it multiplies.

As a middle manager, it’s clear just how much every code update eventually rolls right down to your team. That’s why you use any and all influence at your disposal to help make those changes feel less overwhelming for your folks. Whether it means speaking up for more reasonable timelines, prioritizing workload, or encouraging smarter release practices, you do everything you can to keep your team focused and effective instead of burdened by a tidal wave of changes.

Good leaders do not fly blind. They use data to see the full picture. Dashboards that track defect trends, customer feedback, test coverage, or stability give leaders an early warning before issues explode. It is not about staring at numbers all day. It is about watching for patterns and asking the right questions.

If defects jump, what changed? If customer dissatisfaction grows, what experience is breaking down? If test coverage drops, what part of the workflow is being rushed?

Want a real Quality Team? Join the right minds.

Silicon Valley has a long history of siloed teams. Development stays in one corner. Testing sits in another. Operations and support rarely speak unless something is on fire. That structure might have worked twenty years ago, but it kills quality today.

Quality is a team sport that works best when everyone is aligned. Cross functional teams that share goals, user insights, and customer data move faster and produce stronger results. Quality thrives when barriers come down. When developers, testers, operations folks, and support all play on the same team, the work gets better fast. Cross-functional teams are the secret sauce. By sharing real customer feedback and steering incentives toward quality goals, teams start pulling for the same finish line. For instance, I used to be on a “quality squad” that mixed people from every department. Weekly meetups turned into powerful sessions where ideas flowed and issues melted away.

Bringing It All Together

I could go on and on but I'll bring this all together now. Strong leadership is the thread running through real software quality. The leaders who succeed are those who set clear goals, give every person a chance to own the outcome, encourage constant learning, and keep communication honest. It’s part art, part discipline. You have to move quickly, but never carelessly, relying on data, being hands-on, and switching gears when the road changes.

If you want to push things forward, start by checking your current quality practices and pinpoint one action you can take. When leaders step up with purpose, raising the quality bar isn’t just possible. It happens one day at a time, and everyone, including teams, users, and the business itself, will see and feel the results.