Weeknotes 06×06: Should we assess our anticipation and dread?

So that was series 6, which started near the beginning of February. What just happened?

  • 06×01: The two hard things in management are priorities and scheduking.
  • 06×02: Micro-prioritisation is surely possible
  • 06×03: Empathy and legacy
  • 06×04: Delegation vs delivery
  • 06×05: Unorthodox procedures

How was it?

I’ve got a short, 3-day week coming up, and I’m off after Easter, so that’s basically February and March for me.

Right now, I feel like I’ve been productive and pushed a lot on a lot of fronts – possibly too many. Some of that is my own fault and drive, some of it is because we always seem to be busy as a company, and some of it is entirely external factors (hello GDPR).

Looking back further, to a couple of series ago, I was exploring the idea of “craft”, and the notion that if you’re going to something, then you should absorb yourself in it, understand it, do it as wellas you can, and really develop it as a practice – as something you practice.

you knit

I haven’t written about that this series, but I do feel like I set something in motion back then. Like I’m able to define my role better now, and understand what I want to get from it, so that I can assess whether what I’m doing is pushing my boundaries, and hitting my targets.

In fact, this week I ended up going back to basics and listing my own current, personal core aims in a Google Sheet when things started getting a bit too much. I described this to the wife as putting clothes away. It’s great having lots of clothes to wear, in the same way that it’s (probably) nice to have lots of work to do. The core aims are the clothes drawers – I might still have the same amount of work to do, but by sorting it into aims, everything just “feels” tidier, and more manageable.

What happened this week, and what did I learn?

Monday: Most of the office were out at the annual User Group. Had a half day, where I was keeping an eye on our support inbox, and nothing too crazy.

i understand your frustration

Tuesday: A GDPR session run by Brighton Chamber of Commerce in the morning, reminded me that GDPR a) makes sense, b) MAKE NO SENSE and that WE’RE ALL DOOMED. Data is complicated. What the GDPR itself wants is fairly straightforward. What it’s defending against is a nightmare. Codes to take on codes for other codes. I know too much about computer security, I think.

In the afternoon, I had a useful session on Javascript with John, which was mostly a case of describing the last 4 years, topped by some initial next steps. Starting to feel more confident on this front, although code will feature heavily over the next year.

Wednesday: Had to work from home, which meant I got lots done. I used the momentum from the GDPR session the day before to get back into the work and do some good planning. We had a follow-on meeting for some recent shapefile-related work to decide what else needed to happen next. I had to pick up #son1, so bit of a truncated day.

Outside of work, I had my first random contact via Twitter, asking about software career development, after I posted that I’m free for questions after 20 years of making it up as I go along. It was slightly odd and scary, doing the “sudden mentor” thing, and me realise both how little I know about working today, as well as how much I’ve learnt. I may need to talk to a mentor about how to mentor people 😉

Thursday: Was my main day in the office, and the only real day that everyone else was in together, which meant lots of meetings. Sometimes it’s unavoidable, but I am pretty wary of chopping and changing subject a lot – it’s realllly tiring. The opposite extreme to having a day to myself coding (which is tiring, for different reasons, and doesn’t geenrally happen.) It would be great to keep track of how many different meetings, or topics, I have in one day, and move to limit it when it’s getting too many. I know how much it takes out of me.

All the discussions were good though. I may be able to re-prioritise some work I’d put a lot of pressure on. I’ve got a rough path forwards on next stages for our server setup. I drafted a negotiative mail about invoices and got some feedback.

Friday: I was really tired after a long day the day before, and an early start. However, had a 1-1 with Alex, a GDPR plan sessionw with Kim, and in between managed to send a useful email, and publish the responses to an internal survey I’d sent round months ago on our social value. So that felt good. I’m really bad at publishing things like that – they seem “forgivable” so aren’t high priority, but I’m also fairly afraid that … that what?

I’ve never been great at finishing-completing. I like to go back and make changes, so a “final” publication gets pushed back. I’m my own worst critic, which is stupid – partly because then things get posted late. And partly because I’m not focusing on what other people think is important.

