The philosophical playoratory

Continuing my observations on being a working, playful engineer: you can read the introduction in Part 1

Time flies when you’re in the lab

I recently read, in a borderline mystical article about the Taiwanese chipmaker TSMC over on Wired, the phrase “time flies when you’re in the fabs” (production plants where microchips are fabricated). Substitute the ‘f’ in “fabs” with an ‘l’ and you have the same for me in the lab… sort of.

In that article, the time-flying stems from the sort of sensory overload we experience when visiting a new city or a factory for the first time: the quantity and intensity of new inputs and interactions can overwhelm our mental processing capabilities and it’s tricky to know where to focus our attention.

For this effect to take hold in a calm, familiar lab we need other stimuli, something unusual to happen, to kick us out of the routine and into a mode that could (until a technician reminds us) lead to us forgetting that it might be lunchtime. We need play.

The lab for the development engineer

It perhaps doesn’t sound right to associate a lab with play, this agile alertness that brings joy and satisfaction to an activity, and there are certainly some instances where, as you might expect, the conditions necessary for play simply aren’t there: we’re repeating a totally standard test on standard parts for re-qualification. In other instances, excitement occurs, but not necessarily play (quality investigations spring to mind, alas).

For me it was as development engineer that my playful relationship with the lab really became most apparent. Setting out to produce something new from an initial idea gets the creative juices flowing, the mind whirring. Extending this into the lab is brilliant: not yet knowing if parts can be tested with current equipment, not knowing what the results will be (even if we have hopes or technical expectations for what they should be), uncertainty as to how representative of a potential final product the initial prototypes will be all gets us thinking, imagining, tinkering, bouncing ideas off others in the team. At this exciting stage we’re a long way from expecting pass/fail reports or sometimes even answers: we’re finding out what the questions should be, we’re in the phase where interesting results are to be found in the realms of “promising,” “so-close…,” or “so far off…": results that lead to further ideas and testing.

Playtime!

These are my most “alive”, most playful moments in the lab, with multiple phases and objects (in the grammatical sense of people and things) of attention: chatting with technicians, handling parts, checking drawings and the test rig, figuring out how samples might be mounted, whether we need new fixtures (if we do, and we need to order something, playtime quickly ends!). The lab technicians may have encountered similar ideas in the past and warn what their weaknesses were. This is where the ‘plan’ (the official test request that I wrote back at my desk, in the past), meets a reality which is starting to become “now”, and need knocking into shape to bring closer to practical reality.

Starting the test entails switching attention from the personal and the physical to the informational: whilst still operating keys and switches and clicking a mouse button, still discussing with the technicians, we’re opening the appropriate programs, ensuing all the settings and parameters are right for this test (they may be totally custom, or tweaks of some existing presets), priming the data logger to start upon a certain trigger signal, and then pressing some kind of ‘start’ button to run the test.

Finally the test begins: I’ll have my hopes, fears and expectations, and (if I’m in the lab whilst testing is under way) I’ll be weighing up the results against those expectations as they come in. I tend to be unable to avoid interpreting every single result as it comes in, pondering already - too soon, but in preparation - their meaning, and of potential repercussions or next steps in the product’s development, whilst actively reminding myself (part of an engineer’s training and experience) to avoid reading too much into the insufficient data that we currently have… If I’m helping with the test (usually a bad idea, but sometimes necessary), I’ll be petrified of missing a step, but too distracted by the results to be able to calmly concentrate on my tasks, so sometimes I’ll make mistakes. Equally, though, if I see a totally unexpected result come up, I’m on hand to discuss it straight away with the lab technician, ready to test hypotheses and to come up with a plan on the fly.

For very slow tests (the archetype for me here being corrosion testing), those doubts and expectations surface from time to time at unexpected moments, the spirit of the test spooking me from where I sit, calling me back to the dungeon - I mean lab - to check up on the parts, peeking into the chamber to reassure, or to terrify myself, before the official end of the test, all the while being aware of the suspicion of influencing the test by the mere peeking inside…

This is all part of the game, aspects of play.

Not play

Typically, for me, the sense of play is over long before the full test is finished: testing itself quickly becomes routine and requires that different mindset and expectations of a technician. As hinted at above, a key difference between someone like me and an experienced technician is that they typically don’t let themselves get distracted by results, and can - we could say stoically, though it often seems more simply to be their nature that drew them to this job, rather than any additional philosophical system modifying their behaviour - just plough through the testing, seemingly effortlessly concentrating on testing each sample correctly.

This raises some interesting questions about games and play: surely there are games that require quiet concentration, the ability to avoid distraction and still be able to react to variance? Yes, of course! My counter to this point is that, if the prior play has been successful, and the test runs well, then you could put any practised technician in to run the test itself, without any knowledge of the parts or the origin of the test: it’s routine that wins, not reactivity or any particular alertness.

Indeed, under certain circumstances, I would run the test myself. There are aspects of this that I appreciate: handling the parts, knowing their type and expected performance, I observe and register many things, almost like a craftsman; the same with the test rig and mounting the samples for each test. Yet this doesn’t feel playful to me: it’s careful and precise, but doesn’t require the alertness or the ability to bring in factors from all sorts of sources for it to work. It just does work, and can (should) be a bit of a plod.

Usually, the end of the test also doesn’t feel like play: it’s mostly loosening things and removing samples from the rig. Typically, we’ll look at a few of them to see if anything unusual happened to them, visually; if it’s an unusual batch, then I’ll keep them all for possible analysis afterwards. It’s the analysis, interpretation and presentation of the results where the playful can re-emerge.

The philosophical playoratory

It’s in such an appropriately equipped, ideally local and freely accessible lab (rather than an external test centre), where you know the colleagues and can take the time to discuss things with them, that a lot of what makes engineering so appealing come to life: bouncing ideas off each other, deciding what tests to run on which parts, what equipment to use, who would be the best person to do the testing. Phrases like “oh, let’s try it in there” or “could we perhaps…?” or “let’s test a couple of parts, see where we stand”, or “how do we get this to fit?” and “do you think we’ll be able to see if…?” represent play in the lab.

Analysis of the data or of parts after testing can also be playful, the classic example here being the microscope: “check there,” “zoom in to that”, “measure that bit there” - but of course with the same phrases being applicable to charts and data - always trying to figure out meanings and implications.

When I consider my interactions with the lab, things get philosophically complicated and interesting, with multiple relationships and perspectives manifesting at different phases during a test, and, sometimes, all at once. Here’s a list of the semi-philosophical aspects that flicker in and out of attention in the lab context:

