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.


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.

Also published on Medium.

One Reply to “Weeknotes 06×04: Get things done, or get things delegated?”

  1. Pingback: Workweek

Comments are closed.