Lose Yourself to Engineering?

It’s fairly safe to say that 2013 was Daft Punk’s year. They brought out, to great hype, fanfare, and reviews their latest album, Random Access Memories, which made it into third place in The Guardian’s “Albums of 2013” list, behind John Grant’s Pale Green Ghosts in second and - in their opinion - Kanye West’s Yeezus in first (for the record)°.

I listened to Random Access Memories intently over the weeks following its release - and hated it. Then I loved it, finally settling for an awed respect. Nobody could put it better than Sasha Frere-Jones at the NYT: “The duo has become so good at making records that I replay parts of ‘Random Access Memories’ repeatedly while simultaneously thinking it is some of the worst music I’ve ever heard… Does good music need to be good?”

The opener, Give Life Back to Music comes across as an all-too respectful homage to 70’s funk, without adding anything to new to music at all. Yet, filter away the actual tune, inspect the nuts and bolts of the whole album and you’ll find so much to admire in the way it’s been assembled. It’s a damn fine engineering job.

Music is my main hobby, so with access to all the power that Cubase provides, I could conceivably compose and then produce something along those lines (though I emphatically don’t work in that direction).

Despite those bold words, though, I’m still fairly terrible at production, which is music’s engineering. A music producer (or audio engineer, as they are also called) has to work on ensuring that:

• voices (human or instrumental) have their own place in the mix,
• are clean and tidy, or dirty and scruffy, as desired;
• no frequency is overloaded, or uncomfortable to the listener

As I say, I’m not very good at it. Whilst I can appreciate a good mix, I tend to desensitise my own ears by overlistening to my own mixes, always wanting more (when less is by far the better way) andthereby muddying the sound to a point where it sounds acceptable to me on my own headphones, but is a disaster on loudspeakers, for example.

Music production consists as much of a workflow as product engineering does and goes something like:

• Audio mixdowns (exporting each track, whether synth, samples, humans or tubas into an audio file)
• Post processing:
• Panning
• Levelling
• Equalising
• Loudness
• Compression
• Distortion
• Reverb
• (and much more)
• Testing
• Ensuring that none of those frequencies are overblown
• Making sure no voices are lost
• Validation
• pre-mixes
• album-wide sound levelling
• Final mix
• mastering and publishing
• (gulp!)

For each step, the producers have a vast array of tools at their disposal for each step, but final quality control can’t be quantified away - it’s still in and between the ears.

Daft Punk had three things going for them in this intrepid exercise: lots of experience, a huge budget and a big team. Now, whilst the duo weren’t short of a penny or two given their back catalogue, it was still a massive investment on their part to go down the rout of maximising the human aspect of this album. It ended up being a massive, globally managed project, with all of the collaboration, communication and data transfer challenges that such an enterprise generates.

And all of that for, musically, a rather dull record.

It takes me back, perhaps controversially, to my days working as a packaging engineer at Ford. It was part of my graduate induction programme at the company and, if I’m honest about it, I felt that it was somewhat beneath me. Putting parts into boxes? What’s “engineering” about that, then?

All of it. It was, in reality, a complex puzzle that needed to be completed against time whilst ensuring the safe arrival of pretty much each and every single possible component in a car after transportataion across half the world, with all conceivable qualities of route. More than that, the product and methodologies were endlessly optimisable.

So, working as part of a large global team, with a big budget, complex problems to solve, worse problems lurking behind any cut corner and bad, vending-machine coffee on offer, I came up with… a cardboard box.

If you’re in that situation, too, remember Daft Punk and Random Access Memories - your product may, superficially, be dull to much of the population, but, if you end up Doin’ It Right, it will sound great.

Happy 2014!

°(alright, and perhaps for a small boost in search engine findability, too… :-))

As opposed to engineering with hectic grumpiness

Ah, finally - it's the Christmas holidays. At last, I've a chance to divert the kids into the path of their doting and understanding grandparents, then to sneak upstairs for a spot of stolen quiet-time. Time for switching off, for thinking and, in not too big a dose, writing.

