Weeknotes 350
This week I did
Digital skills. And learning the error of my ways
Among lots of other things, I’ve been working on how we can improve people’s digital skills. It’s an interesting problem in a remote organisation because you need digital skills to improve your digital skills. A survey of 63 members of staff showed that most people are pretty confident with tools they use everyday, and that lots of people want more specialist support to learn more about tools specific to their role. In the middle, there is a large group who are not very confident about digital tools they don’t use very much. So, based on the survey results, the best solution would be to focus on the majority and improve their confidence in tools they use fairly regularly but not every day.
But then a conversation about the needs of the people who hadn’t taken the survey completely reversed my thinking. The same point had been said to me a few times but I hadn’t really got it, I didn’t grasp the impact of how we might leave behind those already left behind. Focusing on the majority isn’t always the best way to go. Sometimes, and most definitely in this case, we should focus most on those that need to most help. So, I need to completely rethink my approach to improving digital skills.
The technology charity
I think I’ve figured out how to make the technology charity book more interesting to anyone who isn’t me. I’m rewriting it as a story of how a small charity faces some challenges, starts to use technology to overcome them, and then goes on to become a “technology charity”. It’s completely fictional but based on experiences I’ve had working in charities. There are two main characters, one who represents the charity sector with all it’s risk aversion but desire for change, and the other represents the tech sector with it’s speed, scale and sometimes lack of consideration. How these two people figure out how to work together is the analogy for how charities figure out how to use technology to achieve impact at scale.
Retro and delivery plan
I did my retro for last month and planned what I want to work on this month. The lesson for the month was that too much work in progress means I don’t get much done, so I’m sticking my head in the sand about all my other projects so I can focus on writing the technology charity and buying a house.
I read:
Is agile radically different?
The people at Create Change think so. This post explores some of the friction between linear project processes and cyclical (or agile) project processes. It doesn’t really explain much about the differences between the two, but it offers some ideas on how to help the shift the using more agile processes. The first is to explain why it’s essential for the organisation to adopt agile methods, but the post doesn’t actually explain it. So here’s my quick explanation. The two biggest factors to product (and so organisation) success are whether someone will use that the org creates, and how quickly they start using it. Linear project processes start with an (often wrong) assumption about whether someone will use what is being built, and because they try to build the entire solution up front, take a long time before someone starts using it. It’s only then, after the project is finished, that the org learns that no one wants to use what they built. A cyclical project process starts with the same (often wrong) assumption but seeks to validate it with real users as quickly as possible, and use that learning to change what is being built so that people will want to use it.
Non-human personas
I’m getting quite into personas at the moment, and the idea of non-human personas is pretty posthumanist, which ticks my boxes. I can imagine an ecosystem map of personas with people, organisations, systems, etc., all interacting.
Why you can’t solve knowledge problems with information tools alone
With eighty percent of knowledge un-codified, undocumented, tacit knowledge in people’s heads, the idea that having information “all in one place” to make it easy to manage makes me shake my head at the lack of understanding of the problem.
And I thought about:
Work in progress
When you really get into it, managing work in progress is far more complicated than it seems. The glib advice of “reduce WIP” or “Stop starting, start finishing” is surface level, it doesn’t get into the cause of having too much work in progress and give any rationale as to why it’s better to reduce it.
A few thoughts that have occurred to me:
- You can’t really control WIP if you think managing workload and capacity is about keeping people busy. Until we can all embrace work being about ‘delivering value’ not ‘spending time’, there will always too much work in progress.
- With a focus on ‘delivering value’ comes the need to prioritise. That is really really hard. It’s creates the difficult question of who gets to choose what is most important. No one really knows what’s most important or most likely to achieve a particular outcome, no one knows how to reach that conclusion, it is ultimately unknowable. In that case, how can prioritisation ever be possible.
- The highest value work is the highest value, whether it’s internal team work, business as usual work, or new work. But no one knows what that is.
Until I feel like I understand the problem I can’t really figure out a solution. In the meantime, we’re experimenting with a few different ways to get more control over our time.
Tackling hate on social media is a lost cause
I’m coming to the conclusion that hate (racism, sexism, etc.) on large scale social media platforms is inevitable. Any system that allows people to do harm to others at scale (because they already hold certain positions of power and privilege) is inherently racist, and that’s before you even get to content moderation and user behaviour. Reducing scale seems like the only solution to me. Maybe, if every user on a social media platform was only allowed to connect with 100 other people, we wouldn’t see all of this.
Chatbots
Or conversational AI, as they are now known. I’ve been a long time lover of chatbots, and find it interesting that they haven’t really hit the mainstream. For lots of emerging tech, the barrier is finding the right use case but I think that’s a problem for chatbots. I don’t even think utility is the reason. Sure some can be pretty basic and have a high failure rate but that’s down to poor design and implementation rather than the utility of chatbots in general. I wonder if the thing that will give chatbots their boost is interoperability of platforms. When someone can start a conversation on a website, carry on later over email because they need to send some documents, and then add the chatbot to a Whatsapp group to finish the conversation, then they’ll become really useful. Whilst they are trapped in one-to-one conversations over a single platform, they’ll never reach full potential.