I was stimulated, by an article in the Journal of Organization Design, about how to do design work recognizing the need for agile evolution, the fact that designers do not always get it right and the fact that people don’t always behave as planned .
Good design does not always lead to a good organization because the designers are “boundedly rational”, and because people have their own wills which can cause them to act in unpredictable ways. Also, a good operating model for today may become less good tomorrow because the environment changes in ways that require new tasks or require tasks to be executed in new ways.
Agility, as I am using the word in this article, is the ability of organizations to adjust as circumstances change. But it is also the ability to adjust when part of the design that has been developed proves to be ineffective, either because the design is wrong or because people do not follow the design.
So why do people behave in ways that are not intended by the design.
First, they are influenced by the challenges they face, which may not have been anticipated by the designer.
Second, they have their own ideas about what tasks are most important, which may not always be the same as the intentions of the designer
Third, they choose behaviours that they believe are most effective for completing the task, which may not be the same as the behaviours that the designer thought were needed, and
Fourth, they choose behaviours they believe are most beneficial for them personally (personal rewards) and for their team or department and these can be in conflict with the behaviours that are most beneficial for the organization as a whole.
So what does “designing for agility” look like in practice?
We need to start with a definition of “good organization”. Good organization is an organization where “capable people work well together”. “Capable people” means people with the skills and personality suitable for the task combinations they are allocated. “Working well together” means that the people interact effectively where their tasks involve working with others in the organization.
Armed with this definition, “designing for agility” means:
- having a good understanding of which tasks need to be executed particularly well for the organization to succeed (which behaviours are critical to success) and how the people responsible for these tasks are currently behaving (if an organization already exists).
- focusing on achieving a fit between the person and the task, particularly for the most important tasks and most powerful people. This is about the “capable people” element of good organization. Fit occurs when the person already has the relevant skills, values, behaviours and understanding of priorities needed for the task. In these circumstances the slipage between intended behaviour and actual behaviour is likely to be low, at least where the intended behaviour is appropriate for the job. To go from mistfit to fit The designer will need to adjust the task or the person or both.
- focusing on designing solutions to “difficult links”: important interactions between people that are likely to be (or are known to be) suboptimal because of conflicting objectives or competence issues or personality issues or …. This is about the “working well together” element of good organization. Design solutions may involve adjustments to people, to task definition, to interaction protocols, to leadership structures, to incentives, to information systems, to locations or to ….
- designing strong performance accountabilities, so that areas of “misfit” or “difficulty” that impact performance are quickly exposed.
- “fast redesign”, whenever a “misfit” or “difficulty” emerges. A “misfit” or “difficulty” may emerge because the design was inappropriate, because the people are not behaving as the design intended or because circumstances have changed. Managers should be encouraged to think like the manager of a football club. If a person is injured – redesign. If a person is not executing their tasks well – coach or redesign. If we are losing the game – coach the team or redesign. If two people are not working well together – coach them or redesign. Every manager, therefore, needs the authority to redesign in their own area, as well as some competence at or support in good design.
- creating “design authorities” at different levels who can check whether the continuous process of small redesigns is challenging the overall working of the operating model or whether broader operating model changes are needed. The process should not be an approval process, which would slow down the redesigns. It should be a review or audit process, which raises red flags when a small redesign may have consequences that have been overlooked.
- designing a process that enables managers at all levels to signal the existence of and drive the resolution of “organizational tensions”: a “misfit” or “difficulty” that is not part of their authority, but is effecting their ability to execute their task. This process needs to be like the “tensions” process in holacracy or like the “Andon cord” on a Toyota production line.
- putting in place a culture and a reward system that reduces the natural forces of self-interest and department-interest which can distract from “organization-interest”. Managers also need to be supported with training that will help them evaluate the “organization-interest” when making small redesigns.
Since the enacted or realized or real organization is how people actually behave rather than how the operating model design expects them to behave, all design changes should focus on what actual behaviours are likely to result, given the actual people involved, the current cultural norms that will be difficult to change and the likely pressures on the organization that may affect behaviour. The enacted or realized organization emerges from the combination of the formal design plus the informal behaviours. Design work is mainly about designing the formal organization, but this should always be done with an eye on the likely impact the changes will have on actual behaviour.
Ashridge on Operating Models 
Thanks for the post Andrew! Interesting thoughts! If you would like to follow up this topic of agile organizations; it would be interesting to read a post on your thoughts on a few topics;
1) sAFE (scaled agile framework – its an attempt at addressing how to organize for agile above the level of an agile team. Many struggle with this. Spotify is an interesting example that has been written about https://www.jeremiahlee.com/posts/failed-squad-goals/ . While they perhaps did not use sAFE per say, the attempted an IT oriented agile approach to organization design).
2) Thoughts on perspective top-down and bottom-up and “who knows best” in terms of org design. There is a classical tension between those who believe that some intelligent persons can design a complex system seen from above and get it quite right, and those who do not have much faith in this and are all for decentralization and autonomy and letting the employees themselves decide. Most agree that on some level capable people should decide how they work, while managers focus on outcome. But there must be some balance. In relation to organizational agility, this is an interesting tension to hear your thoughts about. I think this article addresses some of it; and sort of positions itself as “design from top – but listen and change fast if needed”.
Thanks for keeping this blog alive!
Kind regards, Hans-Christian
Hans-Christian, For some reason, I have only just seen this post. Sorry. You always ask such good questions. On sAFE, I am no expert. But the key seems to be to try to divide up the work so that as much of it as possible can be executed by agile teams. It is hard to see how you do this in a continuous process manufacturing environment or in a sales force. But there are many activities that would benefit from multi-functional teams working in sprints with clarity about who their customer is (internal or external).
Bottom up versus top down is largely solved by iteration. At one level, you have no choice other than some top down: when the CEO appoints his or her team of direct reports, this is top down. When he or she adjusts this team because it is not succeeding, is this top down or bottom up? Clearly, the people who do the work know best how to get the work done, so, their voice and/or their knowledge needs to be part of the thinking. Holacracy formalizes the iterative process of design, through the process of raising tensions. However, in most organizations this happens informally anyway: I complain to my boss that Ashridge Marketing is not doing a good job of marketing my courses, and suggest that I have my own marketing budget. My boss discusses this with Marketing and makes some adjustments that go part way to achieving the change in organisation that I want, but Marketing fears!
I do think though that “some intelligent persons”, for me I would say “some persons with lots of organisation design experience”, can design a complex system from above and make it much better than it was before. But the system will still benefit from regular further adjustments resulting from tensions, even if only because it is a living organism and performs a bit differently from one day to the next as circumstances and people change.
Andrew, a couple of thoughts.
1) You indicate that good organization is an organization where “capable people work well together”. Don’t we need to do a bit better than that? An organisation could have capable people working well together, but not realising the organisation’s purpose and goals, perhaps not even operating profitably (if a commercial organisation).
2) I wonder whether a necessary condition for agility is adaptability, and if so, how that might influence thinking about the necessary conditions and competencies for organisational design?
Peter, Excellent thoughts Peter. Glad to see that you are back in thought provoking mode. For me “capable people” means “people with the capabilities they need (and motivation) to execute the tasks given them”. So, iff I make you “goalkeeper”, you need to have the skills to stop the ball going into the net, save penalties, boss the defensive players, throw the ball out, etc. Hence the onus is on me to define the roles and find the people to fit, or find the people and define the roles to fit them. The people will collectively realise the “purpose and goals” if I define the roles right, agree the goals and make sure they “work well together”: like a football team.
On the issue of adaptability, I address this with my “adaptability test” in the “nine tests of good organisation design”. This test involves anticipating changes that may or may not be needed in the next few years due to changes in markets or people or pressures, and then assessing how difficult (often the difficulty is power politics) it will be for the organisation to adapt as needed. If people individually are adaptable that helps. But, even if the centre back is willing to play in goal (adaptable), it does not make him or her a good goal keeper. So there are limits to the benefit of having highly adaptable people. You also need to be able to adapt the organisation design.
Andrew, thanks for the elaboration. So … if I understand you correctly, a good organisation requires a core capability that is about defining roles well and finding suitable people, or finding good people and defining suitable roles … then perhaps the most critical element in designing for agility is the capability of developing and sustaining dynamic people and organisational capabilities?
On adaptability … the first part of your response sounds like good business strategy (a combination of market and corporate strategy) … with one of the most common tools being the development and sustainment of an effective business model (which gives expression to the connection between market opportunity and organisational capability)
I note that effective business modeling capability is an invaluable precursor to effective operating model capability, as it enables higher quality, lower cost operating model design, reducing the risk that effort is put into operating models that are not sufficiently viable when tested against the underlying business model.
(I am pleased to see how various elements that you are advocating provide strong support for the enterprise transformation lifecycle that I have been using with clients for the last five years – see https://enterprise-modeling.org/concepts/)