Professional Documents
Culture Documents
Operating in The Ambiguity Zone-20220315120919
Operating in The Ambiguity Zone-20220315120919
Session 6
Learning Outcome
• Many organizations will only do this when they have reached point B, and
are faced with a crisis in confidence and business performance. By then it is
too late. Point B is the inflection point at which the new technology, or model
that has previously been looked down on by incumbents, scales to the point
where it becomes the dominant way forward. Like a parachutist experiencing
ground rush, the new technology ramps more quickly than expected, leaving
no time for a lagging, slow moving incumbent to respond in an effective way
• So the answer to this dilemma, of course, is never to get to that inflection
point B. And that requires not just episodic innovation initiatives that are
instituted in response to rapidly declining performance or an existential
threat, but continual experimentation to create the opportunity to ride the
next wave before it is too late.
Introduction
• Yet operating in the ‘ambiguity zone’ (as we have called it) is not easy. It
requires not only a heightened level of boldness in being willing to disrupt
your already well-optimized model, but the ability to concurrently manage
more than one potentially competing business model in the same
organization, a readiness to allocate precious resources towards continual
experimentation and reinvention, and the culture to support all of those
elements.
Building velocity through continuous
innovation
Building velocity through continuous innovation
• 3M, for example, talk about ‘Time to Think’ and have, since 1948, encouraged
employees to spend 15 per cent of their working time on their own projects,
utilizing 3M resources:
– What would you do if you had access to world-class laboratories and
scientists, and almost one day a week to investigate a new idea?
• This policy allowed the team that worked on Post-it® notes the space they
needed to devote to a development process that had to overcome multiple
barriers over the course of 12 years before launch and widespread success.
Some of the ideas that come out of Time to Think (six to eight projects, twice
a year) are supported by ‘Genesis Grants’, which can act as research seed
money of anywhere between US$30,000 to US$75,000, enabling staff to
explore ideas outside of the rigidity of business unit budgets.
Building velocity through continuous innovation
• The team at the UK Government Digital Service (GDS) have initiated a policy
where for a defined period (two weeks or one month) they give the people in
the team the freedom to go off the pre-planned roadmap and work on
anything they want, as long as it is for the good of GOV.UK – with fewer top-
down commitments. The policy, called a ’firebreak’, is seen as vital to ‘release
some pressure from the system’, minimize top-down commitments, take a
step back, reduce layers of complexity, but also to work on new ideas. As Neil
WIlliams, one of the Product Leads at GDS wrote:
– A whole team working off-roadmap for a whole month might sound
reckless or indulgent. But in fact, it would have been reckless not to …
Great things can happen when you give creative, passionate people the
freedom to explore ideas.
Building velocity through continuous innovation
• Ideas, problems and opportunities are collated for a month leading up to the
firebreak. Pitch and demo meetings allowed everyone to keep up to date and
decide what they wanted to work on. Learnings from the process are
captured in wrap-up meetings.
• Hackathons and hackdays are focused ways for digital-native organizations
to carve out time for new ideas and prototypes. As well as running monthly
hackdays when employees can work on anything they want, LinkedIn
initiated a quarterly project called (in)cubator where any employee, whether
they work in engineering, sales, design or HR, can come up with an idea
relating to any part of the business and pitch it to the executive staff. If the
project is approved the team can spend up to three months of dedicated
time to work on developing the idea. But in addition, the executive staff
commit to mentoring the project leads to do everything they can to help it to
be successful.
Building velocity through continuous innovation
• Similarly Apple has an initiative, called Blue Sky, that gives employees two
weeks away from their usual job to work on special projects, and Spotify runs
regular ‘hack weeks’ with a similar aim. Facebook has a long (well, since 2007,
which is long in Facebook years) tradition of running hackdays (and nights)
where engineers and other staff come together to build anything they want,
the only rule being that it must not be the same thing that you work on in the
day job. Many of Facebook’s best-known features (including chat, video
sharing, the Like button, and the Timeline) have originated from hackathons.
In the run-up to a hackathon, engineers submit potential ideas and groups
form organically to work on them. Pedram Kenyani, the engineer who kicked
off the practice of all-night hackathons at Facebook has said about them:
– It’s a way to experiment with ideas in a low-cost way. Lots don’t make it
into products, but every hackathon tends to result in four or five things
implemented on the site. A couple have changed the direction of the
company.
Building velocity through continuous innovation
• Such hackathons go far beyond the traditional company ideas scheme, and
are regular and deliberately created opportunities to generate the space to
progress ideas from thought into prototype. The practice of carving out
dedicated time to focus on innovative projects is not new, but what is
different is the scale and breadth of how this culture is systematized in the
digital-native organization. In this context, these kinds of embedded
conventions are seen not as a nice to have, but as essential to the fabric of
how the company runs and to its success in the future.
Building velocity through continuous innovation
• Joel Gascoigne believes that the ratio between these three elements at
Buffer is around 50:30:20 but each organization will inevitably need to find
their own levels. One alternative split comes from Intuit (the financial
software business that thinks of itself as a ‘30 year-old start-up’). Speaking at
SXSWi in 2013, Intuit CEO Scott Cook described a 70:20:10 model for
products and budgeting:
– 70 per cent is focused on the core or oldest products, with the objective
of incremental growth and maintaining profit. This is the ‘rowing team’.
– 20 per cent is focused on young to mid-stage products with an objective
of profitable growth. These are the ‘white water rafters’.
– 10 per cent is on completely new products, about solving user problems
and proving a leap of faith. This is the equivalent of ‘diving for sunken
treasure’.
Building velocity through continuous innovation
• ‘Gall’s Law’, as expressed above, comes from John Gall’s 1975 book
Systemantics: How systems work and especially how they fail. Gall’s work has
inspired a number of authors in systems thinking but the book actually
focuses more on what we can learn from system engineering failures and
how not to design systems. The law (although it was never expressly stated
as a law in the book) is essentially an argument in favour of
underspecification (so it has a natural affinity to agile thinking which we will
discuss later) and argues that owing to the difficulty involved in designing
large complex systems accurately, it is far better instead to design smaller,
simpler systems that can then develop incrementally based on a continual
input and measurement of user interaction and needs
The case for a more iterative, emergent
approach
• This was, and is, a simple concept and yet it is quite profound. Think of all the
complex systems that we try to design and launch (from large IT projects to
government policy implementation) that fail from the outset. As Josh
Kaufman has pointed out in his explanation of Gall’s Law, complex systems
are full of interdependencies and variations that are almost impossible to
anticipate but that actually play a significant role in making the system
function:
– Complex systems designed from scratch will never work in the real world,
since they haven’t been subject to environmental selection forces while
being designed … If you want to build a system that works, the best
approach is to build a simple system that meets the environment’s
current selection tests first, then improve it over time.
• Far better surely, to start with something simpler, easier, smaller and evolve
from there. This is why, in scenarios characterized by complexity (such as
those within which most businesses now operate), prototypical, emergent,
The problem with waterfall
The problem with waterfall
• In the context of the modern business environment, which is more than ever
characterized by complexity, it becomes essential that we define challenges
in the right way, avoid conflating the complex with the complicated, and set
about shaping the response to those challenges in the right way.
Complex scenarios require emergent solutions
Complex scenarios require emergent solutions
• ‘Best practice’ is one of those terms that, while not inherently bad, has
become so overused as to be stretched beyond its rightful application. So it
gets applied generically to any scenario where an understanding of the most
effective methods to solve a problem is desired. Our wish to create certainty
out of ambiguity, and to impose control over the unpredictable leads us to
wish to standardize approaches and apply best practice to many distinct
types of situation. But as we have shown there is a big difference between
simple, complicated and complex challenges.
Complex scenarios require emergent solutions