Weeknotes 292

This week I did

Product practice

Thought a lot about what makes up a product practice. Fundamental to it is, I think, the goal of maximising the value of the product by focusing on solving problems. The problems give the practice focus and direction. An optimum practice would achieve maximum value for a product more quickly than a less optimum one.

Leadership in matrix teams

After a brief conversation on Twitter I wrote a quick blog post about the kind of leadership or management that might work well for matrix teams. Matrix teams could have a ‘convener’, someone who is probably in a senior role within the hierarchy of the organisation and so has the influence to bring people together, but who can then give over the responsibility of assigning and tracking the work to the team. There’s so much to think about in making matrix teams work effectively, they are so much more than just ‘a team that has people from different parts of an organisation’, things like Interdependence theory, which I’ve been trying to understand to see if it provides some sociological underpinning to matrix team interactions (which I think might be different to cross-functional teams because of the instability of membership).

The coordination problem

Sent another Irregular Ideas newsletter, this week talking about the problem of using technology for coordinating people to achieve bigger goals.

And I thought about

New knowledge creation

I think the modern knowledge economy has two categories of work; creating new knowledge and collating existing knowledge. Most of what we see on Twitter (as an example) is collating and spreading existing knowledge (often in an attempt to increase follower count). I’m not interested in that. I want to be exploring new ideas, which by their nature they aren’t easy to express in ways that encourage conversation. So then, what is the measure of success? How might I know where this kind of exploratory thinking might be going? Maybe it’s ok for it to not have a goal, even if that feels a little uncomfortable.

Goal setting and achieving

I think we separate ‘setting goals’ and ‘achieving goals’ too much. I think we could use what we learn in doing things to achieve the goal which help us refine the goal take the next steps towards it. Maybe a cyclical process like this:

  1. Set a goal
  2. Take a step towards achieving that goal
  3. Get feedback on whether that action took you closer to the goal
  4. Use feedback to refine goal and/or decide next step
  5. Go to 2, and repeat.

This approach means that rather than having a fixed goal to start with that is never reviewed, the goal is refined at each step so both the goal and the actions to achieve it change together. The faster you go through the cycle the more refined the goal becomes and the more likely that the steps are taking you towards it. Better than working to achieve a fixed which is either impossible or irrelevant goal.

Random thoughts of the week

Rogers’ diffusion of innovation concept leads us to think that being an early adopter is a trait of a certain type of person and so if they’re an early adopter of one thing are then they’re an early adopter of other things. I think it’s more likely that the early adopters of one thing become the laggards of another thing as they are tied to what they adopted. Wearing face masks might be an example. Those that were first to start using them will probably be the last to stop using them.

When we talk about alignment (on a project, strategically, of whatever) we often mean imply that it means everyone moving at the same pace, and therefore everyone has to move at the pace of the slowest. If different parts move at different paces then they become unaligned. And disalignment brings a whole load of problems.

If loosely coupled systems are more able to accept change, then loosely coupled teams working with loosely processes should be more able to accept more change. Designing a team or processes around being loosely coupled in order to handle change depends on knowing how much change is going to have to be dealt with, and the reason this type of design is so difficult to get right is because there isn’t a quantifiable, tangible measure of change. Things don’t change in centimetres or kilograms. Without that, we can sense that change has happened but not have the means to compare it to other change. Maybe this is why organisations attempt to design themselves in ways that don’t change, which makes changing even harder.

A thread running through all of these is how the ‘pace of change’ is so important.

Read this week:

Token-based products

My interest in web3 waxes and wanes, but this week I watched/listened/played with some web3 stuff: Ethereum Explained, Should I do a token? and Rabbithole. I’d really like to explore how web3 technologies can be used to create new types of charitable organisations that utilise tokenisation to manage activities and have impact. A token acts as a store of value, and plays a coordination and cooperation role within networks and communities by acting as a reward mechanism. That means that ownership of fungible and/or non-fungible tokens is a kind of codified social status, which could be a way to recognise ways people are contributing to a cause or outcome, from making a donation to sending a tweet, and then rewarding them within the community product.