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 transportation 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…!

…an attribute which this post could not be accused of possessing

Cycling back home from the industrial estate where I work in an otherwise romantic Heidelberg, I cross a bridge that soars over a main road with its gemütlich evening rush hour jams, and, in the same leap, over an idyllische railway line to Mannheim. The bridge, though acting here only as the scenery for the introduction to this post, would be worthy of a blog post itself in the hands of one more knowledgeable and appreciative of its design. It is certainly more complex than normal, with a second cycle path spiralling up between road and rail to meet mine.

The thing is, when I’m cycling back from work, this tributary deposits riders cycling up it directly onto my side of the road. This isn’t of itself a problem - I can move over to leave them room. But when I do this, we both end up cycling on the wrong side of the road, also known in England as the correct side of the road.

Over the years I have imagined myself commenting to the other riders: “Oh, you’re English too?” Only I’ve never dared. Not only because I’m quite so brazen, but because the grammar of saying it in German is so tricky to get pithily right that we’ll have crossed before I’ve had a chance to parse it, especially if the person on the other bike is a lady.

Yes, it is with a weary sigh that I note that German, like Latin and some others I could probably research for you, is a language that feels the need for three genders. Echoing our stereotypes of German structuredness, the language can be viewed as a series of matrices, with lattices of cases and word endings that can either be viewed as ladders to a higher plane of language, or linguistic snakes that will land you in grammatical trouble wherever you misstep.

Mark Twain certainly had great fun pointing out the bizarre logic of this supposedly highly logical language in his essay “The Awful German Language”

What this baroque structure does offer is an unusual form of efficiency. Word endings become signifiers to what action is being done by whom to what, if at all. So, in the name of efficiency, I could refer to an English lady as an “Engländerin” - two distinct words implicated by the ending of just one.

The flip side of that efficiency, however, is a certain fragility: if, after drafting a phrase, I want to change the subject noun to a word of a different gender (or, in the more likely scenario, I find that the gender I had assumed was wrong), I have to wade back through the whole sentence, changing and correcting word endings scattered throughout it to something different. If I was fed up with Eine kleine Nachtmusik  I could go for a small nightcap instead - Ein kleiner Schlummertrunk, meaning I have changed all three words in that sentence (and that’s without the accusative case of me actively wanting one, which would end up as Einen kleinen Schlummertrunk…)

So German and its relatives are efficient when things go right, but each error results in a cascade of compound grammatical catastrophes. I find English to be more robust to errors: a glitch in one portion of a sentence doesn’t have to mean a complete rewrite. “The” is “the” whatever grammatical chaos is going on around it.

So this post is really all about efficiency and where it should be applied.

There seem to me to be three distinct strategies available:

• Being highly efficient in one way
• Being efficient enough in multiple ways
• Enabling functionality in as many ways as possible

Mechanical components are generally efficient in one way, but if they go wrong, they are broken and need to be replaced. Highly-strung systems will also break with the loss of a first component, and may even result in losing a chain of components, as in a German sentence.

Systems can add robustness through redundancy. This is generally at the cost of efficiency, but usually can be said to be efficient enough.

Enabling functionality in multiple ways is reflective of the organic, of the free-form, of the gnarly - yes, of language, too. It’s not often possible to attain this in mechanical engineering - I’m struggling to think of an example here, but perhaps sacrificial anti-corrosion coatings is one, where a scratch leads to corrosion of one material that results in the protection of another.

But when we’re designing our product, irrespective of its apparent simplicity, we can always consider the efficiencies going on around it. We need to design for safety, for cost-efficiency, for energy efficiency - for a product’s whole lifecycle. And if we can step away from the fragile and towards the organic in considering the world our product inhabits, we can perhaps go a long way towards attaining the maximal efficiency over the long term. Nature managed it, anyway!   Escaping from the semi-philosophical and going back to my bike problem; because of this ability in German to feminise words, either I could ask “sind Sie auch Engländerin?”, which would be efficient, but would, through that word auch meaning also imply that I was also female, or I could ask “sind Sie auch Engländer?” implying that she was male.  Mixing things up to avoid the problem ("kommen Sie such aus England?" - do you also come from England?) would be an option, but none of the alternatives is as concise as the original thought.

So I have never dared ask… And I expect that’s fine by the good ladies of Heidelberg.

From the relative safety of landlocked Heidelberg in Germany, I’ve been keeping tabs on this year’s Americas Cup sailing race. With a whole pile of relatives in New Zealand I was of course rooting for Team Emirates New Zealand, who just came up short after leading so convincingly and for so long. Ultimately the rapid development of both the boat and the sailing team of Oracle Team USA led to the kiwis being overhauled and the Auyld Mug being retained by the Americans.

But whoever won, just look at those boats! They’re incredible, from their hydro- and aerodynamics via the hull and structures all the way through to each pump and winch… these are incredible floating and flying feats of engineering.

So for all the talk of your Ellisons, Ainslies and Spithills, let’s give a big engineering shout out to the design and development teams of Emirates Team New Zealand and Oracle Team USA. Kudos!

Now then, back to work…

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 been 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, and “explode” quality departments out to other teams?

Just before this (at the time long overdue) vacation, I was invited to attend a meeting with a technical sales guy from a supplier. Normally, I must admit, I tend to be somewhat (too) polite with people I meet on a professional basis, which can get in the way of the real goals of a meeting - obtaining information and actions. This time, though, exhausted as I was following the stresses and strains of moving house, and from lack of quality sleep during the hot summer nights, I was on a shorter fuse than normal.

And it felt great. I finally didn’t care about potentially hurting somebody’s feelings with indelicate questions - I just asked, and asked again if I felt I was getting a wishy-washy (salesy) answer. I was liberated to become a grumpy engineer: I stopped filtering myself, tying myself in worrisome knots, and got to the heart of the matter much more quickly than I would have.

