Q&A with QA: How Best Buy’s Quality Director Scales QA Across 200+ Teams (Part 1)

What does quality actually mean in a large enterprise, and how do you achieve it across hundreds of distributed teams?

In this first installment of our “Q&A with QA” series, we sat down with Pete Draheim, a 15-year veteran at Best Buy who leads quality assurance and engineering tools for one of the world’s largest retailers. Pete shares his insights on scaling quality across distributed teams, the evolution from testing-focused to proactive quality engineering, and what it takes to build a center of enablement that serves 200+ engineering teams.

Q: Can you start by describing your role at Best Buy and what your team is responsible for?

Pete: I’ve been at Best Buy for 15 years now. I started as a quality manager in the integration middleware space and was promoted to director of quality assurance back when our dot-com was still a separate business function outside of IT. For several years, I was actually the only quality professional as an employee at Best Buy until 2017, when our CTO combined digital and IT systems under one umbrella.

Right now, I’m a director responsible for two main areas: engineering tools and quality functions. On the tools side, my teams administer and support tools like GitHub, Artifactory, Jira, Confluence, Slack, and Lambda Test. We also manage developer productivity AI products like GitHub Copilot. On the quality side, I oversee our integrated program testing team, which focuses on end-to-end business testing, plus our test data management and test environment teams that support all engineering teams across the organization.

Q: How do you define quality in a large, customer-centric organization like Best Buy?

Pete: In my mind, quality really means defect-free, though that exists on a continuum. Perfect quality isn’t achievable, and even if it was, it would be too expensive. Quality management is about applying quality functions to maintain the appropriate balance between quality and cost—or really, quality and speed, since I basically equate cost and speed. Something slower costs more; something faster costs less.

Quality has both a proactive and reactive focus. The proactive approach prevents defects from coming in through things like code reviews, CICD processes, version control, and working in small batches. The reactive side is testing. But fundamentally, you can’t test your way out of bad quality. Testing just reveals the quality you already have. If you don’t invest in the proactive part, you end up with a high-cost test function and you’re behind the eight ball all the time. More defects means more rewrite time and more retesting. Minimizing defects is the key to speed.

Q: Do you find yourself more in proactive or reactive mode, and how do you balance the two?

Pete: It’s hard because the reactive sucks you in. The reactive is what gets leadership attention—the test results, the bugs, the things we’ve been pre-programmed to focus on in the software development industry. You have to be conscious about it.

Part of what I have my integrated program testing team do is objectively measure the quality of products being given to them. My IPT team only gets involved in complex projects—things involving 20, 50, 100 teams and 20, 30, 40 different applications. Testing lasts weeks and really slows down velocity. So if we can improve the quality coming into that integrated testing phase, our velocity will be quicker.

We push teams by asking: Where is your CICD? What is your test regression focus? What do your unit tests look like? Are you integrating every day? Are you building and deploying to a lower environment every day? If not, why not? It’s hard—you get dragged into the reactive all the time.

Q: Do you ever face pushback from development or other teams, and how do you handle that?

Pete: Part of it is my personality and my experience. I don’t find a lot of people pushing back. As the quality function evolves, I think of the developer function as one of my customers. Having empathy for their plight is one of the keys. It’s about helping them achieve their goals and framing it that way.

Q: What prompted you to build a QA center of enablement, and what made that model successful?

Pete: Not all program leaders or project leaders are required to use my team’s services—they’re not mandatory. You can skip IPT and performance testing and do those functions locally. Depending on the scope of the change, it doesn’t always make sense to go through these centralized functions. It’s more about enabling teams that need it and managing risk.

Here’s what’s important: each product engineering team is accountable for the quality of their product. We’re actually not accountable for quality, which takes pressure off of us. They’re also encouraged to use us because they don’t have to pay for us—we’re free to them. That’s not always achievable in organizations, and I worry about it. If each project had to pay for my services, they’d be incentivized not to use them.

We’re a fixed, high-skill, high-experience team. The average engineer on my IPT team has been working at Best Buy in testing for more than 10 years. The level of knowledge these individuals have in our systems is critical. When somebody joins our team, it probably takes about two years before they’re actually providing value. Long lead time, scarce resources. So we manage and prioritize the work that comes in, and we’ve been in a position to turn work down.

Q: What governance standards or processes are essential when QA operates across many distributed teams?

Pete: That diversity is actually the primary challenge because we don’t have standards and governance around software development processes across all teams. That’s changing—in 2025, under my boss’s ownership, we’re introducing standards and governance processes for software development.

Previously, each team could choose their own technology and development processes. At one point, we had some teams doing agile, some doing waterfall, teams working together where one was waterfall and one was agile. That led to a great degree of conflict in how you develop, deliver, and test software systems.

We’ve slowly put the vises on this. Engineering leadership and the VPs all want to be able to move engineers to where the most valuable work is. We can’t afford to have teams sized everywhere at the level they can deliver across. We’re looking at different organizational concepts where we bring the size of each core team down from 12-20 to maybe four or five, then build cross-functional engineering teams that can work on different projects—front end, back end, supply chain.

The better we can get at standardizing our processes, our tools, the technologies—we need everybody working in the same language, maybe in the same IDE, singing the same song. That’s cultural change, which is the bigger thing.

——-

A huge thank you to Pete for joining us and sharing these valuable insights from the trenches of enterprise QA. Stay tuned for Part 2 of our interview with Pete, where we dive deep into AI’s impact on his team, quality assurance as a whole, and why he believes we’re in the midst of a transformation as significant as the shift from saddle-making to automobile manufacturing.