The Pragmatic Perfectionist

I used to think of myself as something of a perfectionist, and made a virtue of it; I wouldn't do that now. Increasingly, perfectionism - or at least considering oneself to be a perfectionist - is seen as a vice rather than a virtue. The somewhat disingenuous notion of claiming - in a job interview perhaps -that one of your faults is perfectionism, is now more commonly seen as exactly that - a fault - rather than a desirable quality. The impression that the so-called perfectionist is endeavouring to portray may be of the meticulous worker who shows incredible attention to detail, is diligent and will not settle for second best, and who is therefore a desirable asset for any employer; they may instead be creating an altogether different, and largely unfavourable, impression.

To many - and this is a feature of almost all articles about what not to put in your CV and what not to say at job interviews - the man or woman who claims to be a perfectionist is going to be labelled a nit-picking pain in the backside; annoying and obsessive and generally not good to work with. And to a large extent that is right, perfectionists are likely to be fixated by minutiae, unable to see the bigger picture and so focussed on getting everything just so that they are unable to finish tasks and thus risk missing deadlines.

There are some jobs in which being a perfectionist must be an asset. Given the choice I'd prefer to be operated on by a surgeon who was a perfectionist rather than one who went about his work with a "That's probably good enough," sort of attitude, but in many jobs and professions, there gets to a point where increasingly delving into detail and worrying at tasks adds little or nothing and can be detrimental. Often the point is reached when further tinkering and tampering actually impairs the process or product; a sort of diminishing return.

I once worked with someone whose role, among others, was helping to design process flows, and anyone who has done that sort of thing (and I have) knows that in analysing a process or activity, there comes a point where having covered all of the basics and important stuff, you reach a state where anything else that gets added merely makes the thing more complex and introduces potential failure points without adding value. And this person, in their eagerness to cover all the bases, in their quest for perfection, would frequently need extended deadlines and would often design processes that only they really understood, included unnecessary functionality and were impractical to build.

There is a fear of failure with some people that drives them to constantly refine, fiddle, and tamper to the point where their search for perfection actually contributes to their failure. Nowhere is this more evident than in sport, where teams - or individuals - may, when they are going through an indifferent spell, and are making simple mistakes, try to cut out those errors by getting everything 'just so' and make matters worse. The golfer, whose putting has gone to pot could be an example, or the footballer for whom the goals have dried up; both will over compensate and try too hard. The golfer gets the yips and three putts from a foot from the hole, and the striker takes an extra touch just to be sure and is tackled. Striving to be perfect and to eradicate mistakes sometimes achieves precisely the opposite. It is at times like these that the perfectionist needs to think of another word that begins with P, and that is pragmatism.

One of my many jobs working for HSBC was system testing, taking the application that the programmers had built and making sure it worked - or more precisely, trying to break it, trying to use it as it would actually be used in the real world and see what it did when things went slightly awry, or when the system was asked to do something that it had not really been designed to expect. With virtually everything we touch these days being based on one computer system or another, when we are all so reliant on our smartphones and the apps that they run, software and system testing is becoming more and more important. There are lots of tools for the tester, and testers themselves are highly skilled, sometimes as skilled or even more so than the people who wrote the code they are testing. But when I started testing it was in a quite informal environment and the way I learned to test was quite unstructured, albeit that it was taken seriously. What I quickly realised was that in most cases, when given something to test, covering every possible scenario was out of the question because it could not be done within the deadline- and anyway, my experience has been that you no matter how much you test, once a system or a program goes live, some user will do something you could not possibly have thought of!

That is where the pragmatism comes in, dealing with things realistically, making decisions based on practical rather than theoretical considerations, and accepting that sometimes perfection isn't possible. For instance, I once worked on a project for which the bank brought in a highly paid team (much more highly paid than us mere employees) of external testers to work on an automated process that was being developed. They spent about six months testing (with the team they had, this worked out at about three man-years of testing) this automated process, while I was tasked with testing the manual equivalent (that is, the exceptions that did not automate).  They tested every conceivable scenario - and some that I was at great pains to point out to them were not actually possible. As far as I remember, they never really finished the testing.

I was given two weeks to test my piece...on my own. I did it - it involved some very long days - and at the end of it, the manual process went live...and the automated process did not. The stuff I tested worked -with a few inevitable glitches, some of which were with the mainframe side of things rather than the user interface or the actual functionality that I had been responsible for testing. And the only reason that I managed to get it tested and the bugs fixed within the deadline was because, rather than insist on perfection, I was pragmatic. There was a point I reached when I had to chose between meeting the deadline with a product that worked well enough or missing the deadline to squeeze in a bit more testing...and missing the deadline wasn't an option.

There is a difference between attention to detail and perfection, and I'm a great believer in the Pareto principle; about 20% of your effort will cover about 80% of what you need to achieve, and the other 80% of your effort will be spent on the last 20%. Sometimes that extra effort brings such a marginal reward that it isn't worth the time. The pragmatic perfectionist who applies the Pareto principle allied to attention to detail will always be more effective than a straightforward perfectionist, because ultimately, the pragmatic perfectionist gets things finished.