So the lesson here for me was that I should try to distill the essence of grumpiness (giving waffle and muddiness of answer short shrift, wanting to get out of meetings as quickly and as effectively as possible), without having to go down the route of exhaustion or really offending my business contacts. Tips, tricks, resources on this would be welcome!

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!

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.

originally posted on one of my several now defunct blogs, called On Engineering, on 7th July 2013

Who reads procedures?

What, you don’t? Alright then, another question - who writes procedures? Ah, well, on that front, I have a confession to make: I do.

But hold on - if you’re not reading, why bother writing?

Let’s go back to the start, see what we’re dealing with. Procedures are company-internal documents that describe how things should be done. In that sense, the closest analogy I can offer is that, like the laws of the land (which I presume you, like me, haven’t read in their fullness), procedures form part of a distinct yet only subconsciously perceived scenery - barely noticed until you crash into them, or if a newcomer starts asking for directions.

That newcomer point is important: the bigger the company, the less likely it is that someone can naturally pick up and run with the workflows and networks of people and systems that combine to get things done. A start-up’s first instinct is not to write its procedures. Only when the company is established and has grown do such things begin to matter and procedures - instruction sets for beginners, for those lost in a maelstrom of work, or for those about to be audited - are written. (Rands in Repose has written a lot about transitioning from start up to big company, including and very eloquently about procedures and process in the software world)

So, I’ve written procedures. I’m not a prolific proceduralist, thankfully, and the ones that I’ve been involved in are hardly internal best-sellers, but at least I can say that whilst novels they certainly are not, I have at least experienced some satisfaction at having the procedures approved and published.

Or perhaps journalism would be a better analogy than novels - when I was writing them, there was a real sense of urgency surrounding them. There was a sense of deadline, of needing to fix something that was broken.

But with a procedure? Which nobody will read? Hmm, that doesn’t quite add up. Unless people do read them. Some few, key people who then tell others how things should work - and those others more or less understand the intent and get on with it.

Until teams drift apart, new people come in and things get broken again.

Procedures - the making of

The key to remember is that procedures are principally a work in the written language, which means they always need some knocking back and forth and into shape - editing - at best within a small, motivated and expert working group. They are official documents, so they’ll need to be given their ID numbers and released into whatever system your company uses.

Procedures are also visual documents, so a certain design aesthetic is also worth investing some time in. Even if the only graphic in there is the workflow, it’s always worth trying to make it look and feel right by considering format, colours and alignment. If it looks shitty now, it’ll look shitty in three years’ time, and it will still have your name on it!

Procedures are structured documents, too, like technical reports: Introduction, Scope, Definitions, Resources involved, the step by step guide and the workflow should all be in there.

Structure, word and graphic need to be sound in logic and clear enough to read without frustrating or confusing a reader by descending into ever diminishing circles of definition (or spiralling up its own arse in grandiose sweeps of meaningless bluster. Ah, speaking of which, I’d better be moving on here…)

What is a good procedure?

A procedure is like a process flow, but for people. Do this, then that, inform this person, file that data there, fill out this form, review with that team, finish and get on with your lives. Like a good process flow, a good procedure should capture the steps, decisions and loops that result in a final product. A process results in a part, a procedure results in information. Both should maximise output and minimise waste.

Do procedures define or describe?

Companies generally muddle by, if we’re honest about it. There are things that need to be done and, buoyed by our honest and human sense of duty usually overriding any sense of “oh, let’s just forget it and do something fun instead”, we talk and email and chivvy and stress and eventually get things to a sufficiently complete state that we can move on to the next disaster.

Procedures formalise and idealise those inner workings of a company. Going back to the process analogy above, a procedure should be designed to maximise efficiency - in once sense, it is an engineered document (hopefully with decent spelling), in the sense that defines how things work in their optimum way.

So the question above is misleading: procedures do describe, but really they should define.

Are procedures a cure or a symptom?

One key reason for writing procedures is to correct course on some workflow that is sailing onto the rocks. Often, the rocks weren’t formally recognised before, so the new (or updated) procedure is effectively charting dangerous waters.

One of the biggest balances that a company has to manage, however, is resources. Even if we were all able to live and work on one project only, and all of our team members could do the same, tensions and bottlenecks would arise. With teams being involved in the multiple carousels of projects, individuals start think-feeling for themselves, taking on tasks that aren’t strictly theirs “to keep things moving”, while others try to keep low and out of the firing line. These tensions generate ever greater emotional potential.

This is where procedures form the “laws” of the company. He should be doing this, she should be doing that, but only when given this signal or that information. They should serve to de-escalate things. If they can’t, then it’s a clear sign that the respective teams aren’t set up correctly for that combination of tasks.

Ghost protocols

Eventually, all of these new definitions and workflows become the new day-to-day and procedures are no longer referred to. Or or those new spangly ways of working fade into disuse, yet their respective procedures remain, sitting in (often a bewildering array of) libraries somewhere, gathering digital dust, crumbling as entropy attacks their bits and bytes.

The dust is kicked up by everybody’s favourite bugbears, audits. As audits suddenly loom (which they tend to do), links are checked and if they still work, are distributed, some conscientious colleagues bookmark them and may even scroll through the procedures themselves. They generally won’t read them, though.

Occasionally, an auditor will prudently validate his job description and note a discrepancy between a job done and a procedure. Hands will be wrung, failure to comply noted and efforts made to be better in the future.

By that stage, though, procedures are usually dead. They lie in state - Lenin’s waxy visage springs to mind, though without his enduring popularity. Perhaps three people in my company know where to find them. Everybody else who needs to know anything about how things should run simply ask me directly - or kind of muddle by.

Anything, of course, being preferable to reading and understanding procedures. Although: at least procedures don’t get irritable if you consult them.

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 26th of June 2013

(wow, perhaps I should become an industry marketing writer…!)

As one of the know-it-alls, I have to admit to having felt some trepidation at facing the North Americans. Our regions have been working more or less independently for the last several decades and my fear was that the Americans, with their equally vast but differently tuned automotive experience, would be open only in the expression of their hostility to our ideas.

