The Value is in Dealing with the Messy Stuff
Thursday, January 10, 2019
Over the last several years, I have had the opportunity to lead a few projects that were too large for any single team to execute. I also dealt with problems that did not fit to the existing team and org structures at all. Some of these were also “multi-VP” problems (see below). These were messy and ambiguous projects that tempt you to give up, and walk away.
I decided to write down my observations and lessons learned as I find that people who want to grow in their careers as managers or individual contributors must be comfortable to deal with such problems. Otherwise, they are unlikely to be able to influence and deliver anything of consequence.
It starts with silos
Who doesn’t blame silos at their place of work for its slowness, bureaucracy, and dis-function? Who does not want to eject themselves from such places to land in magical silo-free lands where things move perfectly fluid?
We blame silos for their resistance to change. Silos are known to produce architectures, processes, and operations that follow communication lines between those silos, with little regard to the overall problem. This is the essence of Conway’s law:
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.
In his Toward Simplifying Application Development, in a Dozen Lessons, Conway later clarified that the importance of this principle is to probe
(whether) your design organization is keeping you from designing some things that perhaps you should be building.
or even more important, to ask the following question.
Is there a better design that is not available to us because of our organization?
This question is the quintessential litmus test for silos. Most of us who had frustrating experiences with silos would answer affirmative to this question.
Yet, we also prefer small independent autonomous teams for faster decision making, short feedback loops, and to move accountability closer to where the information and execution is. In fact, we can sum up the whole micro-services movement as one to create small silos for agility and efficiency to create value quickly. Through micro-services, and micro-services inspired architectures, we are facilitating small independent deployments of code, each of which does one thing well, and are removing the coordination tax monoliths need to create value. As Wikipedia notes:
Fair enough. But notice the dichotomy between wanting to break silos apart, and yet wanting small autonomous teams (i.e., silos) to move fast.
Why this dichotomy? Can these both wants be right? Is there a way to have the efficiency and agility of small teams and yet avoid the trap of Conway’s law?
This dichotomy is not fictional. You can lead no major body of work of consequence without facing this dichotomy. Regardless of your title or role at your workplace, dealing with this topic is an essential prerequisite to growing influence and leadership. You are unlikely to influence change if you remain frustrated with this dichotomy, or avoid it altogether by ejecting yourself to land elsewhere.
Silos are efficiency centers
The first thing to recognize is that we need silos for a reason. Once we understand how to decompose a large problem into several smaller problems, silos help solve those parts efficiently. You structure the silo as a work center to concentrate around the information to solve the problem, equip it with the resources needed, and push decision making to the silo. Thus, each silo becomes a center of efficiency to produce value quickly.
Silos allow clear roles and responsibilities. You know where to go and who to ask when there is a problem. Everyone in the silo is in close proximity to the information needed to autonomously make or change decisions. This leads to empowerment, and empowerment leads to accountability.
Silos also breed their own micro-cultures, which include rituals, processes, rules, language, pride, and ownership.
The culture and processes that the silo breeds for itself are usually optimized to run status quo efficiency. The status quo may be one or more problem areas, execution of certain tasks to produce some well-defined outcomes, or of producing something of value that fits in a broader context. A “user profile” team in an e-commerce company or the shipping team in a retail store are perfect examples of silos.
The silo’s micro-culture also makes up an invisible boundary around it. The “pride and language” that each silo develops constitutes the other face of a coin called “ownership and accountability.”
Out of necessity of autonomy and efficiency, silos develop a terminology of “us and them.” Hence they appear insular and resistant to change. For example when you approach the “user profile” team (a silo) for what you think is really an important feature, they may get a response that “our team will decide after the next sprint” or that “we have decided not to build that feature for x, y, and z reasons.” You may think that they are resisting change by being inflexible when in fact they may just be exercising their autonomy.
As we shall see below, such resistance is not always the silo’s fault.
Silos become inefficient when you’re attempting any major change that spans multiple existing silos. Silos appear friction-some when you overlay a transformational change on top of existing silos.
I face this challenge with most large problems I work on. These problems don’t always map to existing silos. I can’t tell which of the existing teams can help solve the problem.
I will give you one fictional example of what I used to jokingly call as a “multi-VP” problem.
A multi-VP problem is one that either requires multiple VP level managers to work together to structure a solution, or the implementation of the solution takes longer than the tenure of a single VP level manager. That tenure may be around 2–3 years, where as the solution may take 5–6 years. In either case, the chance of getting the problem solved successfully isn’t high.
Here is my fictional example. It entails breaking a large monolith database that everything in a company depends on for most of the data, into smaller decoupled databases to facilitate a micro-services architecture. Sounds familiar?
The technical architecture for the problem is simple. It may involve building blocks like picking a new cool database technology, data modeling, data migration, dual-writing data, data migration, adapters for switching between old and new database etc. for each logical chunk of data in the monolith database. Drawing up the architecture is the easy part. Everyone gets excited about this part as it is considered innovation.
However, who should actually do the dirty of work of implementing this architecture? I’ve had some colleagues complain that they “need power” to “push through” their architecture.
Should we ask the team that manages and administers the monolith database to implement this architecture? That team may be equipped with the skills needed to administer the database servers, and databases efficiently. They may be the best in the company to run that database at scale with high availability. They may be adept in capacity management, upgrades, backups and restorations without a glitch. They may be experts in schema management and indexing. Just by looking at the query, they may have developed the skills to spot bottlenecks. But they are unlikely to lead a micro-services transformation as they may have never looked at the apps that depend on the database, or have the faintest idea of what those apps actually do, or practiced any coding.
How about we ask one or more of the tens of teams that depend on that monolith database? Not having the need to know anything about the nitty-gritty of managing a database on their own, they are likely used to throwing all their database tasks over the fence to the team managing the database. They probably also have long scrolls of features to build. Over time they might have developed certain development cadence that has no cycles left to learn and pick up database related work.
This is the nature of an ambiguous problem. It is large for any single team to pick and solve. The problem involves many building blocks with no clear mapping to existing silos. Implementing a solution takes a lot of time. The outcomes are unclear and are not guaranteed. You may encounter several surprises along the way.
I struggled, in the beginning, to get such problems solved. I used to get frustrated and sometimes considered moving on instead of trying to find a way. This changed once I tweaked my mental model.
My original mental model saw the organization as being political, inflexible, bureaucratic, and incapable of change with pockets of teams, vested in their survival, resisting any change. This is a fairly common mental model employed by a lot of us. However, this model is flawed, lethargic, and instills stagnation and not change.
My attitude changed once I changed my mental model. Now I see such problems as being ambiguous in nature. My mental model now recognizes quickly that existing silos are not optimized to resolve the ambiguity, that there is no problem with the existing silos, that the new problem requires a new approach, and the opportunity may be mine to break it down.
Disrupt current silos to create new silos
When faced with ambiguous problems like the “multi-VP problem” above, first recognize that you need to disambiguate the problem, restructure the complexity of the problem, and influence the organization to instill change. This is easier said than done. It requires empathy with existing silos, humility to let go of your ideas, and patience and tenacity to influence others.
While I can’t write down a prescription that everyone can follow, below are some of what worked for me, and what I saw others practice.
- Owning up the problem, by recognizing that there is an opportunity to step up and own the problem, as messy as it may be, instead of acting like a victim facing a villain. You should be comfortable with the mess that comes with owning up an ambiguous problem.
- Developing and clarifying why. It is not sufficient to say that the problem you saw is important. You have to be able to break it down into specifics that others can relate to, identify themselves with, and are motivated to solve. This, of course, requires identifying and building coalitions, and proactively identifying risks and blockers.
- Following through the execution of a solution by helping form new silos to efficiently solve the problem. This may be the hardest part. But recognize that no other person may have spent as much time as you on the problem, and there is likely no one who can do this step for you.
- Finally, remaining focused on the outcomes and not on “how” you want the problem solved. That is, you should be willing to let go of your ideas of the solution so that new silos can develop to own and efficiently solve the problem.
These are all traits of leadership.
Some of the most effective leaders I had a chance to work with are master-disambiguators. When faced with making a transformational change, they focus on disrupting existing silos only to form new silos to lead the change. They rely less on positional power and more on influence to disambiguate the problem and develop ways for others to contribute to a solution.
Back to the point. Instead of blaming existing silos, you may have to form new silos to make transformational changes. This does not mean re-organizing the existing teams into a new reporting structure. You may do so at a later time, or skip it entirely if the culture of the organization is built around units of work and not reporting relationships.
Deal with the mess to make an impact
To conclude, silos are not bad. Most silos are centers of efficiency. Instead of always trying to overlay a new transformation, whether small or large, on top of existing silos and getting frustrated with the slowness and friction, you may have to first structure a solution, then figure out what kind of silos you need to execute efficiently, and then step up to lead that change. You proceed, and then discover that the new work centers (silos) are not helping the next transformation. You go through the same process again. This is a cycle.
You will stop blaming the organization for its silo culture once you recognize that existing silos are optimized to run the status quo efficiently, but not to lead a change.
Conway may have recognized this when he writes about his second lesson in Toward Simplifying Application Development, in a Dozen Lessons:
Lesson 2: If you want the cleanest possible product you have to find the simplest possible design before organizing to build, or else you have to be prepared to reorganize.
Let me reiterate that this stuff is not easy. The dichotomy between wanting to break silos apart, and yet wanting small autonomous teams is a natural process of instilling change. It can be frustrating. There will be ups and downs. Success is not guaranteed and you will make mistakes. Therein lies an opportunity.
Update on Jan 12, 2019: In response to this post, Sean Gilles observed that I used “silo” and “team” interchangeably sometimes, and offered the following difference between the two
A team is part of an organization’s model of how problems get solved and silos are part of the observed reality of how problems get solved.