The Weeknotes where I Decide My Future

Hullo, my name’s Graham and I’m a tech lead. I’m vaguely on Twitter and other spaces. Oh yeah, I wrote an intro, didn’t I?

Monday, the delivery of news as a dark art. I started the week by telling the team I’m dropping to 3 days a week from September. Even though I’ve thought about it a lot and know it’s the Proper Time and a Good Thing, it was still an oddly and unexpectedly emotional thing to announce out loud. It’s something I’ve been thinking through and gearing up to for a long time, and there are lots of reasons for it, but it still seems strange to say it out loud.

I mumbled through it a bit more than I’d have liked to, and some people weren’t there, and I had to disappear into meetings and dad duties for a few days after. I ended up emailing the people who weren’t there, as I wanted them to hear it from me first. In a separate strand, I’m thinking a bit about remote working – I wonder how more important announcements can be relayed to the whole team better. Synchronicity is important, but so is personal delivery. And I’ve never seen a mass e-mail which works well at all.

(Time passes)

Chatting this decision through with the tech team has been oddly and unexpectedly “good”, in the sense that it’s raised a lot of questions which, I think, are currently being allowed to sit there and “simmer”. There is apparently nothing like a more drastic change to focus minds and open up discussion. In the end, I opted to talk to my team individually rather than as a group – this meant we could focus more on how it affected each individual, and I got a lot richer, more personal feedback and longer discussions that we wouldn’t otherwise have. Group size (and location) is really important for things which have a lot of “effects”, I think.

It’s been a fair relief though, and all the things I’ve been vaguely worried about in my head have now turned into post-it notes that I can actually do something with. I still haven’t read the Anti-fragile book, but get the impression that certain changes, done in the right way, lead to a stronger and more resilient organisation/organism. That doesn’t mean “throw your team in the deep end and they will turn out amazing”. That won’t work. It means that you can introduce certain stresses into the system in a controlled way, and then observe and guide the response of the system accordingly.

A pontoon, with a pair of sandals on

What else happened?

A good session on Thursday between Alex and the product managers (Flo, Stefan and meself), building on top of our revised “3-month/6-month” backlogs structure from a few months ago. We’re recognising the need to have a clearer set of known, working issues at last – not easy when juggling 5 or 6 sites, with code going back 6 years. What are we finding that works for this process so far?

  • Finding the time to get everyone together, ideally in the same room. Initially I suggested I could go through my issues separately, but it was actually useful to see the rationale and decisions on priorities that each Product Manager had.
  • Spending time up front discussing the ideal key focuses over the next 3-6 months. Sometimes this is clear, but often it’s not, and it’s really handy to bounce ideas around the others involved in planning work.
  • Working with epics in Jira – this makes it easier to lump stories together and deal with them in blocks. Sometimes a focus area just doesn’t happen for whatever reason, but we can make a joint decision on all those issues in one swoop.

Rock and roll.

A curled piece of rope.

I’ve continued to meta-meta-plan (pata-plan?), drawing up the agenda and structure for our MT’s strategy planning day next week. I guess you can never tell whether a structure will play out as you want, but I’ve been trying to learn from previous attempts this time, and started out with a recap of what we’ve tried before and why things fail. Things I’m doing differently this time are:

  • Aiming for a draft company strategy, with extra time for it to soak in and for us to reflect on it outside of the group.
  • Setting out a rough sentence structure to end the day with, ie work towards a particular grammatical structure. This borrows a little from the idea to write press releases for new developments first (except without the details), or from the various templates that guide ideas such as “As a X, I can Y, so that Z”. Aiming to write things down forces clarity, or at least that’s the idea.
  • Brought in more facilitative/liberating structures – starting with giving the team more solitary thinking time rather than just wade through group think discussions. I’ve borrowed the 1-2-4 setup for sessions where I think it makes sense, and 1-4 sessions in others, alongside some scales to map out our instinct, and dot votes to identify priorities.

Will it work? Find out next week…

