Weeknotes 06×04: Get things done, or get things delegated?

Wednesday. Writing my weeknotes both late and early, because I didn’t get round to writing anythig last week, and because I’m away the weekend coming up.

Main Wotsits from Last Week

I may be my own worst enemy when it comes to expecting change. I’ve pushed a couple of times to get people to think through some product design for upcoming features, rather than just launch into building something. This is generally good, and results in a meeting to bring thoughts together, hooray.

But sometimes – sometimes – I do think it would be just easier to ‘pretend’ to get on with it, and then raise all the same questions at the start of the work, and wait for them to get answered. Sometimes the “feeling of productivity” ushered in by a ticket being “In progress” is much more motivational than all the books and articles I’ve read and not really explained to anyone.

I think I’m on the right path though, by forcing discussion up front, and there have been a lot of benefits which go semi-unnoticed. But I should probably stop expecting other people to see things the way I do just because I’m managed to get them in the same room.

I think I got a bit annoyed at the start of the week as work for the product I’m responsible for seemed to get pushed back again. Things do get done on it, but I really feel like I have to fight for it, despite people apparently thinking it’s important to keep the product going. As above, I can’t decide whether it’s better to push for more time up front, or sneak in some time myself and get on with it. I’ll give it another month and see how it goes.

Otherwise it was snow time, except we didn’t have that much snow 🙁 We did have a power outage instead, which fairly fatally took down a server, which we then had to restore elsewhere to get some deliveries together. Ah well.

What I Learned This Week

Learning vs Delivery

I’m wondering about the dynamics of delegation, individual learning, and the inherent tension between letting people make mistakes, vs getting stuff done.

We’ve been working on a new feature the last few weeks, which has gone OK. However, I’ve stepped away from managing the process as I’ve done with previous work. It’s decently complicated, and there’s a bit of a deadline on it, but it’s not down to the day so there’s a bit of leeway. So it’s a good candidate to let someone else try out task management, tech spec, and people organisation – as a team, this is something we’re still improving on, and I’m keen to encourage others to dive in.

Which is great, but at some point – and as person responsible for delivering tech builds – I do need to work out my involvement. And so far, I’ve been fairly hands off. It’s only really this week, when we’re supposing to be releasing the work, where I’ve taken more of an interest, and started being more directive on the work. Yes, you could read that as “slightly taking over” – and I’m aware it’s like that, but I don’t want it to be too much of that, if you know what I mean.

So… a part of me thinks it’s gone well, and the team have gained in experience, and all’s fine. But a part of me feels like I could have done it differently, and better. What would I have aimed to have done differently over the last few weeks?

  1. Somehow be more open with people from the start about levels of support? As with a lot of things, perhaps expectations is the biggy. Sometimes it’s good to throw people in at the deep end, but not usually. Sometimes it’s good to hold people’s hand as they go through a process for the first time, but not usually. Getting the expectations around support and review are pretty vital, I think. Being up front about what skills a person should expect to focus on may help, and perhaps setting some timelines and mini-review meetings – like more focused 1-1s – would be a good idea. Safety nets, not stabilisers.

  2. Be clearer to other people that this is “experimental” work – that things may not go as smoothly as other work, but that there are other aims here.

  3. Decide who is taking on the responsibility, and follow-up with them afterwards – and it’s not too late for me to do this. Currently we have retros and 1-1s as feedback loops, but I can see the value of a mini-retro with the right people to go back and look at the process.

Keep Calm and Carry On

This week has seen a few people jumping into a large bid, which is of high importance. However, I’ve deliberately opted to stay out of the crowd on this, despite it’s importance. Partly, because too many cooks spoil the broth, and I’d just be one more person for others to organise. And partly (mostly) because I think it’s helpful to have someone concentrate on anythng else that needs doing. So I’m resisting all temptation to stick my oars in, and just getting on with other stuff.

All part of my “stop doing more shit” push.

What happened ths week?