• My relationships with colleagues
  • Philosophically related to politics, practice and ethical action
• My relationship with the parts
  • Those parts and their multiple meanings and implications are present physically and (differently) in my mind. In both contexts are they real entities on which I imbue real concerns and hopes. I sense them and I imagine them.
  • Philosophically related to the perspectives of…
    • practice and technique
    • phenomenology (understanding how we experience and interact with others, along with borderline metaphysical considerations of “reality”)
  • ontology (understanding what is, and how it is)
  • epistemology (knowing what we know about the part, and what we still don’t, and want to know)
• My relationship with the test equipment
  • direct (if I do the testing myself)
  • indirect (if the technician does the testing for me)
  • knowing its strengths and weaknesses, relationship with “real world” use
• Philosophically related to…
  • phenomenology
  • ontology
• My relationship with the test process / procedure
  • determining steps in advance: planning
  • being alert and open to possible changes as they come in
  • action
• My relationship with pretty much the whole of history (or at least the history of science and technology)
  • how we ended up with these machines, parts, means, methods and levels of understanding
• My relationship with the “background technologies”
  • Paper, screens, mobile phones, furniture, buildings, infrastructure
  • Fans, coolers, data networks of the equipment being used
  • Test rig consumables
• My relationship with the data
  • Philosophically…
    • hermeneutics
    • epistemology (how do I interpret the data, what knowledge and experience do I already have that permits me to understand what the data is telling me in this particular, hopefully productive, way)
    • phenomenology (how am I viewing the data, how are they mediated)
• The overarching experience of testing
  • phenomenology
• Full suite philosophy

As we can see above, the lab - and engineering - is full of the key perspectives of philosophy (that I’m aware of, anyway, discounting metaphysics):

• Hermeneutics - interpreting requirements, procedures and results
• Phenomenology - “feeling” and experiencing the parts, through your eyes and modulated through instruments
• Epistemology - assessing the current knowledge about a thing, trying to figure out what’s not yet known, and how to know it, how confident we can be in that knowledge, and how to deliver that knowledge to others
• Politics and interaction (and a kind of technological ethics) - dealing with lab technicians, lab managers, getting timing commitments or confirming resources, dealing with problems
• Maybe some ontology, as an overarching concept? What exactly are these things and tools we are dealing with? How do they exist, what becomes of them during and after testing? What are our affordances, what can we use, manipulate to our advantage, ensuring power and data connections, temperature conditions, etc

These perspectives all intermingle, and attention flickers between them. I, as a non-philosopher engineer, have a lot to learn from them, which is why I’m here, writing this!

Play anywhere!

This extended reflection on my experiences in the lab is only one example of how work-time play can arise. The phrase “productive meetings” doesn’t need to be an oxymoron: ideas really can arise out of playful action, even in a meeting environment.

Don’t discount non-work play at work

Another form of play - equally important, in my opinion - is recreation. Ultimately, this is about restoring body and (in our case, in the work environment, more significantly) brain to be ready for the next pulse of work. Our brains really do get tired, gum up with waste chemicals that need removal or simply need more fuel, after all. But we, as humans, also need to tend to our groups, teams and societies - so that lunchbreak the technician reminded us of earlier is important in this way, too.

Documentational drag

In engineering, as at home, playtime is often over swiftly. Data gathered from the tests needs to be summarised and reported; completed, those reports have to be saved in the appropriate library for future reference - tagged and searchable so that future colleagues have a chance of finding what their predecessors got up to in the dim and distant development of those tests, products and processes. And, of course, the physical needs to be tidied up, too - a fundamental part of play, but not, as far as I experience it, play!

From play to mastery

Another aspect to consider is that the goal of work is mastery: knowing what to minimally adjust to achieve the maximum desired effect. Mastery is a calmer version of play, secure in the knowledge that what you’re doing is right (and good), but retaining that awareness and reactivity to adjust to any small deviations.

Just as there are various perspectives to focus on whilst mastering a musical instrument (sound, agility, improvisation, etc) - or even, come to think of, a measuring instrument, there are ways of mastering engineering topics and systems that aren’t purely technical, but require that playful agility, that personal phronesis, way of acting, that has become such a key part of my thinking on engineering.

Once mastery has been achieved, though, the goal of a company is often to move back beyond mastery to renewed play - to build on the already-mastered to expand its competencies and to stay ahead of the market game. This is an institutional challenge that goes beyond the individual, but it relies on individuals to recognise that necessity and not to succumb to the deadening constraints of overspecification and the mere passing of audits.

Getting back into the game

I’d like to end on a personal note: as I mentioned in my penultimate post, I’ve been between jobs for a while. I can now report that as of May 2023 I’ll be getting back into the ring, in a new arena, with completely different products to those that I used to be involved in making. Fortunately my new employer recognised the skills and experience that I will bring with me to their game, and I’m looking forward to making use of them once more. But most of all, I’m looking forward to playful engagement, moving things forward with a new team, in perhaps unexpected, but fruitful ways.

By “play” I mean, of course, “work”, but in a certain mode, which, because it’s work, isn’t always fun but can be, more significantly, very satisfying.

What is play, and can it work?

Thinking back to an episode with my daughter from a while ago, I recall fondly how she wasn’t in a good mood - well, OK, that’s not the fondly remembered part; what is, is that we changed that through play. I joined her as she sat listlessly on her bed, surrounded by toys: a few cars, horses and an array of some of her smaller cuddly toys. We both just sat there, amongst the toys, for a little bit - at least she didn’t send me away. Then, on a whim, I grabbed a car and started driving it over the mountainous terrain of her duvet. The car drove up a ridge too fast and flew into the air, now swooping and banking in all of the suddenly available three dimensions. My daughter responded by reaching for a toy horse, which leaped into the air to chase the thieves escaping the scene of their crime in my car. The glint returned to her eyes.

From there the story took many magical twists and suspenseful turns, including more chases, clever distractions and arguments, as well as frequent restorative and reconciliatory cups of tea amongst the protagonists, until, at last, the horse rustlers were apprehended and promised not to do that again…