Coffee finisher-completer

Pressure metrics

Maybe one of the things we’re really bad at is understanding the emotional attachment we have to particular bits of our work. We (as managers, in general, across the world) are great at ranking tasks in a backlog, checking with others for deadlines, assigning business value, etc, etc, etc. But we don’t stop to think about which bits of work we’re looking forward to, and which bits we’re dreading.

Which means we have to deal with something amazing one moment, and then (literally) ten minutes later, we’re on the other side of the planet, in terms of both subject matter and mood. And that’s a) tiring and b) difficult. ANd the best thing Iv’e done all week, this week, is to remind myself that I’m human. A human, with limits. You can’t jump across five different things and not have them take their toll on you.

Maybe by predicting and understanding – or “estimating”, as we’d say in software dev terms – what work we have coming up, we can achieve something better, something more finely crafted. We could…

  • schedule our work to make mood swings less erratic
  • make sure that we do high-attention work when we’re freshest, eg in the morningm or when we’re more likely to be alone
  • be more open, and let others know what state we’re in – either informally (chatting) or formally (calendar notes?)
  • plan to fit our expected work to our environment better
  • factor in better rest and relaxation time after “heavy” work

What would an assessment of work enthusiasm look like? If I was tagging it, it might be a 5-rank categorisation, something like: YAY | alriiiight | meh | ick | GROOO – in best to worst order, of course.

so many emos

Maybe this is something for next series, but I’ll look around and ask around – maybe people have done this already, but in a way that’s not excruciatingly “sensitive” and cringey. Or maybe it’s all just overthinking it, just as a distraction from the actual GROOO work. Don’t know, will think it over a bit.

Anyway, I don’t think I’m going to weeknote for the next 2 weeks, so enjoy yourselves, and don’t do anything I wouldn’t do.

Reading

Also very useful: Louise Cato’s list of democracy and civilisation books.

And finally, here’s my ongoing list of found inspirations.

Weeknotes 06×05: Two successes and Split universes and Product clarities

This week’s weeknotes go over a couple of things that have been a bit of a challenge, but that I’m pleased about the outcome with. The first touches on the challenges of coding and tech team management. The second looks at the joys of raising things honestly at a management level. I’m not sure if they’ve of any use, but maybe it’ll inspire some questions, and serve to connect with others in similar situations.

The week started out with a bang. I was pretty tired by Monday morning after a few good, but really long days off. At work though, we were up against it, as a dev team. With our user group coming up in a week, we needed to bring a new feature together, which involved the usual complexities which make technical projects so challenging, yet also satisfying:

  • working out solutions to complex, inter-related puzzles
  • implementing it in a technology we’re not necessarily very experienced in
  • understanding someone else’s code
  • bringing everything together across different members of the team
  • setting up, understanding and debugging code flows with three services talking to each other
  • liaising with the user/support team to get spec and documentation materials written, in between them getting ready for the user group
  • liaising with product owner – or deputy, in our case – to answer product questions that arise, in between them getting ready for the user group

By Monday we knew what we had to do, code wise, and what our challenges were. But we weren’t sure what our solution was – . John had had a good idea, and I wanted to help out, either directly with code, or indirectly by clearing some space for him. With John or on Tuesday, and me in a Board meeting on Wednesday morning, we’d have to be very smart indeed about keeping each other up to date, and swapping code and notes back and forth.