Time for calm, quiet reflection is an astoundingly rare commodity. It has to be cherished and nurtured wherever possible, especially in that most unlikely of environments, work, where we happen to spend a goodly chunk of our lives. Reflecting on the the year that is petering out as I write, the biggest theme for me has been focus, or how difficult it has been to apply it with any regularity, and asking why I've not been successful at blanking off the world to exclude everything and everyone save the task to hand.

In the hustle and bustle of this engineering world that we inhabit, it's easy to get caught in the undertow of "actionism" (from that great German word Aktionismus) - doing stuff, doing more stuff, doing the same stuff again, doing more of the same stuff slightly differently; all of it urgent, most of it dull, mostly simultaneous, all of it with consequences for colleagues, suppliers and customers that mean, under the circumstances, we're unable to say "sod it." We're lynchpins without the luxury of deciding our priorities. Well, that's how I've been of late.

So, making use of this Christmas calm, I've tried to slow down, to reappraise how I - how we - work as engineers. The goal, I have decided, after a few sips of tea and a little staring out of the window, is that we must be able to work with grace, patience and precision.

This may sound like a whimsical, romantic view of master watchmakers or coffee roasters at their most reflective - but there's no way around it: it's the best way to approach any task. So let's have a think about what each of those concepts mean, and see if they make sense.

Grace and patience

Grace and patience are the rhino hide protecting the core of precision, which is the aim of any engineering activity. When they are too thinly applied, actions and deadlines chip away at the "precision" aspect of what we do. If we lack precision, then it's easy to become rattled or ratty when our decisions are questioned.

Grace is the ability to take on board what a task or a product requires, as communicated by people or by circumstance - or, as is more often the case, as not quite communicated by people or by circumstance. Grace means:

• Not being caught up in the emotion of the action
• Not being ruffled by the urgency of the action
• Retaining the ability to think clearly
• Retaining the ability to call in help and assistance from others without transferring the "panic"

... all the while, if possible, without becoming aloof, or putting on the "insufferable smile."

Patience is very much linked to grace, but means having the inner robustness to delve into a task, to keep at it, to maintain the ability to ask the right questions, to wait for the right answers as they develop. It is and requires:

• the ability to focus on a project
• the ability to "plod" through the logic of a project

Precision

Precision is the mark of getting things as right as they can be. It doesn't mean perfection (of which there is very little to go round), but rather getting the small things right, even if it's a version change to 1.1.2, so that the big steps can also be taken later. There are hundreds of examples that I could list, but in our world, understanding tolerances, GD&T callouts, specification callouts. etc spring to mind. They need to be defined them correctly in the context of your product.

Note that I don't mean setting tolerances arbitrarily small - precision is a result of the discussions with production, with suppliers, with customers, in the spirit of grace and patience. Getting things right, properly, defensibly.

Discovering the environment of grace and patience

A corollary of all of the above is that we as engineers need the environment in which to work with grace and patience. I would love to be able to say that we should be developing everything in splendid isolation from business needs. Like an AT&T Bell Labs from the glory days of transistors and lasers, or a 1960s IBM, we should be capable of working on the future. To be honest, though, I can't even imagine working in such a world. It could be wonderful, it could be terminally dull (though I dream it would be the former).

We need to face reality. I work in the automotive industry, which tends to be rather full of rowdy reality, so I know what it means to suffer business pressures alongside engineering and development pressures, in open-plan offices, without air conditioning.

Attaining the "state" of grace and patience in such an environment has to stem from a conscious decision to find and to nurture them first. As far as I can see, the breakthrough needs to be mental.

