Using BAPO to apply structure follows strategy
3 likes3,755 views
The document discusses the BAPO approach to organizational design, emphasizing the importance of aligning structure with strategy and managing change carefully to avoid retention issues and inefficiencies. It outlines a methodical way to categorize product capabilities, architecture, and team structures while minimizing unnecessary collaboration and resource allocation. Key principles include ensuring that structure follows strategy and iterating on designs based on feedback and context.
Using BAPO to apply structure follows strategy
- 1. 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
- 2. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/ BAPO is a way to approach org design
- 3. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/ But, org design is typically OPAB, not BAPO… why?
- 4. 4 Changing org structure is messy
- 5. It’s reasonable to expect that an org structure change may include manager changes “people leave managers, not organisations” Retention problems
- 6. It’s reasonable to expect that an org structure change may include manager changes Some managers get more or less direct reports than others Politics and manager retention problems
- 7. 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
- 8. It’s reasonable to expect that an org structure 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. 9 Therefore, we should avoid changing the org structure unless we really have to?
- 11. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Melvin E. Conway
- 12. You can’t pretend product capabilities are independent if the architecture is coupled
- 13. 13 Therefore, structure drives architecture, architecture drives strategy?
- 16. “Unless structure follows strategy, inefficiency results.” Alfred D. Chandler Jr
- 17. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/ BAPO is Jan Bosch’s more fleshed out expression of “structure should follow strategy”
- 18. 18 “Business” → product strategy → product life cycles → overlapping s-curves
- 19. https://hbr.org/1965/11/exploit-the-product-life-cycle Not every product idea makes it to growth Every product eventually becomes a commodity
- 21. 21 Innovate to identify the next capabilities; Differentiate to exploit current capabilities; Commodotise old capabilities for efficiency or to exit
- 22. 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 Differentiating (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 differentiation ● Number of experiments attempted
- 23. 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. 24 “Architecture” is about cohesion and coupling (aka dependencies)
- 25. 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
- 26. Dependencies should be 1-way. Volatile things might depend on stable things. Stable things should not depend on volatile things. “Commodity” service “Differentiating” service “Innovation” service
- 27. 27 However, fixing an architecture is typically not instantaneous and...
- 28. It’s not useful to play pretend
- 29. 29 The point is that you have a target architecture designed to be aligned to product strategy.
- 30. 30 “Process” is about ways of working aligned to product strategy constrained by architecture
- 31. 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 Differentiating (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. 32 Different people have different preferences for different ways of working
- 34. 34 “Organisation” is structure to support desired ways of working
- 35. Minimise staffing allocation to “commodity”. Decide appropriate % allocation between “differentiation” and “innovation”. “Commodity” teams “Differentiating” teams “Innovation” teams Minimise Judgment call on how to balance remaining allocation between “differentiating” and “innovation”
- 36. Note there might be a cascade from “product teams” to “internal platform teams”. Product team Internal platform team Innovation Differentiation Commodity Differentiation Innovation
- 37. 37 Design teams to minimise the amount of coordination required across teams.
- 38. 38 “Collaboration is expensive. Unnecessary collaboration is particularly expensive, especially as it can mask or hide deficiencies in underlying platforms or capabilities.” Team Topologies by Matthew Skelton, Manuel Pais
- 39. 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 effort on commodity, decide distribution between differentiation vs innovation; 4. Design teams and account for individual preferences
- 40. 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)
- 41. 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
- 42. PRO TIP: Start where you are; expect to iterate 42
- 43. PRO TIP: Sometimes it’s not about teaching people how to fish. If someone delegated the fishing, just provide the fish. 43
- 44. 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 fish
- 45. 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