META: What’s so interesting about a Technical Director anyway?

Fear of modern times

FOBB – Fear of Being Boring. It’s a modern problem: everything that you do is so transparent: documented and published and curated a hundred times every day. FOBB is the inverse of FOMO – it’s the anxiety that accompanies the creation of content, rather than its consumption. Fear of being normal. Of being mundane, set against the tide of the attention economy.

Against this backdrop, I’ve been thinking about my own weeknotes experience again. Weeknotes have always been ambiguous for me – sometimes they’re my own scratchpad, not much more than my notes to myself. And at other times they’re closer to a Real Blog ™ with Actual Points and Arguments, intended to Say Something. That’s when I get sucked into FOBB, when I’m trying to connect to people, other than myself.

Every blog is a TV channel

To be sure, I don’t think my weeknotes will ever be un-ambiguous. But I would like to work on the ‘connected’ side of them a bit more, and make them more useful to others. I’ve learned from blogging for years that Content is hard. But at the same time, it’s in publishing openly that we commit to our ideas, and that we come to be our own, harshest critics. Openness, and the mere potential for feedback, forces us to be honest with ourselves first and foremost.

Since simul-publishing on Medium as well as on WordPress, I’ve really noticed the FOBB-factor. Highlights, claps, responses and all that. And the worst bit is I know it’s an addiction that capitalist tech deliberately put in place, to feed engagement stats back to their investors, to boost the charts. That feeling that we all want to be loved, distilled into Powerpoint slides. Was I happier when I was purely blogging without stats and comments? Would this post ever have even come about?

Who’d be a tech lead?

Either way, the question is in my head, and openness dictates I turn it into words.

So here it is – you, dear reader, what interests you? What do you want to know, about what it’s like to be a Technical Director, to build technology that feeds off government data, to bring together data, code and politics, to run a tech team, to exist as a working father, to work in the private sector, to use Jira without too much swearing?

Generally I try to cover some of the following, because this is what I’m working through currently and therefore find interesting – Medium readers, feel free to highlight particular items which make you happy?

  • The peculiarities of code, and how to make it a team activity
  • Helping teams work effectively together
  • Responding to crises
  • Balancing way too many diverse things and stay sane

But then, I’m also aware that there’s so much that I probably take for granted, like being able to knock together scripts, or sharpen up communications tools, or commute in to work with a bunch of amazing people. What am I missing out?

The next series of weeknotes is looming, and I’m going to try to make them fairly accessible – sketches, rather than oil paintings. Fragments I can replay to myself in a way that cements feedback loops. But I’d love to roll some comments in from yourselves, you hidden ghosts out there, you internet shadows lurking with thumbs.

What are you curious about?

