Best Practices of Organization Design, Part 1
As an engineering leader, people are your most important job. Without your engineers, your technical writers, your product managers, and everyone else on your teams working together, there is no product. There is no service. There is no business.
If you are a VP of Engineering, your job is much like that of an architect's, but with people. Events that are happen externally or internally, positive or negative, shrinking or growing - can impact what your team does and how you work.
- You may need to hire more people to scale out your service.
- There may be a new product to build, possibly requiring a new capability.
- Your business may be expanding to new countries in new time zones.
- New features may be taking to long to develop and require to much coordination across teams.
- Your CEO may have just set a new strategy.
- You may have lost a key leader, or some of your managers.
- Teams may be complaining about the amount of bureaucracy to get to production.
- Your workforce may have switched to being fully remote or hybrid.
When these situations come up, it is time to explore changes to your organizational structure. Implementing a new organizational design of your most important powerful tools you have to respond to these changes. And when I write powerful, I mean that in all the good ways, and all the bad. It can be a difficult tool to wield correctly.
The process of moving your organization forward through these changes is commonly known as a reorganization. Reorganization can be a scary word for your people, and you. Even if you are comfortable with them, you should have empathy for those aren't because it is new, or because they have gone through difficult ones in the past. From your their perspective, their world, team, and role could all change instantly. Without enough context, they may not understand what is changing, or even worry about their job safety.
Is this really my job?
Some people may ask "Why should I do the design, isn't this the job of HR?"
While HR is a key partner, as a VP of Engineering your job is to implement your strategy to achieve the mission of your organization. Your domain knowledge is essential in understanding what will be an effective structure for your business. You will also have a better understanding of when these changes should happen.
A tempting trap
The potential for anxiety during a reorganization isn't news for most leaders. We have seen reactions of people to reorganization announcements, both in person and over Zoom. As a people leader, it is also a natural reaction to want to avoid this pain for your teams, and for yourself.
…And so you can delay changes by giving new responsibilities to existing teams, increasing the number of reports under managers, of leave gaps in your management chain. And all of these can work for a while, but they shouldn't be considered long term strategies. While you can avoid pain in the short-term, this is only a band-aid solution.
If you try to add a new product or capability, but do not change your structure, you are likely to introduce ambiguity in your teams' priorities. Even worse, delaying structural changes will make the lives of your people harder as accountability becomes more diffuse. Work can begin to stall as more coordination is required from more teams to deliver even small features and improvements. The net effect of working in this environment long-term makes achieving your strategic goals very, very difficult, and the morale of your teams plummet.
Why does this happen?
The effects of Conway's Law
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
Ask the people I have worked with, and you will quickly find that this is one of my favorite quotes. This is because it is so obvious once you understand it. And you can't "unsee it" after you observe it happening.
The structure of your teams is like a natural force. Over time your systems, your products, your platforms will begin reflecting the shape of your teams. This effect is known as called mirroring. You can "fight" against this, but it takes a lot of planning, oversight and intentionality to work against the entropy created by your organizational structure. In fact, this effect is so strong, that some organizations take advantage of this force by organizing their people into the shape of the system architecture they want to realize. This referred to as the Reverse (or Inverse) Conway Maneuver)
I won’t go deeply into Conway’s Law here, but there are many excellent write-ups on applying it to Organizational Design.
With this knowledge it is clear that your architecture and organizational structure are linked. What else should you consider?
Galbraith's Star Model
Organizational Design is about more than just structure. There is no shortage of Organizational Design Models that you can use to help you understand how differentness aspects of your business relate to your organizational structure. My current preferred choice is the Jay Galbraith - Star Model (which I learned more about during a great Enrich discussion!).
What is great about this model is that we can use it to visualize the relationships and interactions between five aspects of your organization: Strategy, Structure, Processes, Rewards, and People.
The structure of your organization is important, but making changes to it without considering how information flows within your organization would be a disaster. Likewise, implementing a new strategy without creating new rewards and incentives for achieving strategic goals can stifle the changes that you want to make. And of course you want offer training and paths for development to your people, and hire people with the right mindsets and skillsets to fit into your new structures.
I think Strategy, specifically Technical Strategy, is most important item on this list when it comes to Organizational Design, and should ideally happen as part of any Strategy development process. If you don't have a Strategy written down, or if your Strategy doesn't address key Technology details, than you should create one yourself first. Without one, any changes will be much harder to justify. Changing your structure without having a clear picture of the future can be confusing for both you and your people. This is a subject on to itself, but I would suggest reading Technology Strategy Patterns to get started (You can also check out my review of the book, and some of my other thoughts on Technical Strategy)
But wait, there's more
The Star Model gives us most of the picture we want, but organizations also have a backdrop consisting of Mission, Vision, and Values. In a small organization, these may have been defined by the CEO and the founders. They may be based on the personality and values of your founders. In a larger organization, you also may have a Mission and Vision specific to your business unit. Together these represent the culture your organization aspire's to be. You might not even use these words, but your leadership team set an example with their behaviors, and create the incentives for others.
Mission, Vision and Values are usually evergreen, or at least change very infrequently. They are the context in which you develop your organizational structure. They can help you make decisions in your design. A well written strategy will weave these into the narrative and call out these connections.
Putting it all together
To recap, I have listed nine aspects of your organization to consider during our process of Organizational Design.
- Vision
What is the world we want to live in? What do we want our products and our organization to be in this world? - Mission
What are we trying to achieve? What are we doing to create the world we described in our vision? - Values
Who are we and what do we expect of each other? How do we interact with the world, and our customers? - Strategy
How will we achieve our mission? What is the roadmap to get us there? - People
Who, how, and where will we hire? How do we we develop our people? How do we build a healthy work environment where people feel included and understood? - Rewards
How do we incentivize people to live our values, respect our processes, and work towards our strategy? - Processes
How do our teams work with each other? How do you empower your teams to deliver? - Architecture
What are the technological capabilities we need to achieve our strategy? How are they connected together? How are they accessed? How do they scale and support our products? And finally… - Structure
What are our teams? What do they do? Who are our leaders? Where do accountability and responsibilities lie?
Regardless of the frameworks you choose, the goal is to model all the variables that will impact your redesign and understand how they relate to each other. This works for me because it feels like I've modeled everything important.
Reality check
If you have all of these available at your organization, great! But it is far more common for some of these to not exist, or just be out of date. And contradictions can slip in over time as leadership and priorities change.
But as someone responsible for moving around dozens or hundreds of people, finding, reading, updating and even creating some of these will be a fruitful exercise. And it is a great opportunity to work with your different peers to co-develop changes and share some ownership of your design with others.
Getting started with your design
Before doing too much thinking, I suggest discovering who your partners and stakeholders are. I mentioned HR already, but you will also want to bring in your Finance partners to help you plan for budget changes. There will be others you should work with depending on your organization, such as Product and Program leaders, and other functions who support or work with your teams. Your boss of course will want to be looped in.
I like to divide the process of a reorganization into 3 distinct steps:
- Creation The development and documentation of new structures and processes
- Communication Working with team and stakeholders to ensure that they understand the changes gather feedback
- Implementation Putting the design in place, moving and hiring people, and establishing new practices
Design is the fun part. Communication is the hard part. And Implementation is the part that people think will happen "magically" and often forget to plan for.
These of course overlap, but you should plan for them each distinctively. Each step sets up the next, and will have feedback loops. I'll be diving into each of these individually over the following posts. You can read the part 2 of the series here.
In the mean time, I highly suggest checking out Team Topologies by Matthew Skelton and Manuel Pais which has inspired a lot of my thinking. They present a flexible and coherent framework which you can use to design your teams and their interactions.
1 Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis MacCormack, Baldwin, Rusnak Harvard Business School, 2008