Golden Rules for Organizational Structure

Guidelines for designing successful tech organizations

In the realm of organizational structure inside a technology (or R&D) org, I’ve observed many different structures over the last 25 years. Through that, I’ve developed a set of guiding principles and best practices I think provide broadly optimal results. While these aren't rigid mandates, they serve as valuable starting points for fostering productive conversations when organizations deviate from these principles.

If you’re a 2-person startup, this post isn’t for you - but when you’re anticipating scaling rapidly, or you’re already at 100s or 1000s (or even 10s of thousands) of software & product folks, I hope you’ll find this guidance helpful, because it’s designed with you in mind.

Before we get started, a note about terminology & role names. I will use terms that are broadly in use across medium to large technology companies, although obviously there’s variation. One company’s Director is another company’s VP, for example. Not every company has “Senior Staff” engineer roles, but most have “Principal Engineer. Etc. You’ll have to translate the terms I’m using into the roles and levels at your company before you implement any of these. I’m going to cover engineers, product managers and their management counterparts since those typically make up 90% or more of a technology org. There are other roles that are sometimes part of technology orgs such as Technical Program Managers; User Interface/Experience Designers; Product Marketing Managers — the general guidance below could be applies in general those roles, but the specific ratios will be different.

Defining the Essentials

Organizational Health encapsulates an organization's adeptness in functioning effectively, adapting to change, and nurturing internal growth — ultimately driving high performance. Tackling organizational complexities or pain points cultivates active engagement, heightened productivity, and enhanced performance.

Organizational Effectiveness gauges how effectively organizations fulfill their missions and propel their visions through core strategies. Human Resources and Organizational Development efforts must align seamlessly with desired business outcomes.

Organizational Design aims to craft an organization that optimally aligns with and brings to life the business strategy and goals.

Being Intentional about Org Design

1. Communicate and rally buy-in around these "golden rules" or guiding principles. You can’t have directors or VPs building a Monaco-like fiefdoms that operates by their own rules. This is a discipline everyone needs to follow (hiring managers, execs, recruiters, HR) at all levels of management.

2. Initiate an HR-assisted "organizational structural assessment" across the entire organization (all functions), highlighting misalignments with the model and guiding principles.

3. Engage your functional leaders (e.g. engineering & product VPs, principal engineers) in discussions about potential concerns, exploring connections between structural misalignments and execution challenges.

4. Functional leaders then collaborate with HR and executive leadership to devise a comprehensive plan for gradual adjustments, potentially involving leadership or individual contributor hires, organic evolution, reorganization, and more.

5. Audit periodically (more on this at the end) to determine if you’re trending towards a more optimized design. Hold top-level organizational leaders as responsible for a healthy organization as you do for delivering results or operational excellence.

6. Bonus Suggestion: Collaborate with HR to establish robust individual contributor (IC) career ladders for PM, TPM, Design, Marketing, and other roles beyond engineering. This often-overlooked element ensures that you’re communicating that ICs can advance their careers, increasing their compensation and influence, without the need to transition into managerial roles.

The "Golden Rules" Unveiled

The guidance principles are divided into the following areas: Span of control, Layers, PM to Engineering Ratios, Engineering Seniority Proportions

Span of Control (Spans)

This refers to the number of subordinates or direct reports that a manager or supervisor oversees and/or manages within an organization. It represents the breadth and extent of the managerial responsibilities that a single individual can handle while ensuring efficient communication, coordination, and supervision. In essence, it defines the range of employees for whom a manager is directly accountable and responsible for guiding, directing, and evaluating their work. The concept of span of control is crucial in designing organizational structures and determining the hierarchical relationships within a company. My guidelines for an effective span of control, by level of manager are:

• Managers (often described as “line-managers”) should oversee 6 to 10 reports. Newer managers should not be over-burdened with directs. More senior managers, especially those on the verge of promotion to director, can handle up to 12. In either case, beyond 12 it becomes very difficult to effectively conduct 1:1s, mentor your new employees, hire, and do the "individual contributor” (IC) work that most front-line managers still own.

• Directors, VPs & above are capable of managing 8-12 reports. Typically the majority of a Director+ direct reports will be managers (or directors for VPs), with the rest being senior ICs. You need to expect and assume a level of independence from the more senior directs a Director+ would oversee.

• No one with a Management title (including Directors and VPs) with less than 5 direct reports. When you intend to rapidly grow a team you can include your “open reqs” as part of your span calculation for that manager. If you don’t or won’t have enough direct reports to satisfy this condition, you don’t need another manager in your org. The only exception I’d make is for newly minted “team leads” where someone is managing a couple of employees as part of their intended transition (or a try-out) into management.

Some words about organizational scope:

• Directors typically manage between 25 to 100-person orgs (including sub-organizations managed by other managers). Senior directors handle a range of 50 to 200-person orgs. VPs are responsible for 100 to 500+ person orgs.

  
  The overlap between these recommendations is intentional (and one of the ways you determine when a manager/director is ready to promote is the scope of the organization they’re managing already being at the “next level”)