Thinking back to an episode with a supplier, I recall fondly how one of their process had proven to be less stable than expected - well, OK, that’s not the fondly remembered part; what is, is that we changed that through… well, in an engineering sense, it was through play. We sat in the meeting room, surrounded by parts, flipcharts, whiteboards, the projector and tools. Then, on a whim, I asked about one particular aspect of the production line; the supplier responded with details on that, which then raised more questions, leading to a dash to the production line itself to see for ourselves, then to modify and tune parameters, replace tools, take parts into the lab for testing, eager for results and direction.

From there the story took many developmental twists and political turns, including more trials, confusion, argument, and restorative cups of coffee amongst the protagonists until, at the end, the process was stabilised and the supplier promised not to do that again…

What just happened?

What unites these two episodes despite their very different contexts is play: both involved getting involved and getting caught up in a situation, openly and staying alert to sensing, reacting to and guiding what happens. Play is by no means a passive or “useless” activity if it’s guided towards the matter at hand: the brain is whirring away looking for signs, adapting, trying, sometimes failing (I got told off by my daughter for attempting to use a teddy as an all-powerful giant to smash open a cave), but quickly adapting again to find something that works to maintain momentum.

Play that lab report

‘Play’ has a childish ring to it, connotations of a lack of seriousness, of ‘wasting time’ on Wordle rather than writing that urgent report, and it remains true that the playful mode isn’t suited to all engineering tasks (filling out Bills of Materials springs to mind). But, with play, we can allow ourselves and our teams to widen the mental net, to get things wrong to then get them more right, to find more efficient workflows and to make work simply more fulfilling, whatever the task.

Indeed, if you think about it, what is report writing but an exercise in language, and what is language but one of our most fundamental modes of play? In writing, you’re looking for words, trying out phrases, sorting and re-sorting the order, searching for alternatives, yearning to get past that frustrating and tantalising “tip of the tongue” barrier, whilst still progressing the word count or in editing afterwards.

One level beyond that of language being a form of play is to treat philosophy as play, too, as Joseph Dunne points out in the introduction to Back to the Rough Ground:

philosophy can seriously address practical issues and be a form of play.

Later on, he expands on this thought:

Philosophy is itself a practice, and, as in the case of any other practice, it is only when one gets caught up in doing it that one can learn to get out of it what it can give

Being aware of what Dunne means by “a practice” is important: it’s that non-technical, non-prescribed art of action and interaction: it’s not-checklists (but it can be involved in creating checklists in the first place!) Play, in all contexts, is about agility, being fleet of mind, and being prepared to expand horizons of opportunity.

In my next post, I’ll give an example of a particularly rich source of ‘play’ from my experience, namely the lab.

Until then, keep playing!

I am, for reasons beyond my control, at present - yet hopefully “only” - between jobs: being out of my last job is a fact, and finding a next one isn’t (I’m working on it, and have a couple of potential leads), so uncertainty abounds.

I posted about how I feel about this situation on my personal blog over at Diversions Manifold. The philosophical aspect that I want to reflect on here is, now that I’m not working at an engineering company, whether I am also (again hopefully, only temporarily) out of engineering, and, because of that (temporarily) not an engineer.

Staying engineer

Without right now wanting to go down the rabbit-hole of trying to define what, exactly, an engineer is, we can at least posit that the two (engineering and being an engineer) are different states (being and doing): so I am and remain an engineer, but I’m not practicing it.

Briefly to the personal, I’ve been out of my job for nearly two months now, and it’s been tougher than I had expected. All that searching for appropriate new jobs, updating CVs and cover letters, preparing for interviews, accepting rejections, and the frequent switching between hope and - well, not despair, exactly - but certainly concern for the future, have taken a higher than expected toll on me.

But all that work on the CV, tuning each cover letter for each application and now having had a couple of positive-feeling interviews, has made me aware of the wealth of experience I can count on. This experience isn’t just “past”: it now constitutes part of me and my neural networks, enabling me to act in my own unique yet “engineeringy” way. Each item on the CV recalls the nous and the feel I have for the combination of techne and praxis, for the technical and the playful in my profession. Significantly, they all still feel “live”, accessible and deployable for whomever and wherever I end up working with and for. Each item hides, or signifies, a story. Not just “work experience”, but real struggles, achievements, lessons learned or buried for possible future connection to another event: bruises and scratches (usually suffered by mouse and text) that have formed me. Those learned paths haven’t, I feel, become impassable and atrophied in those two months out of practice.

Those same experiences are also devilishly difficult to describe to someone in an hour’s online first interview…

Hearteningly, I find myself looking forward to making use of those skills again, and haven’t entertained thoughts of trying out something else entirely.

So, to me, I’m still an engineer, and potential employers seem to concur. The other question was: am I out of engineering?

Not quite engineering

The one tech-adjacent hobby that I’ve been working on during my gardening leave that could be considered to be “engineering” is resin 3D printing of mouthpieces for brass instruments. Actually playing those instruments (in my case, the trombone), is clearly a different category of activity altogether - and combining the two is a fascinating pursuit.

At present, I’d say my 3D printing is at more of a craft stage than anything engineered. This is not to denigrate crafts at all: they most certainly require ingenuity and a feel for both the materials and what is to be achieved through them; they rely on internal impressions and learned pathways for the craftsman to interpret and “feel”, then to act - or react - at each stage of the process. In all honesty, that also describes rather a lot of engineering: the spectrum of crafts does overlap with that of the technical as well as of the purely artistic. In my case, I’m only now beginning to settle on a half-way reliable print setup that allows me to make design changes and print them without the permanent fear that they’ll fail; concentrating finally on the part itself without worrying about the printing process that goes into producing it.

So, although my equipment and materials have all been engineered to a high degree, my own use of them is not at an engineered level. My craft has not yet been elevated to engineering (I say this whilst bearing in mind that many crafts would be smothered by engineering).

My engineering self does have an idea as to what’s required to make the whole setup more engineered: having a good, reliable technical setup, selecting the best materials for the job, developing reliable tests and parameters to measure and compare each iteration, and gaining confidence in the information available to me.

Just that first point is complex enough, involving optimising factors like print orientation, support structures, UV exposure times, resin bed tilt rates and (quite key) temperature control. My current settings - and challenges - have all stemmed from not-quite-understanding what affects the quality or success of a print.

In philosophical terms, then: epistemologically I’ve been floundering to find the knowledge that will lead to success, still unable to transition between types of knowledge, from having a “gut feel” to a theory and procedure that will - all other things being equal - guarantee a successful print and product.

This is a very common engineering dilemma. We have nous - an idea that something works - which we can even specify in terms of parameters that should lead to a quality product, but we don’t usually delve back down “to the atoms” to understand precisely what’s going on in either theory or practice… until it goes wrong, our assumptions are challenged, and we have to learn new details.

