s05 ep05: Stay light
There’s a great line in the great song In Time, by Sly and the Family Stone: “stay light, and wait for me”.
Staying light is good life advice.
It’s been a few weeks since my last note because life took over and I’ve been reading and writing other things in notepads during journeys and in the minutes between the rest of life’s never-ending logistics.
Since the last note I’ve been to Northern Ireland twice on a criminally early flight, and the rest is below:
Some things I’ve been working on
Saving time and unnecessary confusion/thinking power: Is this the non-dev version of automation? Is this just fantasy?
- Looking at data from our support tickets to drive reductions in failure demand and shape future product dev. Jess and Adam pulled together some tasty spreadsheets of tag data for me. DATA DATA DATA
- Writing policy guidance on third-party code so we have the answer if we get asked about it, and also to recognise the risk factors of site-wide plug-in type things getting owned.
- Testing out email macros — will this save us time and thinking in future? Dunno, but — more widely — I’m a firm believer in trying something and testing it and being comfortable changing or discarding approaches if they are proven to not work. The testing bit is the important bit, but also uncomfortable if you like a plan to be set and fixed in place. We have the phrase ‘emerging policy’ when we are in the uncomfortable middle part between a thing for which we have no plan at all and a thing which has been conceived, tested, tweaked and tested again to a point of becoming ‘policy’ or ‘how we do this’. That middle emerging policy bit before getting to the ‘how we do this’ point is a place of much change and flux and can be unsettling. This is a known, but not solved, problem. I guess the one thing you can be certain of at Delib is that things will always change.
- To try and resolve ambiguity I’ve also done some quick reactive investigating to give immediate answers to puzzles about our software and some of the tools we use
- I did a screen-record of how to do a thing. It took me 2 minutes and I’m convinced[1] that this could be a way to share tacit knowledge in a fair and even way across the people who need to know.
Some other things I’ve been doing:
Writing presentations. We had our user group in Bangor, Northern Ireland this week (it was great) and I did a brief talk about what’s coming next, which was pretty informal and I’m aware I rambled and went off-piste due to not practicing it enough. > Side note on this: I would really like to speak at an event on something I am knowledgeable and passionate about and can prepare for properly, but I am a) not at all sure I’m good enough and b) have no idea what I am qualified and knowledgeable enough to speak about. What to do when you’re not a deep water specialist but a splashing in lots of puddles poly-ist? This is where I need support/mentoring/a firm nudge in the back and/or some candid feedback. I will accept if that feedback is “you should definitely not speak at any event” though it will sting. Stings can be a catalyst too [2].
I planned and delivered analysis training — I’m doing more of this at the moment and I’m heartened that the results of these sessions is confidence in teams on how to manage their analysis workflow. To be clear, I am not a data scientist, this training is on how you build a solid process to be able to analyse consultation data, not what the results should look like.
I’ve also been planning for a long-overdue visit from James, our Australian director, this month — this I am looking forward to. Related, I’ve spent some (also long overdue) time with Jess, Lorna and Ben independently: part catch-ups, part transactional, part hanging out, all important.
Some puzzles:
- Which decisions are best made collaboratively and which are better dealt with by shaping an idea first, then building consensus and moulding it?[3]
- When to communicate a potential change when a plan isn’t finished and will definitely change again — cats, pigeons etc.? See further above on emerging policy.
- How/when to communicate when you know that a plan might change, but you yourself may not have the knowledge about the potential shape of it — Aim: being open but not spreading Fear, Uncertainty and Doubt (FUD)
- How to regain elasticity in my bounce-back-ability from changes to routine (like travel away )— stay light
- How to stop myself drifting away from colleagues and becoming a lonely iceberg — I want to prevent this in general, but especially when rattling through these puzzles in my brain as I tend to unwittingly distance myself when I’m over-analysing.
I read:
Carl Haggerty’s great post on dealing with shame and guilt, which appeared in my timeline thanks to the excellent sharing skills of Dyfrig Williams.
Shame and guilt come into a lot of the puzzles above for me (as well as life in general, amirite?), I am aware I could get the balance wrong on decision-making, communicating and so on, and in my attempts to spare people from FUD I might also — inadvertently — be making them feel shut out. I strive always to get the right balance but it’s awful to have good intentions and still get it wrong, and very hard to communicate the whys and hows of things to lots of people who aren’t always in the same place. Capturing detail in tickets and central places goes so far, but maybe not far enough. I wrote a year ago about self doubt, it feels connected.
I’m doing really well at staying light here, eh?
Also this:
I have also read:
Marginalia — ten years of poems and texts from Penned in the Margins, a publisher I’ve only just discovered. Their book covers are lovely. And I know I’m not supposed to judge them by that, but still.
Light Lifting — short stories by Alexander Macleod. Really excellent
This is going to hurt by Adam Kay. I now think this should be mandatory life reading.
[1] On being convinced: I will be once I have tested and tried it a few more times, obvs
[2] …but not without a good bit of burning pain first. Resilience is a skill only learnt through scarring.
[3] This is not just a question on a micro scale for an SME when making its own internal changes, but it also relates to democracy on a macro scale, which — neatly — fits into the work Delib does. When should you involve people in decisions which may affect them? There are some things which are absolutely great to co-design, but even then the limits of what can be done should be pre-established, such as ‘we aren’t able to spend more than x amount on this’. At the very least, a collaborative decision needs someone to have provided context, limits, and an outline first so that an informed process can happen. Often, a democratic process is about consensus building (here’s our broad plan and how we think it could work – what do you think?) and not as much about design by committee (we have this situation/challenge, how might we solve it?), but both have their rightful place.
