The Canny Engineer Thinks

Engineering Things Done

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

On Staying Engineer

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!

Is Software Engineering Engineering?

Software seems to be getting all the glory these days, with the notable exception of the Curiosity landing - but any system that uses a a rocket crane to gently place a one tonne nuclear rover into a crater on Mars is astounding. Aside from the MSL, though, it's all Facebook this and Google that - even Microsoft, the uncoolest of them all collects kilometres of headlines. I get the impression that engineers like me, working on "things" like metals, coatings, fluids, remain unlauded. In modern parlance, I work on "dumb*" things. They are non-trivial things, of course, otherwise I wouldn't be engineering them, the products I work on also have many millions of users and the company I work for even makes a profit - but it's not software.

The world of software deserves its acclaim. The engineering that I do could hardly be imagined without IT. Spreadsheets and presentation tools, web browsers, emails, data analysis software all across the spectrum to text messages are an integral part of my working life. In one sense, then, software is "merely" a tool that enables me to add value to things. Equally, I am aware of the tools that I use when I'm not in the office: music sequencers, smartphones, GPS systems - and blogging apps, of course.

All of this software resides in hardware, but in many cases the physical is largely transparent. Software defines the utility of the hardware.

So software is one of modern life's key enablers. It can be stunningly complex and is in a perpetual state of development (unless the company goes bust or is bought out for its team). The question is, though: is software engineered, or does it somehow "happen"?

Put another way: if I were to dust off my Basic or my Turbo Pascal and hop over to a software company, would I recognise what I would do there as engineering?

The title Software Engineer certainly exists. It can be found in the job pages of Facebook and Yammer. There are university courses offered in Software Engineering the world over. There is a Software Engineering Institute at Carnegie Mellon, and the Fraunhofer Institute has its own Experimental Software Engineering group.

Yet despite all of this apparent validation, the title still seems diffuse and interchangeable. Some companies avoid the title Engineer altogether, using by preference the word "Developer", which seems currently to have the highest cachet, whether the practitioner is Junior, Senior, Expert or Chief Expert. A developer friend tells me that where he works, the title "engineer" is not used at all, as it smacks of robust inflexibility grounded by paperwork, whereas developers are by nature free to react quickly and autonomously to the ever-changing requirements and bug discoveries that define software.

I see what he means (and take slight, but acknowledging umbrage at that assessment of engineering). But others use the title "Engineer" as a standard moniker - including Google, of all places. So how do they use it?

James Whittaker (now back at Microsoft) in his highly engaging book "How Google Tests Software" describes many of the development tools used by Google during software development. They seem to be parallels of my own tools. He talks about specifications, about a kind of FMEA (risk derived from what Google calls ACCs - Attribute / Component / Capability factors), about test and validation, about breaking things to find their weak points and subsequent focus on fixing those areas.

A Google Software Engineer (also described in the book as a "feature developer") is responsible for delivering tested, bug-free code to a particular project. Software Engineers in Test are geared up to write code and test-frameworks to find bugs in the product, and Test Engineers work specifically on ways to break the total product in clever ways.

It all sounds quite similar to my world. Instead of code, I write drawings and specifications. I organise testing and validation, I have to deal with change. Our manufacturing engineers ensure that product can be made and our quality engineers ensure that product is measured and released for sale. However, whilst specifications, documentation and requirements are all present and largely correct at Google, they come across as being secondary to the ultimate goal of shipping bug-free code.

