Weeknotes #162
Team health and renewing energy
A big focus for my thinking this week has been around team health, and how it is affected by the culture and atmosphere they work in. There isn’t much of a team, we’re individuals working on separate products, each facing our own difficulties alone. Given that there is no future for the way we work now, and that they are going to have to learn how to pull together as a cohesive team to deliver our new product, and that this will only happen if we can improve the team health, then we have a challenge ahead of us.
My hope is that us working together on our new product can be the vehicle for creating a healthier team made up of diverse individuals who appreciate each other’s differences (as a counter to the conformity pressures) and have a broad range of skills that enable them complement each other in to doing good work that focuses on delivering value for our clients and the organisation. This takes me back to my previous conception of what I need to achieve with the Product Managers, that rather than building a team that works together in the usual/cross-functional ‘product’ way, instead they are a team that takes their skills out into other departments of the organisation in a almost ‘consultative’ model. It’s about creating a space of safety and good practice that they ‘come home to’ in order to recharge before going out again to deal with challenging situations. I also think the stability of a sense of ‘team home’ will help them with leveling up the work they do on our new product as it will involve a lot of going out of their comfort zone.
From market research to machine interpretable
We reviewed the initial finding of some recently undertaken research to help us understand customer needs and whether they want us to fix them. One of the key insights was to ‘What customer do with Standards. It seems than none of the customer’s surveyed use the Standards as they are published, all go through a process of interpreting and adapting the contents of the Standard to fit their needs.
This leads to questions about whether we should be trying to understand how our customers. Some customers want to do that for themselves as they have experts that have built a career around their knowledge and ability to interpret Standards for their business. Some people at BSI believe that customer use cases for Standards are so unique and bespoke that it isn’t possible to do this
The research identified two broad use cases of interpreting and adapting for two different types of Standards. Technical standards were used to create test methods, and quality management Standards were used to create training. Both cases use the Standard as a measured threshold to answer definitively whether a test is a pass of fail or whether
So I wondered how we might go about creating a system that could interpret and adapt a Standard for a particular use case, in this example to create a training course. I picked ‘BS ISO 56002 – Innovation Management’ because its something I’m interested in. The document is written by humans to be read by humans, but I noticed was how structured it was. The document has lots of titles, short paragraphs, and lists. This structuring lends itself to a schema that can be overlaid in much the same way as machine learning can interpret voice for Alexa, Google Home, etc.
There is an avenue of thinking at BSI about this interpreting and adapting which we could call the ‘Verb approach’ where we describe each clause in terms of an action it requests of the user, e.g. monitoring, reviewing or determining. If a computer can read a sentence of text, look for those verbs, and then tag that sentence, it can begin to develop an ‘understanding’ of the intent of that sentence.
Intents include:
- Amend – Make minor changes to reflect changing circumstances. (Synonyms: revise, alter, change, modify, qualify, adapt, adjust; edit, rewrite.)
- Analyse – Perform a methodical and detailed examination. (Synonyms: examine, inspect, survey, scan, study, scrutinize, peruse; search, investigate, explore, probe, research.)
- Determine – Cause something to occur in a particular way. (Synonyms: control, decide, regulate, direct, rule, dictate, govern, condition, form, shape.)
- Monitor – Observe and check the progress or quality of (something) over a period of time. (Synonyms: observe, watch, check, scan, examine, study, record, note, oversee, supervise.)
- Review – A formal assessment of something with the intention of instituting change if necessary. (Synonyms: analysis, evaluation, assessment, appraisal, examination, investigation, scrutiny, inquiry, exploration, probe, inspection, study, audit.)
In addition to “Intent”, conversational interpretation also includes the concepts of “Entities” such as organisations, partners, shareholders, “Contexts” such as leadership and responsibility, and “Events” which are triggers from outside the Standard we’re dealing with, which for us could be an update to a normatively referenced Standard.
As and when I get time I’m going to continue to explore how I could map a Standard using this conversational machine learning framework so that a Standard can be interpreted. Then the next step will be thinking about how to understand the contexts organisations want to use that interpreted Standard in so that an adapted output can be produced.
Go-to tools
I’ve been doing some work on roadmaps which has helped concrete my thinking a little about what roadmaps are for, how to structure them, how to make them useful for the team, and how to use them to communicate various things about our work.
I used to go in search of the one perfect roadmap that would mean everything to everyone. It could be used by directors to see the themes and directions, by sales to drive go-to-market strategies, and by developers to know what customer problems we’re trying to solve and so what to build next.
I realise now the idealistic naivety I had around roadmaps. They aren’t the guiding light for teams I was hoping for. They are a tool to do a job. And if you have more than one job to do it’s likely you’ll need different roadmaps (or different views of what is essentially the same roadmap) to accomplish those jobs. Roadmaps are a tool, and the tool needs to fit the job. Perfectly beautiful roadmaps that serve all needs at all levels don’t exist.
Puzzle pieces
This week the Product team spent some time together working on how each of the puzzle pieces (AKA features) that we are working on individually fit together to create a single cohesive picture.
For the new product we’re building we started with the PM’s creating a list of features as that is easily within their comfort zone, but now we’re beginning to group the features into capabilities, have each PM take ownership of some capabilities and figure out how to make all those features work together. I’ve also been working on hypothesizing our personas for this product and modelling the account subscriptions.
Building a new product in this kind of conceptual way is really interesting but we struggle with pace and focus because we’re so distracted by all the other ‘day job’ work that we have to do. I’m not sure there is anything I can do about that other than keep looking for opportunities to work on the new product.