Life in a hierarchy: survival guide
Life in a hierarchy: survival guide
Organizational structure affects your day-to-day work, you'd better know how your area is organized.
Where your organization sits in the company might significantly affect your day-to-day work. Things that matter to senior leaders tend to spread out and shape the team's direction. Furthermore, reporting hierarchy impacts how your team is perceived.
Every company is unique, yet there are common patterns. Recognizing these patterns helps to identify leverage points and the right stakeholders to get the job done.
It's unlikely that a company with a thousand employees will have a flat structure. There will probably be four or five managers between the CEO and the individual contributors. Reporting lines help to keep people together who need to work closely and separate people who don't need to interact often.
The challenge is to figure out who needs to work together.
Common types of structure
One option is to let engineers report to engineering managers, and engineering managers report to engineering directors. By this logic, designers report to design managers, data scientists to data managers, and product managers to product directors. Let's call this a function-oriented structure, meaning that similar job families report to the same manager.
Alternatively, all people required to run the specific business area might report to the same manager, regardless of what they jobs are. Let's call it a product-oriented structure. The definition of areas is very specific to the company's business model. For example, a SaaS company may have a customer-facing are where users can subscribe for the service. Another area for the same company might be about integration with other SaaS providers.
There is no perfect structure, each has its flaws. There is no universal advice which one to adopt. In the function-oriented structure, it's not obvious who defines priorities and funds projects. Product-oriented structure might overemphasize immediate need to deliver and overlook long-term needs such as architecture, refactoring, quality.
The two structures above might be implemented as they are, but it's also common to build a hybrid structure. There are reporting lines: engineers report to engineering managers, designers report to design managers. In addition to that, there is a person who manages a group of people required for a specific project or product.
This type of organization called a matrix structure. Notably, this structure has two types of managers: functional and resource managers. The resource manager is the official one, they handle performance evaluation, career grow, and all the administrative stuff. Functional managers is a person who defines priorities and scope of the work. For example, a data scientist reports to a data manager, but they are also working with an engineering team for the next six months on a big project. So they join team daily meetings, deliver work required for the project, and, actually, might interact very little with their official manager.
The structure sets the context
The org chart influences prioritization, decision-making. It might even make a great work not visible for the right stakeholders. Org structure also influences the architecture1. The structure you're in defines the context around your team. Some people say that in a big organization, culture follows structure2.
Structure defines priorities
The company might have priorities, but each department also has its own goals. These goals aren't necessarily aligned. It's quite common for function-oriented structure to have craft-specific objectives. The user experience leadership is pushing for a new design. Engineering leaders are calling for a big architecture project. Data leaders are concerned with the big data migration. These locally defined priorities might not be aligned with the company ambition to grow the business. Yet, when the performance of craft leaders depends on delivering a design initiative or completing a data migration, they will push for their agenda.
Aligning your team goals with the priorities of the parent organization is important. Balancing between company priorities and local priorities is a fine art. All important developments in your area should be connected to company or department priorities and have a good rationale for investing effort.
Structure impacts decision-making
In a product-oriented structure, the decision-maker is clear. They may not have all the necessary information to make the decision, but at least you know whom to speak to.
In matrix and function-oriented structures, responsibilities may be unclear, and many people might be involved in the decision. In these structures, a common mistake is to ask everyone for approval.
Imagine a scenario where the team wants to introduce a block with personalized recommendation on the main page of a retail website. The manager of the team goes to the boss of product managers.
The product leader nods, but asks how much effort it will require and if it has been aligned with engineering. The manager of the team talks to the engineering boss, and she says that the change sounds reasonable, and we can allocate engineering capacity to work on it. However, the engineering leader wonders if people from data science can build personal recommendations.
The manager then goes to the data science leader, who says that they cannot build a personal recommendation within a reasonable time frame. Instead, they can show the most popular products on the platform, so it's better to ask the product people if that still makes sense. Oops, we're in the loop now.
Good relationships with people, communication skills and knowledge of stakeholder needs are required to navigate situations like that.
A piece of advice worth mentioning:
Tip: Ask for objections, rather than asking for approval.
Some people might be reluctant to approve your idea because they don't know if they have the power to do so. They might also be focused on other priorities or too busy to think about your idea thoroughly.
When the decision maker is unclear, it helps to reverse the situation. You give everyone a chance to speak up, and then you act in the absence of objections to your proposal.
Applying this to the previous example, the conversation between the team manager(TM) and the product leader(PL) might look like:
— TM: Hi, I wanted to ask you about the personal recommendation proposal. Do you see any product risks or how this initiative might harm other developments?
— PL: No, I think it makes sense. I'm not sure if it has been aligned with engineering.
— TM: I am talking to them later today and let you know how it went. Then we agreed that there are no blockers on the product side to move on?
— PL: Correct, keep me in the loop what other managers say.
— TM: Sure, will do.
Recognition of the work
Each type of structure is better at certain aspect of the work. What your boss recognizes as a great work will depend on what they are incentivized to achieve. This affects what people are rewarded for and what type of behavior is frowned upon. A product-oriented structure naturally prioritizes the business impact. This is important, but it may be dangerous if the business impact is the only criteria.
For example, engineers might be rewarded for quick solutions, creating unreasonable technical debt for the short-term benefits. Even worse, engineers might be discouraged from actually doing the engineering work like testing, automation, refactoring.
In a function-oriented structure, the emphasis might be on complexity and standardization, and the value for the end customers and the company might not be clear.
In a matrix structure, different managers focus on different things. To highlight relevant aspects of the work done by your team, you need to understand stakeholders needs.
Incentives shape the definition of success, they create implicit rules for what successful teams or individuals do. Look for teams that are being praised and individuals being promoted, and you will understand what your organization truly values.
Power struggle
Sometimes different parts of the company have conflicting objectives, that cause tension between teams. This could create situations where one team achieving their goal means the other team fails. When teams' objectives are in conflict, it is difficult for them to work together.
Let's take an example. Team A oversees an overall user experience on an online shop. They care about page load speed and bounce rate. The goal of Team B is to promote new products and categories, which is why they put banners on different pages to get traffic. These two objectives are in conflict. When Team B's roadmap is dependent on Team A, interesting things start to happen. Team A has little incentive to support Team B—Introducing new content might harm load speed and bounce rate.
Such situations often happen between platform and product teams. A platform team is focused on completing the migration to the new technology, while a product team is focused on delivering business features. The product team might escalate the conflict and push back on the migration. But then next month the product team asks for support from the platform team. Will it create trouble?
Situations like these could have different outcomes depending on the escalation path through the organizational chart, the decision-making power of senior leaders, and higher level priorities.
Relationships with people work on top of the formal hierarchy. This is why it is essential to maintain good relationships with people you might work with in the future. It is one thing to have competing objectives. It is an entirely different thing to do harm to people you know and respect. Building relationship with people is never a bad idea.
Conclusion
The org chart affects many things in a company. It creates implicit rules within teams, affects communication, and defines priorities and key stakeholders.
Understanding which type of structure you are and its strengths and limitations is a key skill for managers.