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.

The Weeknotes where I try to explain the Beauty of Coding

It’s the end of May, in more than one way. I’m a whole new decade and have the scars to prove it. We’re running out of time, and out of Eurovision votes. It must be the moment for some weeknotes.

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?

A sign for a Polling Station, plus cake.

ONE. The beauty of coding.

Coding is one thing. Software design is another. Software design is all about going beyond just making the computer do things – it is about making your code into something “assembled”, usable by both yourself and others, a collection of logic organised to make sense, and from there, to be a joy to build on top of.

I had lost sight of this a little, in the continual travelator of life. But this week we had some opportunity to revise our (working) code for a little while. I looked through a new object that Hon Mond had put together (we make sure code is reviewed) and that he was writing tests for (we write unit tests – usually). If already altered some code to be slightly more testable, but making it more testable threw up some interesting conversation – what’s best for testing isn’t always the best design.

Design for what though? For whom? Software design, I think, comes down to two questions:

  1. Can other developers pick up and use the code easily from an external perspective, even joyfully, as with users picking up a service interface?

  2. Does the internal structure of the code allow it to be extended quickly, understood and adjusted easily?

The hard thing about software design is that it’s often akin to strategic thinking; When designing one object for re-use amid a network of other objects, all vying to do similar things, deciding what the object won’t do is tough. It involves a commitment to set limits. And developers often seem to hate imposing that on their universal Turing machines.

TWO. Getting used to UX as a blocker to sign off.

Our UX processes have been evolving quite rapidly over the last few months (such I am absolutely loving – it feels like a certain passion in some of the team members has exploded.) There are, of course, knock-on effects from this which are good, but take a moment to get used to.

This week, I really wanted to close up some tasks which are hanging around from last sprint (we run fortnightly sprint cycles). Actually, some of it was the same code as mentioned above. The code was working, and we’d had to omit some functionality we’d have loved, but what we had seemed to tick enough boxes for now. So I’d decided, in my head (and sort of in the sprint meeting too), to commit to closing them by end of Friday.

During Friday afternoon’s testing, we hit a performance issue with the functionality at larger scales. It was taking too long to respond to the user in some situations. For clarity, Scale is a bugger – you can generally guess that things will suffer as usage goes up, but it’s hard to say how (Linearly? Exponentially? Or will economies of scale kick in?) or at which point it will Actually Become A Problem.

(Side note: I love investigating and fixing scaling issues, but I hate trying to explain or estimate solutions for them.)

So at 4.50pm on Friday, we gathered around a Skype call on John’s phone, and 4 of us agreed it was a blocker to release and that some further work would have to be done on it next week. I felt slightly frustrated, but as John noted, it’s actually great that Flo (on the other end of the skypaphone) was able to stand in as the voice of the user, and prevent this from being accepted. Previously – as I was tempted to do – we might have said “it’s an edge case” and write it off to come back to later.

But we didn’t. And when I realised that was a shift in the right direction, it actually became a moment of pride, rather than disappointment.

Go team.

THREE. Taking some time off.

So I wasn’t really sure what I wanted for my birthday this year. Well, apart from solar panels, natch.

40 is a big number, where you start thinking about death instead of birth, where there’s not one but two generations beneath you, and often the same above. Dan Barrett put it very well:

In my 30s I was bowled over when I realised that being a grown up isn’t a thing and it felt profound but I reckon the realisation in my 40s that everybody’s barely holding it together is a bigger deal. Hugs everybody 🤗

For me, a passage from The Erstwhile also hints at the sense of a change in direction:

The water, the millions of tons of it, was stationary like a millpond. … But the stillness of the water became a secondary feature to the movement of the snow. It fell straight down into its own reflection

So it’s been a while since I took a proper look at myself. About 10 years ago I went on a tai chi and meditation retreat for a week, and I wanted to do something similar again. But school runs and parenting, etc. So I’ve decided to take 2 weeks unpaid leave off in June, and intend to use it to “re-ground” myself – to just stop and reconnect with why I do my job.

It sounds like a midlife crisis. Maybe it is. But I also know I chose to do the job I do because I care about it, and nothing’s going to change that. I want to think through how I do it though – what’s really important to running a team and a company and the state of data and power in the world. Ideas are already gathering.

I may even try to skip up to London during that time, so drop me a line if you’ve read this far and might be around (or down on the south east coast).

It would be good to explore.

Other places

Til anon. Wait, is that how “anon” works?

