It is fair – and not in the slightest bit unusual – to say that we have been struggling to apply our resources properly of late. My office is nominally dedicated to product development - but, with our well-appointed laboratories on site and our general level of expertise and “seen it all” experience, we’ve ended up having a whole pile of test and validation work to plough through, which, as I’ve pointed out in the past, I personally don’t view as one of this engineering life’s great driving forces.
{An aside: ensuring that your development team is focussing on its job is a perennial battle: a recent article in the Economist on the future of work points out a study done by Pfizer in 2008 which showed that its most highly skilled employees were spending around 20 - 40% of their time on routine work. Now, if I could even get up to 20% development work, I’d be happy…}
Roll up! Roll up! Become a validation engineer!
So - I want to be less involved in validation. This means I need somebody else to do it for me. I’m not a marketing type by any means, so enthusing about something that I despise doesn’t come naturally - but I still need to think through how to “sell” validation to someone else. I need to think things through, which is the general point of a blog, unless I’m very much mistaken - so here goes:
- There are plenty of people who like little more than running around organising things - defining who needs to send what to whom and by when, then chasing up on all those leads.
- There are others who have the ability to create, track, update and check off tasks in lists.
- There are still others who enjoy the mechanical challenge of getting parts to fit into unnatural environments (we don’t necessarily design parts to fit into test chambers)
- There are plenty of people who feel important when they get to put a “pass” or “fail” stamp on things.
- There are engineers who can lose themselves in reading and understanding specifications,
- And there are those who are happiest with the prospect of endless work without much in the line of variation.
A validation engineer needs to combine all of those attributes.
That’s me in the mirror
So which of these attributes don’t I have? Well - to point out the obvious first: I can work on validation (successfully, too, it would appear, as I keep on getting more of it to do!) - I’ve done it for year upon grinding year. I fail dismally at routine and at repetition (validation often requires testing the same set of combinations over and over, from different production locations or tooling sets, for example) and I really have to force myself into ordering precise numbers of components, counterparts, etc, force myself into counting the parts that arrived, and figuring out how to fit them into test equipment.
But it’s largely a condition that borders on the philosophical - validation is at the wrong end of the engineering spectrum for me: it should be the crowning “dumb” step at the end of all the concept, specification, definition, understanding and testing work that constitute the development of a product into something produceable in series. It is validation as in rubber-stamping: this is a valid product; it does what it was expected to do, namely – meet specifications.
Meeting specification is the go gate for product in the “physical” world – not release into the market. We can’t iterate as quickly as app writers can, but also smartphone apps don’t generally have the potential to kill people if they go awry. So the biggest task for an engineer in the traditional industries is to write a cogent, coherent, consistent – and legible – specification that can act as a realistic hurdle and as a decider between good and not good product.
Then, other engineers need to read those specifications. Alas, the percentage of humans who have actually read through, understood and organised test work according to specifications is as vanishingly small as the number of people who actually wrote those specifications still being in that role.
Let’s validate - something - quickly!
As soon as someone, somehow (often based on arcane and mysterious procedures – or company lore – or on a whim) decides that validation testing is required other than as the natural end of a development programme, chaos ensues.
Emails are sent expressing urgency, whilst tacitly acknowledging cluelessness regarding how actually to proceed; priorities are dumped on the already overloaded yet ever-helpful testing team – and above all, the sense of the emails is one of desperate hope. Hope that responsibility can be abdicated, that no further questions will be asked, that no sample parts need to be organised, that timing will be according to promises already made.
Of course validation is urgent, and of course it’s important – in our world you’re simply not permitted to deliver (or be paid for) parts that have not satisfactorily completed validation. It’s just that, for a development engineer, validation (as opposed to development testing) is dull, dull, dull.
There, I said it.
Finally, though, we managed to get some outside help, and we hired a student – more about which in the next post…
