Last week I was at an offsite business workshop, where the key players gathered to hammer out the setup and highlight the hurdles for the next phase of our major PLM project. This offsite was in Ladenburg, that charming historical Roman town between Mannheim and Heidelberg on the Neckar river…

… though of course, our hotel’s location was in the industrial outskirts of the town, where the charm was of distinctly another flavour. I didn’t stay at the hotel, choosing instead to cycle there and back, a lovely ride along the Neckar (going past the spot I’d been recently on my Panasonic road bike).

The hotel even had a section dedicated to bikes in the garage, which was greatly appreciated.

One lunchtime walk to escape the noise of such a large group took me to the fields outside Ladenburg, with a view to an old-looking chemical factory. See, it does have its charm:

I’m a pretty good sketcher of words and ideas, but a terrible completer of posts: making sure that the ideas make sense and connect properly, trying to get the wording and the feel right, trying to draw conclusions and lessons from whatever experiences or thoughts I am trying to describe; sometimes even deciding which service to post things on (a ridiculous situation, in all honesty) - that’s all hard work, and sometimes I just don’t feel that I have the energy to complete it.

As a result, my pool of drafts begins to overflow and prevents me from really finishing.

So, in the spirit of draining the pool and refreshing my perspectives, here’s a dump of my most current drafts, cross-posted on Blogger and on my Micro.blog instance!

Rethinking which services I should keep, and why, is something for another day.

A review of Umberto Eco’s The Island of the Day Before

created 2023-09-06

This is a most typically Umberto Eco book, of an unknown, uncertain narrator reconstructing the putative, fragmentary notes of a shipwrecked passenger of a sailing ship, weaving them into an improbably rich, thoughtful, infuriating and nebulous narrative.

Had I not read Six Walks in the Literary Woods, Eco’s talks on his theories of narration, including the constructs of the Model Author and the Model Reader, had I not already re-read The Name of the Rose and Foucalt’s Pendulum, I may well have given up on this book.

Is Agile agile?

created 2023-09-28

I remember years ago reading about an almost unbearably enlightened concept in project management called Agile. I wished, as we trudged along those familiar, well-worn yet somehow always overgrown, brambly and muddy paths through gates and past millstones - sorry, milestones - towards yet another similar product launch in the automotive industry, that we could put those paths behind us and start afresh, be agile.

The name itself was glorious, tantalising, joyful, even, bringing to mind fleetness of foot and unbounded creativity with the goal of bringing something new and fresh to the world.

That, I had to admit, didn’t seem to very closely describe the world I worked in. With Agile’s origins in infinitely malleable software, I knew I would never personally experience agile project management. Herding recalcitrant parts into vehicles was always going to be an uneasy fit with agile methods, I was sure.

I would never experience agile; until I suddenly did, at my new company in a new industry - and I have some thoughts I’d like to share.

No, agile is not agile

What I can say, after five cycles of sprints, workshops, reviews, retrospectives and planning is: the method never for a moment felt agile.

In our short training course we learned how we could achieve a goal even within the constraints of stupidly and very artificially short development cycles. Rapid feedback loops would trump planning and design (which always leads to trial and error anyway).

But the way I experienced our agile project was remarkably rigid. We brainstormed a load of User Stories against an equally brainstormed set of OKRs (Objectives and Key Results), which formed the “Backlog” (even though they weren’t at that time uncompleted or delayed, which is my usual term for items that are in backlog), then dumped a load of them into the first Sprint.

That Backlog was in one sense the Prologue to the whole project, and our very own, self-defined Millstone.

Now, of course we weren’t totally naive about it: we knew which User Stories represented basic functionality and which would naturally come later, once these basics were sorted. But a number of difficulties with our systems meant that we got bogged down even at that early stage and the prospect of closing off User Stories in an acceptable and documented fashion diminished day by day.

And then, suddenly, it was time for the Sprint Review, for the Retrospective from that Sprint and planning for Sprint 2, with the Backlog looming like some Godzilla of Not Done, no paradigm of agility.

We were able to add User Stories as other issues cropped up, and we did in the end discover that some User Stories were irrelevant or completely incapable of being completed with the systems we were working with: these were ultimately tagged with “Won’t Do” rather than Done.

But that initial setting of User Stories set our path in just as rigid a manner as the traditional “Waterfall” method, and I even began to think that the Waterfall has some benefits like repetition of tasks and documentation for each milestone, ensuring that they mature with the project, rather than being looked at once, documented and dumped.

What did I learn?

This is a key question for any initiative and is built in to the Agile method in the guise of the Retrospective.