Curios dog, natch

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.


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)[×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


(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.


Reading: (Lucifer, by Mike Carey)[], and re-reading Foucault’s (Fearless Speech)[] which I should blog about separately, as it relates a lot to both 1-1s and Weeknotes.

Weeknotes 06×03: Empathy is also Hard, and Working Out what to do with the Past

Overall feeling: Like I can’t quite remember, like it was all a bit of a dream.

Spoiler: Friday contains the good thoughts, on agility and the past and the future. Also, no gifs this week. If you make it through, thanks for reading 🙂

What happened this week?

Thinking back, this was a really fast week. At times I felt focused. Other times I felt like I was drifting. Periods of productivity flitted around, but sometimes it was planned, and sometimes it was more reactive.

I started out at the weekend, really – I knew I had too many things on, so sat down to work out what the minimum next step I could do on each was, to keep things moving. Then I prioritised these steps, and then I put them into my weekly Trello board (one column for each day) in a schedule I thought was plausible. Oh yes, I’m all about the micro-strategy right now. It certainly felt like a weight had lifted from my mind, anyway.

On the whole, my week was a lot more development-heavy than I was expecting. This was probably predictable, in hindsight – fellow dev Luke was away the last three days, and fellow dev Alex was away the first three, visiting WWI graves in the Somme. Which I’ll come back to, for narrative reasons. Alongside staff absences, we have a couple of technical pushes on at the moment, both of which I’m not directly involved in, but am supporting on as a Technical Manager [TM].

And, alongside that, the move to our new server has had a few foreseen and unforeseen knock-on effects, and so I’ve been picking those up, as everyone else is pushing on with the real work.

So I haven’t got done all of what I’d hoped to do, but it was kind of fun to get my hands dirty again, and be able to do some real world work that fed straight back to end users within the hour.

A Post Script

Two weeks ago, I wrote that there are only two hard things about management. This is obviously a lie. Empathy is hard too. Or, no, empathy is easy if you’re listening, but to listen, you have to shut up – both the tongue and the mind. Shutting up is the third hard thing about being a manager, but probably the hardest thing. Harder than prioritisation and time management.

As a manager, there’s a force and a pressure on you, to be someone. You feel a responsibility to Make Things Happen, which in turn, makes you want to Say Things.

I’ve found there’s only really a need to Say Things where I think my experience tells me that it wouldn’t otherwise be said – in the right time frame, or the current context. Sometimes things are urgent, and there’s no time to let people work out a solution if you have one. Sometimes you have to say things you’d only say if you were drunk, because honesty isn’t really a British thing, but is essential for combating rumours and gossip.

But otherwise, people benefit from silence from a manager. So long as they know they’re trusted to do the work, and trusted to ask for help when they need it, people are generally much happier figuring things out for themselves, making a few mistakes, and taking the long, learning route.


One of my big focuses was to get some closure and open up the next strand of work for our clients in the US. We’re at a bit of risk of a never-ending (“iterative”) project, so I’ve keeping an eye on it and checking in with Emma and Obi, who are doing the work, with a view to make sure it gets managed OK, and the client is “liaisoned” properly, if that doesn’t sound rude. I went back to our original quote from a year ago, and suggested some new financial arrangements following a delivery this week. Felt a bit squeamish about it – I’m not a great one for negotiations, but I also know I’m just being a bit silly about it. I don’t like conflict, but so long as you’re rational and acting in the other party’s best interests, people are generally fine about these things, aren’t they?

Also had a quick technical chat with one of our UK-based Local Authority clients, who are looking to integrate our site with their intranet. It’s great to chat to people who know what they want, and what path is ahead of them. There’s a User Group coming up next month, and I’m still feeling bad about missing it – I do like listening to users…

(On the downside, why is there never a simple way to connect with Skype any more? Still, only took about 10 minutes to get the conference meeting setup, which is better than other calls generally. Does anyone keep metrics on time wasted negotiating group chat tech?)


Had a really good catchup with the rest of the Management Team, with some important developments which I can’t really share here. But managed to piggyback off the meeting to go through a couple of things I wanted to resolve this week – to get agreement on pricing structures, and to get agreement on the year’s product roadmap for Hive Pixie.

I think one of the most important ‘internal processes’ I go through is to get ‘buy-in’ – I’ve noticed that I do this a fair bit around decision-making: I like to check that people are happy with a decision I’m making. On the one hand, this could be seen as a lack of confidence – sometimes it is, but I do try to be honest about this, and will frame the discussion more as a ‘sanity check’ or a review, than a ‘sign-off’ one. But other times it’s about lines of responsibility, and – more importantly, perhaps – shared direction. If people aren’t happy with what I’m doing, then I’ll be left doing it myself, and it’ll be a right old struggle to get others to help out later on. Well, more of a struggle, in some cases 😉

I once described what I do around decisions as a bit of a sham – all I do is collect the info, structure it, turn it into a rational, defensible process, and play it back to people to see if they agree. I don’t really make any decisions at all, just discover them.


This was the day that Luke and Alex were both out. We also had Kim and Emma working from home, so the office was pretty quiet. I spent some time on dev stuff – signing off our site migration task (prematurely, as it turned out), making some small code tweaks, and trying out our new Virtual Machine setup, which sadly broke my development environment. Oops. Still, it’s great to be able to get to this point – I set up the initial environment months back, and over the last 4 or 5 weeks, it’s started to take on life within the wider team, so I’m kind of closing the circle. Proud of the way this bit of work has developed, and will certainly try to remember it in future.

Also had a 1-1 with fellow dev Hon Mond, which I deliberately also used to explore the capability framework / career path guidance I’m putting together slowly. Developing this in conjunction with others, instead of doing it myself, was a decision I’d made at the weekend, and was influenced by chatting to fellow Weeknoter Julie Byrne and hearing briefly about her (much more organised, I suspect) workshop approach.

Getting help from others is something I’m really trying to improve at. A bit of me still feels like I’m ‘cheating’, if not failing, but the results are always clearer and more participative all round. So far.


Here was whee the #user-support channel started to become my home. I’d already been trying to work out some permalink stuff for the Local Authority client I’d chatted to on Monday, having promised to send something over. We then discovered a few things that had been missed in translation when the site migration happened – a parallel deploy had been partially rolled out, and while there was no broken functionality, the speed improvements we spent a few weeks putting in place had effectively been rolled back. TBH, the risk was raised at the time of deployment, but wasn’t bad enough to warrant worrying about. Fix it easily, move on.

That sort of set the tone of the next day and a half though, so instead of getting on with the work on Ethical Impact I’d hoped to do, I was fairly mired in git, my IDE, databases, and Jira issues.

I think I got to midday on Thursday when I realised that the end-of-week stuff I’d hoped to look at just wasn’t going to get done. I checked there was nothing that couldn’t wait, and shoved everything back in Trello.

Spent the afternoon catching up with fellow devs John and Hon Mond on the major bit of work they’re doing. I’ve stepped back from this a bit, but wanted to check in and see how things were going. There was less clarity than I’d hoped for, so I ended up making some strong suggestions to have conversations – or if they’d been had, to write down the decisions. I hope I don’t come across as too controlly-controlly when I do that – I hope it’s the right choice, and I suspect it’s only done from experience of seeing tasks going awry when people are confident that things are fine.

I like knowing answers up front.

Ended the day with another user support issue, going back to some code I wrote 5 years ago. But ran out of time.

Friday, Five Years Ago

The second half-day of the week, after Tuesday, and I think I’m getting the hang of these half-days. The first time, two weeks ago, I struggled to stop thinking when I left work, and ended up writing up notes in the afternoon. Now I’m more stringent about it, and treat my afternoon off just like I treat my day off – effectively, no comms, and a deliberate intention/effort to Do Something Else. Meditating for 15 or so years really helps make that shift, actually. It’s one of the reasons I think I’m OK at jumping between lots of contexts over the course of a day (which doesn’t make it right or effective or any less tiring).

At the start of the day, Alex – returned from the WWI battlefields in France – was telling us how the crops growing over the old trenches, filled with new layers of earth, grew differently to the surrounding crops due to this difference in layers. Here’s an aerial photo:

Trenches from the air

These lines, their shapes dug a hundred years ago, now shaded in multiple greens, feel like nature locking human history into her own output. The politics of war, now embedded in the hue of vegetation.

I spent the morning mostly looking at the issue that I started looking at yesterday, which meant going back to some very dodgy SQL I wrote 5 years ago. On the way home, I sat on the train and thought about the past, as the cold fields of Sussex floated past. Decisions we make now are enshrined and built on. We build layers on layers – our processes and our politics and our efforts are all just ways of building new layers.

Someone (who I should get in touch with again) told me last year that the difficult thing about running a product isn’t scaling it up, but keeping it going. Another tech leader talked about how versioning meant you were always dealing with parallel histories, in one go. Age is the antithesis of agility. The layers are inevitable.

The lines of the code I was staring at took me back, to before I knew most of the people in the office. Just as the lines in the crops take people back to a story they’ve only seen in black and white photographs. Trenches dug with metal. Processes growing all around us.

I had this feeling that I was dragging something – but not the code itself, not skills. Nothing other than the past, really. As if those 5 years in between – where #son2 was born and the company grew and relatives passed away and we moved house and local authority with it – as if they’d never really happened.

On the train, I think I made a decision not to be a captive of that weight of the past. If I truly believe in agility, and all the catches from the world of ‘agile’ that hook into my philosophy of lightweight nomadicism, then I’ll address it. Somehow. In time. Not immediately, but eventually.


  • Finished reading M Train by Patti Smith. Gave it 5 stars on Goodreads, and probably the reason I’m wittering on lyrically above. A great nomadic book about memories and attachment and coffee.

  • Started reading Famous for 15 People by my friend James – short stories, ranging from the amusing to the macabre. I’ve read a few before, but love reading them again. Some of the ones I haven’t read before have been creeping into nightmares.

  • Also started volume 7 of the Unwritten, a graphic novel series I’ve been following for a few years now. Excellent series about the power of narrative.