Fortunately, that trepidation, whilst not completely baseless (I had my reasons for such thinking), did not crystallise into anything tangible, for the most part. I did notice participant numbers fluctuating during the two days of training, with some key individuals spending a remarkably small amount of time with us, even considering the typical day-to-day calls upon their time, but those who stayed throughout were attentive, asked good questions and kept us going through all the jet lag and windowless meeting room atmosphere with their overall positivity and willingness to learn.

We certainly brought new ways of thinking (though also some not so new but not fully implemented standards) to the forum, and they weren’t dismissed out of hand, as could have been the case. Having the backing of our global management team undoubtedly had a helping hand in keeping the peace there, but I got the impression that what we were presenting made sense and was difficult to argue against. The discussions were mostly about context and capabilities rather than acceptance.

My own presentations, on the engineering behind our product, and on technical problem solving, were well received, even though my first presentation went well over its allotted time. This really was the breath of fresh air that the team were looking for. Again, discussion was constructive and showed that my American colleagues were learning something that they were keen to be able to implement in their own region.

Is there a life beyond the office?

Despite the windowless conference room, which sat as an enclosed island within the sea of cubicles, I have to admit to being quite impressed by our American headquarters. It felt like a rather different company to the one I work at in Germany, altogether more professional. It exuded a quiet professionalism (aided by some careful noise damping, which is fully missing in our offices, and even a soft white noise that is intended to be filtered out by the mind, along with similar frequencies, making the whole thing “feel” quieter).

There was an excellent canteen, with a sandwich-making bar, main courses, cookies and - the pièce de résistance, a soft-whip ice-cream machine. Coffee was always available from the Starbucks bean-to-cup machines, as were various colas and fizzy drinks (in huge 12 oz. cups), with ice of course also being on tap.

Rooms with view

Alas, beyond the offices and hotel, I didn’t see much at all.

On first impressions, there wasn’t much to entice anybody out of the hotel, even though I really needed to escape - the windows were welded shut, so it was all aircon air and faintly Soviet-looking corridors. 

Accepting the company transfer from airport to hotel wasn’t a mistake per se (it was lovely being chauffeured around in a Lincoln Town Car), but it did mean that I didn’t have the flexibility of a hire car this time around - and not having a car there is pretty much fatal there…

Whilst it was all about the people this time (OK, the people, the burgers and the beers), and making contacts, not having seen downtown Detroit, Birmingham, Rochester or any surrounding scenery, was a bit disappointing. I’ll have to do better next time.

Getting to and from Detroit was fine. I was pleasantly surprised by Delta airlines (I’d always heard pretty negative things about them), but the service was very good, bordering on the excessive when the purser came to shake everybody’s hand and to thank us all for choosing Delta. On the other hand, I was disappointed by the support from KLM-Delta when my return flight from Detroit was delayed by connecting flights from Miami and Orlando. Alas, they didn’t return the favour with us in Amsterdam Schiphol, meaning that I missed my final flight back to Frankfurt.

That resulted in a jet-lag-groggy four hours in yet another airless lounge and an electronics store, where I managed not to by a new tablet on a whim.

So - the next training will be on home turf in Europe. Will that be the biggest challenge of them all, trying to enthuse those colleagues in the midst of one of the biggest slumps in the automotive industry? It shouldn’t be. The biggest challenge will be turning this initiative into a resource that will be available for all new and existing employees. That’s going to be fun, for sure - more on that as and when.

At least in Europe I should be able to enjoy more fresh air than I have in the past two trainings…

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 31st of May 2013

Yesterday, Thursday, being a bank holiday (at least in my state of Baden-Württemberg), today was a classic German “bridging day”. One day’s holiday resulting in a four-day weekend is simply too good a ratio to miss for most Germans, and I had also planned to take advantage of the bridge.

But with so much going on in so many frantic ways, with so much on my plate and buzzing in my head, I felt it was better to ensconce myself in a quiet, colleague-free office and get some work done.

I was disappointed to to see upon my arrival an office full of colleagues who had had similar thoughts, all chatting away about a colleague’s house-build project, architects and unreliable builders. I skulked off and found an empty manager’s office nearby, docked my laptop there with my own peripherals, left my cordless phone on its station and closed the doors. I spent the morning trudging through drudgery (hello, PPAPs) and then the afternoon working on DFMEAs and updating my presentations for the training I’ll be giving in Detroit in a few weeks' time.

It was great. I didn’t need to plug in my headphones, nor did I end up continuously distracting myself with the internet. I simply worked, ticking off my “Big Three” tasks for the day, plus a few “Notable Nuisances” as the hours ticked comfortably by.

It all comes back to environment. As I hinted in my post about Engineering Things Done, I cannot work effectively in an open plan office. There are always people on telephones, colleagues discussing work or debating which is the cheaper internet provider. Sometimes it’s good to get involved in the community aspect of work, that’s certain - they’re decent people, and I’ll need their support at times, too, so I daren’t become a recluse - but I need peace and quiet to work properly.

I suspect that most engineers would be better with flexible environments. We’re knowledge workers, so need time and space to think. Even when we’re dragged into quality mud-fights and validation testing, our minds should be at peace so that we can maintain our “switchability” between big picture and detail.

So - individual offices for engineers? That would be impractical. But the ability, both physically and culturally, to switch environment and context is important and needs to be cultivated.

originally posted on one of my several now defunct blogs, called On Engineering, under my persona Literally Engineering, on the 23rd of May 2013

We’re on the cusp of starting the migration of our CAD data into a full-fat PLM system (in our case Teamcenter from Siemens). It’s now becoming clear what the task ahead of us entails - approximately one thousand 3D models and their associated prints need to be collated, tagged, parametrised, renamed, renumbered and transferred.