At work I - with the team, of course, it couldn’t be any other way - recently completed my third ever sprint review, took part in its corresponding retrospective (the cool kids say just “retro”), and planned for the fourth sprint, by reviewing and prioritising the backlog.

To put that into context, I am now - finally! (I can no longer write “Finally” without thinking of Vaughan William’s A Sea Symphony) - involved in my very first “agile” project, and I’m at least getting used to the jargon. But, is it as good and as efficient and energising as I imagined it to be, back when I was on the outside, jealously looking in?

From the confines of automotive industry projects and the traditional task-and-milestone mills that were our project styles, I would hear and read of some distant enlightened lands of agile project management: from where I stood, agile appeared desirable, enjoyable, more efficient, “better”: today I wonder if this is really the case.

As with any , including training that included the agile manifesto, descriptions of sprints, retrospectives, workshops and all of those good things - or at least a variant (the purists would no doubt say ‘deviant’) of it - at work, and I have some issues with it.

I’m also somewhat distracted by the vocabulary, especially the notion of the word “backlog.”

Before starting the project, the word backlog felt wrong to me: it implies work that behind its planned completion date and is building up through some form of bottleneck, whether this be . Before kick-off, backlog is prolog(ue)

This Guardian opinion piece on the British NHS, or [this search]([NHS backlog site:theguardian.com) for articles containing the words “backlog” and “NHS” in the Guardian, or this article referring to the backlog of asylum applications in the UK really give a sense of what I mean

Now that we’re a sprint in, and we see what we had collected as “to-do’s” and did and didn’t complete in that first sprint, we see the collection of unedited “User Stories” that really does act as a mass to be reduced. A backlog, perhaps, but also a mountain of ice cream needing to be eaten spoonful by planned spoonful

User Stories are not tasks

Project Management is a technology, a process, a human-made artefact, which also enforces a lot of documentation (that most people in the world won’t read)

Engineering engineering

created 2023-10-14

really for my Literally Engineering engineering blog

I tumbled literally not engineering into the New Year 2023.

Now working again, a confirmed escapee from the automotive industry, I find myself contentedly and, by my own reckoning, at least, gainfully installed in the engineering community of a medium sized company making sensors for industrial applications.

I also find myself wondering whether I might still actually be literally not engineering.

Information wrangler

My new working environment, beyond the desk, the chair and the coffee machine, is digital. I no longer handle parts or discuss testing in the lab. Instead, I deal almost exclusively with data and information: electronic representations of real, or potentially real, things (sensors that other companies buy), and with “non-things” like methods, guidelines, specifications and communications.

Through this last point, clearly I do deal a great deal with the very real, the occasionally thoroughly perplexing and frequently enriching interactions with my colleagues and other humans in all their complexity.

In this combination, my role combines both forms of knowhdge characterised by Aristotle that I’ve been focussing on, techne and phronesis, which refer to making (in the original sense of the crafts) and practical politics respectively.

Aside from the physical handling of parts both new and old in my previous job, is this any different?

In one respect, no, it’s not very different: the technical drawings that I used to produce, or, better, have produced for me) are informational representations and intentions of something that should ultimately end up being made, manufactured, turned real. But my current position puts me at at least one remove further from our final product. I help to ensure that our data and (data + meaning + truth or accuracy = ) information ends up in the right form and location, with sufficient accessibility and searchability that it is useful to those colleagues of mine who do work on products that will ultimately be manufactured, sold and put to constructive use in industry and society.

Gotta role with it

My position currently consists of three main roles: representing mechanical engineering in our company’s new PLM initiative, updating and managing our design guidelines, and, closely linked to those, managing our CAD systems, methods, and - surpise! - data (servers, databases, etc).

This new working world of mine has an expanded ontology compared to the previous one, in that I now also have dealings with two additional domains, electronics and software. These, too, work mainly informationally (electronics schematics creating the general logic, plus the software and firmware that tame the chips).

These domains can be seen as models for my own new sense of engineering, if engineering is what it is that I do. They construct “devices” that work according to particular rules and logic, to meet certain goals, within a largely technical domain.

They make use of tools and consider ways of testing their output against predetermined requirements and - that word again - constraints (price, availability, approvals, maturity, etc).

In total, this set of roles raises the question for me: what of that is engineering?

Intriguing devices

If electronics and software can be considered as “devices”, then so could the objects and elements that I work on: the outputs of my work are not physical but logical devices of varying complexity, that need tweaking, tuning and, occasionally an overhaul or complete replacement.

To be able to do any of that, I need to understand their mechanisms, weak points, inconsistencies and failures - just like in any engineering context.

