Best Practices of Organizational Design, Part 2 - A Design Outline
In my first post, I introduced these 3 steps of Design:
- Creation
- Communication
- Implementation
Creation is the first step. And as I mentioned before, if you like to nerd out on frameworks, systems, psychology, process, and diagrams, this part may be the most fun! Organizational Design touches each of these.
What do we mean by Design?
We can define the output of the Creation step based on both our understanding of Galbraith’s Star Model and Conway’s Law: Strategy, Structure, Processes, People, Incentives, and Architecture.
I expect any Design that I create will need to be visualized and communicated within presentations, documentation, diagrams and roadmaps. I like to have multiple versions of these for different sets of stakeholders: What a CEO wants to know will be different from what your individual contributors want, which will be different from what your Finance department is interested in.
The actual artifacts that I share touches on Step 2, Communication. I’ll share general ideas throughout, but will go more into this subject within the next post.
Overview of a Design process
I suggest tackling the areas of your Design in this order:
- Strategy
- Architecture
- Structure & Processes
- People & Incentives
I’ll give an overview of each step below, discussing how they connect and how they contribute to the overall design.
(These steps also assume that you that you already have Mission, Vision and Values. If not start there.)
Learning and inspiration
For those wanting to dig deeper, I’ll also list the places where I have found great frameworks, inspiration and visualizations for each step. My general strategy is to start with a book that provides a foundation and then adapt it to my current situation.
My suggestions are somewhat opinionated. I recommend taking what works for you and when you find something that doesn’t, substitute it with another framework that better fits your philosophy and situation. The point of this overview is not to be prescriptive, but rather to provide you with an understanding of what aspects you should consider throughout your design.
How much time to invest?
My best answer is: less than you think.
Knowing nothing else, I would block out a week - two at most - for each step. I may not be “done”, but I should be able to finish just enough to move forward and and start gathering feedback. For each step, I’ll list a few heuristics I use to decide when to move on.
It can be tempting to over-design, and do more work than needed. I may also be tempted to redo prior work. Establishing clear time-boxes and processes helps mitigate these traps. I also want to setup feedback loops to revisit my work products throughout the process. If this sounds like “lower case-a agile”, it is. I am creating, testing, gathering feedback, and iterating.
Issues around silos, culture, or visibility of work require more socialization. If this is the case for you, I would learn a change management framework before I get started. More on that in the future. In the mean time, Switch is a great read on the topic.
Major points of collaboration
I’ll list potential collaborators in each section below. The scope of an Organizational Design is large and covers several functions. Unless I am at a very small organization, I wouldn’t expect to create everything on my own …and no one likes to be handed a document affecting or interpreting their work with zero opportunities for input. The titles I list are really just shorthand for accountabilities that you want to cover. You may not have a CTO, but you will have a Technical Leader (maybe it is you). Be prepared to adjust based on what has been created, and with whom you may need to collaborate.
1. Strategy
Why Strategy first?
If your Strategy doesn’t exist, this is your first task! The Star Model shows Strategy at the top, and for good reason. All 5 members of the Star Model have feedback loops with each other, but Strategy is both the literal and figurative “point” of your Organizational Design. It is the plan for achieving our mission. It doesn’t need to be perfect, but it does need to exist to enable decision making.
If there is an existing Strategy, you should read and internalize it before doing anything else. You may find that it does not include enough Technical details. Or in other cases, parts of the Star Model and Architecture may not have been considered during its development. In those cases you will likely want to update the existing Strategy to account for constraints in those other areas.
Remember, Strategy is NOT the most important thing after the Design process. At the end of the day, a Strategy is just what you say you are going to do. The other parts of the Star - Structure, Processes, People, and Incentives - are how you actually make it happen. They represent the operational aspects of your Design. If they aren't developed to support your Strategy, then it will be very hard, or even impossible, to be successful. Worse yet, both credibility and trust in leadership may go down because it is easy to see when actions do not match words. This is why it is so Important to create (or at least update) these pieces together and ensure coherence.
My potential collaborators
CEO, CTO, Heads of Product, Sales, Business and Marketing, Engineering Leaders
Signals that I may be done
- We have enough information to create an architecture.
- We answered key strategic questions.
- I measured buy in from collaborators and stakeholders and am comfortable moving forward with the feedback.
Where I find guidance and inspiration
Good Strategy Bad Strategy is the quintessential guide for writing useful strategy and avoiding common strategic pitfalls.
Playing to Win for understanding and creating both Business and General Strategy.
Roman Pichler’s Product Vision Board and blog for developing and communicating Product Strategy.
Technology Strategy Patterns for understanding what goes into a Technology Strategy and how to present it.
2. Architecture
Another form of Strategy
When working with some really experienced Architects, I picked up on a common saying. I don’t know who to attribute it to, but it goes like this:
Architecture is the act of translating Strategy into Technology.
This is a clean and powerful definition of Architecture. If Strategy defines what your system should be capable of doing, then an Architect can turn this description into a design. Architecture can and should be feed back into your Strategy. It can communicate areas for investment. It can also be argued that Architecture is actually part of the (Technology) Strategy and should included in step 1. This makes sense to me. I list it here as a separate step because as a leader of engineers, this is one of our largest contributions to the organization.
Thinking of Architecture in this way also plays really nicely with Conway’s law. If you have a Strategy, you can design an Architecture. If you have an Architecture you can design an organization to produce it.
My potential collaborators
CTO, Enterprise Architects, Solution Architects, Engineering Leaders
Signals that I may be done
- My engineering teams can understand and articulate the overall architecture.
- We have addressed all capabilities required by the strategy.
- We have enough information to define practices and teams.
Where I find guidance and inspiration
The Software Architect Elevator to understand how to work across the organization as an Architect.
Domain Driven Design Distilled for a set of modern design tools to understand systems and communicate designs.
Designing Data-Intensive Applications for a deep understanding dealing with scale of users and data in distributed systems.
3. Structure & Processes
Intertwined
If you read Conway’s Law closely it isn’t just about structure:
Any organization that designs a system…will produce a design whose structure is a copy of the organization's communication structure.
—Melvin E. Conway Wikipedia
The communication structure is how the organization works together. In our model, you can replace organization with Structure, and communication structure with Processes. The Structure sets up the shape, but the Processes define how information moves around between teams. A mismatch between Structure and Process can be the cause of many issues. A common example of this is introduce agile methodologies within a waterfall organization without making structural changes. The take away here is that when changing one, you should consider its impacts on the other.
This is also where reality of your Strategy sets in with concrete changes for your teams. I plan for more feedback in this area than others. I want to make sure my proposals here are strongly rooted in our values. Staff may strongly identify with existing structures and practices. Showing respect for what is in place, while walking through changes from a values perspective can help people connect with the why of the design in order to better understand the what. My leaders are also crucial for this step. They will be communicating with the teams, gathering feedback, and getting buy in across the organization.
My potential collaborators
Enterprise Architects, People Managers, Engineering Leaders, Program and Project Management.
Signals that I may be done
- The structure and architecture can be mapped on to each other without ambiguities.
- Each team has a clear scope and responsibilities.
- Processes support and reinforce both the structure and architecture.
- The structure can be understood by staff and they understand how their team relates to others (Low cognitive load).
Where I find guidance and inspiration
Team Topologies, and its recent companion, Remote Team Interactions, Remote Team Interactions, for a comprehensive framework for designing empowered teams with easy to understand cross-team interactions.
Accelerate for developing practices which establishing a learning organization with a culture built around delivery, automation, feedback, and iteration.
4. People & Incentives
In the end, it’s about the people
Your Organizational Design means nothing without people. Often left out, this is one of your strongest levers. Foster a healthy work environment. Attract, hire, retain, and develop those who can be successful in your organization. In the short term, incentivize your existing teams to adopt the changes. In the long term, incentivize everyone to reinforce values, structure, and processes, creating a learning culture designed to drive your strategy.
For myself, these are two areas where I lean the most on my partners. Human Resources and Recruiting have deep expertise in developing practices including: Transparent and equitable promotion and compensation practices, hiring practices which nurture strong & diverse teams, live and on-demand training, flexible schedules, support for remote work, great documentation, a focus on work-life balance, and the inclusion of staff in the development of these practices. In our current environment, these are becoming table-stakes for medium to large technology companies for both hiring and retention. These won’t all be under your direct influence, which underscores why working with your partners in Human Resources and Finance is so important.
Find ways to align the goals of your people with strategic goals. And just as important: incentivize training, learning, teaching and development. Incentivize your teams to reinforce processes - not just by blindly using checklists, but by adopting best practices, and iterating and improving the way you work for all. And remember, not all incentives are explicit. Be aware of what behaviors your culture is implicitly incentivizing. Those may be stronger than explicit incentives you create (See: Culture eats strategy for breakfast)
Make healthy teams with healthy hiring processes. I like to bring in people with different perspectives. I find the collective experience of a more diverse team makes them stronger. They learn to be more empathetic and understanding of different working styles. They are more willing to try new things. They have more energy. Hire people to add to your teams’ culture rather than fit into it. I find that variation of skill level on a team also increases collaboration. Newer team members have experienced team members to learn from, and senior team members have opportunities to improve their teaching and communication skills.
My potential collaborators
Human Resources, Recruiting, People Managers, Engineering Leaders
Signals that I may be done
- We have developed training to implement the design and help our people develop any new required skills.
- We have practices with clear behaviors that embody our values and support all aspects of our design.
- We have hiring practices which ensure the people we want to attract are applying and moving through the hiring process.
Where I find guidance and inspiration
Dare to Lead for developing a healthy, open culture.
Work Made Fun Gets Done for practical ideas on rewarding staff in various ways.
(This is admittedly my weakest section for guidance. Most of my learnings have been in practice, with other leaders both in Engineering and Human Resources)
Conclusion and what's next
There is a lot here, and depending on the depth you explore each topic, it could be ambitious. If you are designing an organization that is a growing startup, then you may need to go though most of the steps here yourself. As organizations grow, more and more of these items will have been created, leaving you with less work overall, but also with less flexibility.
In either case, the changes you propose will be a big opportunity for change. Clearly articulating your Design, absorbing feedback, and iterating on it will be critical in generating buy in and strengthening your Design. Change Management, which can sound like a very bureaucratic, unfeeling process, will enable you to guide people through changes while considering not only logic, but their emotions and the culture of your organization. The next topic, Communication, will be key in helping you do this.