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...!

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.

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