I can consider as actually being secondary to their actuality in the engineering environment as actually being secondary to their actuality in the engineering environment.

Infra-engineering

Like infrared or infrastructure, infra-engineering is my imagined term for the work done “below” engineering, to support it. Foundational engineering , we could call it.

of what I do is engineering? This is where my uncertainty regarding the definition of engineering itself requires that I attempt to break things down into sensible components to see if, during reassembly, any parts or subassemblies look like engineering as I understand or have experienced it.

A more philosophical stance

One attraction of where I now stand in the engineering landscape is that I can view the whole more philosophically than before. I can use the term “ontology” in both the technical, “PLM” sense of listing out the parts that we have, and in the more philosophical sense of “what are we dealing with here, exactly?” This would include discussion of our beliefs in PLM entries representing physical products, those entries including thumbnail images of CAD models of those components ; or, indeed, considering CAD assemblies as mere containers for the components, plus positional relationships.

It can all get me back to the very beginnings of this blog, considering the writings of Gilbert Simondon , and his considerations of concrete and abstract parts.

Outputs

Perhaps the clearest way of investigating the essence of my work is to ask what I will be “producing.” For a “true” engineer, the product would be clear: designs and specifications according to which items could be made and sold to a market.

Rather than items that can be sold onto a market, I am helping to design the environments in which our engineers work. My customers are my own colleagues, the engineers - and they can be demanding! In addition to designing that environment, I’ll also be documenting it and specifying how these colleagues will work: I have to define both the path and the handrails / safety railings for it.

That sounds very bureaucratic, I’ll admit. But here, too, is a question: are bureaucracies engineered?

Outputs:

• A realistic, understandable and internally marketable (acceptable) system and structure for storing and linking engineering data with other and with non- engineeing data.
• Workflows
• Administrative constraints and guardrails
• Specifications
• An organised knowledge base
• Installed, tested and approved software
• Tested and approved methods for working with that software
• so, whilst I no longer deal with labs, I certainly deal with testing: I write (or at least imagine) test scripts, and I record the results in text, screen shots and screen captures.

A digital Dewey

The obverse of outputs is of course the inputs that I need to consider. Now, since I’m not personally generating much of the data, but figuring out how best to organise and present it, like a digital Dewey for libraries, my inputs are the platform that we must tune to our needs, representative data for testing, and in Agile project management speak, User Stories and challenges, known issues and ways of working, that need to be selectively reimplemented or optimised, or bypassed, with the new systems.

There’s a train of thought that the administrations, procedures, methods and laws of modern society are themselves forms of technology. And technologies are engineered.

Here, I am still defining and specifying how our CAD engineers will work, including fruitfully constraining choices in terms of things like material selection, design for injection moulding and the like. These outputs will be the design guidelines and standards to which our engineers should or must adhere.

On the PLM front, I’m helping to define the form of engineering data and collaboration on that data within the confines of a pre-existing PLM structure.

Tools and methods

Graphing and flow charts, procedures and guidelines

Ways of thinking and interpretation

Thinking as an engineer who does rather like to minimise bureaucratic effort. Lifecycle and maturity states. Drawings and metadata. Relations, links and causality.

Knowing what we need to prove, our affordances

Handling our CAD data, our releases, reports - and the network of components, assemblies that ultimately lead to products being sold on the market.

Action and agency

In this role I do quite a lot. Testing to understand the limits and constraints of our systems.

How else would I describe it?

If what I do at work is not engineering, then what is it? Luciano Floridi refers to philosophy as conceptual design… So, could what I am doing at work, as well as here, in this post, be referred to as philosophy?

Or a chemistry of engineering: picking the atoms of information and turning them into valuable molecules, rigid crystals or flexible polymers of information that undergird the products that we make.

Perhaps I’m operating as a lawyer of technical information, determing what’s “right” in engineeringly “legal” ways.

The classic analogy for this sort of work is to the architect: someone who, combining innate, but trained, aesthetics with technical understanding and realism, creates - in combination with a vast range of experts - a new structure that can be used by many people over time.

Design engineer

I am a designer of engineering methods. The basic software elements are already present, the systems made available by companies larger than our own. But we need to select the

… and I didn’t get further than that (yet)

Jeptha (a Handel oratorio)

created 2023-10-31

Last Saturday, on the 28th October, I sang in my second Bachchor concert in the Peterskirche Heidelberg. Once more in English, though notably less heavy than Vaughan Williams’s A Sea Symphony, this time we were singing Handel’s final oratorio, Jeptha.

