Dreaming of Quality (Engineers)

I love mentoring and teaching for many reasons, but also because it forces me to clarify my thoughts. Planning today's 1:1 with one of our QA/QC engineers helped me realize what I really want from a QA/QC engineer.

Let's start with something familiar: software engineering.

Software engineering is fundamentally about problem solving. It's not about fancy programming languages and frameworks and certainly not about typing. (So stop optimizing for screen time.) It's about finding a good-enough solution to a problem.

So, now we have QA engineers and they assure quality. QC, then, is about controlling quality. So far so obvious, but what's at the core of those disciplines? We'll have a look at quality control first.

It all starts with knowing how bad it is. Goes for your toothache, your squealing engine, your software about to be deployed. QC is the dentist telling you: “You've got a cavity in that tooth. Do you want to fix this?”

And here we're at the core: it's about the question! It's about you being able to make a decision because you know the problem. If QC does their job, you can make an informed decision what to deliver to your customers. Without QC, well, you hope for the best and good luck.

There's a ton to be said about what skills are useful for a great QC engineer—we'll get to that some other time.

After QC has figured out how bad it is, QA steps in and says: “This is crap and not going anywhere. But that, QC said it's mostly okay, so let's ship it!”

Barebone QA is about enforcing a minimum standards by saying: no.

(Hint: If you're QA and you say “no”, and nobody ever listens, and you can't make them listen either, then you're not assuring anything. You're measuring. It's called … QC. Welcome to your new job.)

Barebone QA just says no and that's it, but great QA remembers and follows up: “This is usually crap, so how can we improve this permanently?” And then they make sure that improvements happen. QA is concerned with the process, and it's an exciting topic to look at, but we'll get to that some other time.

QA helps improve the process, but fundamentally, it's again about the question: “How can we improve this permanently?” Yes, you need to know whether the output is usually crap so you can ask the question. But in the end a team assures a certain level of quality not by rejecting flawed results, but by constantly producing adequate stuff. Why? Because each rejection of a feature about to be shipped lowers your throughput. If you don't get anything done, how does that help?

So, with QA in great shape, the level of quality constantly rises. Hurra…wait, what? Nobody wants that! The thing is: quality is great, but it comes at the price of speed. Especially startups, they don't want too much of it. They need to be fast to survive. They want enough quality, they want adequacy. There is such thing as too much quality after all.

Who makes sure of that? Who takes care that the quality does not go overboard, that the level, measured by QC and kept in line by QA, is barely enough, not more, not less, but precisely adequate for the business?

Could be the CTO, the CEO, the leadership team who decide how much quality is needed for business. Ultimately, it's their responsibility, right? I don't think that's a great answer because I think it's a bad idea to let people delegate their thinking. Let's step back one second.

We need someone to make sure the level of quality makes sense. That the features and fixes we ship don't have too much, nor too little quality. That's a thinking task, not a doing task. If you get it wrong, then ensuring the quality is meaningless, even counter productive, because the further away you're from adequate quality, the more you hurt the business. It's really important to get this right.

And because it's important, this task should not rest on one person's shoulders. One person goes on vacation, gets sick, gets run over by a truck. As a general rule for any manager: don't let your team delegate their thinking to you. So, who then?

More than control, more than assurance, this is about figuring out how much quality is adequate. How do we call this role, this responsibility? Unfortunately, after this crescendo I'm at a loss for words. Quality Adjustment Engineer? Mmh. Quality Determining Engineer? Meh.

Anyway, combine all those three roles together, and we've reached the height of my current dreams on quality: the quality engineer (QE).

You start by giving the quality engineer a set of business and technical requirements. The quality engineer crunches the requirements and figures out the minimum quality needed so the software can be shipped. The QE then steps forward and helps put a process in place to make sure your engineers regularly deliver that adequate quality. (QA) Finally, the quality engineer crunches the software being produced, and measures the results (QC).

Figuring out adequate quality is fascinating and I've some ideas, but this, too, some other time. Coming back to the beginning: Quality engineering is about asking questions. And it's about knowing which questions to ask, so the company in the end wastes as little time and effort as possible.


Thanks to Rianne Caballero for helping improve the draft!