Ontologically, it’s fascinating to recognise that I have converted concepts and ideas into 3D CAD files into sliced printer files into print jobs into actual parts (and surprising amounts of waste), then, on the basis of trials, updated the CAD files to continue the cycle until - still a goal - I have a satisfactory product… for me. After that, I’d have to be able to translate those parameters for other players, and players of other instruments.

Phenomenologically, I have interacted with computer and machine user interfaces, (hermeneutically) interpreted 2D renderings of non-real 3D objects into mental “understandings”, and then, finally, felt, tried and (unfortunately, in many cases) smelt the final product as they emerged from the whole production process, leading to a search for less pungent, officially biocompatible materials to work with, as well as for the “perfect” design.

Sounding it out

Leading on from the phenomenological experience of the part, the “true”, or “real” end of each 3D print is a satisfactory quality of the mouthpiece that’s been produced. Here, at the time of writing, I’m leaning heavily on my “ear” and on the personal feeling of playing a new, plastic mouthpiece, all the while comparing it (is it “better”, or “worse”) to my standard brass mouthpiece, to previous prototypes? That’s not an “engineer’s” way of understanding quality, and it’s far from being scientific. So I’ll also be searching for ways to standardise tests (involving microphones and sound analysis software, for example) which will still, no doubt, depend on me playing the instrument with the new mouthpiece in it. Can I define a standard embouchure and air pressure to play even a standardised sequence of notes in exactly the same way for each variant, like a golfer honing their swing?

Probably not, but I’ll try.

That’s the engineer in me knowing what’s required - but not yet engineering.

Admin it!

One aspect of engineering that I’m very far from with this hobby is the whole admin, bureaucracy and documentation aspect of engineering. Ultimately, engineered products are to be used by customers, so must meet norms and regulations, be economically viable, environmentally acceptable. So, even if I did end up with a technologically proven mouthpiece design, I have the feeling that, without a company behind it, it’s still a craft. Is engineering ultimately also an economic activity? It’s something to consider!

Working it out

Practically speaking, and to summarise: I’m out of engineering, but I still know what it looks and feels like, and feel able to rejoin the ranks of the engineers. Just wish me luck on that front: I don’t want to have to be too philosophical about being out of work…

My previous post was about what I term a “field perspective” of work, which started out as a tangential idea on the engineering profession and our tools and was generally a happy, contented thing. When I encountered this heartfelt account from journalist Elle Hunt about her struggles with burnout a few days ago, I had to acknowledge it. She writes very openly about it:

The crash, when it inevitably came, was more of a hard stop. At around 11.30am my hands froze on the keyboard: I simply could not type another word. Trying to will myself on was a surprisingly physical sensation. I was pushing on a pedal that had got me this far – and finding, with mounting distress, that the tank was bone dry. Closing my laptop felt like a failure.

Burnout is a negative mode to the extreme within the spectrum of strive and thrive, stumble and fail, within those fields of perceived wants and needs that lead to plans and work, all within our own professional fields as well as the personal and the grand political fields. We are often left to manage these forces and strains by ourselves; sometimes the feeling that we’re unable to cope encroaches ever nearer.

Discussing the stresses of work is really important, even more so as the burnout wall approaches. The dilemma is that the closer we get to burnout, the harder it is to talk about it. Elle’s take on it is the right one:

I am sharing my story not because it is exceptional, but because I’m convinced it isn’t.

It was her introduction to the book that got me reading James Suzman’s Work, A History of How We Spend Our Time. Hopefully she can use the New Year to reset her relationship with work, whilst I keep firming up my own thoughts on Work: or what we do to ourselves as engineers.

A post from one of my previous personae, Literally Engineering, from November 2020. I keep coming back to this one, and feel that the overall idea stands up well.

A field perspective of work and politics

Why think about work?

I was going to write about applying engineering methods to philosophy (I still plan to). Trouble was, as I got further into it, that post became more and more unwieldy as considerations popped up like: what are tools? and: what are engineers? (Philosophy, eh?) Since engineers work (as in - it’s our profession) that’s how I came to start writing about work itself, to provide a basis for those questions that, I hope, will let themselves be written about a little more easily. 

Remember: this a blog post, so it’s not definitive and I’m sure to return to the idea once I’ve read more into it (I’ve also just started reading James Suzman’s Work: A history of how we spend our time) - but… here goes!

Work: what is it good for? 

Fulfilling, defining, meaningful consumer of time; a source of satisfaction, stress and sleepless nights, of distraction from the finer points of life, or of structured relief from the chaos of family and friends, all of whom can also be… hard work. That’s work.

Have you had that experience, that if you fixate on a word in your mind for too long, it suddenly sounds ridiculous? “Work” ends up sounding like a frog’s croak or something. But before it reaches that stage, “work” can stimulate all kinds of hints and notions and emotions, whether we focus on its meaning as a verb or as a noun, or let it flicker between the two. Professions, occupations, undertakings, jobs, roles, tasks, responsibilities, duties, even hobbies and maintaining relationships: all these forms of work are, fundamentally, as in physics, a question of energy transfer. 

Without a potential or a gradient, energy will not flow. And in the case of work, without a start signal, nothing will cause that potential to rise. That potential is of a mental, emotional nature that can, at a certain threshold, signal the pumps to start up so that energy can be transferred to whatever objective we have in mind.

The signal, the “programming” of the operation and the action itself involve the bridging of some gap between a current state and a future imagined state. All of that together builds “work”.

Building up the model (this is also work)

It is feasible, if unrealistic, to consider the future imagined state being precisely the same as the current state (the defining word here being “imagined”). Practically speaking, we might think of this as being the notion of maintenance activities, but maintenance is still “real” work, requiring energy. For this “zero work” scenario, we would have to imagine someone sitting in a pleasantly perfect state, with no improvement or activity imaginable. Or someone who was dead, but that path doesn’t appear to lead to any useful conclusions.

Here’s what it might look like:

This state can only last to the point at which our character becomes bored, or uncomfortable, or wet or cold, or hungry, or needs relief from previous digestive activities. A tension arises, which spans the current scenario and an imagined future state:

The tension of intention

