Organization: Beware Of Implicit Dependencies

I have to confess, as a manager, the topic of organizational structure isn’t exactly my favorite, but you know, it’s part of the job.

The reason why it’s not my cup of tea is mainly because I’m not a huge fan of abstractions. They simplify complex systems and make communication easier, but they also risk losing the finer details. In organizational structures, this abstraction translates to viewing people as roles and relationships (I should say reporting relationships here). While this helps manage and organize, it can sometimes overshadow the unique contributions and complexities of each individual. Balancing this abstraction with a deep appreciation for the people we work with is essential for effective management. Some might argue that not being fan of abstraction is heretical for someone involved in the abstract world of software engineering, and they might be a bit right! Overall, I prefer to focus my energy on tech and product-related topics.

That said, organizational structure often becomes a source of friction because it defines the boundaries between teams and the levels of responsibility and accountability for everyone. When poorly defined, it can lead to disillusionment and a belief that the structure is meaningless. If people don’t buy into it, engagement, motivation, and trust in the company can all suffer significantly.

These issues may emerge slowly, but over time, they can cause critical damage. Since the organization is an abstraction of the company’s structure, doubts in this structure can erode trust in the company’s overall strategy, products, and leadership. It’s like not trusting the structure of a building—you wouldn’t want to live there, even if there is a nice parquet in one of the apartment.

An organization can be visualized as a graph (yes, with vertices and edges for the nerds out there). The nodes of the graph are people, and the connections represent the reporting relationship. We often simplify by using a tree instead, but in reality, many connections are implicit and not represented. These implicit connections turn the tree into a more complex graph and can often be the source of many problems. When I refer to the details lost through abstractions, implicit connections are a good example. They are not defined or visible anywhere, and we frequently rely on the goodwill of individuals to manage them in their own way. Due to this relative invisibility, I believe we underestimate their importance to the success of projects and the company.

An implicit connection can exist for various reasons. For instance, a team might be unable to complete a task independently because it lacks a specific skill. This deficiency necessitates synchronization with another team possessing the required skill to accomplish the mission. Managers will coordinate to align their timelines, and then team members will work together to ensure they meet the same standards.

Another example is the need to align business and engineering to roll out a product, which requires someone in the middle to coordinate this effort. Such responsibilities often do not appear on the organizational chart, but certain roles implicitly involve managing these connections. One particular group of people is especially exposed to this: Product people. They are the cornerstone between various stakeholders (business, strategy, engineering…) and often spend most of their time managing implicit connections. They are connected to too many people, but not in your org chart, obviously. What is likely to happen in this case? Meetings. Meetings are the temple of implicit connections; this is where they thrive. Most meetings exist because of these connections. However, since implicit connections often arise from something undefined, or badly defined, meetings frequently fail to push the envelope. Consequently, you’ll find many people complaining about having too many meetings with little to no value for the company. Product managers then morph into project managers. Since product people can no longer focus on the product, its definition will likely be driven over time by top-down decisions or by engineering teams. In certain contexts, the latter could actually be beneficial though.

Managing implicit connections does not create value for the company. At best, it controls a portion of potential chaos.

Let’s get back to our organization. To design an effective one, we have first to define the company’s vision, strategy, challenges, and key focuses. With these in place, we can then establish an organizational structure that efficiently addresses these elements. In other words, we should be able to define units—clusters of nodes (i.e. people) that could be teams, departments, tribes, or other groupings depending on the company’s context—and make them responsible for a common mission. We must then define the nature of each node, which essentially refers to individuals with specific titles and roles, and the nature of the connections between them. Let’s start with the connections. This part is relatively straightforward: like I said earlier, a connection between two nodes usually means “A reports to B,” implying that B is A’s manager. While some companies might have variations, we’ll stick to this basic concept for simplicity. And of course, we are not talking about the implicit connections here, only of the ones explicitly put in every org chart.

A node, on the other hand, captures more information. It defines a person (with their name), their role (with their title), their scope (defined by their unit), and their level of responsibility and accountability (the position of the node in the tree is a good proxy for this, though titles can also convey some of this information). Responsibility, closely tied to ownership, is crucial for empowering people and teams. Accountability is vital for organizations, especially during critical discussions—you don’t want a dozen people in front of you. Responsibility can be shared across a branch of the org chart, but accountability typically falls on a few individuals.

At this stage, you may wonder, ok, that’s fine, vision, strategy, units, nodes, and connections. Sounds like a plan. But let me share with you some common issues I’ve encountered in various organizations:

• Scopes not clearly defined: It leads to multiple implicit connections between nodes, causing communication overhead and excessive synchronization. This friction often signals that the organization doesn’t empower enough its units. It can also be a sign of a lack of clarity in terms of vision and strategy, making the management unable to correctly structure the teams accordingly.

