Weeknotes #270

Photo of the week:

This week I did:

Going down

This week’s main focus was on getting a coordinated and cohesive view of the upcoming work from all the teams that will be working on it at a lower level of detail. We did it mostly asynchronously (obviously) and involved four teams; Design, Content, Web development an CRM development. It was great to see our understanding of things change and settle as we work through questions that people bring up. Writing stuff down and diagramming it out helps us think through our solutions and lets others help us see the gaps. It’s important for the next stage where the teams will work on certain aspects independently.

Humane technology

I started the Foundation for Humane Technology course and it’s given me so much to think about. I’m already considering the product decisions I’ve made at work in light of some of the things I’ve learned and it’s definitely given me a different perspective on the whole Twitter audience building thing.

September retro and October planning

As it’s the end of the moth I did my monthly retro to look back at how well I did in achieving the work I said I wanted to do at the start of the month. I also did some planning for October but feel like my lack of focus (see below) is preventing me from getting to a good plan about what I want to do in October, so I’ll come back to them soon.

I read/watched/listened this week to:

Uncertainty is closer to reality

In this video about why saying “I don’t know” is important for success, Annie Duke explains how false certainty leads to problems whereas embracing uncertainty is closer to reality as we don’t know what will happen in the future, and how we conflate false certainty and confidence in unhelpful ways.

A Problem Well-Stated Is Half-Solved

The podcast by the Center for Humane Technology talks about the meta-crisis of solving the problem with problem solving. That the way we solve short-term problems often leads to unintended externalities and this podcast does a great job of showing that we need a better way of understanding and solving problems.

Focusing on product outcomes will shift you to a product mindset

This post by Jeff Patton explains how technology development and product teams continue to have the majority of their focus on outcomes, and how difficult it is for teams to own the outcomes of the customer.

And thought about:

Out of focus

This week, and the last few weeks, I’ve been floundering a bit with my focus. I know it’s a reaction to finishing my masters, which I was very focused on over the last few months. I haven’t yet figured out what I want to spend my time and energy on so I’ve been bouncing around but trying to test out new projects and coming up with new ideas. I think this is because I struggle to connect those new ideas to my goals, so either I should use the goal as a means of deciding whether to pursue the idea or expand my goals.

The language of async

If badly run synchronous meetings are bad, then badly organised asynchronous communication will also be bad. Documents and diagrams need a standardised and agreed language to help everyone read them. Documents need information architecture. Diagrams need keys. The difference between diagrams and maps needs to be understood.

Next week I’m going to:

On the to do list

Get closer to finishing the solution design phase of a project I’ve been working. I don’t think it’ll be quite finished next week, but it should be very close.

Complete at least three modules from the Humane Technology course.

Figuring out which projects I should spend some time on.

Go for a run.