• Managers, Directors, and VPs should ideally be at the same or higher level as the ICs they oversee. For instance, if a manager holds a "level 6" position, they should manage ICs who are also at level 6 or below. Similarly, if a "Principal Engineer" (PE) holds a level 7 position, their manager should hold a position at level 7 or higher. Again, these numbers may vary in your organization, but the concept is the same. This alignment ensures management is at roughly the same or higher level of experience and seniority as the people they manage. This level-aligned reporting relationship also provides senior ICs with a clear career path to advance within the IC track, allowing them to expand their scope and influence without feeling obligated to transition into management — a choice many may not desire or be suited for.

Layers

In organizational design, "layers" refer to the hierarchical levels or depth within a company's structure. These levels help establish the chain of command, reporting relationships, and communication pathways within the organization. The number of layers in a company's structure can vary and is often determined by factors such as the organization's size, complexity, industry, and management philosophy.

Each layer represents a distinct level of authority and responsibility, with individuals at higher layers having more decision-making power and overseeing those at lower layers. Typically, the higher you are in the layers, the broader the scope of responsibilities and the greater the level of strategic decision-making.

Maintaining an optimal number of layers within the organizational structure is vital to mitigate the risks associated with excessive hierarchical levels. When layers proliferate without a well-defined purpose and efficient information flow, communication breakdowns can occur, leading to bottlenecks in decision-making and reduced overall organizational efficiency. By maintaining an appropriate number of layers, the organization can enhance its agility and responsiveness, better equipping itself to swiftly navigate and adapt to dynamic shifts in the business landscape. My guidance for layers and keeping them as flat as possible is that:

• The median gap between the lowest level ICs and VPs should be 2 layers of management (IC → Manager/Director → VP should be the norm)

• The maximum gap between the lowest level ICs and VPs should not exceed 3 managers (IC → Manager → Director/Sr Director → VP is OK) where IC → Manager → Manager → Director → VP is generally not). If have a very large org and few levels (such that VPs have 1000+ people), you might see IC → Manager → Director → Sr Director → VP. But going back to our spans guidance, you should ensure that each layer is required for the business and employees to function.

• No “I-shaped teams” - I shaped teams have a VP at the top, then very deep vertical hierarchies with a number of managers/directors with few directs, and then a layer of ICs at the bottom. Between the “gap” & span guidance, these are the first management roles you should look at consolidating/eliminating. Either that or transition those managers back into ICs, because that’s what they are functioning as. I sometimes see this when companies don’t have strong IC tracks, so in order for anyone to get a raise or more scope, they have to be promoted into a “management” role. I strongly suggest fixing this problem at its root, because having a bunch of managers-in-name-only is toxic to an organization’s effectiveness and sends the wrong signal to employees about what managers do.

Product Management Ratios

The ratio of Product Managers (PMs) to Engineers is hotly debated, but I find if you think about the stage your product (or company) is in, it’s helps a lot.

When Incubating new Products, it's recommended to initiate the process with a lone PM overseeing the incubation phase. As the project advances through its early stages, consider adopting an initial ratio of 1:1, involving one Product Manager and one hands-on Technical Lead (TL), facilitating a focused collaboration and separation of concerns in terms of who does what. This ratio expands over time, gradually transitioning towards the normalized ratios established for early life, fully developed and late-life products.

In the context of Early Life Shipped Products, my standard guideline is to maintain a ratio ranging from 1:7 to 1:10 (1 PM to 7 to 10 Engineers). This proportion effectively balances the responsibilities of Product Managers to the engineering teams, ensuring efficient but not burdensome oversight and coordination. This is still enough PMs that you can engage heavily with prospects or customers and be incubating new (or add-on) ideas.

As products progress into the Fully Developed, Late Life and Optimization phases, it's prudent to further fine-tune the ratio between Product Managers and Engineering teams. Within this context, an optimal range of 1:12 to 1:20 is effective. This range accounts for the reduced scale or frequency of product changes and the heightened clarity surrounding well-defined customer base and their needs.

As far as managing product managers, I have observed that many PM managers (like UX leaders) are still doing IC work. You’ll often see PM Managers or Sr Managers with “only” 4 directs and PM Directors/Sr Directors with a max of 6-8 direct reports. I’m not generally a fan of many-layered PM hierarchies (PM IC → PM Manager → PM Director → PM VP). At most I’d want to see only 2 layers of depth (PM IC → PM Manager/Director → PM VP). In most cases the org is better flattened or split up and aligned with the lines of business the PMs are supporting. Being “PM heavy” or worse, “PM-manager-heavy,” means you have folks churning out ideas that you don’t have the people to build. Avoid this if you can.

Engineering Ratios

Creating an effective engineering organization involves getting key ratios and focus areas right to ensure a productive balance between innovation, technical know-how, and strong leadership.

Engineering Roles Focus: Features vs. Non-Features

One important aspect is how you divide engineering work between creating new features and handling other essential areas. Strive for a 70/30 split, with roughly 70% of effort directed toward building new features, and the remaining 30% addressing things like common services and security. Achieving this balance through a central team helps unleash creativity while maintaining critical functions. This is just a rule of thumb, but I find that if you tilt too much towards the “common services” you’re likely missing out on delivering differentiators that mean the difference between a growing product line and stagnation. Conversely if you ignore common services/security you put your ability to scale, your availability, etc.

