I was delighted to speak (along with the passionate & entertaining Eleanor McHugh) at the recent joint Sci-Fi-London and London Girl Geek event, celebrating the anniversary of the ZX Spectrum.

The slides don’t make a whole lot of sense on their own, so here’s a summary of what I said:

I wasn’t lucky enough to have a ZX personally: my first computer was an x86 that I hacked and soldered together from a number of broken ones thrown out by my dad’s work. I often joke that the permeating scent of my childhood was solder and the soundtrack the sound of bloody Gideon falling off the path on the trek up the mountaintop to the wizard’s castle in King’s Quest III. But since I was growing up in South Africa (where everything arrived a few years late), there were certainly some highly prized Spectrums around, and some of us were very jealous of the folks who had BASIC as a third language.

I think the culture the Spectrum created shaped the experiences of a couple of geek generations. Something (relatively) affordable, that you could code your own programs on and share them (though a couple of folks in the audience highlighted that writing to tape in no way guaranteed your ZX would ever read it again…) really was revolutionary. And there is something special about first interactions with computing being about CREATING rather than just using or consuming. I’ve done a lot of training redesign in recent years and this need to move away from consumption to creation in order for adults to really learn has been a key theme.

The (again relative) openness of the ZX Spectrum was important too. Partly since there had been an “assemble it yourself” version, circuitboard diagrams were available, and though Sir Clive probably didn’t approve, the vast proliferation of personal “build from scratch” grey copies and manufactured (cheaper) copies, especially in places like the old Soviet Union, contributed to the number of people building things, and so the sheer scale of programs being written and shared. The fact that much could be shared in written form (computer magazines printed code!) speaks to a more innocent age … and the storage medium being a normal audio tape meant that code could be broadcast over the airwaves (this is the Channel 4 logo piece on lesson #4).

Removing barriers, both reducing cost and making it easier to create & share programs (especially games!) was key to the success of the Spectrum. I remember being taught Java at university and how for those of us who could already program, we were appalled at how many lines of Java it took to get a simple “Hello world”. For those who this was their first introduction to programming, no surprise that they were lost. Many left the course, or really struggled through the next few years. There is great power in something simple enough that a kid just a few years old can write and get something to run — it’s why I’m a fan of Python as a teaching language, since you can get something that DOES SOMETHING in just a few lines.

And so, I have great hopes for the Raspberry Pi. We need another generation of kids that play WITH computers as well as ON computers/Playstations/Xboxes. Some people have criticised the Pi coming as just a circuitboard, but I think this is part of the beauty of it. Understanding the hardware is important, and much as I love my iPhone (and iPad!), it kinda sucks that you can’t break them open and have a bit of a look round.

We build better stuff if we understand it from the circuits up, and we all learn more if we create rather than just consuming. So viva la Raspberry Pi!

It was not an easy decision to leave Procter & Gamble, where I have been an Information Decision Solutions manager for the last 10 years. It’s a brilliant company (recently named #1 for leadership development by Chief Executive magazine) that afforded me wonderful opportunities to develop as a professional and an individual, as well as granting many lasting friendships with colleagues I both like and respect.

I started at P&G whilst I was still at university and worked up through a variety of roles, from Systems Analyst to Product Manager, then Project & Programme Manager and more recently Engineering Manager type roles in various business domains. I also had the privilege to get involved in a number of organisational development activities, founding the company’s LGBT employee network in the UK which was recognised as a Star Performer Network Group by Stonewall in recent years, leading recruitment in the South West and redesigning our internal management “colleges” to be exciting experiences rather than “death by PowerPoint”.

For a long time I managed to maintain both my corporate and geek/web interests and activities in parallel, participating in BarCamps, Refreshes & SxSWi when I could and even writing a book on geek project management for SitePoint. In recent years my travel schedule at P&G has meant this became harder & harder and frankly I missed the digital side of things.

The prospect of being able to marry both worlds together in the same job really is geek manager heaven. I can’t wait to start!

“If you can not measure it, you can not improve it.” – Lord Kelvin

My recent experience using The Eatery got me thinking about how much having the right measures helps you track and influence performance. Data is awesome and measures are great — nothing focuses the mind more than a graphical representation of how broken something is.

Unfortunately mistakes are often made:

• Picking what CAN be measured, rather than what SHOULD be measured. For example, airlines are reputed to determine an “on time” departure based on whether the plane left the stand on time — not when it actually took off. As a customer who has spent a lot of time sitting on the runway, this is pretty annoying!
• Focusing exclusively on the measure, rather than what it tells you about performance. We’ve all seen a team get obsessed about getting a particular measure to “green” or “100%”, often not really thinking about what the impact will be of doing so. Sometimes it’s fine to have 87% — and the incremental work to get to 100% is time & effort better spent on something else.
• Losing track of the bigger picture. My personal peeve here is measuring whether everyone in the organisation has an annual review (because that’s something easy to measure) rather than whether they actually make a difference — the folks over at Sonar 6 have covered this in one of their colour papers on performance management very effectively.

All this can lead to what one of my colleagues refers to as the Watermelon Phenomenon — when something is green on the outside, but bright red on the inside. Effectively, your measures are telling you everything is fantastic, but your users/customers/employees are telling you it is B R O K E N.

So, what to do?

1. Think about what REALLY tells you whether your business/process/organisation is healthy. Is it sales? Is it customer service? Retention rates? Happiness? How on earth do you measure HAPPINESS? Don’t worry about that right now. Just think about what you think are your key indicators of success/health, in an ideal world.
2. Now, what could show you AFTER the fact how you are doing? These are called “outcome measures” or “blackbox measures” and are typically hard numbers — sales, profit, retention, etc. The disadvantage is they are often broad and reported after the fact — but they are still important.
3. Then, think about what your early warning measures might be. In people management, how many people you are attracting (recruitment) and keeping happy & engaged (retaining) are your outcome measures … but how do you tell BEFORE someone goes as far as leaving that you have a problem? Is it an employee health survey, the team’s feelings about their manager, how much your competitors are paying? Working this out and then finding a way to measure it without losing track of the end result, is probably the hardest challenge.

What’s the worst measure you’ve ever seen, in terms of the behaviour it drove?

So on November 1, I felt a bit like this:

Rather than resorting to a simple panic attack and a paper bag, I pulled out Getting Things Done and reminded myself that processing is powerful. Rather than viewing the “inbox of doom” (as it was becoming known ) as an insurmountable mountain of “stuff to do”, I started looking at it one by one.

For each item, I chose whether to action it (if not: file immediately in the right place, if so, put immediately in @action folder), put it in @maybe-someday, @read-later or @waiting-for (e.g. if a conversation/topic had moved along but the next action was with someone else). Surprisingly, this really didn’t take that long. Within a couple of days I had processed the insurmountable 4000+ down to ~500 I had to actually do something with!

Best of all, I was back at Inbox Zero. And I’ve gotten back down to zero every day since.

Having nothing in your inbox, even if you have 514 in your @action folder, is curiously calming. Knowing that you know exactly what needs to be done, that it is held in a safe place, that you no longer need to frantically make notes in sharpie on napkins at lunchtime because “OH SHIT I JUST REMEMBERED” is … serene.

I can highly recommend it

Further Reading

For anyone wanting an introduction to GTD, LifeDev’s GTD Cheatsheets are a nice clean resource; Gina Trapani’s Simplified GTD is fabulous too.

To be honest I am much prouder that my team at P&G, the Application Management group, were finalists for IT Department of the Year only a year into our existence as a team!

I didn’t get to attend the awards dinner as I was gallivanting around New Zealand on sabbatical, but my awesome team were there and accepted the award on my behalf. The judge’s comments were reported over a crackling mobile phone connection to the North Island of NZ as “An outstanding individual who has made major contributions within her company and to the wider IT community. The judges were blown away by her submission!”

Other coverage: UK IT Industry Awards 2010: and the winners are…, BCS announces winners of UK IT Industry Awards 2010. UPDATE: nice story from University of Bath Computer Science department.

Grid used for prioritization of tasks & deliverables, plotting by importance and urgency

The grid helps you divide your tasks & deliverables into four categories:

1. Urgent & Important (fire fighting) – these are the everyday priorities, things that have either come up urgently or important things that you didn’t get to until they became urgent.
2. Urgent & Not Important (distraction) — these are the easiest things to move on to once the fire fighting is done, but hardly the most productive. Everyone has their tasks that fall into this category. For me, it’s checking my email or voicemail rather than making a choice to work on something more important.
3. Not Urgent But Important (quality time — aka fire prevention) — the things that are important. Part of your strategic vision. The kind of things that mean you have left a positive mark on a place after working there. Shouldn’t you be investing more time here?
4. Not Urgent, Not Important (time wasting) — ever noticed the guy in your office who seems to spend time arranging his desk rather than doing any work? Or putting new colour labels on files that were already perfectly workable? My best friend avoided revision for our final exams in school by deciding he simply HAD to learn Linux right then in that fortnight when revising should have been top priority…

The point isn’t to never do tasks in certain categories, just to become much more conscious of the choices you’re making. I’ve been using this grid for years now and I can certainly not claim that I never do tasks that are not urgent & not important — but now I make a conscious decision about whether to take on the next big important thing, or whether to spend the 5 mins before lunch sorting through my expense reports.

Try it for a week and see if it makes a difference for you!

Go on over, check it out and let me know what you think!

Not only will you be helping us all understand the state of our industry, but you also get the chance to win some cool freebies for participating — more details here.

This is very much a double-edged reality — on the one hand I tend to focus better on my holiday or business travel, limiting email time to 15-30 mins per day. On the other hand I am now faced with over a 1000 emails still left cluttering up my inbox.

I usually deal with this via a mammoth processing session, using many of the tips already covered in the Inbox Zero series. If you’re not nodding along with me here, stop right now and go investigate Inbox Zero. It’s a brilliant attitude to owning your email rather than it owning you and how to get brutal to make that happen.

Since I have been in roles where I have travelled A LOT, I’ve gotten pretty good at these mammoth processing sessions. Here are some extra tips — essentially how to look at your email sideways in ways that make those 1000 shrink down to something much more manageable:

1. If your email client is also a calendar, sort by “message type” or “icon” and deal with any meeting invites, responses or cancellations first. These are the simplest type of message as all that is expected is that you accept, accept tentatively or reject.
2. Next, sort by sender. The same people will have emailed you multiple times and often you only need to actually deal with the most recently received. The rest can be filed or deleted en masse (as per your usual strategy).
3. As needed, group by conversation. Occasionally you’ll come across a long, complicated conversation thread. Again, you’ve been away so you can probably save time by skipping to the most recent instalment or two and ignoring the rest of the conversation. No one likes the bastard who returns from holiday and presents everyone with a point-by-point treatise on the entire email chain.

Pretty simple, but sometimes the simple things make the most difference. Next time you have a mass of inbox processing to do, try looking at your email sideways to shrink it.

* Please note: I have both RSI and Carpal Tunnel Syndrome so for me using a Blackberry (and most other computer equipment) really is painful. This was not a slur on Blackberry interfaces in general

The book was expert reviewed by Kevin Lawver and Drew McLellan who both did an admirable job of ensuring that the content stayed applicable to all sorts of projects and teams, both big and small. They also bravely took on the role of managementese-weeding and survived with remarkably few lasting scars Drew has written some thoughts on the book on his own blog. I thoroughly enjoyed working with both Drew & Kevin, as well as the team at SitePoint.

If your interest is piqued, then check out The Principles of Project Management book page or download a sample chapter.

In the interests of full disclosure, I would highlight that all the links are affiliate links — i.e. if you buy the book via that link I will both be able to track it and get something back