Weeknote #160
One yes or one no
All it takes is one ‘no’ to stop an idea. What if all took was one ‘yes’ to start an idea?
I listened to a talk between Simon Sinek and Tony Hsieh, Zappos CEO, and one of the things they mentioned was about how permission for work happens. Where work requires permission it usually also requires consensus, which means everyone has to say ‘yes’ and one ‘no’ can stop the work. This is the risk averse approach. It’s slow and careful and shares responsibility among all the people who say yes.
Shifting to one ‘yes’ to start the work is undoubtedly faster, but it relies on lots of new and different things like decentralised leadership, and comes with an increased risk of lots more things failing, which isn’t a bad thing if the organisational culture is one that accepts that.
The reason this is interesting to me is because an organisation’s approach to decision-making is one of those overlooked underlying aspects of digital and/or agile transformation. I think the reason so much organisational change and transformation fails is because it tries to use the same old approach to things like leadership and decision-making and only change superficial things like the technology an organisation uses. As we’re going through a change of our value proposition that involves building a new product using new methods but underpinned by all the same old leadership thinking, decision-making, HR, finance, etc., I wonder what chance we have of succeeding.
Team of the future
My awareness of the culture of conformity and consensus reached a new depths as I was given direction to prioritise highly visible work over the highest value work, reporting and project management over strategic thinking, creativity and flexibility, and politiking over commercial acumen.
I’ve restarted working on my ideas about what a modern agile product “team of the future” could and should be; multi-disciplinary generalists focused on problems and taking responsibility for it’s own recruitment, finance, etc. But maybe, given the culture of actively avoiding things like team diversity, this isn’t the best place to build that team.
Hyper-specific Context Standards Ontologies
I’ve been thinking about the disconnect between supply and demand in our Standards business. Standards are written in an unbiased, context-free way, which gives them a certain amount of independence and authority, but it makes the application of what is written in the standard much harder to implement. We think this application of the info in a Standard is the biggest problem our customers face. They need to understand how to apply that info to their unique business, but we aren’t able to meet that demand because we supply fixed documents that we have no control over.
So, in attempting to solve that problem perhaps we can find another way to meet the demand. In its simplest form my idea is that the client business provides the information about their specific context which is fed into an ontology system that matches the relationship between the business’ unique context and the information in whichever standard(s) apply. Ontologies are also great for tackling the problem of interoperability between standards from different publishers, so it becomes possible to create a standard for Standards and use it to support businesses in a way that more closely matches the customer’s demand.
What is Product Ops?
There was an interesting discussion on Twitter about Product Ops. Some said there is no such thing, that it is just part of product management, whilst others associated things like handling support queries, reporting, tool admin, responding to technical incidents, etc. as Product Ops (basically, all the human interactions that keep a product going).
It makes sense to me that Product Ops is a different but connected thing to Product Management. And it raises the ownership questions. Should Product Ops be separate from Product Management, or should it be managed by a separate role, perhaps the Product Owner, or should the concept of Product Ops be owned across various teams and departments?
It seems connected to the question: What’s the difference between a Product Manager and a Product Owner? If the ‘product’ is the interface between the organisation and customer, then perhaps the two roles intersect through that interface. So, perhaps the Product Manager passes value through the interface from the customer side into the organisation and the Product Owner passes value from the organisation side to the customer. This gives them a ‘external/internal’ split, which might be useful in .
There’s lots to think about around how to structure Product teams in ways that work effectively for their particular context.
Process improvement experiments
I’m starting to raise the profile of the ‘discover, define, develop, deliver’ process to help create greater balance in our product work. We’ve used them as headings for our new not-really-kanban wall, and I’ve been adding to our playbook to help provide guidance on how to know if a piece of work has reached the definition of done for . Visualising the work in this way is a step in the right direction but we’re still a long way from using other kanban concepts like limiting work in progress and pulling the work rather than pushing it through.
This wall, along with our Planner board, are experiments in improving the ways we work. Each tool/technique used in an experiment comes with benefits and challenges, not least of which is adoption, but if both of these are about communicating that we want to experiment with ways to improve our working, then that alone is a good thing. The greatest challenge with these kinds of things is always that in order to work effectively there needs to be a mindset shift from people, not just a toolset shift. That is the difficult thing. It would be difficult anywhere, but I think it’ll definitely be difficult here.