Other things:

  • The photos this week are from a weekend trip to the folks in London. We finally took the kids to see Dad’s sailing club – he’s been sailing all his life, but it’s not a side of him the kids see necessarily. We found the caterpillars of cinnabar moths, and fished with a bit of old rope.
  • Ow, my back. Feeling properly 40 now, as life has manifested in some sort of trapped muscle. My new regime is to stop sitting around on my arse quite so much…
  • A few little things have kept me inspired this week – little snippets of observations from people in meetings and in chatrooms. But I forget what they were. Maybe I should keep track of them somehow – it’s the little things that count most times – a brief, unexpected sentence that tells you more than a whole review session. These are the krill that I live off, some days.
  • I’ve started picking through the feed of weeknotes again, somehow. I thought I might try highlighting other weeknoters who I’m enjoying reading – like the old #followfridays on Twitter. #wickedweeknoters tag? Anyway. Recently I’ve been enjoying the tech thoughts of Ben Lidgey and the amazing notes from Nadja bester who talks of all the things I’m into but don’t write about. Here, at least.

A discarded chair and trolley next to a litter bin

The Weeknotes where I tenuously apply a Driving Course to my Work

Hullo, my name’s Graham and I’m a tech lead. I’m vaguely on Twitter and other spaces. Oh yeah, I wrote an intro, didn’t I?

Monday, I’m off work instead of Tuesday, to get the train to Bournemouth for a Driving Awareness Course. Tut-tut me. Still, I get some train time to read through a bit more of the GDS recap Digital Transformation at Scale, and start thinking about requirements for the tech team next year.

The driving course is actually pretty interesting. I’m particularly struck by the “EEE” approach to reducing risk in automobile safety: Education (like the course I’m on), Engineering (safer cars and tech), and Enforcement (making sure people actually act safe). It strikes me as a good general approach to reducing risk – or indeed change management on the whole. Thinking through running a team and setting aims for change, I can break it down into:

  • Education: Setting clear and feasible goals, keeping them documented, readable and in sight, and referring back to them, with rationale
  • Engineering: Making sure that what we’re building in the way of software, infrastructure and hardware helps make those goals easier and achievable.
  • Enforcement: Making the ongoing decisions and steers to prioritise some work and de-prioritise other work, and keeping people on track, often when they want to go down a different path.

I think it’s always a good day when you find a new alliterative initialism to help guide you in life.

A cake being made in a factory

Tuesday, I seem to be bouncing between a hundred Google documents.

Coding style is one. Alongside the “tooling up” mentioned last week, I’m making a more conscious and concerted effort to “solve things once” while we go through the current software design phase. Today, I’m looking over previous approaches to error and feedback messages being passed around during data validation, and seeing if we can get 1) a general philosophy, and 2) a specific code approach in place. Part 1 should change a lot less often than part 2. And part 2 may not always be possible, depending on what other things the code ties into.

Another document is looking at an approach to how we work as a “semi-remote” organisation. It’s hard trying to get the right balance here! So many trade-offs between individual and company needs, and then between what could/should be set up front, and what/how can be played with over time. I don’t really want to spend my time constantly tweaking expectations as we go – it’s a lot of overhead and it gets confusing and petty rather quickly. The more we can get right the first time, the better. But feedback loops are important to allow suggestions to come out, even if they don’t get acted on immediately.

I figure people have done this already, so ask around and on Twitter a bit, which has been really helpful – and certainly indicates many companies (even much larger ones) are fairly flexible and seem to evolve a repectful, flexible style. Stone-runner Louise pointed me at this reading list from Richard McLean. This chat between Steli and Hiten is also a good listen for the ins-and-outs of partial remote working in particular.

Aside from the process, it’s also got me thinking about what an office is for, once it’s not the “default” work environment. Does it become more of a central repository for shared resources, like machines and databases and books and meeting rooms? Is it “downgraded” as a social space? No answers just yet, but thoughts welcome.

Scene from the office, subtitled 'He put my stuff in jell-o again!'

