The management of TIME ITSELF

There can be few greater misnomers than the title of the course I attended for two days last week: Time Management. Who thought that one up? Not students of metaphysics, anyway. The management of time? We can philosophise it, theorise it, chop it up into humanly sensible bits, run our lives to it; but we certainly can’t manage it.

Still, what’s in a name? It’s a pithy title (better than “Trying to make the best of our remaining hours on earth, at work and at home”) and at least sells courses to HR departments, so let’s go with it.

Manager-like, let’s also get straight to the core question: why was I there and what did I learn? (Management questions are always double-barrelled).

I was there because during a personal development chat with my manager and director, I raised the point that I was struggling to maintain my deadlines; overall we were happy that the quality and quantity of my output were acceptable – my work, however, was (is) often last minute or late. It was generally accepted that this was the result of the sheer number of inputs and outputs I’m supposed to manage with minimal support. A sensible remedy would of course be giving me a colleague or two; but since adding resource to our group is off the table for the next couple of years, my director suggested some training. My manager and I exchanged a subtle rolling of the eyes, but agreed it couldn’t do much harm.

And so to the second barrel: what did I learn?

I don’t know how to answer that question.

So I’ll break it down. There are two ways of looking at it, the tools and the settings. Let’s start with the easier of the two:

Tools

Engineers love tools, so here are a couple that were mentioned.

A certain Mr. Eisenhower is credited as saying “What is important is seldom urgent and what is urgent is seldom important.” This was used (by Steven Covey in his 7 Habits of Highly Effective People) as the basis of a matrix that can be used to help sift through all the tasks you have facing you in this sort of way (my version below):

We should strive to be in the green zone, working on non-urgent and important projects. {Sigh}. I’m going to try implementing the matrix at work by setting aside a couple of hours and sorting my upcoming tasks as best I can.

As an aside, I would be tempted to try and add a third dimension to the matrix: Interesting / Not Interesting. There are tasks, such as validation testing, that are important (otherwise you don’t get regulatory approval to ship parts), can either be urgent or not urgent, depending on how the project is going, but which can be terminally dull – validation tests don’t tend to tell you anything in the slightest bit interesting about the product: these are the sort of tasks that grind me down to dust.

Another tool that we were shown was called “SAULUS”: It’s a German acronym which in English would end up something like SECSIV

Situation (Analyse the situation, i.e. what’s preventing you from working optimally)
Effects (Describe the Effects of this distraction)
Causes (Assess the causes of the situation)
Solutions (Brainstorm solutions with somebody else – a mentor would be best, though a colleague might do)
Implementation (Do it!)
Verify (Check)

Sound familiar? Yes, it’s basically an FMEA for a human issue. Our Quality colleagues would use an Ishikawa fishbone diagram.

The example I used was “too much surfing the web at work”, leading to ineffectiveness. One of the key causes I identified was the noise level in my offices: not just in decibels but in audible discussions that don’t concern or interest me at the time. I suffer from an inability to shut out extraneous noise (I’m the type of person who can’t help listening to another conversation even if I’m on the phone to somebody else. Sorry about that….) A solution would be to find a quiet room (an empty meeting room does the trick) and the implementation is to book it via Outlook. As for the verification – well, I’ve been doing it since the start of the year and I find it to be very effective and at least I know that I can focus on things given the right conditions. Now, if only I could get my own office to go with my new non-existent colleagues…

Adding colleagues fails the R in “SMART” test, that actions be

Specific
Measureable
Attainable
Realistic
Timely

Delegation was also mentioned. It’s a tool that can be learned, especially if you’re not a manager and even if you don’t have colleagues that do directly the same job as you do. Whether it’s an email query that needs answering or a project in itself, delegation ensures that work is done without overloading you.

Yes, I noticed a big flaw with that delegation argument, too. It’s a double-edged sword, try not to get hit by people delegating back to you, and all that. Let’s move on.

Saying No. The ability to say no in a professional, constructive way is a tricky skill to learn, but it’s vital to stay on track with your own targets. It’s something I’m terrible at, but I’m going to practice, with Eisenhower’s Important / Urgent Matrix as a template.

Settings

Engineers are humans, too

What do I mean by settings? In this case, I’m talking about how we are as people. During the two days we filled out a couple of personal analytical questionnaires (rate things 1-5 then score according to categories). These highlighted two things: firstly that I’m driven by a desire to please, which makes it most difficult to say no (I’m also driven by speed and data, so I tend to “pulse” my work but get it right). Secondly, that I need to work on prioritisation (Eisenhower), target setting/following and coping with distractions.

A chunk of the “settings” theme was related to stress and looking after ourselves. This would be a course in itself, but the general gist is: eat well, avoid burnout, avoid alienating your family and friends, stay healthy.

Don’t look back in anger

So no, I didn’t actually learn anything that could be described as groundbreakingly new. However, having two days out of work to think about work was very valuable. For me, the biggest positive of the course were the attendees: there were five of us in total, which was in itself a nice, workable number, and we were diverse. Our crew was an architect, a production manager, a museum director, a logistics manager and a development engineer; we got on very well indeed.

We came at the time management problem from different perspectives and arrived at different answers.

How about you? What are your experiences with Time Management? If you’re feeling bogged down with tasks, I hope this post at least gives you a direction to search in. If you’ve been through all of this before, let us know your thoughts and experiences in the comments below!