Foundations of Humane Technology: the course all product managers should take

The Center for Human Technology offers an online course aimed at people working in tech to encourage us to consider how we can make technologies more humane.

Foundations of Humane Technology will prepare product teams to create technology that treats attention and intention as sacred, protects well-being, minimizes unforeseen consequences, and ultimately builds our collective capacity to address the most urgent challenges facing humanity.

It’s easy to tell ourselves that if we don’t work on large scale social platforms that our products have no means to cause harm and so we don’t need to think about these things, but in fact unless we understand and amplify the message that all technology should be humane, how can we ever make any technology better?

The course consists of eight self-paced modules.

  • Setting the Stage – What challenges define this moment in history and how can the technology we build help to address them?
  • Creating Shared Understanding – How can technology engender the trust and understanding we need to solve complex problems together?
  • Respecting Human Nature – How can technology work in harmony with the vulnerabilities and biases with which all humans have evolved?
  • Narrowing the Gap – How can technology address inequity and practically integrate voices of people who experience harm?
  • Minimizing Harmful Consequences – What economic forces affect products, and how can product teams help address and reduce harmful externalities?
  • Helping People Thrive – How can products help people act in alignment with their deeper intentions, rather than optimizing for engagement?
  • Centering Values – How do the conditions of our lives shape our values? How might product development be informed by metrics but centered on values?
  • Ready To Act – How can we create a culture of humane technology inside of our workplaces and broader industry?

All product teams teams should do the course, ideally together so they can talk about the issues and ideas the course raises. If you’re interested, sign-up now.

Epictetus was wrong about control

Epictetus, the Greek Stoic philosopher, thought that all external events are beyond our control. But, he said, individuals are responsible for their own actions, which they can examine and control through rigorous self-discipline. And here lies the paradox. If you are in control of your own actions, that means you can choose to direct your time and energy at taking control of external events.

An example? External event: asteroid hitting planet earth. Taking control: become a planetary scientist and work at NASA’s Center for Near-Earth Object Studies to track comets and asteroids that pass close to the Earth.

Perhaps what Epictetus was really trying to say was that as individuals we can’t control all external events ourselves. So, that’s why we have civilisations and learn to work together, and have people that specialise and dedicate their life’s work to one thing, all so that as a species we can control more and more of the external events in our world.

Charity Service/Product Model Canvas – iteration 2

Charity Service Model Canvas – iteration 2

Users at the centre.

Understanding needs and problems on one side and outcomes on the other.

Acquisition and Solutions intersect the Users to show that equal consideration needs to be given to getting people using the product as building it.

Below the line of user interaction is Costs, Partners, Resources and Funding.

Doesn’t have Activities like iteration 1 did. Should it?

Weeknotes #278

Photo of the week:

Season’s greetings, by Banksy, ironically displayed within a shop.

On this week’s Done list:

Connecting concepts in systems

I’ve been working a lot this week on how different systems ‘conceptualise’ things and how those concepts move between systems with very different data structures as the data moves between them. The same ‘concept’ is defined in different ways and needs translation and common language between the systems. What constitutes the identity of a user in one system isn’t the same as in another, but it’s easy to miss the impact of the differences if you don’t dig into them.

Irregular Ideas

Sent out the thirteenth, fourteenth and fifteenth irregular ideas. I feel like my writing is getting a bit better with the constraints of talking about a specific idea, only having a few paragraphs to do so, and putting it in an email so I can’t change it later. It’s different to writing a blog post where I’m more likely to throw in lots of loosely connected things.

Future Skills

I worked on the first email for the Future Skills guided learning to try get the template right which will hopefully make writing the other nineteen emails quicker. I need to give it lots more time and get the emails written and set up so I can start marketing it. Of all my side-projects it feels like the one that has the most potential for actually meeting a need rather than just being of interest to me. I think it might still not be practical enough but until I get some people using it and get some feedback it’s all guesswork.