Right now, that character can “see” and hold a new, imagined, state, in mind - a “field of intention” sounds about right as a name for this - but nothing happens yet beyond some highly complex neurological and physiological changes that prime our character for action. Mental maps are generated of where the action should take place and where appropriate utensils might be found, a general concept of how the action might be completed is mentally sketched, as is an assessment of how much energy might be expended during the undertaking - which can also lead to the conclusion: “ah, forget it”. It’s only when an action occurs, however, and physical energy is expended, that the tension can be resolved, as in the sketch below:

The arrow represents some kind of action, and the new state is now “real” - though it may or may not be the one that was imagined. Smashed cups, bleeding fingers or unsaved work being lost are not generally part of our imagined states, but they happen.

There might be complications…

Of course, in real life, things aren’t as simple as a single pairing of state and new state: there are near unimaginable possibilities for work and potential new states are bubbling up continuously and almost simultaneously in our minds - a major stress factor in life is often “what to work on?”:

Sometimes the answer is clear, sometimes not. Sometimes just doing nothing is… very appealing. Typically, it is rare that we can complete one task to the exclusion of all others. In the course of a day, for example, we’ll meander from task to task, completing some, making progress on others, ignoring others still.

Each point along the meandering path actually represents a new state, where new possibilities arise, leading in some cases maybe to the sudden elimination of one possible task, or perhaps the creation of several more. This results in the “bubble” of imagined states taking on a different form (or, at least, content), with different intensities, at any point in time.

It’s the intensity, felt or understood emotionally as well as rationally, arising from all of these potential futures and actions that drives our decision making

Constraints set us free

This is not the place to discuss in depth the notion of freedom, but it seems pretty clear to most of us in these pandemic times that freedom to act also requires ensuring the safety and security of others to act. This implies social constraints that allow us to act upon our fields with confidence (because we and those around us know what is right) or - if we have nefarious or illegal intentions - we have to have to act below or around constraints, in secret, for example. These constraints also condition the array of imaginable future states. 

This all brings us to the next point in this - up to now - very simple sketch: other people.

If operating in society is sociable, then even engineers are sociable

Fortunately for most, to the chagrin of others, we humans don’t live or operate in isolation. We live and work within groups that build fields of tensions. Sometimes those tension fields align, and are complementary, like “we’re all hungry”, or “our spears are rubbish, we need new ones”, or “we should invest in education for our children” … and actions based on those tensions arise, not all of which - it has to be said - are complementary or coordinated, but the overall vector of which can target the imagined state:

These groups may be small or large, and come from all ends of the spectrum of human activities. Some groups will be our employers. Other groups may be colleagues in other departments acting as further constraints (Finance! Sales! Purchasing! Legal!). Groups can be companies in competition within an industry, or from different fields mutually assisting one another (e.g. engineers and medics), or mutually opposing each other (environmental activists and fossil fuel energy companies).

As groups encounter other groups, societies build up, and the fields of tension become more complex still. Politics arises (also, by necessity, within our companies of employment), providing guidance and structure / infrastructure, as well as constraints - and gets messy:

Sometimes societies are largely peaceful and are able to maintain a way of life via consensus and legitimate state power: some permit autocrats or populists to come to power, who need to create and highlight enemies both from outside their society, and from within, usually distinguished by race or religion (sigh), who need to be subjugated or expunged:

Pictorial rant aside; In any case, ideas arise from groups or individuals and need recruitment of others to perform actions with sufficient strength to achieve those goals. Recruitment also requires coordination or coercion, but these are ways of guiding or moulding the “intention field” of others.

The future imagined state from here?

The future imagined state of this blog is to have posts on what are engineers, what are tools, how the two interact, and, ultimately, for this series at least, to return to the original idea of applying engineering methods to philosophy.

Thinking back to groups: can they completely bypass each other? Perhaps, but it seems that technology and the engineers who develop it are a link to pretty much all areas of activity in the “developed” world. Think birdwatchers without the creators of binoculars or monster telescopic camera lenses. And that’s where I think we can fit engineers into society - who will be the subject of my next post.