A large Elvis mirror picked up from the street for my birthday
Thanks for the birthday present, team.

The weeknotes where I admit 1-1s are actually pretty scary

Hello, weekdiaryarchive, how are you? Are diaries even allowed to have feelings, or do they need to stay absolutely impartial and as deanthropomorphised as possible, for fear of external bias? The electronic note I’m writing this into – is it really as independent as I believe it is?

My name’s Graham and I’m a tech lead. I’m vaguely on Twitter. These are my weeknotes.

Black and white photo of plastic wrapped round a tree

In true Warren Ellis style, I am running around after headless chickens stuck in multi-pies this month. Tomorrow (written on Friday) I turn 40 (in capital numbers) which I don’t really mind at all, and to be honest the numbers don’t mean much to me, but a eurovision is on, it’s a full moon 🎑, and the opportunity to throw a party is just too obvious. So mostly my energy has been focused on playlists-from-the-ages and making shopping lists and watching the semi-finals.

I’ve been making work notes as well over the last few weeks. Here are some things that have been in my brain.

ONE. Continued thoughts on what constitutes “work” as you get more senior

Setting strategy and standing back is a strange game. Directions you set months ago can take a quarter or more to bear fruit. By then, everybody has forgotten the strategy documents and original intentions, which is why it’s so important to remind yourself of them regularly – a side effect of reviewing progress is to keep that narrative and timeline established.

Or is it? That Tao Te Ching phrase persistently comes to mind: In the end, the people say “we did it ourselves!” But perhaps this leaves the door open for a perceived imbalance of power – it’s easy to assume that Delivering is the Value. What would minimum viable management look like?

One day, maybe I’ll write a book on tai chi and leading. But for now, it chimes with the agile notion: Test, but don’t commit. Listen. Adjust. Small amendments to strategy are better than sticking oars in and rowing in a different direction every month.

TWO. Maybe I enjoy 1-1s for the discomfort?

I’ve been catching up with team 1-1s after a couple of months away from them. Mostly due to illnesses and holidays, but maybe I’m just making excuses. Still, the absence throws the experience into a stronger relief when I do get back into the habit. My own emotions stand out more. Which is to say:

  • All the leaders and literature tell you how important it is to do 1-1s on a monthly or weekly basis. Over time, I know this is true and correct.
  • But giving 1-1s is also a really scary experience for a lot of team leads. They often go against day-to-day culture, I think – either because they’re not ‘getting on with work’, or because they can (/should?) delve into more emotional and personal conversations, and things British people really hate talking about.
  • That’s really intense in a face-to-face situation. If you’re reading this and you’re fine giving 1-1s or indeed relish them, that is cool and I look up to that. But OMG, the energy required to fit personal development and wellbeing into organisational structures, strategies, legals, etc can be very draining, mentally and emotionally.
  • It’s fine to run a slightly “duff” 1-1, I think. People are tired, distracted, etc and you can always respond exactly as you’d like. It’s also fine to pick up afterwards and carry on a 1-1 if you need to elaborate a conversation or remark further. There’s no sense in waiting for the next scheduled catch up.
  • Really, maybe, the best advice is to remember that 1-1s are just a chance to BE a person – to get away from the hierarchies of delivery, to forget about specifications and standards for a bit, to allow both yourself and the other team member to just be yourselves for a few brief moments. Ultimately, 1-1s are more important as a space for that, and all the stuff about career progression and achievements and stuff is just a reminder that stuff is all an important part of someone’s life, but not the totality.

So yeah, 1-1s, scary but only because being yourself is scary.

THREE. Roles should be unit tests to each other

We’re continuing some brilliant conversations to clarify our product “ownership” roles, which I mentioned last time. As part of this, I’ve realised how useful it is to have more than one person involved in any single role – we’ve split up a single “Owner” role into a twin “Strategy” and a “Manager”. The conversation to define these, in relation to each other, really highlighted how the two can support each other by checking and reviewing the responsibilities of their counterpart. The Manager can check the strategy for clarity, and the Strategy Lead can approve the Roadmap deliverables. Separation of functions, with cross-checking. (We do this in the dev team a lot, with code review baked into all code that gets released.)

I wish there was a way to write unit tests for this. Test- and Behaviour- Driven Development hint at generally automated / agreed checklists for what emerges and how things progress. I see phpunit versions of Labour’s Brexit tests in my head. Automated organisations are only a decade away – AIs can set the strategy based on the company values provided by shareholders, and the input metrics provided by private SaaS infrastructures.