Systems-shifting product management

I set up a project page on my website and started to try to define systems-shifting product management, including the idea that product managers develop by learning how to increase their leverage rather than gaining influence and authority within the organisational hierarchy.

Stuff I read and listened to this week:

Public service product management

I listened to Tom Loosemore on ‘the product experience’ podcast talking about product management in the UK government. He talks about how part of product management is creating that space in organisations to do product management, that understanding user needs is do much harder then we think, especially in environments with messy and uncertain human behaviours and that joining up teams, channels, and solutions is essential for achieving the real outcomes for people.

Using maps

Simon Wilson, also on ‘the product experience’, talked about using mapping to know where we are and where we’re going. Mapping, and working in visual ways, are useful for bringing the users of a service forward into people’s thoughts. Maps help us understand the shape and scope of a problem, who it affects, how it affects the organisation. They show us a narrative and help us understand movement.

Decentralise decision-making

I read Jason Yip’s post about using doctrine to allow safe decentralised decision-making by establishing consistent decision logic. He writes/quotes, “Strategy doesn’t give employees enough guidance to know how to take action, and plans are too rigid to adapt to changing circumstances. In rapidly changing environments, you need doctrine to get closer to the ground. Doctrine creates the common framework of understanding inside of which individuals can make rapid decisions that are right for their circumstances… If strategy defines objectives, and plans prescribe behavior, then doctrine guides decisions.” Jason proposes an Agile doctrine:

  1. Reduce the distance between problems and problem-solvers
  2. Validate every step
  3. Take smaller steps
  4. Clean up as you go

There’s nothing much to disagree with, either the idea of a doctrine or the things Jason includes within the Agile doctrine. And I completely agree with the problem he’s trying to solve, how to bridge the gap between strategy and plans in a way that fits with modern good practice for cross-functional autonomous teams. The challenge, as always with these things, is the broad context they have to be conceived for and the narrowing of the context for them to be applied.

Three tech trends charities should know about

It’s great to see the emerging tech trends of metaverse and NFTs being talked about more within the charity sector. It’s always hard to start because the typical response is often cynicism and disdain (even from people who you’d expect to want to consider new technologies with an open mind) but given the increasing speed of change it’s even more important that charities do start to understand new tech. Broadly, I think there are three areas of impact new tech might have on a charity that bare some thinking about. The first is how it might affect the people that a charity is trying to help, e.g., gambling charities should definitely be keeping up with how metaverse games will affect gambling behaviour. The second is how new tech might affect the charities existing ways of doing things, e.g. social media fundraising, which to many fundraisers probably looks like just another channel. And then thirdly, how the new tech might disrupt charity business models, e.g., Decentralised Autonomous Organisations forming the basis for a new way of tackling a cause.

Thought about this week:

The discipline

Following on from product managers product managing product management, I’ve been thinking about the discipline of product management. I guess I use the term ‘discipline’ to mean a structure practice, almost like a martial art where the same moves are learned through repetition which means the practitioner can then put those moves together into sequences that work with each other and not against. This discipline and practice, if adopted, accepted, appreciated by an organisation, brings a balance of order and flexibility to how an organisation makes decisions about the products it develops and runs. It brings clarity to what’s important, and uses that to set focus. Perhaps one of the benefits of this discipline is making it easier to see when something breaks from the discipline and disrupts that clarity and focus.

Which way to work

My current side-projects include Systems-shifting Product Management, Irregular Ideas, Future Skills, and future.charity. Along with also doing online courses and writing blog posts (such as weeknotes), I feel like I’m not really making progress quickly enough on any of them so I’ve been trying to figure out the best way to work. I’ve scheduled time for each project one day a week to try to make progress on all of them at the same time, but I still continue to question whether it’s better to choose one project and set myself a bigger chunk of work to do over a few weeks before moving onto another. Before this scheduled approach I just picked whichever project I felt like working on that day, which gave me more flexibility to do easy work when my mind needed a rest and more complicated work when I was looking for more challenge, but lacked structure to get me to actually work on things I might not really want to.

