Weeknote: urgent, important, fashionable
In which we explore some recurring themes
In government data circles, there are many important things that aren’t considered all that fashionable — or indeed sexy. I might revisit this as a theme another time, but for now let’s talk about data catalogues, as that’s been on my work mind this week.
I’m all for user-centred design, and if the primary user of data is an analyst or data scientist, and the use case is to deliver timely insight to inform an urgent decision, cataloguing that data might seem like a luxury — get the data in, clean it, analyse it, share the results, these are the steps we rightly focus on in our team and many like ours.
But working in the public sector, on potentially sensitive data, collaboratively, in a secure environment, and facing (entirely appropriate) scrutiny for our use of data, knowing what data is where and used by whom for what purpose becomes important. Aside from which, it makes the job of an analyst easier if they know what data is already available, what could be made readily available (by, say, giving them access to something that’s there but not shared), and what needs to be acquired or accessed from elsewhere.
I said these things become important, but they rarely become urgent. Far from being just a management consultant’s go-to slide, the relationship between important and urgent things became really clear for me this week. Colleagues of mine have readily acknowledged the need to catalogue and monitor our data use, but have worked in a more loosely-regulated environment to date, in order to work faster. I’m looking for the right window in which to switch both technical platform features, and working cultures, to ensure we work at pace, but with catalogued data — attempting to make the important work of cataloguing align with the urgent needs of a data scientist. It’s hard, and I’d welcome advice on both the specifics of data cataloguing, and the general point about bringing important work into the here and now.
Workarounds, tools, and addiction
Which brought me to using a rather crude metaphor this week: that the tools we develop or use to meet urgent needs, when the important longer-term work isn’t yet done, can be addictive, like an opioid. The tools, processes, and working practices we develop to integrate important-but-never-quite-urgent things can act like methadone: a way to gently wean ourselves off the immediate hit of workarounds and short-cuts and it’ll-do-for-now-until-we-fix-this-properly software and even entire systems. We quickly become habituated to, if not formally addicted, to temporary patches or informal ways of working, making it harder to shift to better-designed, more sustainable things thereafter. Indeed, sometimes the temporary tools make the development of better things technically and culturally harder — path dependency and all that. None of this is original, and there’s an entire PhD to be written on this in regards to digital and data systems. but for now my head is buzzing with far more questions than answers.
Prime directive
When I used that metaphor, I quickly followed it with the Prime Directive from agile management: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
I did so because I didn’t want to imply that my colleagues are unwilling to kick bad habits, or that the habits were necessarily bad at the time they took hold — my team’s been working under incredible pressure at a daft pace, so needed to be pragmatic. They absolutely did their best and then some. I reflected that I need to find better ways to offer new avenues and be supportive of better ways of working, without appearing to trash the here and now.
Other things I learnt this week
- I had some great chats this week, with colleagues in my new team about future-facing big picture things, and with former colleagues about well more or less the same. These conversations brought home the extent to which I get my energy from those I share a worldview with. It also left me wishing for more hours in the day to do ALL THE THINGS.
- At a workshop on systems change, I was inspired by looking again at the language of hope, and transformation, and leadership: but left scratching my head at how such things can be applied practically in a time of seemingly perpetual crisis. Akin to the urgent/important discussion above, how does one design a plane while simultaneously building, flying, steering, and landing the self same plane?
- Collaboration is hard! It’s harder in distributed teams, all working remotely, facing competing demands and expectations. Being the pivot around which teams collaborate can be exhausting, but really rewarding if it pulls off. Here’s hoping ;-)
- I can’t/won’t write a review of 2020. I’ll stick to reading reviews by friends such as Dan and Sam, and find another way to reflect.
