Organizations are messy, complex systems made up of people who, similarly, are messy and complex. Those who have found themselves in leadership positions have seemingly developed an intuition of how these systems work. In fact, they’ve likely invested time and energy into improving how these systems work, and they may have even had the foresight to write it down so that others can understand. At their core, these systems are made up of processes optimized for inputs and outputs, or in other words: questions and answers.
We build systems and processes for sizing projects, building product roadmaps, estimating tasks, registering accountability, improving visibility, and many other very constructive things. The belief is that these processes help us become more efficient and fault-tolerant, and that is absolutely true. This machinery that we’ve constructed allows its participants to leverage their finely-honed skills to complete their work with the full trust that their peers are doing their work as efficiently and effectively as they are. It’s obvious to us that without the trust and reliance that these systems establish, we’ll constantly be slowed down by debating, defending, and consensus-building. As leaders, we examine these processes, find the metaphorical sand in the gears, and exorcise it to the best of our abilities.
But, like everything, it can be taken too far.
In this creative, innovative industry we call “Tech,” answers are rarely simple. However, given the high pressure to execute and overwhelming deadlines, we architect processes to make answers easier and more predictable to obtain. We intentionally build walls and communication protocols between various cohorts of people so they can stay “heads down” and trust that the processes and machinery will support them. The aspiration is to have simple answers to questions such as “How long will this take to build?”; “What’s our next project?”; and “What parts have changed so we know what needs to be tested?”
On the one hand, there is a certain comfort and dependability around being able to trust that the process will be able to deliver these answers. Being able to achieve these answers in a predictable fashion is proof that the machinery is working.
On the other hand, the answer is very likely “it depends,” and the way individuals respond to that is where either magic happens or things start to break down.
There are two ways of responding to an “it depends” answer.
The first response might be enthusiasm and collaboration. It usually starts with “Depends on what?” and people from across the team engage in finding out the non-simple answer. New voices are brought into the conversation -- voices that The Process didn’t account for -- and people reach beyond their roles and organizational lines to solve a problem together. Despite the ad hoc, messy, meeting-inviting nature of these conversations, the team celebrates the opportunity to bring new perspectives to the table in unanticipated ways to find a solution.
The other response might be frustration and discontent. It’s somewhere between “It’s not my job to figure this out!” and “The Process failed!”
Now, the instinctive response to this outcry of discomfort and pain may be for leaders to don their Process Architect hat and begin to develop a system to handle occurrences of these types of questions in the future. Who should know the answers to these questions? Where did things break down?
“Making the process better, easier, and cheaper is an important aspiration, something we continually work on—but it is not the goal. Making something great is the goal.” - Ed Catmull, Creativity, Inc.
Instead of offering a solution to the problem these individuals are experiencing, leaders have an opportunity to bring about new behaviors within their team. Passionate discourse and conflict is not only healthy, it is essential. Encouraging individuals to step beyond their roles to ferret out clarity from the “It Depends” will help, at least momentarily, to break down these walls. This collaborative problem-solving will help them build empathy and understand the motivations of their peers. It will foster a shared sense of ownership in the solution, and it will give a voice to those who would not otherwise be included in the conversation. Simply put: it will help every individual on the team be better at their job.
“When people don't understand that being uncomfortable is part of the process of achievement, they use the discomfort as a reason not to do. They don't get what they want. We must learn to tolerate discomfort in order to grow.” - Peter McWilliams
As an organization grows in size and complexity, process and structure will be introduced to make sense and codify that complexity. This is not something to discourage; organizations can realize major efficiencies through the architecture and implementation of this structure. However, it carries with it the risk that these systems will begin to interfere with the type of collaboration that breeds creativity. Leaders must recognize that for every predictable, repeatable system that is put into use, a certain amount of debate and discourse is squashed.
These systems provide structure; they strive to optimize communication and they provide boundaries between individuals’ work. But as often as not, the messy, chaotic pressure cooker is where new insights and innovation are born.
As for how to introduce this into your organization: it depends.