The tagging and parametrisation will take approximately 30 minutes per item, meaning (rumble, mumble, calculators, divide by the solar transit and carry the moon) around sixty working days, for somebody (most likely not me, thankfully) working at full tilt to the exclusion of everything else.

It’ll be a big old resource hit, it’ll cause lots of anguish, gnashing of teeth and grinding of coffee - but the results should be spectacular, even if we’re “only” migrating the CAD data in this first step.

Once we start adding the life-cycle documents for each part, it will become a world unto itself. That’s for another post.

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 11th of May 2013

Engineers, like lawyers - hold on, I didn’t just write that, did I? Well, it’s a valid thought, so I’ll press on. Engineers, like lawyers and other animals, can be classified into distinct genera and species, depending on the path we take within our chosen vocation.

As soon as I had, whilst at school, settled on engineering as the subject I wanted to study and practice, it was clear to me that I was much more of a “boffin” type than a “hacker”. I was always uneasy about mending things, more confident about designing and working things out - so I opted for aerospace engineering. After graduation I went to Ford (emphatically not an aerospace company, despite its history and current CEO). There, I spent some time working in Manufacturing Engineering. I enjoyed the challenge, at times, but I wanted out, back to component and design engineering.

Who cares how it’s made?

Now, my job is (should be) to develop and upgrade product so that it does what it is supposed to, when it is supposed to do it under all conceivable conditions. Whilst it sounds almost blasphemous to say it in these enlightened days of openness and collaboration, I don’t necessarily care how it arrives at that point, as long as the how of its making doesn’t affect the if of its functionality, or its cost too much.

Of course, this means that I do have to care about the process, as it more often than not does affect the product in clear or in subtle ways. So I talk to our process and manufacturing engineers.

Who are, of course, also design engineers.

I suppose we have all settled into a kind of shorthand for engineering titles, as the word “design” is redundant. There are those who design and develop product, those who design and develop the process, and those who design and develop the equipment to be used in the process to make the product designed at the outset (process product design, or something like that!).

By and large, from my experience, process and manufacturing engineers are cut from a different cloth to product engineers. They can work together, but rarely does one stay in the other’s shoes for long. At the extremes, you could envisage the gnarly manufacturing engineer and the soft white-handed product engineer - of course, these types meld and merge, but the tendency is there, I feel.

And we talk.

Silos or troughs

Whether I “get to” talk to these colleagues, or “have to” depends on personalities - which, fortunately, engineers don’t have - but where I work, we are distinct groups that need to be brought together on a project by project basis; we need to jump those famous silos to work together, rather than always being together, feeding from the same trough - perhaps “collaborating freely” would be a better turn of phrase.

Our means of communication is still principally email, alas. Our offices are close enough to walk to, but all too often, simply waltzing into each others' enclosures means a disruption of some sort. We’re all busy people, who need to try and focus on some one thing at a time. Disturbances from outside, whilst of course important, mean a reshifting of focus from some other, hopefully equally important, activity. So to minimise the growling, we email or invite each other to short meetings, which is really the best method to have disparate minds alight on the one subject for a few quality minutes.

So, we have feasibility reviews, we cooperate on FMEAs (still too infrequently), we sketch, we negotiate (more often than not on tolerances), and we make, measure, test, update and approve our product.

We work together, in short.

Ideally, I should embed myself in their world so that my designs flow and interact as smoothly as possible with theirs, and their reflect the functions that the product needs to have. In small, dedicated teams, that could work, but currently it’s all about snatching time to work on one thing rather than another: even were I to share a desk with them, all we’d be doing is shouting over each others' telephone calls.

So I’ll stick to my “ivory tower” (as of course they call it), for the time being.

In praise of process

But from that tower, from behind this screen, I want to place on record my respect for my engineering cousins in process design. These are colleagues who get to play with robots, with sorting and sequencing machines, with presses and with tool designs; these are people who have a very rich and very different mind to my own.

I haven’t the faintest clue how to design and specify a press or a hopper bowl that will position and place fitting after fitting into an assembly rig so that they are all applied - firstly at all, and secondly in the correct orientation.

In some many cases, it is the process people who give one company a slender advantage over another - either through holding dimensions and quality better than anybody else, or by bringing costs down to an attractive level for everybody concerned. In the automotive world that I know, most contracts involve a year-on-year price reduction clause. This assumes that as a product achieves maturity, scrap levels are reduced, efficiency in increased and waste is minimised. These are valid assumptions to make, but the work towards achieving those goals in an economic way is principally down to the process and manufacturing engineers.

So really this post is about acknowledging the diversity within our own world of Engineering and letting it be known that I have the utmost respect for the guys and gals who, much more than Getting Things Done, Get Things Made.

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 2nd of May 2013

I never wanted to be a doctor, nor could I ever be a surgeon. It’s one of those inexplicable things - you can tell me over and over again that the components that make up the human body each have their (vastly more basic) equivalents in engineering: structures, pumps, tubing, fluid mechanics, control systems - but I can’t get past the whole “blood” thing. I’m squeamish.

(Others, fortunately, aren’t) 

Equally, I find it uncomfortable sometimes to think about our environment, and our impact on this world we inhabit. And if you read too much about it all in the press, it’s easy to sink into worry, to feel helpless, powerless.

Squeamishness and worry have no place in medicine, nor in studies into the state of our environment. The only way to work effectively in those fields is through immersion: in the data, in the testing and analysis, in the nuts and bolts of it all. The only way to demonstrate your care and mastery is by results, not by emotion.

The authors of Sustainable Engineering, Dr’s. David T. Allen and David R. Shonnard, have very successfully eliminated emotion from this work.

That is a compliment, of course, and I am sure they would see it that way, too. The book is not a cheery, superficial case of “engineers to the rescue!” Instead, Allen and Shonnard are the sober and cool-headed experts, completely immersed in and at ease with their field, able to bandy about and work with numbers like humankind’s 450 quadrillion BTU energy consumption in 2006, or use of over 120 million tons of iron per year, without apparent effort, or drama. In this way, they call to mind astronomers contemplating the size of Antares - and with this book, they are setting the framework for us to join in that conversation.