Monday: Monthly management meeting, introduced a few points that need discussing, and lined up some meetings for the weeks ahead. Code reviews. Admin to renew some Google stuff.

Tuesday: Half day. Checked in on how development is going, which led to the “Learning vs Delivery” thoughts above. Carried on tidying up some IT and Sysadmin tasks in Jira, which is something I seem to have fallen into tidying up, but it feels good. I’ve started running off a few different dashboards in Jira – the main purpose of these is not to oversee work, but to act as conversation aids when I meet different people, I’ve decided.

Wednesday: More code, then Kim’s Annual Review, followed by a transatlantic chat to catch up on next steps with our US client to deliver data. The US work has started to really come together now, and it’s been great working with Obi and Emma, who I otherwise don’t do too much with.

Thursday: Keeping tabs on the ongoing development work, which is at that dangerous endgame point. Off on Friday, so main aim was to get some clarity about what’s left, so that other people know what’s going on. I’ll find out on Monday if that worked, or not.

But in future, I think I might try an on/off approach to work planning. I think I should probably get a 50-50 balance to getting things done, vs supporting others and letting them learn.

Friday: Had the day off. Went to Eastbourne and saw some chickens.

Misc

Reading: (Lucifer, by Mike Carey)[https://www.amazon.co.uk/Lucifer-Book-One-Mike-Carey/dp/1401240267?SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duc08-21&linkCode=xm2&camp=2025&creative=165953&creativeASIN=1401240267], and re-reading Foucault’s (Fearless Speech)[https://www.goodreads.com/book/show/257781.Fearless_Speech] which I should blog about separately, as it relates a lot to both 1-1s and Weeknotes.

Weeknotes 06×03: Empathy is also Hard, and Working Out what to do with the Past

Overall feeling: Like I can’t quite remember, like it was all a bit of a dream.

Spoiler: Friday contains the good thoughts, on agility and the past and the future. Also, no gifs this week. If you make it through, thanks for reading 🙂

What happened this week?

Thinking back, this was a really fast week. At times I felt focused. Other times I felt like I was drifting. Periods of productivity flitted around, but sometimes it was planned, and sometimes it was more reactive.

I started out at the weekend, really – I knew I had too many things on, so sat down to work out what the minimum next step I could do on each was, to keep things moving. Then I prioritised these steps, and then I put them into my weekly Trello board (one column for each day) in a schedule I thought was plausible. Oh yes, I’m all about the micro-strategy right now. It certainly felt like a weight had lifted from my mind, anyway.

On the whole, my week was a lot more development-heavy than I was expecting. This was probably predictable, in hindsight – fellow dev Luke was away the last three days, and fellow dev Alex was away the first three, visiting WWI graves in the Somme. Which I’ll come back to, for narrative reasons. Alongside staff absences, we have a couple of technical pushes on at the moment, both of which I’m not directly involved in, but am supporting on as a Technical Manager [TM].

And, alongside that, the move to our new server has had a few foreseen and unforeseen knock-on effects, and so I’ve been picking those up, as everyone else is pushing on with the real work.

So I haven’t got done all of what I’d hoped to do, but it was kind of fun to get my hands dirty again, and be able to do some real world work that fed straight back to end users within the hour.

A Post Script

Two weeks ago, I wrote that there are only two hard things about management. This is obviously a lie. Empathy is hard too. Or, no, empathy is easy if you’re listening, but to listen, you have to shut up – both the tongue and the mind. Shutting up is the third hard thing about being a manager, but probably the hardest thing. Harder than prioritisation and time management.

As a manager, there’s a force and a pressure on you, to be someone. You feel a responsibility to Make Things Happen, which in turn, makes you want to Say Things.

I’ve found there’s only really a need to Say Things where I think my experience tells me that it wouldn’t otherwise be said – in the right time frame, or the current context. Sometimes things are urgent, and there’s no time to let people work out a solution if you have one. Sometimes you have to say things you’d only say if you were drunk, because honesty isn’t really a British thing, but is essential for combating rumours and gossip.

But otherwise, people benefit from silence from a manager. So long as they know they’re trusted to do the work, and trusted to ask for help when they need it, people are generally much happier figuring things out for themselves, making a few mistakes, and taking the long, learning route.

Monday

One of my big focuses was to get some closure and open up the next strand of work for our clients in the US. We’re at a bit of risk of a never-ending (“iterative”) project, so I’ve keeping an eye on it and checking in with Emma and Obi, who are doing the work, with a view to make sure it gets managed OK, and the client is “liaisoned” properly, if that doesn’t sound rude. I went back to our original quote from a year ago, and suggested some new financial arrangements following a delivery this week. Felt a bit squeamish about it – I’m not a great one for negotiations, but I also know I’m just being a bit silly about it. I don’t like conflict, but so long as you’re rational and acting in the other party’s best interests, people are generally fine about these things, aren’t they?

Also had a quick technical chat with one of our UK-based Local Authority clients, who are looking to integrate our site with their intranet. It’s great to chat to people who know what they want, and what path is ahead of them. There’s a User Group coming up next month, and I’m still feeling bad about missing it – I do like listening to users…

(On the downside, why is there never a simple way to connect with Skype any more? Still, only took about 10 minutes to get the conference meeting setup, which is better than other calls generally. Does anyone keep metrics on time wasted negotiating group chat tech?)

Tuesday

Had a really good catchup with the rest of the Management Team, with some important developments which I can’t really share here. But managed to piggyback off the meeting to go through a couple of things I wanted to resolve this week – to get agreement on pricing structures, and to get agreement on the year’s product roadmap for Hive Pixie.

I think one of the most important ‘internal processes’ I go through is to get ‘buy-in’ – I’ve noticed that I do this a fair bit around decision-making: I like to check that people are happy with a decision I’m making. On the one hand, this could be seen as a lack of confidence – sometimes it is, but I do try to be honest about this, and will frame the discussion more as a ‘sanity check’ or a review, than a ‘sign-off’ one. But other times it’s about lines of responsibility, and – more importantly, perhaps – shared direction. If people aren’t happy with what I’m doing, then I’ll be left doing it myself, and it’ll be a right old struggle to get others to help out later on. Well, more of a struggle, in some cases 😉

I once described what I do around decisions as a bit of a sham – all I do is collect the info, structure it, turn it into a rational, defensible process, and play it back to people to see if they agree. I don’t really make any decisions at all, just discover them.

Wednesday

This was the day that Luke and Alex were both out. We also had Kim and Emma working from home, so the office was pretty quiet. I spent some time on dev stuff – signing off our site migration task (prematurely, as it turned out), making some small code tweaks, and trying out our new Virtual Machine setup, which sadly broke my development environment. Oops. Still, it’s great to be able to get to this point – I set up the initial environment months back, and over the last 4 or 5 weeks, it’s started to take on life within the wider team, so I’m kind of closing the circle. Proud of the way this bit of work has developed, and will certainly try to remember it in future.

Also had a 1-1 with fellow dev Hon Mond, which I deliberately also used to explore the capability framework / career path guidance I’m putting together slowly. Developing this in conjunction with others, instead of doing it myself, was a decision I’d made at the weekend, and was influenced by chatting to fellow Weeknoter Julie Byrne and hearing briefly about her (much more organised, I suspect) workshop approach.

Getting help from others is something I’m really trying to improve at. A bit of me still feels like I’m ‘cheating’, if not failing, but the results are always clearer and more participative all round. So far.

Thursday

Here was whee the #user-support channel started to become my home. I’d already been trying to work out some permalink stuff for the Local Authority client I’d chatted to on Monday, having promised to send something over. We then discovered a few things that had been missed in translation when the site migration happened – a parallel deploy had been partially rolled out, and while there was no broken functionality, the speed improvements we spent a few weeks putting in place had effectively been rolled back. TBH, the risk was raised at the time of deployment, but wasn’t bad enough to warrant worrying about. Fix it easily, move on.

That sort of set the tone of the next day and a half though, so instead of getting on with the work on Ethical Impact I’d hoped to do, I was fairly mired in git, my IDE, databases, and Jira issues.

I think I got to midday on Thursday when I realised that the end-of-week stuff I’d hoped to look at just wasn’t going to get done. I checked there was nothing that couldn’t wait, and shoved everything back in Trello.

Spent the afternoon catching up with fellow devs John and Hon Mond on the major bit of work they’re doing. I’ve stepped back from this a bit, but wanted to check in and see how things were going. There was less clarity than I’d hoped for, so I ended up making some strong suggestions to have conversations – or if they’d been had, to write down the decisions. I hope I don’t come across as too controlly-controlly when I do that – I hope it’s the right choice, and I suspect it’s only done from experience of seeing tasks going awry when people are confident that things are fine.

I like knowing answers up front.

Ended the day with another user support issue, going back to some code I wrote 5 years ago. But ran out of time.

Friday, Five Years Ago

The second half-day of the week, after Tuesday, and I think I’m getting the hang of these half-days. The first time, two weeks ago, I struggled to stop thinking when I left work, and ended up writing up notes in the afternoon. Now I’m more stringent about it, and treat my afternoon off just like I treat my day off – effectively, no comms, and a deliberate intention/effort to Do Something Else. Meditating for 15 or so years really helps make that shift, actually. It’s one of the reasons I think I’m OK at jumping between lots of contexts over the course of a day (which doesn’t make it right or effective or any less tiring).

At the start of the day, Alex – returned from the WWI battlefields in France – was telling us how the crops growing over the old trenches, filled with new layers of earth, grew differently to the surrounding crops due to this difference in layers. Here’s an aerial photo:

Trenches from the air

These lines, their shapes dug a hundred years ago, now shaded in multiple greens, feel like nature locking human history into her own output. The politics of war, now embedded in the hue of vegetation.

I spent the morning mostly looking at the issue that I started looking at yesterday, which meant going back to some very dodgy SQL I wrote 5 years ago. On the way home, I sat on the train and thought about the past, as the cold fields of Sussex floated past. Decisions we make now are enshrined and built on. We build layers on layers – our processes and our politics and our efforts are all just ways of building new layers.

Someone (who I should get in touch with again) told me last year that the difficult thing about running a product isn’t scaling it up, but keeping it going. Another tech leader talked about how versioning meant you were always dealing with parallel histories, in one go. Age is the antithesis of agility. The layers are inevitable.

The lines of the code I was staring at took me back, to before I knew most of the people in the office. Just as the lines in the crops take people back to a story they’ve only seen in black and white photographs. Trenches dug with metal. Processes growing all around us.

I had this feeling that I was dragging something – but not the code itself, not skills. Nothing other than the past, really. As if those 5 years in between – where #son2 was born and the company grew and relatives passed away and we moved house and local authority with it – as if they’d never really happened.

On the train, I think I made a decision not to be a captive of that weight of the past. If I truly believe in agility, and all the catches from the world of ‘agile’ that hook into my philosophy of lightweight nomadicism, then I’ll address it. Somehow. In time. Not immediately, but eventually.

Reading

  • Finished reading M Train by Patti Smith. Gave it 5 stars on Goodreads, and probably the reason I’m wittering on lyrically above. A great nomadic book about memories and attachment and coffee.

  • Started reading Famous for 15 People by my friend James – short stories, ranging from the amusing to the macabre. I’ve read a few before, but love reading them again. Some of the ones I haven’t read before have been creeping into nightmares.

  • Also started volume 7 of the Unwritten, a graphic novel series I’ve been following for a few years now. Excellent series about the power of narrative.

Weeknotes 06×02: Love will tear us apart. And by LOVE i mean UNSTRUCTURED ATTEMPTS AT PRIORITISATION.

Structure versus creativity and a quest for micro-strategy

Last week I wrote about priorities and scheduling being the hard things in management. Steph replied, sympathising and noting that planning and headspace are useful:

stricter management of my work-in-progress list, WFH more and starting to use OKRs to prioritise important, measurable things seem to be helping. I reckon a lot is about state of mind: what can only you do?

This led me to think about the relationship between the “structure” that prioritisation and scheduling seem to somehow inherently imply, and the act of management as a creative process:

another (meta) thing I struggle with is striking a balance between structured mode and “creative” mode. Do you find you get bogged down in being strictly structured?

There is a definite yin-yang, back-and-forth here between setting restrictions (“the hardest part of setting a strategy is deciding what not to do.”) and boundaries (time, people, etc.), versus letting thoughts flow – which, in reality, means being empathic and using what you’ve observed to solve problems, or to set a path to solve those problems.

At OCSI, there are certain structures we’ve “solved”, and certain ones we haven’t and which still fall into ad-hoc processes. Our sprints are pretty smooth now (and I’m always happy to talk about this to people if they’re interested in how we do it), but our prioritisation between products still needs a lot of work.

Similarly, as my own work jumps between so many different strands, and I’ve never been able to come up with that micro strategisation – all the past year, with mini post-its, and Trello boards, and notebooks, and to=do lists – these are all just mini strategies, disposable like spring breezes, but capable of establishing entire shipping routes.

Having come to this realisation, I think it’s doable. I think I can draw on the other prioritisation frameworks I’ve used to get some kind of micro-process in place – something small that can deal with whatever life throws up but that, most importantly, lets me be creative within its bounds. Something that keeps me in check in order to set me free.

Freedom is slavery

The many worlds I’m involved in really hit home last week – although oddly not for the usual reasons. Generally, it’s easy to get stressed when there are lots of plates spinning and all are shouting to be looked after.

Plate face

However, last week was this weird mix of NOTHING URGENT plus HALF TERM. I had plenty to be getting on with, but no real sense of direction, and aware of normal homelife routine being thrown as well. On top of that , it was my second week of working 2 half days, instead of having 1 whole day off, and my brain kept telling me that THIS IS NOT THE DAY YOU THOUGHT IT WAS.

So by Wednesday (oh yeah, and hours of pancake cooking on Tuesday)

cat, pancakes,bwaaaaahahahaa

…by Wednesday I was pretty scattered, drifting a bit. Some lunch plans didn’t come through, and I hadn’t really worked out my week. I wouldn’t say I was a mess, but I felt very … unstructured. Which had a bit of a knock-on effect, I think. Not guilt, per se, but some sort of weird dissatisafction that must, MUST come from learning how to be “productive” over the last few years. All this GTD shit – it’s not healthy I tell you. Feels weird to relax.

So this week (whoa, spoiler!)

this post is as dark as the night on the far side of the moon

…this week, I’ve made sure I’ve done two things:

  1. work out the smallest possible amount of work each plate needs to move it forwards
  2. assigned a day to each micro action

Hey look, more micro stuff! I should turn this into a theme or something.

Mmmmmmicro Machines, GET OUT OF MY BODY

Oh right yeah weeknotes nearly forgot sorry

So despite all the moaning, I actually got some good stuff done. Liiiiiike:

  • Cemented the roadmap for Hive Pixie in place, by writing it out in lots of bullet points, and turning it into proper Epics and Stories in Jira. Chatted to Emma (senior researcher) about updating reports, and I may have to dig out some code I wrote ABOUT 8 YEARS AGO. That’s from before #son1 was born.
  • Had a nice 1-1 catchup with Kim (marketing lead)
  • Had a nice 1-1 catchup with Gregor (sysadmin), which was also good because we now have a regularly-scheduled meeting in the calendar, which can be difficult when people are part time but this feels like a goo result coming out of a recent Annual Review. Calendars are amazin.
  • Caught up with Kim and Joel (user support) following on from conversations with some users about some upcoming mapping features – this was good because we don’t do a lot of ‘formal’ user conversations up front, and so we didn’t learn a huge amount of new stuff, but it fees like it’s been really good practice to generate questions, get in touch with people, and then bring the results together. I do like this kind of process practice.

Yassss, process

  • Sprint, despite wearing at least 3 different Product Owner hats
  • Being in a fruitful developer-based retro for our use of VMs, which are coming along nicely
  • Ohhhhhh, probably other stuff too, you know how it is weeknoters. I dunno. I could be making all this up, or it could all have been some whaced-out dream for all I know.

Anyway, next week I’m going to write about empathy and cognitive load, if I remember. STAY TUNED.

Other stuff what I’ve wrote recently

Also been

  • Reading M Train by Patti Smith, and therefore also getting into the Patti Smith back catalogue.

Are Data Skills Equally Distributed? Building a Society with Data at its Heart

I wanted to pitch a session at #ukgovcamp18 recently. Previously I’ve chatted a bit about the usability and accessibility of data – that is, how can we make government data more user-friendly, and open it up to the more people? This year’s session carried on this theme, but was more focused on the skills we need to collect, process, and understand data – not just consume it.   At OCSI, we collect a wide range of data about inequality, but nothing about the skills we actually employ ourselves. Isn’t it time we stepped outside of our ivory tower?

Somehow I managed not to fluff my pitch, and proposed a chat entitled ‘Are Data Skills Distributed Equally?’ It got a few raised eyebrows during the intro, which I take as a sign that people are interested in the topic. And sure enough, the (post-lunch) session went really well – discussion was lively, diverse and productive – you can see the ‘official’ session notes here.

My original aim was to talk a little about how to measure and track data skills as a nation, because that’s the kind of thing we like to do at OCSI. But the conversation rapidly turned into a more fundamental one – What do we mean by “Data Skills”? What are the blockers to learning them? And how can we unblock these?

I came away from the session with three main observations:

1. ‘Data’ is about a broad mix of skills

Successful data projects rely on a potent mix of people, as well as skills – but this is still pretty murky. We can’t think of Data as something that geeks do – from identifying use cases to designing and testing stories, I’d say that there is something that anyone and everyone can bring to a data-related project.

To be fair, I don’t think there are many people who would say that ‘doing data’ boils down to a single skill. But too often, we simmer it down to a particular job, role, or technology, often depending on the audience we’re talking to. Remember that whole thing (wow, 9 years ago) about ‘Statistician’ being the sexy job in the next ten years? The rest of the original quote was actually more important: “statisticians are part of it, but it’s just a part.”

Similarly, fascination with trends and novelty means we’ll often hone in on the latest technical movements, such as ‘Big Data’, or even ‘common APIs’. Each, in its own circle, is great. But you can’t expect to follow a trend, get one skill or API in place, and sit back to see magic happen. Efforts need to be more expansive and coherent than that. And to do it *clearly*.

So we need to keep pushing for a better, more wholesome picture of what ’Data’ actually involves. Let’s broaden this out.

Wouldn’t it be great to…

  • Get a conversation going on what combination of skills is important when working with data
  • Start giving equal value to each of these skills
  • Identify where there are gaps in skills which could be filled to make things better?

2. ‘Data’ is dependent on a bunch of other stuff

This ‘network of skills’ is actually more complex than we would like to think. For many people ‘in the know’, it’s too easy to *assume* that data skills are easy. Someone in the session highlighted that there are severe obstacles to entry in the field, such as basic access to computing, or decent broadband, and if we don’t address *these* blockers, then we’re not going to get anywhere very quickly.

I’d also argue that there can be very real *cultural* blockers, which can prevent skills from being established and supported. It’s really important that we break down stigmas of who ‘should’ be able to do what – that we start establishing data skills as something to be proud of, no matter who does them. The public perception of the *value* of data needs re-examining – it needs to be seen as something that “we can do”, not something that “happens to us”. We need to get punk about data.

Again, this should be something we can start to elucidate, and make more transparent. If we can identify the fundamental obstacles, then we can go back and address them first, before expecting people to just jump in and get on with it.

Wouldn’t it be great to…:

  • Start highlighting the things which are blocking broader takeup of the skills above
  • Have conversations with people who are starting out with data and evidence, to see what their needs and pains are
  • Work with people to actually find ways to remove these blockages?

3. The network is everything

The data movement can no longer rely on well-meaning individuals and skilled, lone coders. Again, I think this is something we all kind of know, really. But it’s easy to be an isolated individual when it comes to making an effort – I’ll reluctantly put my hand up and admit I’m guilty of this, because busy and fragmented and all that. We work as a team at OCSI, but outside of that, it feels like I’m an individual, vaguely thinking I can build tools to empower the world, all by myself. It needs more than that.

By deliberately placing a focus on teamwork, and by tying this into a clearer vision of the skills-mix which really push data forwards, we start to shift the debate away from smart individuals, and more towards communities that need mentoring, and groups that need support above and beyond tech skills. We start to see the *connections* between these individuals as more important than the individuals themselves.

Wouldn’t it be great to…:

  • Encourage a more diverse approach to data skills networks, bringing together a wider range of backgrounds
  • Reach out to other groups which need similar support
  • Help groups to learn from other groups

Actions

I’ll admit I’m a little bit stuck here, which is one of the reasons this post has been delayed. I have some initial ideas, but maybe others are already doing this? Maybe I’m just reinventing a wheel that all the other open data groups out there are already inventing, and successfully?

Maybe the initial starting point is these two questions:

  1. What can *I* realistically do, and how can I use my position – where I’m already within a network of data professionals – to push data skills outside of their existing “comfort” networks?
  2. Who should I be talking to as part of that effort, and how? Is that a series of personal conversations, or is there scope for some larger, ongoing “group” to move this on?

More to come soon, but if you’re interested, please do get in touch! I have a list of people from ukgovcamp, and figure we can start to build the network to build the network…

Weeknotes 06×01: What are the two hard things in management?

Revamped opening credits. A dischordant mix of lacrimose strings and upbeat techno. The warning message about scenes of flashing lights jumps onto screen with a flicker of brightly pulsating whiteouts. It’s clear the scriptwriters have been replaced with something cheap at the last minute, but nobody is really sure if it’s by a real human or by a bot. Ratings plummet.

Episode 31. Series 6 is here. I’ll try not to jump the shark.

Last series ended at a busy time. January was the month to catch up on all the stuff that didn’t make it into December because December was so busy. Then UKGovCamp happened and my head was full of ideas which I’m still sitting on, but with good reason and intent.

The other day I was reminded of a quote from Phil Karlton: “There are only two hard things in Computer Science: cache invalidation and naming things.” I’m not going to launch into a computer science lecture here (phew!) but my own attention is simultaneously so scattered and so trying-to-get some structure that I wonder if There are only two hard things in Management: priorities and scheduling.

I started out last week by trying to grapple with having a lot of Bulky Plates spinning at the moment. Sadly these are all long term plates, which means I’ve probably taken too much stuff on over the last few years, foolishly. Looking back over the weeknotes, FOCUS and CLARITY have been the twins to haunt me. Last week wasn’t so different, but their triple sibling, PROGRESS, leaped out and demanded to have its photo taken as well.

I spent some time Monday morning working out all the strands I needed to make progress on. Then I blocked in time to look at the them. This was to be my new organisational regime (Spoiler: Haven’t done it this week yet. I need to make time to look ahead and make time…)

As it’s the start of a new series, here are my current big strands that are pulling me in different directions like a chlidren’s party at Legoland:

  • Team stuff: 1-1s and other people’s careers, which I love but needs some dedicated thought time
  • Tech stuff: Planning next steps and making sure it gets prioritised/done, which is great but needs some writing time and hand-holding
  • Product Ownership on Hive Pixie: Planning out a 9-month roadmap and turning it into something I can follow and communicate easily, which is a brilliant challenge but always more work than I expect and takes a lot of writing and re-writing and drawing strands together which is not very easy in Jira
  • Our own ethical impact: One of our year’s company strategies, which I didn’t originally put forwards or vote for, but it made sense for me to pick up and actually I quite enjoy it, but does seem to mean starting an entire framework from scratch like a mini research project or something, and needs lots of writing time so that I can understand it so that everyone else can understand it
  • GDPR: Which is a whole legal thing apparently

The common threads here are:

  1. I am organising priorities and setting aims, paths and plans for most of this work
  2. A lot of that organisation seems to involve writing up documents and turning things into lists
  3. (Mostly) everything is pretty fragmented with not-a-lot of overlap, and context-switching could potentially kill me

Hard Problem 1: Priorities

What do I/we do next? This is the question that keeps stabbing me in the brain. Everything is continuous, a lot of it is reactive, and even the most ardent of intent isn’t enough to convert the wishes of unicorns into a minimum viable spec.

I think a lot of my cycle looks like this:

  1. Work out what other people’s priorities are
  2. Suggest and discuss a common set of priorities
  3. Do this across multiple things, and so have to do #1 and #2, but for my own work
  4. Write everything up in a list style
  5. Work out all the priorities alongside each other, plus with everyone else’s priorities thrown in.

Basically I may have turned into a Priority Machine. This concerns me.

I would dearly, dearly love to automate this as much as possible – on a personal basis, and on an organisational basis. Please do get in touch with any thoughts on how to come up with a system that takes a few judgements and turns it into a good-enough todo list. I’ve seen the Eisenhower Matrix, which is great for getting rid of stuff that’s not important, but doesn’t help when you’re filling up the top two boxes with the great stuff.

I’ve tried spreadsheets for specific projects, which is great, but I need something much more lightweight for personal decisions. I need tips, suggestions, resources for better ways to pluck priorities out of the air and to shove things into more bullet point lists of their own doing.

Many people try to attack one person all at the same time, from the hit comedy kung fu movie, 'Kung Fu Hustle'. Probably.

YOU ARE BEING DEALT WITH IN PRIORITY ORDER

Hard Problem 2: Scheduling

So I started last week by blocking in some time in my calendar for the things that I wanted to “MAKE PROGRESS” on (this was my weekly aim, after being caught up in various large tech efforts over the last few months. I’m playing catchup.)

THIS ACTUALLY WORKED QUITE WELL. It meant I had everything laid out for me in advance. Not all of it worked – Thursday and Friday, I didn’t get round to the GDPR stuff because the earlier blocks have time had led to some things needing further work. But the lesson here is that the method works, but just not to that scale. I tried out having 3 focuses for a week some time back, and I still think that’s a good number.

Plus one of the feedback comments from my Annual review recently was that I’m often jumping between things, and it might be useful to be clearer about my availability.

So perhaps that’s something I can address this series. Know my limits. Plan out my own time more. Stick to it.

One of the difficulter things I find about that is balancing the work I’m doing alone, and making time for others. Both are important, but the sheer fact that there are more other people than me in the world means that there’s inherently less weighting for the alone stuff.

Coincidentally, I’ve also started a different working pattern this week – doing half-days on Tuesday and Friday, instead of taking all of Tuesday off. I’m planning to work from home every other Friday, so this may be a good time to book in the “working alone” stuff specifically.

In fact, a lot of what I do comes down to office rhythms – certain people are in on specific days, and certain meetings happen at regular intervals. Maybe I should embrace this more, and plan my efforts around it more consciously. Go with the flow. It’s what a sage would do. (Or quit work and live in a mountain. But we’ve only got the Downs to escape to round here.)

Kung fu on the mountain

The product roadmap is COMPLETE, I tell you

Hard Problem 3: Knowing when to stop

I’ve noticed this is something on my radar. A lot of planning can be quite creative, if you let it – knowing when to put the brush aside and say “enough is enough, this will be OK” is hard.

So I’ll stop there.

Scrolls crash from shelves from the hit kung fu movie 'Hero'. Like a boss.