Why distributed leadership isn’t for architects
8 reasons why adopting distributed leadership in an architecture practice is [not] a bad idea. And how to address the challenges.
This post was inspired by the In Detail podcast called Komrade Kate vs Captain Order.
Shout out to Kate, Warwick and Mick who do an amazing job of taking us behind the scenes of small architecture practice. Discussing the challenges of practice and arguing about solutions in an informative and entertaining way. Get it in your ears. But I digress…
In the Komrade Kate episode they discuss how they run projects in their respective offices. Where this becomes relevant is Kate, as it turns out, effectively has a distributed leadership structure in her practice. Throughout the episode they discuss potential limitations of the model and where friction and challenges might lie in adopting this approach. They make many substantial points on the difficulties distributed leadership presents to an architecture practice. It therefore might be useful to look at all the reasons why it might not work (and how you might overcome those issues).
Acknowledging up front, it’s all easy in theory but much harder in practice. And distributed leadership might not work, or be, for all practices, but when the limiting stories are addressed it might be easier than you think.
What is distributed leadership?
As I’ve been working through and thinking about this leadership model I’ve written a few posts as a resource for others and to work through my thinking. If you want a deeper dive then these are for you:
- Architects, lead like pelicans
- Leadership for the future
- The future of architecture is not hierarchical leadership
- Reluctant leaders
At the outset I also want to distinguish between management and leadership.
Management is about taking power from others.
Leadership is about giving power to others.
Management is not bad, leadership good. They’re both important, they overlap, and good management is required to ensure distributed leadership’s success. But I’d like to avoid semantic arguments and will try to stick to a discussion of leadership. Notably, solutions to the challenges of distributed leadership are often more about management than leadership but there’s unavoidable overlap too.
Back to defining distributed leadership. Here’s a basic one:
More traditional hierarchical leadership models concentrate leadership in a single person or representative body. Distributed leadership decentralises and disperses leadership, with individuals at all levels contributing to the success, operation and development of an organisation.
Why it won’t work in architecture practice
It can’t scale
This was the biggest challenge identified on In Detail. My conviction is it does scale. And is also why I think more practices should adopt this model. It scales well, from small practices to the leadership of the profession itself.
Why it can’t scale
Projects require a single person in charge, to allow for delegation, oversight and as a repository of historic knowledge on the project. Resourcing and priorities need to be managed, that can’t be done by multiple people. And as the numbers and sizes of projects increase the difficulty of managing these challenges becomes manifestly greater. One person, or small group of people, needs to be in control.
How it can scale
The first thing to understand is that the practice doesn’t sits in a multiverse where everything and anything is possible. It’s important to begin by creating guardrails for the practice. Guardrails that ensure everyone is working towards shared purpose and goals. Nothing is done without this guiding framework to ensure consistency and provide agreed constraints on the work. That’s at a broad scale.
Drilling down a little further, its leadership that defines and drives the culture. The culture is central to making this work. Everyone supporting and each other and the practice through a shared vision and goals. Not everyone will be suited to a practice’s culture.
It is still up to senior managers to ensure projects stay on track, are resourced appropriately and meets practice expectations. It’s not a flat structure, it’s a flatter hierarchy. Senior staff are still required to have oversight of the office, managing people, resources and the business. Whilst also trusting that more junior members of the practice will step up when needed and do so as an act of leadership, not delegation.
More common leadership and management models require delegation. Distributed leadership understands that everyone is working towards the same goals, in the support of each other and the practice. You’re working for the practice, take pride in it’s work, and it’s not about individual projects. That way everyone has agency and ownership, stepping up to support projects when needed. Delegation isn’t necessary when everyone pulls together, even doing the boring or unpleasant work. It’s part of the culture. Culture scales.
Of course, this is an idealised argument. One in which there are always resources available and everything can be planned for or anticipated and people are all pulling together and in the same direction. That’s easier in smaller practices. It’s nevertheless possible at scale, requiring senior management and leaders with oversight to manage the work. Communicating what’s required and addressing shortfalls or problems, rather than waiting for people to step up. And most of all establishing the culture of agency and ownership of the work.
Experiential learning opportunities are missed
In a practice where people are better matched with their passions, expertise and skills, they can’t learn from the consequences of their actions. Documenters who do not take on contract administration and site roles, for example, cannot learn from their documentations errors or naive decisions.
Other ways to learn
Experiential learning is powerful. One of the best ways to learn. It’s not the only way.
When leadership is to the fore and when there’s a supportive culture, there are many ways this knowledge may be passed down. In the example I gave there might be site debriefs when errors have occurred but also when things have gone well. As Richard Feynman observed the best way to ensure you’ve learned something is to teach it. Teaching could be through a one on one or one on many lesson, or by adding the information into a central office knowledge base system, available to all. A culture of teaching is ensures learning is not undervalued and undersupplied.
The challenge here is to distribute the knowledge more so than put all the efforts into experiential learning. The tendency is often to program time for learning with site visits, talks or workshops. Allowances must be made for informal learning in conversation and reading the office knowledge base. It’s not limited by the leadership model.
An example of how it might be done differently was given in the podcast: Valve’s Handbook for New Employees
Derek Sivers also brilliantly describes how he did something similar at CD Baby in his book Anything You Want, in the chapter called Delegate he also offers a cautionary tale in this chapter Delegate, but don’t abdicate.
Project knowledge loss
In a small practice, when only one or two people ferry a project from start to finish, they are the repository of all information and history regarding that project. A human knowledge base for the project. When leadership is distributed, this knowledge isn’t held by one or two, it’s held by many, especially when people might only work on various stages of the project, conception, documentation, site, etc. It’s impractical and impossible for this not to present problems of decisions, discussions and knowledge being missed or lost.
Knowledge need not be lost
The problem here lies not in the practice model but the reliance on human repositories of knowledge. It’s the systems not the model. Each project should have a knowledge base available to all, so that everyone that needs to be can be across all knowledge of the project. This not only records the history of the project but also becomes a resource for future projects. There’s no Q: “How did we address Council’s concerns in the Smith’s House? What did you say to the planner?” A: “Dunno. That was 10 years ago!” but instead “That’ll be in the project database.” It’s similar to the model Derek Sivers discusses in Delegate.
Boredom from typecasting and specialisation
In distributed leadership one principal is that people work in their zones of genius. The area where their knowledge and skills are particularly strong. For a profession of generalists there’s a risk of boredom or dissatisfaction in being typecast.
Your passion is not boring
The point isn’t for everyone to specifically and exclusively work in their areas of expertise. the point is to focus on their passions. It might be that they’re deficient in skills in this area. Skills can be learnt and passion leads to faster learning. Of course you also want to take advantage of people’s particular skills and expertise but they don’t need to be typecast. A supportive culture will always allow for variety as well as learning.
Experts are not generalists
This follows on from the previous point. It’s not just typecasting that’s a risk, it’s building a practice from experts skilled in one or two areas. By distributing the tasks to people with the passion and knowledge there’s a huge risk when they leave that you’re unable to cover their loss quickly or easily.
Teams adjust
This is more problematic in smaller practices. It’s not really an issue in larger practise with more people, skills and knowledge coverage. Remember everyone is working in support of the practice. People step up to cover when needed.
Also worth remembering skills can be learnt, They don’t necessarily need to be replaced. It might take time, but that balances out when the other advantages of distributed leadership and culture are taken into account.
Impossible to accomodate the complexities of architectural work
Architectural practice is nuanced, labyrinthine and complex. It requires expertise, creativity, and deep understanding of functionality, aesthetics, sustainability, and client needs. Design decisions often involve involved problem-solving, and distributing leadership model might lead to conflicting visions, lack of coherence, and a slower decision-making processes.
Complexity is where it thrives
Bottlenecks and dead ends happen when there’s only a limited number of minds on a project. When more people are involved it’s advantageous. With more minds on the job problems should be easier to solve, not harder.
Sure conflict, coherence and fraught decision making may be an issue but that’s cultural. This is where the guardrails, good leadership and teamwork come into play. Helping guide the process in support of the project. Working for it, not against.
Accountability is impossible
With multiple leaders responsible for different aspects of the project there’s the potential for a lack of accountability and ownership. Clear accountability is crucial to deliver successful projects and ensure that every team member is invested in the outcome.
Everyone is accountable
Everyone is working in support of the project. When you have multiple leaders, there’s more opportunity for people to stand up for the work and ensure the project is done in a way that is consistent with the values and goals of the organisation. Distributed leadership allows others to lead in service of the project when they have the time and energy. Blame, errors, mistakes are owned by the team, not individuals. Everyone is accountable.
A client only wants one leader to speak to
Clients expect a consistent approach and communication with an architectural practice. This can’t happen if there’s many people leading the project.
Zone of genius
When leadership is distributed it frees up time for those that are the best communicators, empaths and storytellers to work with the clients. The strategy of distributed leadership isn’t for staff to be all things to all people, but for them to embrace the things they’re best at and passionate about. That might be working with clients. It takes good communications systems within the office so that they can be across all decisions and the project at large. They need not be the only representative in the office at meetings, but they can be the main point of contact at all times.
Conclusion
No system or model is flawless. Often the failures lie in the leadership and the culture, not the model. This applies equally to many leadership models and strategies. This isn’t to excuse failure in distributed leadership if or when it happens, but to suggest it’s best to first interrogate if the problem lies with the leadership and management rather than the model and strategies per se. More often than not the problems start with the practice culture and that culture is established by the leaders, distributed or otherwise.
Bottom line, it’s not for all practices. When it’s not part of the established culture of a practice, it can take considerable time and effort to shift the leadership model. But it is possible and even a slightly more distributed leadership will have substantial benefits (see previous posts), and no matter the scale of the practice.
Michael is an Architecture Leadership Coach
Supporting architects in mastering a creative model of leadership to build a more adaptable and efficient practice.
Unleash the collective energy, passion, and capabilities of your people.
Find him at Unmeasured