The language used in the book is unsurprisingly far from conversational. For that, we would need to turn to equivalents such as David MacKay’s Sustainable Energy without the Hot Air. Sometimes it borders on the heroically dry: (“a methodology was used that first defined a system to evaluate, estimated environmental releases, determined exposure to sensitive human and environmental receptors,and calculated damage to human health or impacts to the environment.") Overall, though. the authors manage to remain comfortably in the background - which is an admirable achievement on such a potentially flammable topic - in order to present the data and methodologies of engineering for sustainability.

The structure of the book is logical, but somehow overly so. Having the basics at the beginning and the case studies at the end makes sense, with the build-up in between, but I felt that some re-jigging of the chapters would have helped better to engage their readers, engineers like me, thinking impatiently: “great, very interesting - but where’s the engineering?” Whilst it’s true that this is principally a text book rather than a reader, the structure is perhaps even a little old-fashioned, stoic, even.

By their very nature, the trawl through the “meat” chapters in this sustainable sandwich of a book - Risk and life-cycle frameworks, and Environmental Law and Regulation - is particularly hard-going. The information and methods to be found in there can be extremely thought-provoking, such as a medical risk assessment of cancer through benzene exposure versus being a married or unmarried male, or charts showing the explosion in number of environmental regulations, but it’s a dreary trudge nevertheless. It would have been better to dissipate the effect, I feel, by interspersing these chapters with the engineering ones. Also, perhaps as an aside, and considering that the overwhelming majority of readers is likely to be students, the life-cycle analysis of disposable versus cloth nappies (diapers), whilst undoubtedly a classic example, is perhaps not the most relevant Allen and Shonnard could have chosen. Perhaps the subtext of “life goes on” was intended?

Chapter 4, with the slightly awkward title of “Green, sustainable materials” (does the word “green” belong in this context? It strikes me as more of a journalistic term, rather than an engineering one - but perhaps today’s student would feel otherwise), is really an extended life-cycle analysis dealing with the extraction and disposal of materials. Again, it contains some fascinating thought-starters that reward the careful reader: gasoline, for example, is easy absorbed by soil (which sounds bad). Ethanol and MTBE, both additions in terms of trying to improve air quality - MTBE reduces CO output - on the other hand, are less easily absorbed and so are more likely to seep through the soil to reach water sources, and so can pose a greater direct environmental risk in that scenario.

Only in Chapter 5 (of six), “Design for Sustainability…,” do we encounter the engineering process, along with the best summary of what the authors want the reader to understand: “The goal of sustainable engineering design is to create products that meet the needs of today in an equitable fashion while maintaining healthy ecosystems and without compromising the ability of future generations to meet their resource needs.” The chapter deals with the design and costing of systems and components according to the principles of Sustainable Engineering (there are nine of them, according to Sandestin, or twelve if you’re a disciple of Anastas and Zimmerman). These 12+9 principles are listed and described at length, causing a certain glazing of the eyes and reinforcing the idea that this book is to be treated as a reference rather than a recipe.

The key phrase, perhaps of the whole book, is also to be found in this chapter: “…anything that can be measured can be improved.” In essence, life-cycle or risk analysis is a simple matter of multiplying and adding huge or tiny numbers. Emphatically non-trivial is finding what those numbers are. Here, Allen and Shonnard provide an excellent portal into the arcane world of environmental, medical and chemical factors.

The biggest resistance to engineers really starting to work according to the 12+9 principles will be the finding, testing and approving all of the relevant environmental parameters before they can begin to measure the current state of environmental affairs for their product, or even hope to measure the effectiveness of changes made. Convincing management to invest resource and money in these will be difficult - the hope is that it won’t only happen via the negative pressures of ever-increasing regulation and fines.

In the end, this is an important book that deserves its place in the engineering body of knowledge. As the authors themselves state, the methods of design and engineering for sustainability are not yet mature, not crystallised into procedures and workflows; it is not by a long stretch the “normal course of business.”

From my own experience, environmental considerations are largely ad-hoc and regulations-driven. How we as an engineering community implement design for sustainability as the normal course of business rests largely with our colleagues in academia for now. Once the methods and evidence of gains seep through society into industry, the upcoming generation of engineers should simply not have to think about it. They will have become immersed.

Now, the final question has to be: is it more environmentally sound to buy Sustainable Engineering as an ebook or on paper…?

The book for reviewing was provided by Pearson North America with no strings attached save that I produce this post. That I gladly did, although it took far longer than I had intended. Still, we got there in the end!

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 7th of March 2013

Validation testing is a significant part of my life as an engineer these days. Also, I have much more interesting things I could - and should - be getting on with.

Validation is important, but it’s largely stupid - like much of work, I suppose. Perhaps stupid is too strong a word. Dumb is probably a better choice, the opposite of smart. Validation is dumb, and there’s no escaping it.

What to do?

Well, we can talk about it first (even if this is not doing anything about it). Validation is the antimatter of development - put the two together and you destroy engineering life itself (overdramatising somewhat). What I mean is this: development is subtle, replete with success and failure, nuance, puzzlement and, hopefully, finally, understanding. Validation is a box-ticking exercise that brings nothing of interest to anybody, except the approval to sell product, which is a key aspect of business, I have been led to understand… so validation is important.

Testing is an integral part of development, one that I certainly don’t want to discard. When we develop components, we have to pass testing and other approval gateways; based on the resulting performance, either we confirm that parts need to be redesigned because they don’t meet a particular specification, we confirm that our parts do meet a particular specification, or we can write our own spec if one doesn’t exist already. At the end of a development project, validation confirms that the first parts off the real production process are as good as all those expensive prototype parts that were tested previously: validation can be the joyous culmination of all that development effort, champagne all round. So really, my gripe isn’t with concept or process validation testing - these are valid steps in getting a product to market.

Get over it

My gripe is with approval testing; testing that is set as a hurdle to delivery to a given customer.

Hurdles are good in many ways. If everything we did were trivial, anybody could do it. Fortunately, what we do is not trivial, and there is a limited number of companies involved in our market, each with their own strengths and… opportunities. Validation testing from the customer side is a way of filtering out duff suppliers.

But the work that is sucking out the oxygen of development for me right now is not linked to any new development or any new product. It has the Kafkaesque whiff of bureaucracy generating a lot of effort for no tangible benefit at all.

Validation is time-consuming, expensive and is (supposed to be) a key component in my other important-stupid bugbear, PPAPs

So, as I asked before, what to do with it?

The phrase “creative destruction” comes to mind - destroy validation and PPAPs and all of that dumb junk to free ourselves to think creatively. Let’s explore that: can we ditch it all?

Ideally, yes: with all the data swilling around in our company, from development results to production and quality control systems, we should be able to show that production parameters haven’t changed significantly since the product was first approved, and that the standard production checks will have filtered out any weaknesses.

This can work - but often the customer wants to use an existing part on a new platform, or a new part on a new platform, so wants a full set of confirmation test results, in their unique format. Also, it doesn’t avoid the question of whim. A customer can demand results against a particular set of specifications whenever they want. So, you test and you validate.

But why me?

If there’s one industry where whim and whimsy is at a minimum, it’s motorsport. What do they do there? Well, even if they are producing a “series of one-offs”, they test and they inspect and they destroy things, too. Yes, they validate. How they go about it is hinted at in this puff-piece by and from the Lotus F1 team.

The article doesn’t tell us much, but the important point is that they have an inspection team. Just as software smithies have test teams, engineers should have inspection and validation teams. This is what I am missing where I am now. We have fallen in slow-motion into the trap of mixing development and validation in one pot. Alas, because the output of validation is a ticked box (or a boxed tick), and since those ticks in boxes are prerequisites to supply and therefore making money, validation more often than not takes priority, thereby hindering development.

Unite and advance, Divide and conquer

The answer, then, is twofold - and also expensive. First of all, the vexing question of validation testing needs to be tackled at the source - with the customer. To be able to come to a sensible agreement on what’s relevant and what’s useful to test, the onus is on the supplier to show his understanding of the product - how it performs, how stable the processes are, what could potentially go wrong. This is expensive in terms of effort - data-hunting and gathering, condensing it into digestible information and then taking it to the customer for (in all probability) a series of meetings and discussions to come to a sensible arrangement.

Then validation testing must be separated from development. The two should be unique teams with limited overlap, ideally with separate facilities. This, too, is expensive - but not focussing sufficiently on development is more expensive still in the long run.

But perhaps I’m biased.

originally posted on one of my several now defunct blogs, called On Engineering, under my persona The Canny Engineer, on the 21st of February 2013

Phew, what a day! What a lot of days! Things are pretty mad at the moment and have me racing from one fire to the next whilst juggling the other less serious blazes. Things are probably more or less the same for you (unless you work in aerospace ;-)). We need to get things done all the time and seemingly all at once. Priorities rest on ever-shifting sands, cups of coffee are gulped without enjoyment, nerves are frayed.