Very mature organizations can often optimize their level of “keeping the lights on” by dedicating small teams to delivering a platform the rest of the team can operate on top of. I’ve seen rare top-performing organizations where a 90/10 split still works.

Engineering Team Levels and Technical Leadership Ratios

Building your engineering team requires careful consideration of roles and experience levels. Regularly assess the mix of junior (entry-level), senior, and principal engineers (PEs) to prevent any imbalances of skills & expectations and foster an environment of oversight, mentorship and growth for your engineering population. Here’s what I’ve seen work for reasonable mature products.

• Aim for 30% of your org junior/entry level. You can have a little less or more, but not more than 40%. The “onboarding tax” becomes too high and there’s not enough senior level guidance to go around. Mistakes tend to multiply in “bottom-heavy” organizations.

• 40-50% of your org should be mid-career level. This is your population of people who know how to get things done with minimal oversight, likely both at your company and elsewhere, and they can mentor junior engineers, while still having room to grow in their own career.

• 20% of your org should be the senior-most ICs in technical leadership (typically “Senior Staff” and “Principal Engineers” - some larger companies also have Senior Principal and Distinguished Engineer/Fellow levels). You may choose to count your senior management in this bucket, depending on how hands-on they still are at providing technical leadership.

Again, like with PMs, the stage of your product may require different ratios than this (an incubating project may not be able to afford to train up as many entry level engineers just learning - especially if it’s a product that requires domain specific expertise. Conversely, in a very large organization or one that is in continued scale-up, it’s desirable to have more entry-level engineers - both to help address expected attrition, and to provide a pipeline of future senior-level talent.

Relatedly, how you distribute the senior engineers — both in terms of to whom they report and which products they work on — will have a large impact on everyone’s success. Anti-patterns like clustering all the senior engineers on the one “hot product” and ignoring common services, security, operational excellence should be avoided. Pay special attention to teams with more junior engineers, who benefit from the presence of people more senior in terms of setting all kinds of expectations and examples.

The senior engineers are force multipliers when deployed correctly. Conversely, a bad senior engineer can have a huge blast radius, so you have to promote/hire very carefully in these roles.

You can apply these same ratios and rules-of-thumb to other roles like PMs and TPMs, but those orgs tend to be much smaller I see more variation in their org design.

---

Monitoring Organizational Health

I’d strongly recommend organizational health review meetings be separated from any of your other operational mechanisms such as a weekly staff or operations meeting. Org health is a complex, deep topic, and it can either be given short-shrift if stuffed into a business/ops review, overwhelming discussions that need to happen around product, engineering & go-to-market. Org health needs to be appropriately compartmentalized and discussed with a group of senior-level people that are able to have the right level of transparency, trust and discretion - whether discussing DEI, attrition, performance management or a topic such as a “return to office” initiative.

What I’ve seen work is a comprehensive monthly or quarterly review where you review a set of metrics by sub-organization and across the organization, that cover how you’re doing on these golden rules, but also how the organization is doing on its DEI goals, and on hiring velocity (how quickly you fill open job requisitions), attrition (voluntary and otherwise), location strategy (if you’re trying to shift where people are hired or maintain certain ratios of staff to locations). You can even cover general sentiment (as measured by well-defined surveys, not anecdotes).

This would be attended only by the most senior leaders (typically directors, VPs, PEs) in the org and the HR business partners that support those orgs. As needed you can have a “special topics” section in these review meetings where you dive deeper into topics like “hygiene” around your open job requisitions (do they meet company standards for job descriptions, have they been open too long, are there too many of them for the budget, etc); composition/cost by org (country spread); recruiting accepts/declines/pipeline, etc. When there are periodic top-down driven exercises such as “what would you do with 10% less headcount” this is where you’d have that discussion started/kicked-off.

If your org is huge (i.e. many VPs reporting to an SVP/EVP), the VPs can first conduct org health reviews with their own management team, including discussing trends and observations about their own organizations, as preparation for the VPs coming into an SVP-wide org-wide health meeting. Then you can follow with a higher-level/broader org review with an SVP and the VPs.

---

Closing Thoughts

It's crucial not to fixate excessively on any single aspect of organizational health or become overly rigid in following the golden rules to the point where common sense is disregarded. Establishing written organizational design guidelines, robust career tracks for both individual contributors and managers, and implementing thorough auditing processes provides a solid foundation for organizational growth and health.

However, it's important to acknowledge that in these discussions, strong voices can sometimes dominate. While it's essential to listen to all perspectives, effective leaders also display the necessary resolve to prevent any single voice from monopolizing conversations, diverting focus, or pursuing personal agendas at the expense of the factors that genuinely contribute to a thriving organization. Your primary objective is not to please everyone but to build a successful business, which hinges on a well-functioning organization.

By modeling this behavior and setting expectations for your leaders, you create a ripple effect throughout the entire organization. Embracing and aligning with these golden rules empowers technology org leaders to fine-tune their organizational structure, enhancing efficiency, promoting sustainable growth, and nurturing a team dedicated to the long-term success of the business