Quality and Cross-Functional Teams

I’m a fan of cross-functional teams. My main reason is that the different perspectives that each person brings from their respective areas of the business helps create a more complete vision of product and performance risk. Part of quality (and design!) means assessing and managing risk, and I’ve seen time and again the power of bringing people together: better understanding, greater alignment, and improved designs (to name just a few). 

There are challenges with cross-functional teams. In these articles I reviewed (and personal experience), the challenges centered around conflicts, not being aligned with the same priorities, no end-to-end project leadership, and not having a system that everyone worked within together. Below are some articles I was reading, about cross-functional team dynamics and ways to set them up for success.

75% of Cross-Functional Teams Are Dysfunctional by Benham Trabezi. He proposes a Portfolio Governance Team which uses end-to-end accountable leaders for each function and for the project.  

Solver Teams — Hyper Agile & Well Oiled Execution by Ajay Shrivastava. He takes a perspective from a software developer role and recommends a Solver Team approach where every team member is accountable together and they each lead their respective stages of development.  

Working With Cross Functional Teams: Master Effective Collaboration in the Workplace by Vinita Bansal. She reviews four common pitfalls with cross-functional teams, but then proposes six best practices, one of which is to establish a process for the team to make decisions, up-front. 

A Quality Engineer or Reliability Engineer may be part of a cross-functional team for a project. A Supplier Quality Professional, Calibration Technician, Quality Technician, and Quality Inspector may not be, but they are performing functions and duties that have an effect on the success of a product design. Part of being an effective team is knowing what the other teammates are responsible for doing. It’s important because we need to know who to ask or interface with at certain points in our design process.  

Different companies organize their personnel in different ways. A Quality Engineer in one company may be responsible for or performing slightly different analysis than a Quality Engineer in a different company. But there are some high-level similarities so, generally, we can talk about these different quality functions from information that’s off of ASQ.org. The ASQ is a certification body that provides certificates for these quality functions. For designers, there are six quality folks that would be good for you to get to know: Quality Engineer, Reliability Engineer, Supplier Quality, Calibration Technician, Quality Technician, and Quality Inspector.

If you’re in product design, you’re probably working closely with a Quality Engineer. A Quality Engineer understands quality evaluation and control. And they understand product, process, and service. They help develop quality control systems and have the ability to use metrology and statistical methods to diagnose and correct improper quality control practices. They’re probably the ones that are making sure that the project is following and complying with the internal quality standards, SOPs, and work instructions (Quality Engineers might be the ones that are holding you accountable for making sure that technical design review gets completed). They also help set up test procedures, perform test analysis, and may help with inspection procedures.

A Reliability Engineer is a little bit different than a Quality Engineer in that they are focused on performance evaluation and being able to predict and improve your product or your systems’ safety, reliability, and maintainability. They help with prediction, estimation, failure mode and effects analysis, and the development of a reliability test plan for your project. They help apply mathematical modeling to test results and can help with design and performance improvement. They work with reliability program management over the entire product lifecycle.

A Supplier Quality Professional works within an organization’s supply chain and its suppliers to continuously improve performance of key system components. For example: increasing the lifecycle, reducing scrap, or improving repair processes. They implement process controls and help develop quality assurance plans. As a designer, you’re probably interfacing with the Supplier Quality Professional when you’re identifying new components for either existing suppliers, or you’re trying to identify or validate new suppliers.

A Calibration Technician is someone who is important in making sure that the test equipment that you’re using for your verification or validation tests are performing as indicated. They test, calibrate, maintain, and repair all the test equipment for conformance to established standards. A Calibration Technician can help you identify equipment for test in your verification procedures and help you better understand the limits of performance of some of that test equipment.

A Quality Technician is someone who helps prepare inspection plans and instructions, select sampling plans, and prepares procedures. They can help get you up and running when it comes to transfer to production. They can help you identify the best ways to inspect for a critical feature or critical part.

A Quality Inspector is someone who is working in the laboratory. Talking with a Quality Inspector could help give you insight on how to perform your test for your test method validation and also creating a protocol with acceptance criteria that makes sense and can be interpreted accurately.

Some insight from this blog:

  • Learn who the quality folks are on your product development team. Within your organization, understand their realm of responsibilities and what they typically do.
  • Engage them and get them involved at particular times during your product development because they have the skills and a unique viewpoint for us all to make products others love, for less.
  • Consider how you’re functioning within your project teams. Are you trapped in a common pitfall? Is there any advice you can implement from the article authors? I think my favorite was to create a process for decision making (resolving conflicts) up-front.