My growth area for this week

Letting go

Definitely letting go. Still a challenge, probably always a challenge, but an important lesson to learn.

The future of sabotaging work

Every so often the OSS Simple Sabotage Manual on sabotaging workplaces gets shared on social media in return for a few knowing laughs about how it seems to describe the modern workplace. Its description of how saboteurs can slow the pace of work in an effort to hinder the production capabilities of the enemy parallels the bureaucratic work practices that we all love to hate. The implication? That companies sabotage themselves by working in the way they do. And so, if we could only just stop making decisions by committee and revisiting the same discussions and misunderstanding regulations then work could happen faster, and that would just be better.

Or maybe it wouldn’t be. Maybe slow work is better. Maybe the aspects of the future of work that no one talks about because they’re busy arguing over whether work should happen in offices or homes, is that Schumpeter’s legacy of innovation that relies on speed, on first-mover advantage, doesn’t fit the future of innovation we need. People and planet need an innovation that is paced, considered, connected, and intentionally so because it recognises the complexity of the world we live in and that nothing exists in isolation. The ’move fast and break things’ meme is the sabotage manual of the modern day.

Cyril Cal

A calendar that doesn’t let you choose how long the meeting should be, it starts with asking you to write an agenda and then estimates how long the meeting should take.

Weeknotes #277

This week I did:

Planning work for next year

I started doing some solution planning work for the next few months. It will hopefully bring together the strands of work that we’ve been building more recently. It’s like the plot reveals in a detective story where we can start to see why that decision was made back then and why we wanted to do this other thing that way.

More irregularites

Sent my third Irregular Ideas newsletter and got my fourth subscriber, but still have no clue about solving the feedback loop problem. The newsletter is supposed to be about sparking ideas together, but maybe my ideas don’t connect with other people’s, or maybe most people aren’t interested in ideas as a unit of value in the way I am. Maybe it needs a lot more subscribers and then a call-to-action to ascertain whether it’s solving that problem, but I think it’s probably just too amorphous a problem to measure in that way.

Human relationships

I caught a bit of the talk Andy Tabberer did called ‘Human side of delivery: forging relationships & building trust in a remote world’. It was good to learn a bit more about delivery management from the people side rather than practices. In a very simplistic and tactical way I’ve always seen delivery management as being about removing barriers for developers but I found the idea of ‘team health’ interesting and it made me think about what that might mean in different team contexts.

Future charity DAO

I’ve started doing a bit of research into how a DAO could be set up to run as a charity. There’s a lot to think about (that’s an understatement). There are barriers such as DAO’s aren’t a legal entity, and they rely on being able to codify the rules of the organisation, which is difficult when charity law is so messy. But there is also lots of interesting potential to explore for how each of the functions of charity might work in a tokenised system.

And I thought about:

Teams interfacing

I’ve been thinking about how difficult it is to conceive of and describe how different teams within the same organisation interface with each other. I think there’s a difference between teams interfacing with other teams and functions affecting teams, so for example the HR team manages the payroll function, but they aren’t interfacing with any other team as part of their work, payroll happens for all teams equally and so without any particular affect. Interfacing affects all those that interface. Some teams have clearly defined roles, responsibilities and practices, and I wonder if when they interface with teams that are less well defined, that their ‘harder’ boundary is more likely to push the more flexible team out of shape. How teams interface, and the shifting interplay of that interface, could be a systemic cause of friction or lubrication. How well teams understand their place in the organisational systems, however implicit that understanding (because it’s not as easy to depict as an org chart) must also be important for working effectively. It isn’t as simple as saying, ‘this team’s role is to do x’, because that speaks of the team in isolation and not in relation to other teams. Maybe value chain mapping could help to see where and why teams interact, even if not quite how.

