Using BAPO to apply structure follows strategy

1
Using BAPO to
apply structure
follows strategy
to your
organisation
According to Jason Yip
@jchyip
https://jchyip.medium.com
jchyip@gmail.com, jyip@spotify.com

https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
BAPO is a way to
approach org design

But, org design is typically
OPAB, not BAPO… why?

4
Changing org structure is
messy

It’s reasonable to expect
that an org structure
change may include
manager changes
“people leave managers,
not organisations”
Retention
problems

change may include
manager changes
Some managers get
more or less direct
reports than others
Politics and
manager
retention
problems

Don’t change managers
to avoid retention
problems
Direct reports are on
different teams
Managers can’t stay
on top of context of
different teams
People prefer
managers who are
familiar with the
context
Retention
problems
Managers can’t stay
on top of context of
different teams

change may include
re-allocation of
responsibilities
Some people might lose
responsibilities they
liked OR gain
responsibilities they
don’t like
Disengagement
and/or retention
issues

9
Therefore, we should avoid
changing the org structure
unless we really have to?

10
Organisation constrains
architecture;
architecture constrains
strategy

“Any organization that
designs a system (deﬁned
broadly) will produce a
design whose structure is a
copy of the organization's
communication structure.”
Melvin E. Conway

You can’t pretend
product capabilities
are independent if
the architecture is
coupled

13
Therefore, structure drives
architecture, architecture
drives strategy?

15
Structure should follow
strategy

“Unless structure
follows strategy,
inefﬁciency results.”
Alfred D. Chandler Jr

BAPO is Jan Bosch’s more ﬂeshed out expression
of “structure should follow strategy”

18
“Business” → product strategy
→ product life cycles →
overlapping s-curves

https://hbr.org/1965/11/exploit-the-product-life-cycle
Not every
product idea
makes it to
growth
Every product
eventually
becomes a
commodity

https://colescottgroup.com/understanding-growth-using-s-curves/

21
Innovate to identify the next capabilities;
Differentiate to exploit current capabilities;
Commodotise old capabilities for efﬁciency or to exit

Category Description KPI (Key Performance
Indicator)
Commodity
(aka hygiene)
● Needed for product to work
● No customer will select the
product because of this
functionality
● Minimise total cost of
ownership
Diﬀerentiating
(aka better = $)
● Unique capabilities that
drive customer interest and
buying behaviour
● Maximise business value
Innovation
(aka not
guaranteed to
work)
● Experimental functionality
as part of trying to identify
new future diﬀerentiation
● Number of experiments
attempted

Commodity Differentiating Innovation
Account
management
Audience
management
Payments
Campaign
management
Commodity 3rd
party
measurement
Advanced
forecasting
Advanced pricing
Decision
optimisation
New client
platforms
Reporting
New formats
New targeting
Example

24
“Architecture” is about
cohesion and coupling
(aka dependencies)

Services should align to capabilities, though not
necessarily 1:1. Services should avoid coupling
unrelated product capabilities.
Product capability
Architecture
service
Product capability
Architecture
service
Architecture
service
Product capability
Architecture
service
Product capability

Dependencies should be 1-way. Volatile things
might depend on stable things. Stable things
should not depend on volatile things.
“Commodity”
service
“Diﬀerentiating”
service
“Innovation”
service

27
However, ﬁxing an
architecture is typically not
instantaneous and...

It’s not useful to
play pretend

29
The point is that you have a
target architecture designed to
be aligned to product strategy.

30
“Process” is about ways of
working aligned to product
strategy constrained by
architecture

Category KPI (Key Performance
Indicator)
Potential ways of working
Commodity
(aka hygiene)
● Minimise total cost of
ownership
Outsource, use 3rd party
services, internal platform
teams, minimise unnecessary
variation
Diﬀerentiating
(aka better = $)
● Maximise business value Iterative-incremental
development, maximise
valuable variation
Innovation
(aka not
guaranteed to
work)
● Number of experiments
attempted
Running lots of parallel
experiments, acquisition

32
Different people have different
preferences for different ways
of working

https://wardleypedia.org/mediawiki/index.php/Pioneers_settlers_town_planners

34
“Organisation” is structure to
support desired ways of
working

Minimise stafﬁng allocation to “commodity”.
Decide appropriate % allocation between
“differentiation” and “innovation”.
“Commodity”
teams
“Diﬀerentiating”
teams
“Innovation”
teams
Minimise
Judgment call on how to balance remaining allocation
between “differentiating” and “innovation”

Note there might be a cascade from “product
teams” to “internal platform teams”.
Product team
Internal platform team
Innovation
Diﬀerentiation
Commodity
Diﬀerentiation Innovation

37
Design teams to minimise the
amount of coordination
required across teams.

38
“Collaboration is expensive. Unnecessary
collaboration is particularly expensive,
especially as it can mask or hide
deﬁciencies in underlying platforms or
capabilities.”
Team Topologies by Matthew Skelton,
Manuel Pais

BAPO:
Step-by-step
1. Categorise product capabilities on
where they are in the product life cycle;
2. Decouple technical architecture across
categories, ensure one-way
dependencies, make appropriate tech
choices;
3. Minimise eﬀort on commodity, decide
distribution between diﬀerentiation vs
innovation;
4. Design teams and account for
individual preferences

Example: What
I actually did
1. Create a strawman categorisation
starting from existing high-level
architecture diagrams;
2. Validate with one of the senior
engineers;
3. Validate using 1:1s with Product
Area/Tribe Product Leads → this
led to separating “product
capabilities” from “architecture
services”;
4. Validate in a group session with
Mission Leads (NOTE: This didn’t
quite work, will discuss why later)

Example: What
a colleague is
trying
1. Create a strawman with one of the
Mission Leads;
2. Validate in a group session with the
Product Area/Tribe Leads

PRO TIP: Start where you are;
expect to iterate
42

PRO TIP: Sometimes it’s not
about teaching people how to
fish. If someone delegated the
fishing, just provide the fish.
43

Concluding
thoughts
● BAPO is a useful way to frame org
design by connecting product
strategy, architecture, ways of
working, and org structure;
● Expect to iterate - “all models are
wrong, but some are useful”
(George Box) ;
● (Change agent advice) Sometimes
just provide the ﬁsh

To learn more
● (blog) Jan Bosch’s 2017 post on BAPO:
“Structure Eats Strategy”;
● (book) Impactful Software by Jan Bosch;
● (blog) My Medium post on this: “Concepts
I use every day: BAPO”
● (paper) An evolution of BAPO: “ESAO: A
holistic Ecosystem-Driven Analysis Model”
by Jan Bosch and Petra Bosch-Sijtsema
● (article) “Exploit the Product Life Cycle” by
Theodore Levitt, Harvard Business
Review, Nov 1965
● (blog) Simon Wardley’s 2015 post “On
Pioneers, Settlers, Town Planners and
Theft”;
● (book) Team Topologies by Matthew
Skelton and Manuel Pais

Using BAPO to apply structure follows strategy

In this document

More Related Content

What's hot

Similar to Using BAPO to apply structure follows strategy

More from Jason Yip

Recently uploaded

Using BAPO to apply structure follows strategy