Weeknotes 298

This week I did:

Delivery planning system

I created a delivery planning system to help us organise our work better. It uses four factors; impact, dependency, capacity, and timing to order work. Next week I’m going to prototype it with the team and look for scenarios where it doesn’t work before we use it to propose a new roadmap for our product and service development.

Quick guide to QR codes

I finally finished a short blog post that provides some info on using QR codes, mostly for small charities.

Choice?

This week’s Irregular Ideas newsletter looks at free will and how the systems we interact with us to give us no choice.

What made modern work?

As part of my research into Magix Teams I found out that the first cross-functional teams was in 1950, even though it seems like such a modern, digital idea of how to organise a team. That sparked my interest in what things have shaped modern work. So I bought the domain name timelineofmodern.work and started setting up the first iteration of a timeline from the 1950’s to the present day (postmodern era) with cultural changes, technological inventions, important events, etc., that have affected how we think about modern knowledge work. The timeline is still very empty at the moment but as I add to it I’m hoping it’ll reveal some interesting ideas about why work is the way it is.

And I read:

Headless Brands

The idea of headless brands feels really current and on the decentralisation trend, and the depth of research and thinking by Other Internet is very cool.

Universal Barriers

A colleague shared the Cabinet Office’s presentation on creating a framework of ‘universal barriers’. I love the idea of approaching inclusion from a perspective that moves the narrative from ‘some people having accessibility needs’ to ‘everyone faces barriers in using services’.

Levels of Design Ethics

Nate Schloesser’s Levels of Design Ethics has a very posthuman, systems-shifting, flavour about it. It adhere’s to user-centredness at the micro level but talks about how designers need to think about systems at the macro level. It’s interesting to think about whether those things can fit together in the cascading way Nate describes or whether they are mutually exclusive.

And thought about:

Person-centred product management vs posthumanism in product management

I’m trying to figure out whether my thoughts about a person-centred approach to product management (basically, replacing the framework -heavy focus with skills that allow PM’s to thinking robustly for themselves in their context) and how posthumanist perspectives fit into product management (where technology and people are regarded in more equal ways) are at odds or not.

Boundary objects

I’ve been thinking about boundary objects. The term comes from sociology and is “information used in different ways by different communities for collaborative work through scales. They are plastic, interpreted differently across communities but with enough immutable content to maintain integrity.” I think of boundary objects as artefacts that translate ideas between domains. A user story is a boundary object, it allows information from the user’s domain or experience to be interpreted by a developer

High confidence teams

I prefer the term ‘high confidence teams’ rather than ‘high performing teams’ as it seems like a more well-rounded way to describe teams. The height of confidence in ‘high confidence teams’ is where the teams sense of confidence in itself and the confidence those outside the team have in it, are the same. This is basically, how to avoid the Dunning-Kruger effect for teams by comparing confidence. As to how to do the comparison, not idea yet…

Catchphrase comms

One of the best ideas I’ve found in the book Digital Transformation at Scale is that of ‘catchphrase comms’, of using internet meme mechanics to spread messages from and around organisations. It’s something I want to try out with more focus on the ‘work openly, reflect regularly, learn generously’ advice we’re including as we help teams manage projects better.

Control or understanding

A quick chat turned into impromptu user research with an electrician and builder about how their work is managed by the office. My reflection is that we criticise things we don’t understand and don’t control, and so if you can’t increase the control someone has you should try to increase their understanding.

People over processes

This tweet by GeePaw Hill made me think about how we uoften start out by thinking that creating processes for people to follow is the most efficient and effective way to manage work, but eventually, with experience, we learn that creating connection between people and allowing them to figure things out between themselves is far superior.