Without coming over too Zen, I think (but can't say from experience) it should be possible to filter out background noise and to focus on the task at hand. We can help ourselves by taking small physical steps like turning off email alert pop-ups, silencing phones and perhaps setting up "do not disturb" signals for our colleagues; big headphones, for example. Occasionally escaping to a lonely meeting room can work, though it does mean leaving a whole desk's worth of tools behind.

What I'm saying is that we (I, at least) need to be clearer of what our mental capabilities are, what we need to learn and how we should develop ourselves, our processes and our communications with colleagues (commercial, quality, purchasing, suppliers - that whole bubble world that we interact with) so that we end up being able to focus on work, permit the minimum of distractions and can take time to research, collaborate and to iterate our way to the future, all in the spirit of grace, patience and precision.

Easy job. Let's have at it in 2014...!

Why do we have quality departments? Even posing the question feels like a minor rebellion on my part, since "Quality" is such an integral concept in the business of producing things. For "integral" we can also read "taken for granted." Sometimes it can be good to tug at the tent poles of the status quo and see whether it collapses in a heap around us, or if we can move it somewhere more interesting.

This post isn't just coming from a theoretical standpoint, of course. I've had so many run-ins with colleagues from quality that I simply have to question that whole role. Too often have they acted as alarmist messengers and chasers of other peoples' actions whilst understanding neither the problem nor the product nor the processes that they are supposed to be monitoring - that is, seemingly doing nothing about it themselves. They don't add value, nor do they seem to save value - they transmit urgency. Unfortunately, transmitting urgency to the wrong sort of person (for example, me) is precisely the least good way of getting things resolved quickly and effectively.

So, whilst we all inherently understand the idea of producing things in ways acceptable both to customers and to our finances, do we really need quality departments, quality managers, quality engineers? I think we could be cannier about the whole thing - and ditch them totally.

The best way to do that would be to design an engineering company from scratch - alas, not something that I've ever done. But for me, the basic idea would be that the tasks that quality departments undertake can be distributed amongst other departments where those tasks make more sense.

The flip-flop question is this: is it better to decentralise those tasks amongst experts, or to collect them all under one roof and standardise? It may well be that the size of a company - tipping around a certain critical morass - is probably a key factor in this decision. But the prospect of ISO / TS audits should not be!

I work for a largish automotive supplier, and we have quality departments coming out of our ears: it's the world I live in. Deleting them (distributing them) would mean for me personally that I would need to get my designs, from material selection through to defining tolerances, just right; my colleagues in production would have to design their processes to produce within the parameters of the drawings and specs I give them and that all needs to be validated and monitored.

In other words, nothing: eliminating the quality department would have no effect on my key role, nor on the role of my friends in process engineering.

However, I'm forever getting involved in quality concerns, analysing returned or quarantined parts, performing root-cause analyses. This can help me understand our product better, but rarely have I had to change a design as a result of these investigations. Enfolding one or two of our colleagues from quality into our test and development organisation would mean that those defects could ben analysed as thoroughly as they are now, and lessons learned could be centralised, whilst freeing me to work on the next generation of products, which is what, I believe, I'm supposed to be doing.

Manufacturing will still need people and systems to check and to confirm that product meets requirements, both at any given instant and over time - that's for sure; such roles will never go away, but these days we can trust our production team's integrity to manage that by themselves rather than abdicating that responsibility to a separate department.

The role of a quality department as independent arbiter, a kind of internal auditor, remains an interesting point: can we be sure that Manufacturing, for example, will always be open and honest enough about things like tool release decisions and scrap rates when deliveries or performance indicators are on the line? Well, if we can't be sure then it would surely be beneficial to work on the culture of the company rather than to add layers of oversight. Again, it's a question of opportunity cost - would it be more effective for a company to pay people to police their own people, or to research and to produce things more effectively?

If we think (or click) back to my post on how Google tests software, we see that the key philosophy there is: the design of the product should include its testing and confirmation methods. So it should be the  product and process design engineers designing this together, which makes sense to me.

And where would the resources come from to ensure that product and process design could cope with that additional work? From the now redundant quality department, of course.

That leaves the audit side of things. Of course, nobody wants to be involved in audits at any stage. But since audits are a fact of life in many industries, the product and process design teams need to be involved in designing the business systems that they use on a daily basis to use, store, distribute and to archive work. And they should be responsible for proving that these ways work both in theory and are used in practice.

So, eliminating quality departments, partially reassigning them to design and development, is the obvious answer to all of this - yet quality departments seem to grow and grow where I am. Am I missing something obvious that would really justify the existence of quality departments? Or can we continue to "Think Canny" in this funny old business of engineering?

This post was first published over at Engineers Looking For Stuff, to which I contribute every now and again. I enjoyed writing this one so much, and it's so pertinent to the way that I think about engineering, that I asked and received permission to republish it here. They are my words, after all!

Engineers have an often uneasy relationship with words. The common assumption is that if left to our own devices we'll mangle grammar, butcher words and generally leave a trail of linguistic destruction in our wake. This is largely unfair, as stereotypes tend to be, but we are rightly better known for our smithing of iron than of prose. If we think about language at all, it's usually in the sense of grudgingly having to cope with it, or even wishing it away: "we shouldn't bother too much about writing - it's the product that counts."

It's true that product reaching customers is the goal of all our efforts, but words play such a large part in helping us get there that it would be a shame to scurry away from them, as if they were rain and we had no umbrella.

Instead, we should embrace words, using this rain like farmers rather than bankers - because we use them a lot. In our concept proposals, our offers, our specifications, our emails, our reports and even on our drawings, words carry meaning and intent to others. And, usually, these documents have our names on them, thus tagging us as author for eternity. How often does our product do that? (The makers among you rightly have permission to feel smug at this instance - but that still doesn't exempt you from having to use words!).

So pride in a job well done, in the knowledge that good communication leads to good product, should drive a conscious decision to get our writing up to as good a standard as we can - which, of course, means work.

Whether I'm drafting a blog post or a test report, I often feel my mind racing a few words ahead of me, sifting through multiple cascades of options and meaning, every so often stamping on the brakes as I get stuck with a word that hovers on the tip of my (mental) tongue. Even after that flurry of activity, what I "splash" onto the page needs refining, to ensure that it makes sense and - in deference to the reader - gets to the point relatively quickly and painlessly.

This is what I mean by effort, and the onus of that effort should be on the writer. We have to communicate, and, no matter how good we are at sketching and drafting, we can't escape having to deliver words to others. These words carry meaning and other more subtle levels of meaning: the tone.

All of us write differently depending on the scenario. So, whereas I use the word shall all the time in specifications, you'll hardly ever see it in my emails.

Whilst specs and drawing call-outs should be dry and almost legalese, riding as they do on the precise definitions of the words we select, emails can be chattier, depending on your audience. It's always worth considering your emails to be formal documents, however; they have a history and you'll be amazed how often emails from six years ago crop up when you or others are searching for information on a project or product. That's the positive spin on this: there is the negative aspect, that you no doubt can also imagine. So always review before sending (think of that "send" button as "Publish Now" and see what an effect that has on your haste).

The spoken word sets the collaborative tone even more starkly. Face to face there are the immediate signals that everybody sends with voice, body language and participation (or lack thereof) in the discussion, which go beyond the scope of this post, but there are subtle, weasel words that can affect the way people think about their jobs. Indeed, these were the catalyst for this very post.

It was in a project meeting a while ago that I first really noticed them. The product required some pre-assembly of a threaded adaptor and the commercial manager piped up with the comment:

"Then you simply need to screw in the adaptor…"

There it was, that word, "simply." It suddenly struck me how belittling that word was. To him, that assembly was a value in cents. To us it meant: determining the right tightening torque and number of turns, specifying, trialling and commissioning the equipment, specifying control methods, setting up a PFMEA… You get the idea.

Since that meeting I've become very sensitive to "simply," "only," "just" and their ilk and always point them out to those to carelessly utter them.

We have to watch out for those words everywhere. Imagine what real meaning lies behind the innocent remark "we only changed the process parameters a little bit…"

We should eliminate "simply" from our vocabulary (and help others to do the same) not in the spirit of saying "everything is hard", but in the spirit of "we value your expertise, we want you to keep on mastering your work, improving it, and yourself. so that our product can rock even harder than it does now."

What's in a word? That much can be in a word.