(To be clear, this is not a good situation to be in. (Previous weeknotes were a precursor to this)[https://weeknot.es/weeknotes-06×04-get-things-done-or-get-things-delegated-f11b8c55327b] though, so we weren’t completely unprepared.)

In fact, there was no way we could be that smart – nobody is that good, unless they’ve somehow been working together without speaking to each other for years already. I’ve known John about 3 months. Neither of us know the code in front of us, or the real answer ahead of us.

So, a decision. At this point, I made the call to split up, hedge our bets, and work on two solutions at the same time.

Dev team be all like

our dev team be like

This is not what I’d usually do. Usually I’d work this stuff out up front, get a plan in place, then leave people to get on with it. But necessity needs creativity, and plans are fine if you unbeaten the risks involved. We were fairly in the dark here, and there wasn’t even a certainty that either route world work. Sometimes you just have to have a little bit of faith.

For the next few days, we existed in this odd parallel universe setup, two branches coexisting peacefully in git, harsh on the knowledge that we’d only end up using one, but comforted by the truth that we could not, at least, fail to learn some things. Very rapidly.

I backed up the dual universe approach carefully, though. Where there’s risk of failure, there’s risk of people being very disappointed. Some things I made sure also happened as part of the decision:

  • Everyone in the whole team knew what was happening, which made it easier to set expectations and excuse myself from other work.
  • I excused myself from other work to concentrate on my own code. The importance of the user group made this easy.
  • I pushed on getting a “harsh context” in place which sounds worse than it reads. I know that developers – especially me – are prone to thinking that the immediate puzzle to hand is the only one, and that a fix is just round the corner. A “harsh context” aims to remove these two common delusions. In this case, we:
  1. Got together a good set of test cases (which ideally we would already have had), in a Google Sheet for rapid transparency. This would act as our yardstick of progress, not what got reported back by developers’ own intuition.

  2. Set clear times to review progress and make a decision. Actually, we’d already made a call that we would be done by Thursday 2pm at latest (to help prepare comms), and so we had an outline to work to. The actual deliverables changed slightly, but the important thing was that everyone had a time-stick to poke others with.

The planning is everything, hrrrrrrggggrrrr

plan 9 from outer SPAAAAACE

Alex and Hon Mond brought the test plan together, and set up the demo environment.
In the end, John hit some issues that came up too late to make the final cut. I went down a couple of rabbit holes, and it’s not the tidiest result, but it works. We have a demoable release, and we know what works and what doesn’t so we can line up follow-on work easily. The team have done really well, and I think I’m pretty sure I made the right decision. Success One, I reckon.

In between everything else, there was a company Board meeting, and various strategy charts.

Success Two: On Thursday afternoon, I sat down with Luke and Kim to chat about the future of the Hive Pixie product, (which I manage from our side in conjunction with our partner. That’s plot, that is) at a management level. I’ve been struggling to keep work lined up and prioritised recently, and wanted a bit more clarity about how much time we can put into it.

As per last week’s notes, it’s something I’m a bit emotional about, having put a lot of time into identifying a Roadmap and getting buy-in from our partner. And pushing past the emotion, it was a really good, and slightly unexpected chat, that made me realise how tricky it is to run a product by yourself, as a part time job.

It’s tricky to open up all the rationalising that goes into a Roadmap, and to tie it into a narrative that not only makes sense, but that pulls people in as well. It’s tricky to formalise the passion, gut instinct and people’s reactions that you see first-hand at user groups. It’s tricky to keep on selling a focused, long term viewpoint over and over. And it’s tricky to keep on top of that and write it all down while you’re on 5 other jobs the same week.

Alright, stop that para there

weep-achu

(Which is also why a good product owner is an amazing person.)

Anyway, this isn’t success. This is bordering on unreserved ranting. The success came from the measured feedback from the chat, which I could instantly pick up on when working from home the next morning. Feedback I could turn into some templates, some structure, and a process for filing it all in. I have a lot of the dots, I just need to be better at showing my joining up. Here’s the note I made:

Does the process with the most structure win? Structure is clarity, clarity is certainty, certainty is engaging.

(And yeah, one day I’ll open it all up to the wide world. Everyone loves a product process template, right?)

I’ve made a start in this, but am eager to carry on. Just need to find the time. Is it sad to want to do this in your own leisure time?

More generally, working the half day from home on Friday was brilliant. My inbox is half the size it was. Still had a productive buzz the following Monday.

Here I come, inbox zerooooooooooooooo

Samurai Jack

Sorry, no time for links today. Til next week…

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.