Map Camp 2019
I was lucky enough to attend Map Camp, and here’s my main highlights from some of the sessions I attended.
A brief introduction to Wardley Maps
Simon Wardley made his familiar point that maps are much better at strategy than SWOT diagrams.
Most things we talk about aren’t maps. For example, a business flow “map” isn’t a map; it’s a graph. Changing the position of components does not change the meaning.
In contrast, in a Wardley map movement has meaning. The y-axis starts with the user visible value, and flows downwards to the constituent parts. The x-axis tracks the evolution (from novel/genesis on the left through to commodity/utility on the right).
There’s a whole lot more to this, read Wardley Maps on Medium.
What’s the best move?
Andrew Clay Shafer (co-founder of Puppet) talked about learning organizations, chess and vomiting rainbows.
My main takeways are:
You must have a reason to learn something. It takes six months to be fluent in a language, but humans stop early because they learn what they need
The OODA loop requires context (an underlying model). Wardley Maps are an example of that underlying context
Successful mapping leads to a successful business. Not when you do more mapping! (those that say they are “agile” because they do 10 standups probably aren’t).
How often should you map? This depends on how often the environment changes (more frequent changes need more frequent sampling — see Nyquist-Shannon Theorem).
Open Source and Maps
Adrian Cockcroft (Netflix / Amazon) gave us an insight into the doctrine of Amazon.
Amazon has a strong doctrine (see Leadership Principles). The most important one is:
Customer Obsession — Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
If you ever want to understand the why of an Amazon product, you’ll eventually trace it back to an unmet need or an underserved market. You can use this to your advantage — if you want to influence AWS find a big customer and demonstrate they need whatever you want.
Amazon structure their teams according to product life cycle (see Pioneer/Settler/Planner or Explore/Expand/Extract or VC structures like seed, A-D rounds and public). We organize our teams using a similar model at Redgate.
Amazon use the ideas of value chain, but due to their origins they start with a PRFAQ (aka press release + frequently asked questions) rather than a Wardley Map. You can read more about the structure of these here.
To get a project approved, you need a six-pager (Jeff Bezos is a fan of a written narrative!).
Internally, Amazon isn’t organized around projects, they are organized around service teams. Each team has long-term product ownership, performs continuous delivery using DevOps and owns their technical debt. They are effectively run as mini-businesses with their own budget, headcount and are responsible for all operational aspects. Despite this, they’re small (~10 people or two pizzas).
Amazon emphasizes a learning culture. Adrian gave an example of the meeting schedule:
Monday
- Each team meets and reviews revenue, growth and progress towards goals
Tuesday
- Roll up — a representative from each team presents to the head of that particular group
Wednesday
- Operations meeting — All tech incidents reviewed, and one “lucky” team gets a deep dive (even open-sourced). This promotes a culture of learning from failure, and means everyone is prepared even if they don’t talk.
- Business level meeting — all goals reviewed, any customer feedback reviewed at Head of X level
This simple meeting structure gets everything known within the company very quickly.
Capability Profile Mapping
Emily Webber (who has visited Redgate in the past to talk about Communities of Practice), spoke about capability mapping.
Emily started with a very simple demonstration that people’s expertise depend on the context (e.g. if you are an expert product manager stand up, hardly anyone did. If a pay rise is coming soon, are you an expert? More people stood up!).
Some definitions:
- Skill → An ability someone can learn, develop and demonstrate (for example: Empathy or using Photoshop)
- Capability → Knowledge, Skills and Experience that generate an outcome
Emily then described in detail a workshop experience to map out the current capabilities of a group (from individuals to teams to organizations). This should be done by a group of people of various skill levels and follows this basic process.
- Answer the following questions:
- What’d you do? (what are the core capabilities and skills you need in your role)
- What don’t you do that you really think you should? (what’s missing?)
- What do you do that you really think you shouldn’t? (we can ignore these)
2. What themes emerge from this?
3. What skills do we need in order to do these things really well?
4. Ask people to assess these skills
- Grade from “I have no experience” to “I can lead in this”. Emily suggests using the “experience” part (e.g. have you done this before?) to combat the Dunning-Kruger effect
- This should be anonymous
Once you’ve completed these steps you now have a view of your organization capabilities. You don’t want everyone to be an expert in everything (you want a blended mix, a bell curve). Armed with this information, Emily suggests that communities of practice can fill the gap. This isn’t about just calling a training provider!
This session was (as promised) practical — I intend to run this session with a team or two at Redgate and we’ll share the results!
Managing for Serendipity
Liz Keogh introduced us to exaptation (when something evolves to be used in an unexpected way).
Examples of this:
- Failed gaming company decided to build a tool to share screenshots, that became FlickR.
- Failed gaming company decided to start selling its internal collaboration tool, that became Slack.
- Kleenex was originally a make-up remover, but much better as a handkerchief.
- X rays were discovered by mistake.
We had the obligatory introduction to Cynefin.
In the complex world, things are hard. Incentives often don’t achieve what you want (perverse incentives).
- The 20th-century paleontologist G. H. R. von Koenigswald used to pay Javanese locals for each fragment of hominin skull that they produced. He later discovered the people had been breaking up whole skulls into smaller pieces to maximise their payments
- In Hanoi, under French colonial rule, a program paying people a bounty for each rat tail handed in was intended to exterminate rats. Instead, it led to the farming of rats.
In a further example, Liz mentioned a book from John Kay that demonstrated that companies who had an explicit goal around maximising shareholder value where out-performed by those that don’t. This is a topic I care about deeply (who wants to get out of bed to make other people rich?), so that’s another book added to my never-ending reading list!
My main actionable take away was around the difference between a probe and a hypothesis.
A probe needs the following to be successful:
- Indicator of success
- Indicator of failure
- Amplication action
- Dampening action
- Coherence (e.g. a believable narrative of why you might want to do this).
For me, this seems a lower barrier-to-entry for experimentation that full-on hypothesis-driven development. When we’ve tried this at Redgate, finding a hypothesis and the data to back it up is hard; starting with a narrative feels easier.
Conclusion
Was it worth attending Map Camp 2019? Yes.
Did I take away some actionable insights? Yes!
Did I create any maps? No! :(
So what am I going to do about that? Well, there’s no better place to start than by doing, so I’m going to have a crack at drawing some diagrams to capture our current product set and see what that teaches me.