Having lots to do at work is both a blessing and a curse: of course we want to be gainfully employed, but there is a point beyond which the sheer number of tasks that we are responsible for becomes overwhelming. As a result, efficiency sinks to its knees, even if we physically manage to stay on our feet.

This fact has been recognised by many and has become the basis of whole careers on advising people how to do manage tasks. I’ve been on Time Management courses, as I described over at Engineer Blogs last year, I’ve tried hiding myself in empty cupboard-sized meeting rooms without my phones and I’ve tried all sorts of tools like the Tasks list in Outlook to try and find a way out of the mess, mostly to no avail.

Help is at so many hands that it’s no help at all: there’s such an uncontrollable thicket of to-do apps, self-timer apps, of notation apps and (e-) books to be bought that these have become an industry in themselves. All in the name of getting things done.

Late last year I caved and bought the book with those words capitalised by Dave Allen: Getting Things Done. I read it, too - and came away rather impressed. It’s certainly a book of two halves (it feels a little like a ‘buy one, get one free’ deal, where you don’t necessarily want or need the free item), but the first half, where the concepts and mechanisms of Getting Things Done are explained is well worth the entry price. Mr. Allen has an incredible font of quotes that are splashed liberally throughout the book, too.

This isn’t a book review, though. It’s a process review, about Getting Things Done, or, as it’s now known in the trade, GTD.

In essence, the GTD methodology is about freeing up your mind, removing all the vague projects and to-do’s lodged quaking anxiously in your brain and onto physical or digital lists. The discipline of creating lists, of categorising, of sifting and sorting into whatever systems best suit you is geared towards relieving the mental pressures of non-started or incomplete tasks and towards focussing your attention on the next thing to do.

Next steps are a key element of Getting Things Done and recognising this goes a long way towards success. When I have to update a drawing, that is not a task itself, it’s a project. The next steps for me go along the lines of: Creating a new part number or release level in the system. Printing out the current drawing. Sketching up all the changes required: whilst I’m doing that I’ll realise that I need to pull a Change Request number, so I’ll need to go onto that system and generate a form and a number. That number goes onto the new print, which, once sketched up, goes to our CAD designer for modification. I wait. I get the print back for review. I make corrections, or I don’t - I send the drawing back if I do need updates, wait again (doing something else in the meantime), then switch focus back to the print once it’s finalised. Then I need to upload it and “publish” it… And so on.

Each one of those steps are all “small” things, but there are so many of them that constitute this mini-project called “update drawing xyz” that they easily clog up my mental passages (for want of a better turn of phrase). Listing the tasks out on paper or in some kind of digital software means that I don’t have to hold them in my mental buffer. Equally, I won’t have to worry about remembering where I am whenever a distraction occurs - a colleague walks in whilst I’m sketching and requires assistance (often setting off the next mini project of Things To Do), or quite simply when I’m waiting for that drawing to come back from CAD: I can quickly find the next open task and use that,