This is of course totally true. They are secondary (I shudder when I hear Quality Managers refer to what they do as "value add." It's cost-added for value saved.) However there is a different emphasis on rigour between software and hardware that may be reflected in the real titles of hardware engineers but software developers.

One of the directors quoted in How Google Tests Software explicitly states "I suppose there is a fairytale world where every line of code is preceded by a test which is preceded by a specification… But in the innovative and fast-paced world that I live in, you get what you get… Demanding a spec won't get you one… I can whine or I can add value." Equally apposite: "Test plans are the first testing document to be created and the first one to die of neglect."

These statements reflect the same pressures that I experience as a mechanical engineer. We also have timing pressures to deal with, and spec writing is also a necessary evil. But the attitude seems different. I simply could not imagine such a statement coming from a GM or Daimler director, let alone from that great automotive bureaucracy, Volkswagen.

Documents and specifications aside, subtly but tellingly, in a series of interviews with Google Test Directors at the end of How Google Tests Software, each director refers automatically to developers and only occasionally use the word "engineer" as a secondary term.

So perhaps engineering is a nice-to-have concept in the world of software, a little bolted on. On the other hand, we engineers may be too static and outmoded for the modern and fast-paced world of gold-medal software firms like Google. Perhaps our production models that involve factories, process engineers and ISO / TS audits are too rigid to take the liberties that the softies can take and get away with them as often as they do.

But as we have seen, the title Software Engineer is very much in existence. Maybe we need to take a step back from software's cutting edge to where software takes a secondary seat to the hardware. Car or aircraft entertainment systems, or production process control systems would be good examples, as would be the medical equipment industry.

The clearest answer I have found so far to the question "Are Software Engineers Engineers?" lies in a job description for a medical equipment manufacturer. Here's what this software engineer is supposed to manage:

• Development of software
• Verification…of Quality Management and Regulatory Affairs
• Collaboration for the development of software requirements
• Development of the software architecture
• Implementation and integration, supervision of external resources
• Support of product maintenance
• Production and customer care

This collection of responsibilities sounds more like what I have to manage on a daily basis. This software engineer must juggle the code and its application, must (this being the medical industry) monitor specs and regulations carefully and must ensure that production is secured, whilst also designing in a certain ease of use for the end user (I wonder if they say "end user" or "patient"? I think it makes a difference…).

It doesn't sound as sexy as a startup's freedom or a Google's heavyweight fleetness of foot, and it doesn't reflect much of the pioneering spirit of a Brunel or an Edison; but it's engineering as I know it.

Perhaps the difference between the software developer and the hardware engineer really is as simple as the maturity of the market and of the company. Just as terrible auto accidents in the 1970s and 80s resulted in ever-increasing regulation, so potential privacy disasters at Facebook and Google is landing them with audits and governmental control.

Perhaps the Zuckerbergs and Larry Pages of today are the Rolls and Fords of yesteryear, and their companies are destined to become as bureaucratic as their successful forebears. The attraction of startups is that they are small and start under the radar of heavy regulation. To achieve the scale and success of Microsoft or Apple, of BMW or General Electric, they too must generate a strong, supporting skeleton. The trick and the challenge is not to let that become a fossil.

So in the end, what's my answer? Is Software Engineering Engineering? Yes, it can be. There are sufficient differences that both worlds can learn from each other, even if they cannot often transfer people (I see myself more easily transferring to the nuclear industry than to Google) but the disciplines and tools involved have their parallels. In the balance, I feel that my world could learn more from software than vice-versa, especially in terms of sleekness and agility. What could they learn from us?

Apart from great paperwork, I mean…

I'd love to hear your thoughts on this theme, too. Are you a Software Engineer yourself? Or are you somewhere in between (in avionics, say, or electronic gadgetry? Fire away!

*dumb: software is deemed smart, but it, too, can be reduced to equations and lots of "if…else" statements. Not as dumb as they sound, my components react to certain conditions in particular ways, and with more subtlety than many programmes do.

Pass the resource please (and spread thinly)

Terracotta Warriors photo from romainguy on Flickr

As an Englishman living and working in Heidelberg, I am often asked if I work for SAP, the business software giant based down the Autobahn in Walldorf. I don't, of course. If I did, I'd be writing about software development, the management thereof and how utterly astounding their legendary canteen is.

The question is not a daft one, though: around 10 thousand people work at SAP in Walldorf, forming a more or less willingly thrown together (or at least well-paid) melting pot of 80 nationalities with English as the working language. It’s easy to assume, then, that a middle-class, technically minded foreigner living in Heidelberg earns his crust and her Grauer Burgunders at SAP.

I know a few people who work at SAP, and they are generally of a particular ilk (physicists and mathematicians, i.e., not my type) so I know that I don't need to yearn to work there, but there’s one thing I envy them: resources for R&D. Globally, (2011 figures) SAP has 16 thousand employees working in R&D (12 thousand work in sales…).

16 thousand in R&D...

(drifts into a reverie)



(Snaps back with a jolt)

I’m not in that place. I am a development engineer at an automotive supplier; my development activities really only skim the outer atmosphere of the unique world of R&D. Is this a surprise? Is it a disappointment?

Let’s think about the surprise factor first. When I consider my time at university, I don’t recall ever having heard the word “resource” discussed in any manner other than as a general term for learning material. We picked up the material, used the libraries and even the nascent internet; but I was never a resource myself.

Resource was always a “hidden” theme. We were aware of time pressures with the need to study such a wide range of subjects whilst maintaining sanity and health through extracurricular pursuits, but it was always a case of everybody finding their own balance.

My aerospace engineering course did involve one larger team design project that was formative, but as far as I could see, research projects could run in a business vacuum, free from excessive emails or telephone calls, requests for assistance from around the world and quality alerts to have to jump onto. Ah - there we go. Did you notice that word in there, mentioned for the first time in this post? Team.

Entering the workplace was a relatively soft jump for me: I joined Ford in the UK which at the time was recruiting heavily - and, crucially, I joined a team. By that I mean there were several of us who could do each other’s jobs, if necessary and we worked both on improving the product and on improving the ways we worked on those products.

Recently, I was part of a globally distributed team that developed a new procedure for drawing release and approval. The word 'team' in this case represents more a collection of perspectives than anything that could really work to fight the necessary fights. We had representatives from design, from quality, from manufacturing; but none of us were interchangeable in the way that my team position at Ford was.

Developing the process itself was the fun and interesting part. I managed to find a spare license for Microsoft Visio (alas only the 2003 version which is now looking very old indeed) and used it to create the workflow. As it is a cross-functional process, the workflow runs in lanes - development, manufacturing engineering and quality - so the visual aspect was initially quite appealing. Adding the "if… then" loops and the different entry points for product at the various stages in their drawing lifetimes certainly de-streamlined it, though.

But actually running the procedure has been no fun at all. The problem is that it was implemented as a project in itself without great consideration for the resource implications of centralising what was in effect a totally distributed (and therefore wasteful, if potentially evolutionary) process.

So the current situation is that I am currently the only person in a company of over 16 thousand who can create the drawings that those 16 thousand people need.  Imagine SAP setting up a system whereby those 16 thousand in R&D could only work if I finished one particular task amongst many. It wouldn't really make sense, and this is something that I'm struggling with at the moment.

And so to my second question - am I disappointed not to be part of that resource pool? In a word, no. It's harder to explain, but perhaps this is only because of a lack of imagination: I simply cannot imagine being able (or only being allowed) to work on one problem at a time. Whilst I am trying to relearn the art and discipline of focus, it doesn't come naturally to me. I thrive on bandwidth, even if the transmissions occasionally get muddled up and jam because of it. I'm a variety type.

Coming back to those cohorts of SAPlers, though: despite their numbers, there have been reports recently that even they are feeling pressured to breaking point in their jobs. Which means that you can spread even 16 thousand researchers thinly. R&D resources generally expand to fill the product lines a company is working on; even within the relatively low number of headline products SAP produces, there is a vast number of modules that require development and linking in to others, so there's plenty for lots of clever people to do. (Google has around 33 thousand employees, Microsoft 92 thousand, of which 35k are in R&D).

So today's R&D behemoths are commercial, distributed amongst the universities and amongst the startups that thrive or die on their findings; I'm somewhere in no man's land - where are you?

p.s. Happy 40th, SAP!

In, On and Around Detail

Are you blind to detail? Source Wikipedia Ishihara diagram

"It's just a minor detail" is a commonly-enough heard phrase, with only two problems: the words "just" and "minor." Take those two belittling extraneous modifiers out and say it again: "It's a detail."

Often enough, putting a concept or even prototypes together is the easiest (and the most fun) part of a project. The main parameters are in place; detail is "the rest" required so that something that vaguely resembles a manufacturable, saleable product results. It's those unknowns that need pondering, the "not quite rights" that need purging.

Put romantically, not just devils but angels, cherubim, seraphim, orcs, gremlins and all sorts of other critters reside in detail. They battle continuously to make or break your product, whatever that might be. Wrong material or tempering grade? It'll deform too soon, or just snap - if you're lucky at the prototype stage. You got your tolerances wrong? They'll bite you within three months of start of production, on a Friday afternoon before Christmas. Overspecified things to be on the safe side? Your product might be unfeasible to make, or too expensive. When you get the details right, however, that product can go out there and do what it's supposed to do - satisfy customers and make money.
So, we "just" need to get them right.

The first thing to realise is that there are no "hero" details. Every item on a drawing or in a specification can lead to something going wrong, and every item that is not there can, too.
Picking your way through the thicket requires concentration, discipline and focus, namely the three things that are almost impossible to come by in a normal working environment.
So, alongside placing the spotlight on details, this post looks at how and when to work on details.
Without thinking, problems don't go away. Without doing, they don't go away. Normally, one of those activities preceeds the other...

One key way is thinking solo: giving yourself the time, room and environment to think. Daydreaming is often for me the best way of filtering out my surrounds and letting ideas or understanding drift into my conscious view, when I'm least expecting them. Then I at least know what I need to work on. Then it's a case of separating myself from the others and going somewhere quiet to focus on something.
Brainstorming with colleagues is another method - call a guerilla meeting, half an hour over a coffee, just before lunch to ensure the meeting finishes on time; longer-scheduled DFMEAs is another good way of at least discovering what needs to be determined and proven before a product hits the scrap bin more often than the "goods out" one.

There's a key difference between the solo and the team thinking methods: thinking is often misconstrued as "not doing anything" whereas a team meeting is by default acceptable, no matter how inefficient. Let's have a look at solo thinking, then.

Or rather, look away - solo thinking is by and large impossible where I work and, I suspect, where you work, too.

We have an office with around ten people packed into around twenty square metres. It's not a sweatshop, but it is an open shop. Generally, whenever I need to get any quality thinking done, there will be others gossiping, discussing the price of petrol, mortgages, coffee (in fact, they are always talking about the price of something). Then an empty skip lorry will race past the windows, chains flailing and rattling, simply making an almighty racket. It is simply not possible to concentrate.

So I try to escape.

I go off and make a coffee. Or I'll go for a wander to the labs, but not actually get there. I'll saunter nonchalantly down to a meeting room without any meeting planned or find an unoccupied office, sit down and open up the one thing that I want to be working on at that moment.

I turn off Outlook
I leave the phone on silent and on its charging station so that it doesn't vibrate.
I shut down my browsers.
Then I load them up again (I nearly always need them for research and many of our documents are online). Browsers are a huge distraction or temptaion, but I find that if I'm really focussed I forget to browse the news or check my private emails or Google+.
Sometimes I'll uncap my fountain pen and start sketching, or I break open Excel and start working on tolerance calculations, O-ring compression sets; or I'll start searching the internet for the one key factor that I need to define what I'm working on.

In any case, I have to admit, my task-focussed multimedia shut-down strategy can be a tad one-sided. I often need to call somebody - a colleague or a supplier - for an insight on a particular detail. Or I'll send them an email. And I disrupt their work in the process.

So I can do detail - but, like drawings, I can admire detail but I don't necessarily enjoy it; I can occasionally lose myself in detail work, but in the same way that I am slightly colourblind, I don't see detail like a real clear-headed, focussed checker can. Working on the details of a design is often an effort that is sometimes too much and ends up in frustration. I'm not your stereotypical engineering bureaucrat who will gladly and with a sense of achievement check every last entry on a drawing or bill of materials. I'm not naturally a detail person; but others are and that's why we should work together. It's what teams are for.

p.s.

Jobs I could not do because of this:

• teacher marking exams (= engineer marking PPAPs)
• lawyer (=engineer getting involved in patents)
• customs administrator (= engineer and his paperwork (= engineer))
• forensic scientist (= engineer working on quality complaints)
• politician (= engineer trying to get all parties on board)

Oh. I am all of those.