posted in 2015, this text was I think an attempt at capturing the solitude and darker thoughts of a sleepless business traveller - and, boy, did I sleep poorly on most business trips (mostly, I now realise, to my FODMAP intolerance to onions and garlic. I clearly wasn’t on a business trip on the 27th of December, but remembering one - probably brought to mind by a similar poor night following a celebratory meal

Disorientated. Where? Dim pre-dawn - or streetlamp - light crept lethargically, reluctantly, unenergetically through a gap between blackout curtains. Energy aplenty thundered in audio form through the window and into the room: sound waves, but not homely. A hotel room. A truck, or a tractor. Almost military. No, not that - but east European. One east European truck or tractor followed by another: agricultural. A church or town hall bell, three simple rings. What in God’s time is it? Yes, three quarters past - quarter to - what?

Where, a hotel room in Romania. When, a quarter to. Who? And why?

Hand stopped half way to reaching smartphone and dropped back onto the bed. Time was unimportant now, as was place. This was him: a family man. This was him: a company man. This was him: an engineer. Half awake, three quarters not there.

So - a company man. Could that be a defining characteristic? If so, then he had changed. If not himself, then at least his company. He didn’t feel that different after all, even if he was now working for the competition. So - not defining. It was a new start, let that be sufficient for now (not this short now - a long now). Fresh perspectives and new beginnings had brought fresh motivation and impetus - surely to fade - but why not enjoy making new connections and revisiting old challenges with fresh eyes?

A company engineer and a family man: plenty of work to be getting on with. Reason enough not to be lying unasleep in a foreign bed, awaiting meetings, reviews, discussions, coffees and presentations with a whole new group of people. For what? Oh, don’t let’s go there now: there is no what for. Especially when the real question is: for whom?

I am why. They are why. You are why I read specifications line by line - especially the ones I have written; why I go through drawings item by item, FMEAs cause by cause, assign component attributes like a librarian, consider new developments like a patent lawyer; test parts, write reports, write emails, write presentations, travel to stranger places than this - and, from time to time, to write about it all here. For the company: your company.

Four more simple rings, followed by four sonorous ones. Two and a half hours to wait for the smartphone to ring, hopefully until then oblivious to time…

I’m writing this between lectures and dinner on the first of a 2-day FMEA forum in Osnabrück and I’m trying to figure out what to make of it all. If that opening sentence fails to give the impression that I’m bubbling with enthusiasm or energy from the day, it’s because - well, I’m not. Of course, sitting around being talked at isn’t the most energising of inactivities itself, but the content shown so far hasn’t fired me up in any significant way.

The theme of the forum is “FMEA success stories” - but those stories have been in fact pretty sparse thus far. Two of today’s main presentations were about their respective companies' efforts and struggles to implement strong FMEA systems and culture into their workflows. One company gave an update on its mission (now into its fifth year of ‘x: unknown’) to implement an FMEA software system and methodology into the group. The other gave a shorter overview of how they’re getting on (or not) as they make a start on the challenge. The takeaway from these presentations was the obvious: yes, it’s difficult to move away from scattered, ineffective but audit-tick-boxable Excel files to a centralised monolith. And, yes, you need executive and management support for such an undertaking. But not even from the company that is so far along the road did I hear a story about benefits. They have basically arrived, but where, and why? I didn’t hear any anecdotes about finding otherwise hidden potential failures, about reducing potential quality issues by humungous amounts, anything like that

One presenter plucked up the courage to show his efforts to convince a director to invest in FMEA via the means of monetary value (another key theme of this forum). Our presenter’s take was that robust and reusable FMEAs help to prevent project overruns - (on the basis that you won’t be validating things too late, and when validated, then with the expectation of OK results), so the most convincing financial metric was in fact time - a shaky assumption if ever there was one, and one that nobody could pluck up the heartlessness to destroy in the Q&A afterwards.

There is a close-knit group of FMEA gurus in Germany, who attend each and every one of these forums. They consult for others, and many of their clients were here, too - so there is certainly a self-appreciative air to the proceedings, of their being a natural and self-explanatory part of the engineering world. Data is less available. But one guru at least mentioned that his research team studied around 500 FMEAs before and after switching to more robust software and methods: the robuster methods rooted out around 30% more potential failure causes than the older versions. He did proceed to weaken his argument somewhat by stating that most of these were repeat or piffling items, and there was no factoring of the “novelty” problem (would these new causes have been arrived at had the systems been analysed with fresh eyes, albeit using older methodologies?) but at least a couple of the new ones could be treated as being noteworthy.

So - these success stories we’re talking about. They are where, exactly?

There was a presentation on making FMEA meetings more effective by trying to eliminate discussions on rating causes (occurrence and detection ratings), and by highlighting the financial aspect of potential risk - but that’s still a very inward-looking process improvement.

A further presentation from two “big” Americans (in the sense of being FMEA-gurus from America) tried to show the differences between the AIAG and the VDA-described methodologies - but that was a thoroughly overblown observation. When I asked if anyone had “raced” AIAG against VDA on the basis of one common design, to test the theory, or even to try and see if one method favoured one type of result over another, the answer I received was an at least nicely succinct “no.”

That discussion all boiled down to “it doesn’t matter which method you use, as long as you use it properly.”

To turn the focus back on success in FMEAs: how can it be measured? Of course, it’s the nature of the FMEA that potential failures are thought up, thought out and minimised - and those thoughts involve (or should involve) a lot of internal company knowledge and evidence. So nobody wants to (or is permitted to) talk about specifics - but with the forum having been so entitled, I’d have thought that the organisers would have found a way to try to tell the stories in a stronger way.

Perhaps, though, in the context of such a forum, they felt they were preaching to the converted, anyway, so didn’t need to do much “selling”.

Click ‘Go’ to start

Generally what an FMEA is trying to do with a mechanical system is to bug-check its logic. Perhaps we could consider a better tool from software development (How Google Tests Software, for example), where a model is created that through a multitude of test runs can quickly highlight the potential week points. That would be even more difficult than manually thinking things through - but cleverer. Perhaps that’s simply where we stand right now: we’re chipping away with post stone-age but pre-steam tools - and doing a pretty decent job of it, we think.

I know, let’s look in the FMEA

A common selling point of the FMEA is its potential (that word again!) to capture a company’s knowledge through lessons learned, updates and actions, linking to evidence and reports, etc. I was also sold on that for a while, but right now I’m less confident about it. After the “5 year-mission to explore new worlds” presentation, I asked how many of that company’s development engineers use the FMEA software. The answer was: none. Of course expert systems can be difficult to drive, but it seems strange to me to have to rely on external moderators to create the FMEAs, and then on searching through pdf documents to find key lessons learned and design considerations.

Where does FMEA belong?

Many of the FMEA colleagues I met so far came from Quality Management - which I feel should be the parking spot for completed FMEAs. But FMEAs that are still themselves under development (theoretically in parallel with the ahem new product that is gestating) should reside with the product- or process-development teams.

I raised this point later over beers and dinner: others countered that engineering students don’t learn about FMEAs in any meaningful way, so they can’t be expected to maintain one as part of their jobs in the same way that quality engineers do: but that’s more of a comment on engineering education than on any philosophical decision to shield development engineers from such shudderingly plodding work as FMEAs (to put a negative twist on it).

Go on, have another beer and lighten up

The key to these FMEA forums is, of course, the networking. Everybody in the field, regardless of product, industry or division (quality or development) has basically the same problems with FMEAs. But few really try to come to terms with what it means, and what benefits the system has. So it was good to meet a few skeptics among the herd who saw the presentations as well-meaning but non-value-add guff, and who also saw the principal value of such forums in the people themselves.

The evening dinner of local Grünkohl and Pinkel sausages in a local Osnabrück brewery (Rampendahl) made for fascinating conversation, especially as I ended up sitting amongst three of the world’s key FMEA software developers.

But now, after some noticeable time-hopping, it’s time to upload this post, grab some breakfast, and get ready for the onslaught of the second day…

It is fair – and not in the slightest bit unusual – to say that we have been struggling to apply our resources properly of late.  My office is nominally dedicated to product development - but, with our well-appointed laboratories on site and our general level of expertise and “seen it all” experience, we’ve ended up having a whole pile of test and validation work to plough through, which, as I’ve pointed out in the past, I personally don’t view as one of this engineering life’s great driving forces.

{An aside: ensuring that your development team is focussing on its job is a perennial battle: a recent article in the Economist on the future of work points out a study done by Pfizer in 2008 which showed that its most highly skilled employees were spending around 20 - 40% of their time on routine work. Now, if I could even get up to 20% development work, I’d be happy…}

Roll up! Roll up! Become a validation engineer!

So - I want to be less involved in validation. This means I need somebody else to do it for me. I’m not a marketing type by any means, so enthusing about something that I despise doesn’t come naturally - but I still need to think through how to “sell” validation to someone else. I need to think things through, which is the general point of a blog, unless I’m very much mistaken - so here goes:

• There are plenty of people who like little more than running around organising things - defining who needs to send what to whom and by when, then chasing up on all those leads.
• There are others who have the ability to create, track, update and check off tasks in lists.
• There are still others who enjoy the mechanical challenge of getting parts to fit into unnatural environments (we don’t necessarily design parts to fit into test chambers)
• There are plenty of people who feel important when they get to put a “pass” or “fail” stamp on things.
• There are engineers who can lose themselves in reading and understanding specifications,
• And there are those who are happiest with the prospect of endless work without much in the line of variation.

A validation engineer needs to combine all of those attributes.

That’s me in the mirror

So which of these attributes don’t I have? Well - to point out the obvious first: I can work on validation (successfully, too, it would appear, as I keep on getting more of it to do!) - I’ve done it for year upon grinding year. I fail dismally at routine and at repetition (validation often requires testing the same set of combinations over and over, from different production locations or tooling sets, for example) and I really have to force myself into ordering precise numbers of components, counterparts, etc, force myself into counting the parts that arrived, and figuring out how to fit them into test equipment.

But it’s largely a condition that borders on the philosophical - validation is at the wrong end of the engineering spectrum for me: it should be the crowning “dumb” step at the end of all the concept, specification, definition, understanding and testing work that constitute the development of a product into something produceable in series. It is validation as in rubber-stamping: this is a valid product; it does what it was expected to do, namely – meet specifications.

Meeting specification is the go gate for product in the “physical” world – not release into the market. We can’t iterate as quickly as app writers can, but also smartphone apps don’t generally have the potential to kill people if they go awry. So the biggest task for an engineer in the traditional industries is to write a cogent, coherent, consistent – and legible – specification that can act as a realistic hurdle and as a decider between good and not good product.

Then, other engineers need to read those specifications. Alas, the percentage of humans who have actually read through, understood and organised test work according to specifications is as vanishingly small as the number of people who actually wrote those specifications still being in that role.

Let’s validate - something - quickly!

As soon as someone, somehow (often based on arcane and mysterious procedures – or company lore – or on a whim) decides that validation testing is required other than as the natural end of a development programme, chaos ensues.

Emails are sent expressing urgency, whilst tacitly acknowledging cluelessness regarding how actually to proceed; priorities are dumped on the already overloaded yet ever-helpful testing team – and above all, the sense of the emails is one of desperate hope. Hope that responsibility can be abdicated, that no further questions will be asked, that no sample parts need to be organised, that timing will be according to promises already made.

Of course validation is urgent, and of course it’s important – in our world you’re simply not permitted to deliver (or be paid for) parts that have not satisfactorily completed validation. It’s just that, for a development engineer, validation (as opposed to development testing) is dull, dull, dull.

There, I said it.

Finally, though, we managed to get some outside help, and we hired a student – more about which in the next post…

More than a few years ago, bordering on the “many”, I was invited to take part in a graduate selection weekend for Ford in the UK. It was a battery of tests ranging from one-on-one interviews and team-working simulations to presentations and problem-solving “incidents” – all nicely wrapped up in dinners and coffees in a pleasant hotel in the countryside.

One of the tasks – maybe there were twelve of them, I didn’t count – was to decide what equipment should be offered as optional, standard or not at all for a sporty Ford Escort model (these were the pre-Focus days), to meet a budget. We then had to write a report explaining our choices, needing to meet a most important deadline (lunch).

Being a bit of a car enthusiast, I made what I thought was a decent selection (including ABS and airbags as standard equipment), whilst keeping some budget for a few luxuries as standard (a CD player, I think), to differentiate Ford from, say, BMW, whose cassette tape decks were one optional extra, speakers to hear music from seemingly another…

Being a well-drilled undergraduate engineer, I wrote the subsequent report in the only way I knew how - with an introduction, a summary, a body and conclusions.

When I was given the job offer a few weeks later (which I took - a decision point that remains with me to this day, and is definitely worthy of a post of its own), Ford gave me some feedback over the phone. My presentation had been borderline terrible, but the report I had written was excellent.

In fact, it turned out that I had been the only candidate to actually write a report. Everybody else had written prose.

So, in honour of that, and in recognition of the possible fact that report writing remains for me, over emails and presentations, the main recipient of work related keystrokes, here’s my report on report writing in engineering.

TITLE

An Investigation into the enduring and endearing constraints of report writing

Author

The Literal Engineer

SUMMARY

The act of reading a technical report involves a certain mental effort. This effort should be rewarded with increased knowledge. In order to minimise the effort and to maximise the potential for knowledge extraction, the report writer should generate the report in as standard a way as possible.

The act of writing a report invokes a particular and peculiar mode of language, which itself requires a mental switch and effort to maintain, the passive voice. Writing in the passive voice lends the report an appearance (but no guarantee) of objectivity. A potential pitfall of the passive voice is the risk of the writing becoming stilted and unreadable. Yet this pitfall is deemed to present a lower risk to knowledge transfer than chatty and poorly applied novelistic writing.

Deciding on the tense remains difficult. The report should be written with history and evidence in mind; a report is a snapshot of the status of whatever is being investigated at the time, in this case – report writing. Using the passive voice is, overall, a positive constraint.

EQUIPMENT

Mid 2012 MacBook Air

2006 Rain Recording PC workstation with Logitech keyboard and mouse

Microsoft Word 2013 and Online

Microsoft Office 365 / OneDrive

Typepad blogging platform

Evernote note taking platform

Firefox and Safari browsers

1. INTRODUCTION

A technical engineering report can be understood as a window to a complex and meaningful event (or series of events) that took place within an organisation. The intended goal of a report is that its findings be understood. For this goal of understanding to be even remotely achievable, the report writer must describe the event in sufficient detail with sufficient brevity and clarity to form a synthesis of the outcomes of that undertaking. A report should therefore be  logically structured and legible.

Ideally, the summary and conclusions from a report should add to the great body of human knowledge. It is recognised, however, that, more often than not, reports must be produced to describe small-scale and often painfully regular events.

Regardless of where a report lands on the scale of import (or lack thereof) to humanity, the form and language follow traditional structures. Report writing in the technical fields is designed to enforce (the impression of) objectivity. The passive voice depersonalises the investigation and can be construed as an attempt to prioritise facts over individual actions.

I did not post this report on 30th Sep.2014

rather:

This report was posted on 30.09.2014

The tradition of using the passive voice imposes a constraint on the writer, which forces upon him or her (the passive voice at the very least enables authors to avoid the awkward distinction of the sexes) a mental switch and effort to make and to sustain the passive voice. This is an appropriate cost of entry, as the reader needs only recognise one style, whatever the source of the report.

2. THE STRUCTURE OF A REPORT

Reports are constructed around a common set of elements that may vary in style, format or order from organisation to organisation, but nevertheless ensure swift navigation to the pertinent sections or level of detail for the experienced reader - from an overall summary (usually to be found near the beginning), to detailed descriptions of equipment and methods used, via a logically structured body of evidence and discussion. The report at hand loosely follows such a typical structure and does not purport to set any standards with its own form.

It is also based on very little evidence.

3. THE CONSTRAINTS IMPOSED ON LANGUAGE IN REPORT WRITING

Actions and analyses leading to conclusions and summaries – no matter how breathlessly exciting at the time of their experiencing – are, in translation into a report, passed through a mental filter that compresses them into the passive voice.

This imposes a constraint on the author, which, similarly to the imposition of a recognisable structure on a report, lightens the burden on the reader (see Section 3.1 for more considerations on the reader’s role).

As in so many cases, especially in the arts and in engineering, this constraint can be viewed as overall positive: few physicists or engineers have been recognised as possessing the gifts of novelistic writing (or even spelling); honing the craft of the passive voice relieves these authors of many grammatical pitfalls.

The key to the passive voice, and the difference to novelistic writing, is that there are no characters or personalities to deal with. Someone or something does not do something to some other thing or person. Rather, some action is done to some object.

The strut was loaded into a tensile testing machine and its stress-strain curve was determined.

The sample was subjected to 60 cycles of cyclic corrosion testing according to specification X

The tea bag was placed into the pre-warmed cup. The cup containing the tea bag was filled to just off brim-full with boiling water. The assembly was left to stew for 4 minutes.

Humans act in all technical investigations, but the passive voice strips them out as being extraneous information. Whilst this is not always to be considered positive in most human relationships, being able to divide out the common denominators is, just as in arithmetic and mathematics, key to understanding the basic signals of what is being investigated. Humans, then, are a form of noise – in technical reports, at least.

Writing in the passive voice is a skill that must be honed with practice. For as long as the passive voice does not come naturally to the author, each sentence needs to be reviewed to ensure that the reader is not forced to stumble upon a person or a character rather than a description.

The implication of objectivity is valid. It doesn’t matter who did the test (especially in the sense of Professor vs. technician, or he vs. she): it’s not a diary. That information can be captured in lab notes, engineers’ notebooks, or the famous case notes from AT&T Bell.

3.1 THE BENEFITS OF THE PASSIVE VOICE

The passive voice is intended to portray the investigation as being impartial. This:

• enforces a certain mental discipline
• requires a certain mental “Umstellung” that brings the author into a standardised frame of mind.
• permits the reader to read reports from any source in a similar frame of mind.
• avoids “War and Peace”-style questioning of who was doing what to what other thing – no need to buffer names
• ensures that personalities and their status are largely avoided
  • The facts and conclusions come first.

3.2 DISADVANTAGES OF THE PASSIVE VOICE

• It is easy to “hide” the contribution of laboratory personnel, lower level engineers, and so on, to attribute the report to one “star” player. This is more likely to be an issue in the world of university, where academics are forced to publish on a regular basis – a quality investigation on a returned part is less likely to be the cause of professional envy.
• Can be stilted, can become impenetrable,
• Enforces the use of some awkward words or constructions

4. SELECTING THE TENSE

A key decision that needs to be made early on in writing the report, one which generates some confusion, even within one report, is the tense. Some decision aids are suggested as follows:

• Tests are described in the past tense: they were performed (“the samples were tested using the tensile testing machine at yy mm / minute”)
• Results are described in the past tense: “the stress-strain curve Fig. x.y was generated”
• Findings may be either in the past or in the present tense:
• If a test was performed on a particular sample, e.g. investigating a failure, then the findings may be presented in the past tense:
  • “brazing of the joint was found to be incomplete”
• If a result was fundamental, then the findings may be presented in the present tense: “the maximum tensile strength of the xx joint is YY MPa”

5. CONCLUSIONS

The technical report remains its own art form. Its art is knowledge and its form shall minimise the resistance to knowledge transfer. I really think that the passive voice helps to – oh, damn!

BIBLIOGRAPHY

www.sussex.ac.uk/ei/intern…

Whilst I’m no longer much of a gamer (I finished Half-Life 2 and got several hours into Oblivion before dialling down the game time), I do like to keep tabs on what’s going on in that world. Right now, the biggest thing since sliced zombies is Destiny,with its massively online save-the-solar-system campaign of dealing death to death-dealing aliens. Its creation was a huge undertaking, both in terms of manpower and financially.

One paragraph of one article about Destiny really stuck with me, though, and it didn’t have much to do with the game itself. The Guardian newspaper (I wonder if they got additional access because of the paper’s name?)  had a behind-the-scenes article about Destiny that described how large an undertaking it was. The project was so big and so complex, with so many people working from so many different perspectives in such a big converted cinema, that they created the position of “workflow engineer”:

“The company employs a workflow engineer, Brandi House, whose job it is to mediate between the art team and the programmers. “The team kept growing so it became harder to just walk up to the engineers' desk and tell them it’s not working,” she explains. “The engineers started to say, ‘Well, we have 200 artists – I can’t get any work done!'” House has a PhD in electrical engineering and is an expert in user interfaces – now she’s applying that skill with systems to a workforce, - she is effectively debugging the development team.”

This is the wonderful thing about engineering. It is so loosely defined that it can seemingly be applied as a concept to pretty much anything. For engineering to really kick in, that something needs to be complex (yes, a pencil is complex, if you look at it from the right perspective), it needs to be definable and there need to be adjustable parameters so that an optimum can be targeted.

Once you know more or less how something is, you can define - more or less - how it could, or should be, and how - more or less, once again - to get there.

So, whether it’s sorting out your early morning breakfast workflow, or designing your low orbit home rocket - or even if you’re nominally an engineer at work and want things to be better: engineer your destiny!

Lose Yourself to Engineering?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Happy 2014!

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

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

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!

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!

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!

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.

*I would normally put a number to this, but we’re just upgrading our SharePoint database, and stats have been switched off. I don’t know if they’ll be reset when they’re available again. I’ll update as and when I know.

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

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.

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!

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.