I’ve worked according to this methodology, applying the same logic to pretty much everything I do: ideas for new developments, testing that I need to do and subsequent reporting that I need to complete.

The general methodology works very well. It took some time to sift through my projects and my emails, but surprisingly quickly, I found a decent system of project taxonomy and began to see more and more white space in my inbox.

Tool-wise, I ended up using the browser-based software Asana, mainly because I wouldn’t need to install anything on my locked and stitched-up work laptop. Outlook is too stuffed to work for me. It has all the functionality - emails, notes, to-do’s, ability to drag and drop emails into Calendar and into Tasks - but somehow I need to escape the Outlook environment and keep things as focussed as possible - Asana provides this “cleaner” environment for me.

Up until mid January, I had a good set of lists and tasks, as well as an email in-box hovering around the zero level (each email is either archived or generates a set of tasks in my list setup). It was only when I embarked on a series of business trips - to Shanghai, to Kassel - and became sucked into a series of “urgents” that things started to subside back to the old ways of inbox infinity and anxieties everywhere I looked inside my head.

The focus of GTD is very much on mastering the low-level tasks. Dave Allen addresses this regularly in the book - he acknowledges that life-goal-setting (his “50,000 ft+ view”) is a way of finding orientation and goals in life; but if you’re mentally overloaded with pending things to do, you don’t have the headspace to creatively think about the bigger picture.

Get your everyday tasks under control, unload your mind of that burden, and the bigger picture has more room to grow of its own.

Honestly speaking, I’m a bit like a dieter here: bouncing from inbox-zero and being on top of things to feeling overwhelmed. I’m back at the overwhelmed phase, which is why I feel that now is an interesting time to write about all of this: not from the perspective of a smug succeeder, but from that of the struggling disciple, trying to turn things around again.

I am starting to get back on top of my tasks and lists again. I know how it feels to be overwhelmed, to have a brain buzzing with alerts and anxieties; and I know how it feels, however briefly, to be in control.

So - here’s to engineering more efficiently, fluently and… more cannily

originally posted on one of my several now defunct blogs, called On Engineering, on the 12th of February 2013

Blogging about considering new jobs (and doing something about it) seems like a risky idea. Posts are by their nature open to the world, so conceivably my boss could read this.

(Well, it’s inconceivable, really, but let’s go with it for now)

What will he think?

In my case, there’s nothing that he can’t have been inferred from previous discussions, so there’s nothing that could surprise my boss unduly were he to read this. For you, dear reader, there are hopefully some worthwhile thoughts in here - so read on, whilst I write on.

It’s safe to say that I had a frustrating time at work in 2012, mostly for non-engineering reasons (resources, too many inputs and outputs, etc). I decided that a change of scenery would be a good way of clearing the decks and starting afresh, so I applied for a couple of new jobs.

A seemingly attractive way of making the switch to a new company or even to a new industry was, I thought, to glide along the plane of least resistance, taking a training- and background-agnostic route. In my thinking, this route would take me towards Project Management.