Wikipedia, with its patience of multitudes, has a much more informative [summary on Jeptha](https://en.wikipedia.org/wiki/Jephtha_(Handel) than I could presume to write, so I won’t go into the details here.

We had an excellent young lineup of soloists, including an emerging talent in the English tenor Gwilym Bowen , who sang the title role.

I did end up wondering about the political implications of the message contained in the story of Israel’s victory.

Employment (and) agency

created 2023-12-04

This time last year, in December 2022, I was coming to the end of my employment at Cooper Standard. The company was doing what alert companies do, reconfiguring the business to focus on growth areas, and my expertise in threaded fasteners and coatings was no longer considered to be of sufficient value to retain in an increasingly plastics world. Some discussions on timing and payout later, I was to leave at the end of the year.

It’s interesting to look back on that time of wrapping up: calling key contacts to let them know that I’d be moving on, reminiscing on fun and challenging times, wondering what gardening leave would be like; and, of course, digging out the CV to give it a good old refresh, and starting to wonder what I wanted to do next.

Even with the buffer of gardening leave, hope and expectation were tinged by uncertainty. What sort of industry would I end up working in, and would I be able to hold to certain standards (no military, no fossil fuels, for example) indefinitely? How big a commute would I accept, having been able to cycle to work for all those years? Uprooting the family wasn’t really a consideration, but the idea did lodge itself at the back of my mind, along with that other associated mental paraphernalia of leaving a position without having a new one already lined up - including starting the unemployment process in time, in - gasp! - Germany*.

That combination of hope mixed with unease at the directionlessness I was faced with (my pending gardening leave may have felt enticing, but it still led nowhere), held a certain diffuse meaning that it’s worth reflecting on now.

The value of work is grounded by predictability and security. If these are lacking, as they are in so many areas like the arts, or catering, or fixed-term contracts, and for those brave enough to set out as consultants, then you’re permanently on shifting ground, seeking balance, always having to stay alert for new opportunities and less able to switch off, to reflect and - in the extreme case - to appreciate the good things in life.

Fundamentally, it’s about having agency, being able to decide your own path, in your own time, on your own terms, resulting in Action - taking Hannah Arendt’s interpretation of the word - in which a person has the opportunity to show who (rather than “what”) they are.** Merely enacting (carrying out) jobs doesn’t suffice for action in this sense, which is why so many jobs can be unsatisfying, even when they are settled on a baseline of security.

Now, writing this in the luxury of a secure position, in which both I and the role(s) I have at Pepperl+Fuchs are developing, and with the buffer of time behind me, I can admit that the timing of my leaving Cooper Standard was right for both parties - sometimes inertia sets in and we don’t quite reach the threshold for action, requiring an external impetus to get us going again.

How should I summarise this post, then? What’s its moral? Just to make us aware again of who we are in the working world, to be appreciative of security, to be wary of dulling ourselves, and aware of all the other factors that play a role in our decisions, especially, of course, the people and society we live in.

* The Arbeitsamt turned out to be an excellent institution, proactive and leaving me to my own thing in the right degrees, and remarkably uncomplicated, once I got the hang of their website!

** This perspective taken from one of my favourite philosophical books, Back to the Rough Ground, by Joseph Dunne, chiefly about forms of technical and practical/political knowledge.

Back in February I posted about the challenges of being between jobs. Now, following a sequence of online first and in-person second interviews and a remarkably tough choice between two very different offers from very different companies, I’m just a few days (including a bank-holiday weekend) from starting my new job at Pepperl+Fuchs. It’s an exciting prospect, producing an intriguing mix of thoughts, feelings and excitement that I would like to just briefly reflect on here.

On a purely practical level, the nerdy part of me is most interested in the commute. I’m genuine in wanting to continue to avoid using the car to get to work, having commuted by bike for much of my career. Cycling directly to work is alas no longer a regular option. I tried the ride the other day, and it took me an hour and a half to get there. The route along the river is actually quite pleasant, but while I’m sure I’ll be able to improve the timing, it’s still long. My main mode for the initial phase (and, I presume, long term) is combined bike and train. Indeed, I recently splashed out on a Brompton folding bike, which I’ll use to cycle to the local regional train station, take the train to the other side of Mannheim (to Mannheim Hauptbahnhof… and beyond!) and then cycle the rest of the way to work from Mannheim-Waldhof station. I’ll have to see how I get on with public transport again, especially for the homeward journey, where I’ll typically want to get back as quickly and as predictably as possible. I also got it into my head that getting an electric moped along the lines of the Silence S01, also available in Germany as the SEAT MÓ (yes, from the car company), would be an option. It looks like a particularly efficient and effective mode of personal transport - and perhaps even not just a little bit fun… though I will have to upgrade my driver’s licence for it.

With the commute behind me, it’ll be time for the main event, arriving at and starting work. The first day will be intense but largely administrative - meeting colleagues (so many names to remember again!) but also getting set up into the company HR and IT systems, getting my laptop and phone (to work: nerdy-me also interested in, but also prepared for the disappointment of the equipment I’ll be given), installing stuff, setting my first login passwords, finding my desk and the coffee machines… all that good stuff.

What’s really tinglingly exciting in my head now is imagining how the the job will develop, in particular the question as to whether l’ll I be able to mould my projects in the way that I imagine them now. Every so often I’ll catch myself more than just imagining, more borderline fantasising about impressing the team with my excellent ideas, my pertinent and assumption-busting questions, nobly warning them of “gotchas” to avoid that I’ve experienced or considered in the past, agreeing on energetic but realistic plans, and gaining recognition from them and from upper management as being a seed element for an agile, motivated and productive new engineering culture.

As I say, it’s a fantasy, and it will be tempered by good old every day problems and challenges, from IT glitches and limitations, all the way to the inevitable odd, suspicious, cautious, sceptical and otherwise challenging characters from around the organisation - politics! - which, if treated with respect and their views taken into account, can all lead to much better solutions - for this company - than anything that I could have come up with alone.

This is what gives me hope: the knowledge that I do tend to be able to work well with all sorts of people, that I can call upon sufficient experience and awareness to feel but not be overwhelmed by, say, exasperation at a stickler for rules and regulations, or a negative mindset. I’m also looking forward to getting to understand the company, the market - there is life outside automotive! - the technologies and their niggles and problems that I’m sure I’ll end up getting involved in, no matter my original role.

It’s exciting to look ahead, but also to look ahead to again reflecting back on my career so far and this peculiar phase of gardening leave and - for one month only, at least - official unemployment that will very soon be behind me. Where did the time go? What did I do with it? All those questions can be happily set to one side for now, for reflection at a later date, on a well-earned weekend or vacation…

Now that I’ve completed my first full week back at work, I can confirm the suspicion I raised in my New Year’s post marking my return to blogging that the freedom and energy to write and blog that I discovered over the Christmas vacation have been severely reduced:

Alongside the where … it’s pertinent to ask, when would I write? Maybe blogging is principally something for the holidays, when I’m rested and have time to reflect and to write.

The brain drain

Audio strain

Slow overthinking, slow overdoing

• the pleasure of concentration
• the harmony of communication
• the gratification of good work achieved

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What will he think?

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

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

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

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

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

I got invited to some interviews.

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

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

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

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

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

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

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

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

Me (internally): Yes! Easy score here

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

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

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

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

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

• I need evidence of health insurance (which the company should provide on Monday morning - I don't know what time).
• I need an invitation letter (received) and a letter of urgency (not yet), plus a travel itinerary from my colleagues in China - again, hopefully that'll be waiting for me when I wake up on Monday.
• I need my "Anmeldungbescheinigung", Registration certificates, which I couldn't find over the weekend, so I'll need to get one of those on Monday morning, too. I hope my local friendly bureaucrats don't put up too many barriers...

I returned to work yesterday after two months off on paternity leave following Emily’s birth in July. Those two months of wearing shorts, not trousers, T-shirts not shirts were (Emily’s virus aside) wonderful.

Towards the end of my leave, I started thinking about and investigating the world of work again - discovering interesting buzzwords like “social enterprise” and “curation” brought up concepts that I was keen to try to implement in our office. I also checked my work emails to make sure that I wasn’t going to be overwhelmed when I got back.

Whilst checking up on my work emails from home, I noticed a slight reaction of repulsion as soon as I saw a drawing of one of our tube products - this continued when I returned to being “live” at work, too. It’s not the greatest sign for motivation, although the holiday blues are bound to be at work. I fear my lofty ideas will not survive being dragged down to the product level, into the muck and brass of a metal-forming automotive supplier’s life; yet it is at this product level that these lofty concepts need to work, and work seamlessly. Without the product, concepts remain simply that; nebulous ideas.

So - my challenge is to compartmentalise the day-to-day grit (quality complaints, validation testing, drawings updates) into chunks of “done” and to leave myself time, room and mental energy to devote to improving the way that we work. Whilst also giving myself some time to get back home to enjoy my family life.

It is a battle - improving our communication, knowledge distribution and search capabilities can improve work itself - but I do feel that ‘loving’ the product would make it one battle more easily fought.