Weeknotes #156
Testing perimeters
I’ve been thinking a lot about the idea of perimeters this week. In this context, a perimeter is the farthest allowable reach within a team, department, directorate, organisation, industry or society. It’s the limit for things like which opportunities you are able to explore. It’s what is considered acceptable, by yourself and others, given the point you are currently standing at. It’s the line you aren’t allowed to cross.
So, I’ve been asking myself, “What perimeters exist for teams and individuals? Where are the perimeters of my influence? How far out does my influence extend? What things can I affect? How can I extend my perimeters? What if I extend too far, am I likely to lose focus on the nearer things?What areas of the business can I watch but not influence?”.
And I tried a few experiments to help me test my perimeters:
- I presented at a Labs scoring session to suggest my idea to take the BSI’s approach to developing a best practice into a consumer market. There are lots of parallel propositions and offerings around this but essentially its about providing “How to guides’ for anything where there is a clear process for how to do. Moving from being a B2B aggregator business to a B2C business that publishes it’s own intellectual property is a considerable shift outside an organisational perimeter and my professional perimeter as coming up with ideas like this is outside the perimeter of my role.
- I went to a Release Retrospective. We all wrote postit notes to say what we thought went well, what didn’t go well, and what we could do better next time. There was some discussion, but when I asked what was going to happen to all our feedback the answer was that it will be put into a document. I asked how we were going to improve on things for next time, but it was clear that wasn’t the purpose of this retro. I decided to push out of the perimeter that says I’m not allowed to question how other teams work and suggest that for testing of the next release we could have everyone in the same room for half a day so that we could get answers to questions quickly and discuss the tests we were running. There were lots of excuses about why we couldn’t do this. Clearly I crossed the line with my radical suggestion.
Some perimeters are quite explicit whilst others are very implicit, but I think it is how we conceptualise these perimeters that creates the dreaded silos, and that organisational structure isn’t entirely to blame (or, at least, it is but only because it is a bunch of perimeters itself, it isn’t the underlying problem). It’s what we think and do that reinforces or crosses these perimeters. It’s a ‘culture eats strategy for breakfast’ thing. A strategic goal might be to work more collaboratively but the culture of perimeters wins and prevents achieving it. I wonder if there is a way to map it.
This train of thought is still full of ambiguity for me, but one thing I’m certain of is that there is risk in staying within your perimeter (risk of complacency, slow or no progress) and risk from going beyond your perimeter (not achieving your set objectives or getting fired). How do you go far enough but not too far?
Low tolerance for failure
One of the impacts of close and inflexible perimeters is that they create a low tolerance for failure. Everyone knows that repercussions await anyone who crosses the line. The retro is a good example. The meeting was held because someone was told to hold it. Tick done. I bet the retros weren’t suggested by someone on the implementation team who wanted to improve how they work. And no one takes any action to make improvements following the retro. No improvement. No growth mindset. No learning. And partly/mostly because (I think) of perimeters that don’t allow people to fail in a safe way, which means the only way to be safe is to stick to the plan, do everything by the book, don’t deviate, and then if something goes wrong it wasn’t your fault.
So, the question for me is, “How do we ensure rigor and robustness in what we do (which in a traditional command-and-control style organisation would be through strict adherence to quality-controlled process) whilst giving product managers (and everyone else) the creative space (wider perimeters) to explore and develop their practice with 21st Century thinking around distributed and decentralised leadership, embracing uncertainty and variability, and optimising-for-consumption to deliver maximum value.
OKR’s and interoperability
There are three teams within the Product department, who all work on different things in different ways. So, starting with the assumption that we want to show the rest of the organisation that a Product function has value for the organisation, that Product is a cohesive team, and that the work we do as individuals is good work, then a) all of those things need to be true, and b) there needs to be a certain amount of interoperability between the teams.
For teams to have interoperability there needs to be common understanding about what each other does, shared vocabulary so terms always mean the same thing, and shared goals that everyone contributes to achieving. For OKR’s to be the right mechanism for aligning the teams around achieving shared objectives, I think it makes a big difference how there are arranged.
Given the mindset of different teams, it seems easy to organise the OKR’s around asking each team to set their own Objectives and the individuals to set Key Results that are concerned with their team’s work. But this means that the first point at which there is shared commonality of what we’re trying to achieve is at the Strategic Goal level. Which means the three product teams are no more aligned than three teams for three completely different departments.
Perhaps a better way would be for there to be department level objectives that each individual, regardless of team, sets Key Results to show how they are going to contribute to the shared Objective. This aligns what the teams are trying to achieve at the earliest point of convergence. Either we achieve together or we all fail.
What measures we use, and how we measure, incentivises behaviour. At the moment there is a disconnect between the things we say we measure (using OKR’s) and the PM’s experience of being measured by other people they work with, who judge them on delivery. Delivery is important but it isn’t a fair measure for the PM’s as it is so reliant on lots of things and other people, and yet it’s the main incentiviser of behaviour. So, how do we change that? How do we make it so that PM’s have greater control, autonomy, and power over the direction their work goes?
There are so many ways round to consider the whole team measurement piece.
Connected to the OKR’s discussion, is an ongoing discussion about which tools we use to work in the open and share knowledge, and track and report on our work. The options include the usual Microsoft Planner, Aha, and Trello. One of the downsides of Trello is a lack of reporting capability so I built a quick bot that uses the Trello API to pull information from a board. I used my Life Roadmap board as a kind of proof of concept to see what kind of information I might be able get and how I might use it. ‘Roger’s Trello Reporting Bot’ just lists the names of lists and the cards on those lists, but it could be expanded to look at different boards, display the cards, count cards and labels, and report on the activity of the board. I wonder if there’s an opportunity for a product there.
Being induced
I spent a day with lots of other new starters at the Milton Keynes office for induction training.
The organisation’s strategic imperatives were described to us as a mesh with our business offerings (Knowledge Solution, Consultancy, Accreditation) on one axis and key sectors (Food, Healthcare, Aerospace) on the other axis. The value exchange occurs at the intersection of offer and sector. I get how this works for a hard-to-scale business model like consultancy where focus on being sector specialists is a big part of what sells the service into that sector, but I wonder how it works in a more scalable model such as Knowledge Solutions where aggregating information and providing it to clients requires being sector agnostic in order to get scale.
An insight I found interesting was that 85% of our clients don’t cross-purchase from us. If they bought training, they might buy more training, buy they’re unlikely to buy consultancy or use one of our products. Of course we recognise that up-selling is always easier that cross-selling, but other than that it makes complete sense to me that the majority of organisations only buy a single offering. If all of the offerings from the BSI ultimately solve the same problem (business improvement through standardisation) then why would an organisation buy two things to do the same job?
I was listening to a podcast on my way back and the phrase, “The magic of innovation happens at the intersection of different things” was used. It reminded me of how part of the genius of someone like Steve Jobs is that they are really good at synthesizing lots of other influences into a coherent and distinct new thing. They aren’t starting from scratch and creating something completely new (postmodernism pretty much destroyed that myth of the hero-artist-originator but perhaps it still exists a bit in innovation), they are finding intersection points between multiple things . It also fits what we’d been talking about earlier in the day, as to me it asks, “How can we innovate at each of those sections (and who would be allowed to do that (perimeters again))”, and “How do we innovate into sectors that aren’t a focus”.
There’s more thinking to be done about the ‘broad offer vs. specific solution’ in our product strategy.
Thought of the week
I wonder if “the culture of consensus” is an excuse for not taking responsibility and making decisions.
It came to me when someone was telling me yet again why one of the Product Managers couldn’t do something without getting permission from lots of stakeholders. I challenged them as to whether getting consensus applied at all levels including the lowest level of deciding to make a small change in their work, and whether if consensus was achieved at a higher goal level did that mean that people could then get one with doing what they need to do to achieve the goal. Of course there were no answers, as you’d expect from a culture things like that, but maybe the question is enough without an answer.
Question of the week for next week
The question I’m going to ask people next week is, “Why do we have a product function at BSI?”. I’m pretty sure people don’t do a lot of ‘challenging why’ thinking so I’m not expecting any profound or deep answers but I have my own view so if the question becomes a discussion I have my stance on why product functions exist in any organisation, so it would be good to see what others think of this.