It’s not perhaps strictly true to say background-agnostic. Project Managers are often handed the role from within another, and that’s what happened to me at various stages in my career - so I can show a Project Management history: nominally, I am in any case a project manager right now. It forms part of my job title (the other words being “Development Engineer and-"). Whilst I officially combine the roles I also tend to fulfil both roles simultaneously (Project Manager, manage thyself!), which has added to the frustrations I have felt of late.

We were also given project management training a while back. It was in itself quite inspirational and I came top of the class in the tests at the end of it. So, in essence, Project Management is something I can do, more or less without really thinking about it - in fact, what else do I do other than manage projects? Every single task I have, be it “engineering” or “not”, is part of a project, big or small. I do have to force myself to do things like pick up the phone (I’m much more of an emailer or short messenger than a caller), but overall I can work with others and others seem to be able to accept working with (sometimes for) me.

I got invited to some interviews.

Both were within the automotive sector, so I wasn’t going to be changing industry, but I would be changing technologies - glass and engine products were the general themes.

And therein lay the rub with me wanting to switch via the PM route: I thought the technologies would be cool, not the job. You see, what happened in both interviews was something like this:

Interviewer, after some preamble: “Imagine the scenario that a task within one of your projects is delayed. What do you do?”

Me (brain whirring, thinking…): Um, what can I say to this that could possibly be interesting? I’d have to talk to the guy whose task it is, see if I can chivvy him up a bit. Talk to his manager, talk to the customer, see if we can delay - oh, this is all so dull!

Me (aloud): Well, we could, umm, talk to the person responsible for the task (etc)

Me (body language): help! I’m floundering here and both I and my interviewer have lost interest in what I’m saying. He’s staring out of the window, I’m staring at him for some kind of positive reaction…

And so on. Yet within the same interview I had to field some engineering-type questions:

Interviewer: What do you think could be the potential technical difficulties involved in developing this kind of product?

Me (internally): Yes! Easy score here

Me (aloud): Well, there’s the material selection, the coatings, how to apply them within undoubtedly very tight tolerances, how to withstand heat without distortion that would…

Me (body language): Hands waving, leaning forward, engaging the interviewer - more, please!

In the end, I have to realise that I am by nature an engineer, with everything that that entails: all the coolest development work, all the dullest admin stuff and everything in between. Anything else (commercial, purchasing, quality) would mean going against my own grain.

The only question remaining, then, is: can I become an engineering manager? From the aspect of organisation and team working, data access and transfer, deciding on what’s right for the product and for the company - yes. From the aspect of dealing with stroppy employees, an ever-increasing email and travel load, and becoming ever more involved in company politics (whichever company that may be) - who knows. But that discovery is for another day.

Have you transitioned away from pure engineering? Have you made the step up to management - either successfully or stressfully? Let us know in your comments!

originally posted on one of my several now defunct blogs, called On Engineering, on the 11th February 2013

I was impressed by Enrique Scalabroni from the first day I met him – at Williams, in 1985.  He’d turn up every morning in a local cab and always leave late at night – also in a local cab.

via peterwindsor.com

This time, I simply want to share somebody else’s blog post with you, The Spoon Test by Peter Windsor, a Formula One marketing guru and team manager (so, not an engineer). It contains two videos with Enrique Scalabroni, a designer in the Formula One world, explaining the Coanda effect with some cutlery - and, in the second video, some wonderful sketching.

Never underestimate the power of the sketch!

originally posted on one of my several now defunct blogs, called On Engineering, on 3rd February 2013

Apart from the opportunity to see some films that I don’t normally get the chance to see, long-distance travel lost its allure a long time ago for me. I appreciate different cultures and their food, it has to be said, but getting to experience them on business trips is generally not worth the price of jet lag, lack of sleep and missing the family. I’d rather travel to Kassel than Korea.

Sometimes, though, a trip can be rewarding in other ways. My recent jaunt to Shanghai was as special as it was exhausting; after many years of learning engineering and the specifics of my job, I finally became teacher.

To say “finally” isn’t strictly true: helping out colleagues with technical questions is a large part of what we as engineers do. We’re always explaining things to sales people or buyers (usually in full knowledge that it’ll be out the other ear within milliseconds) as well as other engineers. But this was different - I was formally given the task of training our colleagues in the Asia Pacific region how our products work. It was like our own, private, in-company TED talk.

The background to the training was inauspicious: our colleagues in China had a few eminently avoidable issues (incidences or complaints, whichever word-avoidance euphemism is currently in vogue) that required a lot of effort throughout the company globally to resolve, even though for me the analysis and resolution were fairly trivial.

Even before the dust settled, the key action that emerged from all of that excitement was that we needed to increase the general skills level in technology, quality and manufacturing - we needed to spend the effort to train ‘em up in order to save ourselves and the company a whole load of pain and cost.

From a business perspective, it was an investment that would result in a positive pay back (or at least a less negative one).

Getting the admin right is part of getting the product right

Just getting to Shanghai turned out to be a bigger hurdle than I had expected: cutting a long story short, I couldn’t board my flight on the Saturday because what I had thought was a six-month, two-entry visa was in fact a three-month single-entry: I hadn’t checked in advance. Whilst I’m proud to call myself an engineer rather than a bureaucrat, it was still pretty embarrassing, as it meant that I would miss the final organisational meetings with the team on Monday.

For various reasons, I ended up making use of a new rule in China - that you can stop over in Shanghai or Beijing for 72 hours without a visa, as long as your stay is just that: a stop-over. This meant that I couldn’t simply fly back to Frankfurt after the training; no, I had to have an interim airport on my itinerary. In this case I was recommended to stop over in Bangkok.

Fortunately, bureaucrats being bureaucrats, they could only go by the letter of their rules, rather than the spirit of them: I was admitted into Shanghai for those 72 hours, even though my return flight from Bangkok to Frankfurt was only two hours after my arrival in Bangkok.

Sometimes it’s great that the law and its ilk are asses.

What matters is, I got there.

Presenting in pyjamas

Because of all the delays in my arrival, instead of having a few days to acclimatise, to organise and to finalise, I rolled up to the conference hotel just in time for my own presentation. And so, without the chance to change into my suit, I wandered up to the front of the auditorium still wearing what I had been travelling and failing to sleep in - whilst not really my pyjamas, they may as well have been.

Fortunately, that didn’t matter one jot.

Not fortunately, I had practiced my presentation out loud to myself in an empty meeting room back in the offices in Heidelberg. I had given myself the rare chance to test the logic and flow of my presentation before flying, so I knew that I wouldn’t be standing there, staring at my own slides, wondering what it was I wanted to say: I heartily recommend the practice of practicing to anyone.

So, finally I was there, adrenaline flowing as I stood in front of 70 colleagues who were all eyes and ears, ready to listen to what I had to say. Presenting the basics behind what we do and what our customers do with our parts once they assemble them was an enlightening experience. The things I was showing them were what I have lived and breathed at work for the past five years and more. Conversely, my audience really didn’t have much of a clue - and they were agog. Those eyes followed me as I talked, as I tried to avoid walking around the stage too much (I do tend to use up the stage) and even as I noticeably faded towards the end: it went well.

The best of indicator of my success were the questions that people threw at me during coffee and lunch breaks over the next day and a half. For sure, there came many compliments but they weren’t empty: they nearly always came with a question. It was this that really told me that they had been listening and were making the first steps towards understanding, namely confusion.

And the rest is a blur

That evening, we went out for drinks. The next evening, we went out for dinner and drinks. Early the next morning I had a meeting with Shanghai Volkswagen. That afternoon I flew to Bangkok. That night, I flew feet-first in a business class bed in an A380, to get home in time for breakfast.

Was that it?

I’m back in what counts as normality at work again, my temporary rockstardom popped back in the folder where my presentations lie like an unwanted old rag-doll. But, if all goes to plan, it will be taken out, dusted off, given the odd bit of nip and tuck and we’ll be back on the road. The idea is that we take this “show” throughout the company; and that’s going to be interesting, to say the least. We could say that Asia Pacific was low-hanging fruit. My colleagues there were (and still are) keen to learn, excited in the possibilities that this knowledge will give them when dealing with their customers.

In North America and Europe, on the other hand, I’m expecting a kind of tacit resistance. They “know it all”, have “seen it all before” - even though in my experience they don’t talk the right language of our products: I hope it doesn’t go as far as apathy - but could well go that far.

But that’s all to come. First of all, I have to get ready for that exciting trip to Kassel, where at least you can see through the air around you.

It’s true, though - it doesn’t quite have the same ring as Shanghai, does it?