Thursday (What happened on Wednesday?), I am deep in code design decisions that could literally CHANGE THE FUTURE OF THE COMPANY. Well, like all code really. Got to keep some perspective.

(A tiny, belated component arrives from DHL for the new server we’ve ordered. It comes with an SD card to hold the operating system, and I remind our sysadmin, Gregor, how funny it is that the whole company depends on that tiny card. “Yeah, we should probably get a second one.”)

We’re tackling some meaty refactoring work, as we’ve currently got the time and enthusiasm to put some more fundamental changes to the codebase, and to our general practice. Alex, Luke and I have a good discussion on the ins and outs of different code structures for passing messages around. I feel like I’ve tried to solve this a few times before ie. all my life, so it will be good if we’ve finally made the right decision and can stick it for the next ten years.

Relatedly, we renewed the domain for another 2 years. That makes it almost 16 years old now… Not bad 🙂

Two cats putting a candle out on a cake

Friday is a quiet day to end on. I’m putting an agenda together for a “full strategy” planning day in a few weeks. I do love me strategy, and enjoy the fundamentally creative aspect of it all – the challenge here is to entice people in, get 4 people “thinking strategically”, pulling in information and making sure we chat in a useful way, and – somehow – agreeing a select bunch of stuff to do. For a year. Not easy, but also not the first time we’ve been through it.

I jot down all the previous attempts, and try to list what’s not worked with them, and some suggestions to avoid making the same mistakes again. Meta-strategy, all the way up. Or is it down? Anyway, I fill up a few sheets of a document faster than Jack Nicholson with a typewriter (or is it Jim Carrey? I’m so confused) – think through my fingers, use the modern computing paradigm to arrange thoughts, capture, elaborate, remix, dissect. A structure gradually appears, helped along by a ham and coleslaw sandwich and 5 minutes lying in the sun.

At the end of the day, organisations come down to a few basic things – income, productivity, morale, sustainability, etc. Keep a list of these and decide what’s important to change on each of them. Everything else that you don’t want to change, keep a good eye on.

That’s better, there’s an agenda and prep and expected outputs and I think maybe I know what I’m sort of doing this time round?

Either way, we’ll need cake. Lots of cake.

Mickey Mouse, slicing and dicing a delicious cake

The Weeknotes where I Return from My Own Thoughts

My name’s Graham and I’m a tech lead. I’m vaguely on Twitter and other spaces. Let’s get on with it, shall we?

Leftover lost property at the end of term
Lost property. Not a metaphor.

Setting the foundations

Platforms. I’m returning from a two-week ‘sabbatical’ which I wrote up here, during which I relaxed and let thoughts settle as much as I could. It’s just that point in life, and it was a good exercise. I remembered that I build things that people rely on, and I’m good with that. Sometimes stability is more important than innovation.

This fed into the idea of “tooling up” I noticed Monday morning, returning to the office. Get the foundations in place, and everything else just falls into position, so much easier. We’re at the start of a new feature development, so I’m firmly embedding myself in the ‘get things ready to rock’ mindset. If you’re chasing your own processes and tools halfway through the work, everything is at risk. Back-pedalling requires a huge amount of overhead sometimes.

A test plan is another platform for building change, so I also focused on that this week. I dug through the code I wrote so many years ago, documenting it line by line, eking out actual functionality rather than assumed. I’m having a push to document our functionality better as we go – it’s a bit silly how often we still refer back to source code to determine system behaviour. This time, I want to make sure the audit ties in with our client-facing knowledge base and our internal automated tests in equal measure.

Food is also a platform – for the brain, but also for communality, so I forced myself to take a break in the afternoon to go the shop. I have an urge to expand our snack repertoire. Disruptive foodstuffs. Bought smoothie and some Nakd bars.

Got my developer VM updated because it’s important to keep up with infrastructure. This is also a kind of review for the changes the team are making to our setup – getting it working once is exciting. Getting the same thing working across the whole team is a different challenge.

Mindful erasure

