Happy Mapping Monday! Today’s #mappingmondays video continues the series on Doctrine looking at the seven principles of Structure. If youâ€™re interested in finding out how to apply this to your organization, donâ€™t hesitate to reach out via Twitter or email hello at coryfoy dot com!
- Wardlepedia Doctrine Patterns
- Mapping Mondays – Communication Doctrine
- Mapping Mondays – Development Doctrine
- Mapping Mondays – Operations Doctrine
Happy Monday! Iâ€™m Cory Foy, and welcome to this weekâ€™s Mapping Monday. Currently weâ€™re in the middle of exploring Simon Wardleyâ€™s Doctrine. So far weâ€™ve looked at three categories of Doctrine covering patterns of communication, development and operation. But how can we structure our teams and organization to take advantage of those?
So for our fourth video in this series, letâ€™s dive into Simonâ€™s 7 patterns of Doctrine around structure. These are
- Provide Purpose, Mastery and Autonomy
- Think Small, as in teams
- Distribute power and decision making
- Think aptitude and attitude
- Design for constant evolution
- There is no one culture, covering Pioneers, Settlers and Town Planners
- And Seek the Best
This will be a fun one, so letâ€™s dive in!
Our first pattern is around providing purpose, mastery and autonomy. We talk a lot in the world of agile about â€œself-organizing teamsâ€. In the world of complex-adaptive systems, the idea of self-organizing relies on three key pieces: a container with permeable boundaries, significant differences within the container, and transforming exchanges between the agents in the container. These pieces allow a group to create emergent structures to tackle problems. We tend to think of this as a â€œcross-functional teamâ€ with a clear vision. And Simon adds to this, saying that a team should understand what it is supposed to do, and own what it does, while also understanding how they fit into the whole. How? With maps, of course. The gameplays and actions a team is undertaking should be understood in the broader context, of which a map is a great way to show. But a team is also going to need both aptitude to tackle the solution, as well as the attitude to go after it. However, as a leader, we need to make sure our teams know that purpose, and enable them to build mastery in the area as well as have the freedom and autonomy to act. Otherwise theyâ€™re just line workers in a cog-producing production line, and we miss out on the ability to take advantage of the unique skills and capabilities they have.
Does this mean the teams need to be large? In fact, quite the opposite. We want to Think Small when it comes to team size, and what â€œsmallâ€ means depends somewhat on the context weâ€™re operating in. In an uncharted space, we likely want very small teams – 3-5 people. As we move into more custom-built / product based building, the â€œtwo pizzaâ€ team – a team small enough that you can feed them with two pizzas – is more appropriate, or around 10-12 people. As we move into more industrialized, weâ€™re doing less rapid discovery and working more in sequential manners, so we can argue for something larger. But thereâ€™s a point where itâ€™s no longer a team – for example, 40 people on a single team is likely too large, and should be divided into smaller teams based on user needs.
Of course, we canâ€™t expect teams to be autonomous if we donâ€™t provide, well, autonomy. This means we have to Distribute power and decision making, ideally pushing power to those closest to the users or customers. This is actually a tricky one – this doesnâ€™t mean we just throw everything to teams and wish them luck. We should be able to set, as an organization, a guiding vision and direction that teams understand and associate with. They then use the understanding of the Commanderâ€™s Intent to execute on that idea. It also means that governance and oversight is OK – but we should be cautious of our own biases, and challenge decisions using maps. As an example from Simonâ€™s Book – if a team wanted to outsource everything, but we werenâ€™t in the right stage for that, we should be able to help them challenge their own thinking with maps.
Earlier we talked about providing purpose, mastery and autonomy and the need for aptitude and attitude. We we think about these, our goal is to understand that teams have different aptitudes – finance, engineering, marketing – but also different attitudes. Some people are used to executing in very specific contexts, and will struggle to operate in a different paradigm without close coaching and leadership. As an example, organizations which had massive data centers also had excellent engineers supporting those machines – as well as organizational constructs around building, shipping and maintaining products and solutions using that data center. If we sweep in one day and say â€œItâ€™s all cloud and serverless nowâ€ – youâ€™ll still have smart engineers, project managers and other employees, but both the aptitudes – working in a new environment – and likely the attitudes – a much more rapid-fire, agile way of working – will have to come in to play. This is a big change, and one not to take lightly.
But, hopefully thatâ€™s not how we introduce change. Our fifth doctrine principle is to Design for Constant Evolution. We could do this by thinking about how we keep things â€œfreshâ€ on a team, keeping them on their toes, ready for anything. But that also can impact the notion of taking advantage of the strengths of people. Instead, maybe we design our organization such that we are ready for ideas to be discovered, cultured, and then implemented – by building teams that can go into the wilderness, bring back ideas, and then have other teams â€œstealâ€ those ideas, beginning to implement them. Then as those ideas take hold, other teams steal them and productize and utilize them.
And this rolls very well into the sixth doctrine principle – there is no one culture. We like to think that everything is â€œagileâ€ or maybe â€œagileâ€ or â€œwaterfallâ€. But the reality is that we have – and likely need – a mix of cultures and operating models. Simon gives us the terms Pioneers, Settlers and Town Planners. Pioneers explore the uncharted and unknown landscape, requiring incredibly rapid iteration, testing, and high amounts of agility. I liken this to user need discovery – weâ€™re trying to anticipate and understand where the market is going and what our users are going to need.
Settlers steal these ideas and begin implementing them. This still requires a high level of agility, but in a slightly different way. Hereâ€™s weâ€™re doing Solution Discovery – we have an understanding of user needs, and weâ€™re iterating to discover what solution will meet those needs. We can think of more Lean ways of working here, because we tend to have a slightly more defined process weâ€™re using.
Finally, we have Town Planners. They take the discovered solutions and operationalize them – scaling, supporting – sending them out to wide audiences. This has notions of iteration, but tends to be more focused on Six Sigma – we want repeatable, measurable, cost-effective operations. Weâ€™re evolving components here to be utilities that other things are building on top of, so we want stability. We want change management.
But what we really want is the best. We want the best products. We want the best responsiveness. We want the best customers. And this starts with having the best people, and creating the right structures and roles for them. A product manager skilled in rapid need discovery will be unhappy being stuck in a town planner situation working on incremental scaling, and likewise a tester skilled at diving deeply into performance issues with applications may struggle with being thrown into a situation where the product rapidly oscillates from week to week. Also remember that leadership and management are themselves separate aptitudes and attitudes, so someone who is a great engineer discovering solutions may not make a great manager of engineers working to implement stable products. Although I would argue that senior members of teams should be moving towards being good leaders, fostering ideas and growth of other team members.
So to recap:
Provide Purpose, Mastery and Autonomy for small teams. Distribute power and decision making so people are empowered to make decisions closest to the problem. Be aware that evolution is a thing, and we need to design our organizations for that evolution, as well at the attitudes necessary at each evolution step – knowing that there isnâ€™t a single culture which will cover all of the cases. And finally, Seek the Best from your people – by investing in them, coaching them, and growing them to be leaders capable of inspiring and growing others. Iâ€™d challenge you to look at your own organizations and teams this week. What skills do you expect them to have? What attitudes are they operating with? What gaps in understanding the landscape does that leave? And if you still have questions, Iâ€™d be delighted to hope on a 30 minute video call to help you get started. And if you have any other questions or just want to let me know how itâ€™s going reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. Until next week, letâ€™s build structures for success!