Week 7
Weeknotes
November 23, 2018
Week 6
Template for an Area Strategy 
Template for an initiative
November 16, 2018
Week 5
Naming things is hard. All the difficulty I had this week was because we share similar names for close-but-not-the-same things. Also: vision and mission are a very tricky concept for a fractal org structure, each level of abstraction in the organisation needs a vision/mission/purpose but the nesting can get tricky to wrap your head around, particularly when the default model tends towards the hierarchical (ie. someone further up sets the vision, a middle layer makes that into missions/strategy and then the grunts execute.
Good progress though, driven mostly by a a fear of not making enough of it. Standard for me.
Area view 
Product function view 
Bootstrapping and then onward view
November 9, 2018
Week 4
OKRs are doing my head in, and they’re confusing everyone.
Me trying to understand how OKRs cascade through organisational layers
My reading is that the objectives should be co-created (eg. between Product leadership and the Area teams within Product). Those objectives are then discussed more deeply with the people who are on the hook for meeting them to identify the tactics/bets/missions that could be undertaken and what the outcomes (key results) look like.
Doing it this way means the OKRs are co-created and grounded in the reality the teams are in; hopefully creating stretching but not impossible work.
OKRs teams goals
November 2, 2018
Week 3
Less progress this week than I’d hoped. A few of the area teams (these are the groups of teams that broadly/nearly align to the significant steps in our customer journey) have been working on trying to identify their area’s missions. It’s created a lot of confusion, and some frustration.
Confusion
The framework we’d created was intended to help delivery teams identify the work they needed to do to ensure they were helping move the business to where it needs to be to meet the needs of our customers. So what Kuldeep and I have been focussing on is taking all the various high-level goals/OKRs/strategy papers and working out how they all connect. Right now, there are a lot of different things that a team could aim for - so many in fact that just about anything is possible - so we’re not as clear as we could be about what’s important to us as a business.
[insert picture of the wall here]
The use of vision and mission as terms are what seem to be causing the most confusion: at different levels in the organisation these are articulated for the whole business, for a business unit, for an area team, and now potentially for mission teams. Overlay that with the cascade of OKRs then there’s a lot of room for confusion, and I think that’s what we’re seeing.
I suspect that we need to simplify the language, and focus on using the OKRs rather than vision/mission. Perhaps it’s as simple as getting the Areas to identify the Objectives for their teams, rather than the missions.
Frustration
The frustration is mine. I’m trying to remind myself that this is change, and change is hard. In terms of the reorg, we’ve now got 28 autonomous delivery teams who need to start forming and working together as one team. We’re trying to get rid of the idea of design being a phase in the product development process and replacing it with design being a necessary input into building great products. That means abandoning the idea of ‘design up front’ in favour of designers working in the team to move the product towards goodness.
“Start together, work together, finish together”
What that means in practice is that we stop trying to design large swathes and states of the experience on paper, or as prototypes and start releasing little and often. I can sense the nervousness about this, and I understand it - it pushes everyone’s focus onto the actual product that is being used by customers right now rather than a speculative view of the product as it might be at some future date.
Being able to show a mock-up of a possible future state for your product is reassuring for teams and for stakeholders but it’s invisible to customers - and if we’re honest, these mock-ups only rarely make it into customer’s hands. What I’m asking the teams to do is to shift their efforts away from envisioning step-changes for products as they might be, and towards constant, imperceptible improvements on the products customers use today.
October 26, 2018
Missions
team structures
design
designers
Week 2
Great week. Lots of fun stuff happening now we’ve moved past the initial reorg and are now starting to get into the real challenge: how do we want to behave as teams, how do we want to work. My current plan is to keep the focus here, at the team level, and use the fact that everyone is receptive, listening and looking around to see what others are up to.
Lessons of the week
- Walls are amazing. It’s so easy to forget the power of a wall full of half-arsed notes and thoughts. As ever I’m indebted to Kuldeep for reminding me of the simple power of getting your stuff out where people can see it. He started the ball rolling by taking a load of the product process framework we’d been kicking around in a Google doc1 and put it up on the wall. The amount of people who’ve come up and asked questions, or been directed by others to come and see/review/feedback is exhilarating and making the whole thing better and better by the hour.
- Magic happens when you get people of different skills working together on a thing at the same time. Small version of this has been how we’re pulling people from service design, research and product into (finally) setting our way to document the experience our customers have - we didn’t start with polite meetings and alignement sessions, we just grabbed people and pulled them in to help on something interesting and important. Come back next week to see if we can hold the momentum on this…
- The inner game I’m playing is now clear: I need to get the teams (of PO, engineers, designers, researchers and so on) working together on a thing at the same time. This means closing the gap between the team’s intent and the experience the customer has - it needs to be as close to simultaneous as possible for us to get the feedback we need to improve our explanations about our customers and their behaviour (and so build better iterations of our products).
Next week I’ll start putting up some pictures here and showing what we’re doing. It’d be good to be able to come back to this.
Self-praise
I wrote a sentence that summed up the last point - the thing that loses a lot of design teams is they thing that their job is to create the specifications of the thing that needs to be built. I was tweeting in response to Josh Clark who is clearly a man after my own heart.
Design is how it works, it’s not the work of designers
So yeah - that.
Fuck me, Google docs are some kind of hell. I’ve moaned about this (and much else besides) on Twitter.↩