Placing bets, Working on the work & The cost of re-design
What’s the opposite of deep work?
Broad work? Shallow work? Whatever it is, that’s what I feel like I’m doing at the moment. Lots of things going on at the same time, very much by necessity, but the trade-off is not being able to zoom in or out too much.
I feel this works well in some cases (trust colleagues closest to the work to know how best to move things forward) and not so well in others (someone needs help but I need more detail/context to first figure out how).
Working on how we do the work
There are two particular things that I’d like to be working toward at the moment…
- Working in an agile manner (where appropriate).
- Defining and incorporating user needs into our work.
There’s lots going on (as mentioned above) so rather than wait around for the ‘perfect conditions’ to put these things into practice, I’m trying to find opportunities to incorporate these ways of working into what we’re doing now.
As a team, we’ve been doing a bit of this already in a granular fashion which is great. Where I feel I could be doing better is being more explicit about the ‘why’. For example.. why would you sketch something out on paper with people versus gathering requirements and building it directly in the application.
Placing bets versus planning
I really enjoyed this post on building to learn by Gareth Reese.
Knowing if you’re doing the right thing can be really hard when operating in complexity. I strongly identify with this at the moment as we work our way through technical debt.
You might have some inkling of some of stuff you should definitely avoid doing based on previous experience, but what about the mistakes you’ve not yet made? How can you accurately predict them? The answer is… you can’t! No amount of analysis up front is likely to save you from doing the wrong thing.
A complex problem requires a series of probing steps and analysis of feedback to fumble your way towards the goal.
Gareth Reese
Planning is easy when you’re dealing with predictable or knowable things because the steps toward the intended outcome are clear. As the steps and the outcome get fuzzier, anytime someone says ‘plan’, we should really use the word ‘bet’ or ‘guess’.
The change of language is important because it would make it more explicit when we’re trying things out without yet having complete confidence in the outcome, or even that it’s a desireable outcome.
Anyway, I won’t ramble on about this too much, because Gareth does a much better job of explaining this. I urge you to read his blog post.
On this week’s WB40 podcast, Matt Ballantine mentioned that our classic response to complexity is to try and break it down into smaller complicated peices so that we can apply processes to it. That may feel more comfortable, but ultimately it will actually makes things worse and more fragmented.
Noreen Blanluet put this really succintly…
I really like that point about focusing on people and relationships rather than processes. As a techie, my bias is to try and strip back, simplify and figure out a repeatable process. It’s taken most of the latter half of my working life to realise that people are a fairly vital part of the system (duh!) and that some complexity is an inherent feature, not something that can be designed out.
It got me thinking about the broader question of how we might better acknowledge when we’re working in a complex space so that we don’t try and treat it as a complicated or obvious? Also, how might we reshape the way we work so that we can try lots of small, low risk, reversable ideas up front before getting too comitted? (Shout out to Trojan Mice!)
Too costly to re-design
I was reading this post about how aerodynamics are designed on F1 cars. This passage of text caught my eye…
“In reality, some decisions we face as F1 car designers are just too complex to be taken back to first principles and investigated. Teams simply don’t have the time or resources to assess them fully.”
So, the gist is… people copy bits of design from the most successful teams because they don’t have the time and resources to do this themselves. But the downside is, teams might not truly understand how the thing they’re copying works and what the impact will be when they start including their own bits of design.
I wondered if this might apply elsewhere. For example, the work that we do on modernising services. This example doesn’t map directly, but it does in terms of capability being at different levels of maturity in different teams/organisations.
In the public sector, copying or sharing is to be encouraged as it helps distribute good design for others to use, but is there a danger that the understanding of the thing being copied doesn’t transfer nearly as well? Does it matter? (suspected answer.. it depends)
Experiment — Intentions THEN email
Every morning around 9 am, our team put their intentions for the day in our Slack channel.
“Today I’m working on..”
I’ve found that this process goes a lot smoother if I resist the temptation to open my inbox before I’ve first constructed my intentions list. This ensures that my list is driven by looking at what bits of work need moving along versus reacting to whatever pops up in email.
So, this week I’m going to keep my inbox closed until intentions are set, and only then see if there’s anything that needs to be re-prioritised based on the contents of emails.