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.
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.
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 ocsi.co.uk domain for another 2 years. That makes it almost 16 years old now… Not bad 🙂
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.