Weeknotes
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.