Organizational Changes

Things that you should consider

Organizational changes are not only a necessity but also provide lots of opportunities as well. They become necessary in growing organizations or to align to changing business goals. They provide opportunities for individuals to experience new roles and new challenges. No matter what the reason, org changes are almost always stressful because they involve people and people bring along with them ideas, desires, goals, personalities, etc. To not let that cloud my thinking initially when considering organizational changes, I like to first think about the organizational structure without people. Think of this as a whiteboard session where you start with boxes representing teams and forget about labeling who is part of each box. This frees you up to think primarily about how best to organize teams, initiatives, and groups to best or more likely achieve goals.

If we are going to talk about org design, we need to start with Conway’s Law, which is named after computer programmer Melvin Conway and first introduced in 1967. It states, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Conway’s law suggests that many-to-many communications tends to produce monolithic, highly coupled systems. Many, many people have riffed on this concept from Conway putting their particular spin on it. The author of Release It! Michael Nygard stated that, “Team assignments are the first draft of the architecture.” I don’t know how accurate it is but I’ve enjoyed Manu Cornet’s visualization of organizational charts, which plays with this idea that our systems architectures are similar to our organizational structures.

In recent organizational design thinking, the inverse or reverse Conway maneuver has been established. This is the idea of designing our teams to match our desired architecture, instead of letting our organizational structures define our architectures. The importance and practical application of this strategy is supported in the 2018 book, Accelerate by Nicole Forsgren, PhD, Jez Humble, and Gene Kim. I like the idea of taking this one step further up from the architecture. Start by thinking about what we want our customer experience to be, then what architecture is necessary to support that, and then finally what organizational structure mimics that.

A 2019 book, Team Topologies by Matthew Skelton and Manuel Pais, puts forward a concept that there exists four types of teams: stream-aligned, enabling, complicated-subsystem, and platform - each with a specific role to play in the organization. The roles of each are:

• Stream-aligned - focuses on a specific business capability, ideally cross-functional;

• Platform - provides common services to other teams;

• Complicated-subsystem - high specialization, and specific knowledge

• Enabling - a team of experts, mentoring and helping other teams to evolve and improve.

By leveraging these four team types and the reverse Conway concept, Skelton and Pais believe that we can assist teams in managing cognitive load. They state, “Managing cognitive load through teams with clear responsibilities and boundaries is a distinguished focus of team design...to achieve duly scoped, bounded responsibilities, natural - and relatively independent - system (sub)structure is sought to align teams to...takes Conway’s law into account and leverages it to help maintain cohesive structures with clear boundaries and loose coupling.” 

Once we have designed the best organization to support our goals, we can then layer on the people. This invariably changes the org design at least a little, and sometimes a lot. The reason is that with people we need to consider at least three major things: 

• What skills do they have that match the role we are thinking about for them?

• What skills would we like them to develop, and will this next role provide an opportunity for that?

• Finally, are there major personality conflicts that we should avoid? 

You could argue that we shouldn’t need to consider this last point but I’ve rarely found a large organization in which two otherwise high performing individuals don't get along for one reason or another. The people-side of these changes are always the most difficult but people are what make it all worthwhile and therefore should rightfully require the most thought. 

There is no perfect organization. Like most things there are pros and cons to each decision, structure, personnel placement, etc. We are simply trying to maximize the pros and minimize the cons. Like most decisions, these are not one-way door decisions, rather they can and likely will be changed in 12-18 months. As Skelton and Pais state in their Team Topologies book, “...when designing modern organizations for building and running software systems, the most important thing is not the shape of the organization itself but the decision rules and heuristics used to adapt and change the organization as new challenges arise…” The way we develop and build organizations should be a clearly defined heuristic that we teach. The output is less important because it will change and need to change periodically. That we don’t teach organizational design, in most university programs, is as large of a letdown as not teaching product management, which is the topic for a future article.