Flywheel business models interacting with each other

The usual flywheel business models, as described by the uber napkin drawing, show how different aspects of a business drive others and that growth comes from increasing the throughput of the flywheel. But that are always shown as closed systems, in isolation from any other systems they might interact with. I’ve been wondering if multiple flywheel business models might interact with each other in an eco-system of business models. The difference between flywheel and linear business models is that flywheels feedback into themselves whereas linear takes an input, processes it and outputs something of value. I haven’t yet thought of an example of flywheels interact, either to drive to flywheel or slow it, but I’ll keep thinking about it.

Second-order personas

I’m still thinking quite a lot about what systems-shifting product management might look like. One of the ideas I’m playing with to shift the focus off user-centred design and to achieve outcomes by causing changes in systems is to affect the people who affect people, or, to put it another way, work on second order personas. For example, if you wanted to improve the experience someone with disabilities has when interviewing for a job, you can provide them means for overcoming barriers (first-order persona) or you could provide employers (second-order personas) with the means to remove barriers and so change a part of the system.

Spectrum of approaches to problems

I’ve been thinking for a few weeks now about the two opposite ways of approaching problems; engineering thinking, which solves known problems with upfront design and results in repeatable solutions, and design thinking, which solves less certain problems by uncovering the way forward step-by-step and results in more unique solutions. In thinking about critiques of these approaches it occurred to me that the design thinking approach could be seen as ‘throwing mud at the wall to see what sticks’. It then occurred to me that uncoordinated haphazard attempts to solve problems might actually be an entirely different approach, which then places all three on a spectrum from unplanned to planned with the design thinking approach somewhere in the middle.

And this week I read:

World Building

World Building is about story-telling. But it’s about more than that. It’s about how everything connects with a purpose in a coherent way to create the story that exists when it isn’t being told. This is an inspiring idea. In thinking about a portfolio of products all centred around similar problems and users, the world we build shows all who enter it how things are now, where we’re going, and why it’s the right place to go.

Trojan mice

On the theme of lots of small solutions being better for approaching complex problems than big single solutions, What’s the pont’s post about Trojan Mice as safe-to-fail probes into complex situations to gather data and make sense, is really interesting. I’m not sure I fully understand what the post is saying as it seems to be talking about replacing Trojan Horse projects with Trojan mice, but they serve very different purposes and so couldn’t be direct replacements, but it’s useful to think about how we might send . And to throw in another thought, clockwork mice behave in predictable ways but might collide in interesting and unexpected ways. Something to consider for multiple safe-to-fail probes.

The narrative on charity overhead

This is an interesting post about charities position on the narrative about the overhead costs charity’s have on many levels. I wonder where justifying low percentage of overhead as a good thing started. Was it in response to a genuine problem or hype and moral panic? As the post says, those charities that spend most of their money on what would be considered overhead, because of the type of work they do, become disadvantaged by that narrative pushed by the charities that don’t spend in that way. The specifics of overhead aside, it raises interesting questions about where charities draw the line in being competitive or collaborative. In what circumstances is it ok for a charity to do what’s best for itself rather than what might be good for the sector? And when should a single charity disregard it’s own best interests in favour of the sector benefiting more generally? If a charity makes a choice that results in it having less funding and so being less able to achieve its objectives, isn’t that bad for the sector as a whole? It’s a complex issue.

My growth area this week:

Recognising the ask

I’ve been thinking about ways in which we ask for help when we don’t know how to ask for help, or don’t realise that we want help. Maybe it relies on other people recognising changes in behaviour, but sometimes there just isn’t any way to help.

What good product management in charities looks like

I don’t have the answer. But I’m pretty sure that it is rooted in compassion, kindness, integrity, justice and inclusiveness before it even thinks about product practices or applying them in the context of a charity. That’s the hard stuff to get right. Without that it’s easy to go astray and with that the rest of it looks easy.