Career Sponsorship – Notes from WomeninTech Event

Meri Career, Leadership, WomeninTech

A couple of weeks back I attended the final Women in Technology event (founder & MD Maggie Berry has decided to move on to an exciting new challenge; it continues as a LinkedIn group so keep an eye on that for future events).

The event was interesting, but I found a lot of the quite corporate and masculine language off-putting. That reaction was evident in some of the other attendees too; it doesn’t (generally) sit well with women to be given advice that they hear as “use others to get ahead”. Now, I don’t REALLY think that’s what the speakers were trying to get across, but sometimes style can injure substance in unintended ways.

The Q&A at the end was excellent, the panel including Aimie Chapple (MD Accenture UKI) and Jacky Wright (VP at Microsoft) who along with the speakers had amusingly diverse answers to the questions posed by the audience.

Most Interesting Insights

  • Having a career sponsor corresponds with career & trajectory satisfaction
  • Currently, men in senior leadership are 50% more likely to have a sponsor than women at the same level
  • Sponsors pick you: work hard, don’t limit who you talk to and don’t reject it when someone helps or advocates for you (See also Performance, Image & Exposure*)
  • A sponsor isn’t the same as a mentor, role model, boss — they’re someone who can be of help to your career in a specific way (opportunities, advocacy, championing, defending)
  • Ideally you want a portfolio of sponsors — not everybody does which is why you sometimes see a senior leader leave a place and a bunch of folks follow like trailing ducklings…
  • All the women on the panel had at some point not even realised that someone was sponsoring them!
  • Sometimes if you don’t tell your own story, others will jump in — but they may tell it in a way you’re not comfortable with

The single most useful thing I heard? A sponsor probably won’t be a role model. This is where most women struggle, IMHO. We assume our sponsors will be women and more specifically women we will look up to. Once you accept that you can be sponsored by anyone who thinks you’re talented, then the probability of it happening increases significantly. And realistically, while there are still so few women in senior leadership positions, finding a female role model who can also sponsor you is fairly unlikely!

I have also posted my full notes of the career sponsorship event if you’re interested in the blow-by-blow.

* Which can basically be summarised as: people are going to have opinions about you and expecting everyone else to come look at the detail of your actual work before forming an opinion ignores the reality of human nature … and is a kinda arrogant, no? 😉

Agile Projects: The People Side

Published Updated Meri Leadership, Management, Project Management

This was first published on the Cabinet Office website.

We talk a lot about agile here at GDS. We use agile methodologies to focus on our users. The faster we can build a functioning product, the sooner we can get it in front of real users and start iterating based on their feedback.

This has a number of implications for how we organise our projects and manage our people, and I wanted to explain how that affects they way we work.

Multi-disciplinary teams

In practice, we group our people into small, multi-disciplinary product teams. These teams will work closely throughout the day, often meeting first thing for a stand-up, a very quick recap of previous day’s work and a round up of what they have planned. If an area grows too large we break it out into smaller teams again — no one wants to be in a stand-up of 30+ people!

A typical product team will have a product manager (defining the vision for the product and how it will meet user needs), a delivery manager (agile project manager with a focus on making things happen), a technical architect and then a mix of developers, designers, web ops and content designers. We also have folks focused on understanding our users, including customer insight, user research and product analytics.

Transition team stand up

Matching people and projects

We have chosen to organise all of our “makers” into a flexible pool called the Delivery Team which currently has over 70 people. As requests for skills come into this team, we look at what is needed and then match to someone with the right skills and interest in that area.

We want everyone to have challenging, rewarding work, using their current skills well and stretching them to develop further in their chosen specialism (or in a new area if they desire).

Since we may well move people from one team to another based on the needs of the project, we deliberately keep line management separate from project assignment. Some worried that this would be confusing but in practice it has worked well. Each individual can turn to their delivery manager for project specifics and has their line manager as sounding board and for career, personal development and similar topics.

Harmonising not standardising

Over the past few months we’ve also tried to do things in a similar way across products where it makes sense. For instance, having the same sprint timings makes it easier to move people from product to product; encouraging all our delivery managers to use terminology in a consistent way has also helped us to communicate better.

Don’t do it all by yourself (you can’t)

At the moment we have a number of product teams all running in parallel to build GOV.UK as well as a number of other projects.

In order to meet all the short term demand, we have added to our core staffing with a number of contractors from a range of small and medium sized businesses. They’re working on projects with very specific time-limits, and they’ve help make make sure our core staff have the flexibility & agility to respond to changing needs. They’ve also brought us some external perspectives and practices, which have been helping us to meet user needs in the best way possible.

5 Lessons from the ZX Spectrum

Meri Presentations
5 Lessons from the ZX Spectrum

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!

Joining the Revolution

Meri Career, Personal Development

I’m delighted to share that I’ll imminently be joining the Government Digital Service as the manager for their most excellent Delivery Team. I’m hugely excited about working with this astonishingly talented group of people, some of whom I already know and others I am keen to meet, as they work on transforming the UK government’s digital presence & offerings. After Martha Lane Fox called for “revolution not evolution” in government’s digital services, this new department has been growing quickly and delivering in spades, with an approach more akin to a start-up than the traditional image of government IT.

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!

Avoiding the Watermelon Phenomenon

Meri Management

“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?

Going from Inbox 4000 to Inbox Zero

Published Updated Meri Productivity

Through a combination of holiday and time off to let my repeatedly dislocating shoulder heal, I was out most of October. So when November 1 dawned I had over 4000 emails in my inbox. Yes, you read that right, 4000. And my work inbox isn’t like my personal — there’s almost no spam, no newsletters. So virtually every one of those 4000+ emails was really for me.

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

Man with his head in his hands, behind a laptop, with stacks of paper on either side of him. Clearly overwhelmed by volume of work!

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.

Tropical beach, blue sky & sea, with palm tree

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.

Young IT Professional of the Year 2010

Published Updated Meri Career

I was delighted to be named Young IT Professional of the Year yesterday in the UK IT Industry Awards. Hosted by BCS (The Chartered Institute for IT) and Computing, the awards “provide a platform for the entire profession to celebrate best practice, innovation and excellence”.

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.

Important vs Urgent

Meri Personal Development, Productivity

In any job, it’s easy to get caught up in urgent day-to-day matters — “fire fighting” as many describe it. One of the most useful tools I’ve found for breaking the cycle of always working on what is most urgent rather than most important is this prioritization grid.

Grid used for prioritization of tasks & deliverables, plotting by importance and urgency
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!