• Excessive number of layers: It creates a dilution of responsibility and accountability, and a breakdown in decision-making—too many cooks in the kitchen. This is a complex issue because many see the organizational structure as a pathway for personal progression. Without this path, employees might feel discouraged. As companies grow, they tend to add layers to give a sense of progression and power, which I believe is a mistake, but quite challenging to avoid.

• Meaningless titles: Titles that inflate roles can devalue our place in the organization and reduce trust in the company’s quality standards. This can be the result of the previous point but also questionable choices, for example, the proliferation of VPs in sales departments to impress customers. This is quite common, but folks, we need to stop this practice, it doesn’t work anymore in 2024.

• Misuse of authority: The closer a node is to the top of the hierarchy, the more responsibility and accountability it holds. However, this doesn’t necessarily mean it is the most important position. I believe many people use their position as an argument for authority, which is detrimental in the long run. It can weaken the quality and engagement of a team. Being responsible does not mean that everything depends solely on you. It means you are responsible for relying on the right people—the most knowledgeable team members—to energize and drive the team forward. Even though you may have to make final decisions, these should be the result of a collective effort.

As a manager, here’s how I try to influence my peers:

• Keep it simple: Just as we emphasize simplicity in coding and architecture, we should avoid unnecessary complexity in organizational structures. Do we really need new titles in our ladders? Do we really need another layer of management—managers of managers— to tackle new challenges? What is the plus value? For small companies, it might be even more effective to be radical—do you even need to focus on organizational structure yet? This is probably not the priority and your energy would be better invested in other areas. You still have a limited number of objectives and focuses, everyone should align easily without the need to rely on an organizational structure.

• Minimize (implicit) connections: Human connections are essential but challenging to manage and often the root of many issues. Keep connections to a minimum to avoid unnecessary risks. Because do you know how we try to grasp with the complexity of human factors such as connections and communication? Processes (meetings being a form of process). While processes aren’t inherently bad, they can lead to the dilution of empowerment, ownership, and creativity. Introducing in the meantime a new level of frustration. Instead, encourage people to grasp the big picture. Avoid confining them to narrow roles and empower them to manage things independently. This prevents the spreading of responsibilities across multiple teams with project managers or coordinators of any kind, who are often the ones likely to introduce processes. This approach often wastes time, resources, and energy. Of course, some level of cross-team interaction is unavoidable at times, but it should be minimized to maintain momentum and efficiency for as long as possible. People with the same scope and objectives should work as an atomic unit, ideally colocated both in the organizational chart and, if possible, physically. This approach will significantly reduce the need for implicit connections.

• Adapt and evolve: Organizations are living entities and should evolve with the company’s focus and strategy. This is especially true for small and medium companies. Often, organizations fail to reflect these shifts because management hesitates to change. Reorganization is complex and can be damaging if mishandled, but senior management must tackle these issues head-on to prevent bigger problems down the line.

• Explain the organization to people: People are the company’s greatest asset. Avoid reducing them to mere nodes and connections (yes, I did it a bit in this article). Take the time to explain organizational changes. If people trust you and see the logic behind changes, it will reduce the friction associated with the fear of change. People need to be convinced, to be committed and to embrace change.

• Meaningful recognition: We should not rely on titles to please people, which create new layers. They are often a superficial form of recognition and their meaning can vary widely between companies. Instead, we should “promote” individuals through meaningful internal communication, praising their achievements, allowing them to represent the company at external events like conferences and meetups—putting them under the spotlights basically. Compensate them well and empower them by giving them significant responsibilities and opportunities to work on important projects. Recognition should be an integral part of the company culture and applied consistently, but it doesn’t have to be tied to climbing the organizational ladder necessarily. The organization should reflect the company’s business needs and strategic goals, not just what individuals want or have achieved. While having a certain degree of titles and positions can help people understand their responsibilities and establish clear points of contact, it’s crucial that the structure aligns with the company’s mission.

I’m not sure how to conclude this article, but while organizational structure may not be my favorite topic, it is crucial for the success of projects and, more importantly, the company as a whole. By keeping the structure simple, offering meaningful recognition, prioritizing people over processes, adapting to changes, and minimizing unnecessary connections, we can build an organization that supports and empowers its people while aligning with the company’s strategic goals. I understand that some managers view some of the issues I’ve mentioned as unavoidable and tend to be somewhat fatalistic. While I acknowledge that this is a very complex topic, especially in large companies with an extensive history where it’s impossible to reset the entire organization overnight, I also believe we too often give up on addressing these challenges.