Mapping out the abstract is something I really enjoy doing. All decisions come down to understanding the landscape – map out the landscape and how everything is connected, and the decision and the strategy resulting from it simply become a route through from A to B to C to wherever you want to end up. Certain things don’t relate to each other, so you can consider those separately. Certain areas come “before” or “after” other areas, so you can order decisions accordingly..

The difficult part about the abstract is that it’s the wrong side of the eyes – stuff inside you head is tricky to see. Other than our eyeballs being back-to-front, there’s also a whole cruft layer of other thoughts in the way – ongoing deadlines, dinner shopping lists, emails to send. Getting that cruft out of the way is vital, like clearing clouds from below a helicopter to see what’s down there.

One way of doing this is to write everything down somewhere first, so your brain knows it can give up its hold on it. This is generally the first thing I do if I’m getting worked up about many disparate threads – map out the distractions.

Today I noticed another, complementary approach while getting a big board ready to draw my map on. A cup of tea, pen, and board eraser ready to go. You can tell a lot about people by how they write. But you can also tell a lot about them by how they unwrite – the hurried act of scraping the board eraser over a large surface, a frenzied urge to wipe the slate clean, to “get things down” and crack on. But there’s an alternative, my friend. Next time you wipe a board clean, do so deliberately and carefully, in the way that Eastern calligraphers grind ink sticks for an hour. Rub in circles that flow like leaves blowing or kites soaring. Feel the board beneath, and how its stale traces of old, penned ideas catch at your movements. Clear the space like you’re making a nest for a newborn.

The act of unwriting can be that process by which you disregard those distracting ideas. Each swoosh of the elbow is another step towards remembering the question you want to resolve.

Each sprint, an exercise

Almost forgot, but I’m working from home today – #son1 has a singing concert this afternoon. It’s that time of year when schools go crazy – this week has been a (postponed) sports day, a Carribean cafe, a settling session for #son2 and this concert (plus the usual packed lunches, music lessons, etc, etc). Talking to other parents, it’s clear that making it along to everything is often difficult, if not impossible. It’s that re-reminder that flexibility in people’s lives counts for so much – everyone has needs and draws from outside of work. I have an inkling of that for other people in the company, and I wonder if we still paper over all these pressures more than we should.

I’m not greatly set up to develop code from home – I can access code and do reviews, but not really run code to see it in action. I could look into getting a remote desktop connection from Mac to Windows, but to be honest, I enjoy the change of scene as an opportunity to do different things, and do things differently.

I want to use the current work to develop a more standard approach to handling messages, errors and feedback, and jot things down in a Google doc. The question quickly becomes dependent on what our existing code does and what the plans for the current work are. I open up the question to team slack channel, to get their input, but also feel like I may be going down a rabbit hole that’s too far away from the team’s current mindset.

This is a tension I deal with daily – as an apparently experienced software architect, I want to establish rough structures sooner rather than later – my early work happens “on paper” as a way of mapping out relationships and flow. But other developers often prefer a “code-first” approach – get the files in place, and think with the keyboard. I totally understand that approach too – I do use this on personal projects, when I know there’s not much complexity. The delete key is an essential component of software development.

On the one hand, I want to avoid the team getting in a muddle later on. On the other hand, getting into a middle that can be fixed easily is good for learning. It’s like each sprint is actually the opportunity for an exercise; One time, we practice object design. Another time, we practice unit testing. Another, interfaces and invocation, or writing up style guides.

Perhaps I define these team fences subconsciously at the moment – instinctively, yet reactively, I put certain structures in place so that the team can focus on what I think it’s best for them to focus on. But could/should I do this more consciously and clearly? Is it something we can discuss and document at the start of each sprint?

Seizing the “opportunistic”

Something my brain keeps coming back to this week. I heard about an institution who had retweeted someone calling them “opportunistic”, somehow deciding that this word was an endorsement, rather than an indictment (or maybe it was, and the original tweeter didn’t know what it meant either?)

Anyway, I liked the new definition. Coming out of my thoughts on focusing on foundations, that idea of “providing opportunities” stuck with me. Build a stable base to provide opportunities on – I can very much get behind that.