Will the Great Flattening Eliminate Engineering Management?

Evolving Views on Engineering Org Design

The future of engineering management has never been murkier. The 2010s felt like an enlightenment period for the profession, with tons of advancement on agreed best practices, and the publication of seminal books on the subject like The Manager's Path by Camille Fournier, or Will Larson’s highly regarded Elegant Puzzle. But during the last couple of years, we’ve seen a regular drumbeat of stories about tech companies reducing headcount, especially by shrinking their management ranks, a phenomenon that’s been called “The Great Flattening.”

The industry forces that have fueled the Great Flattening with its sharp focus on thinning the ranks and layers of middle management are clear: (1) the drive to financial efficiency in the post zero-interest rate period, and (2) the changing nature of work brought about by the AI revolution.

These two trends are multiplicative. Just as the post zero-interest-rate environment was driving us towards a seemingly insatiable thirst for efficiency, AI burst onto the scene to deliver what seems like unprecedented automation leverage for knowledge work!

The central tenet of the Great Flattening is clear: increasing the ratio of hands on engineers (ICs) to managers promises to simultaneously increase delivery capacity, reduce communication and collaboration overheads, and all while reducing costs. At least at face value, it’s a compelling idea! But what does it mean for engineering management as a profession?

The Drive to Efficiency

The drive to efficiency has been a major software industry trend for a couple of years now. In the frothy zero interest years of a decade ago, software companies were growing with abandon, snapping up talent wherever possible, the cost be damned. Growth at any cost was the mantra. Then, when interest rates returned to a more normal range in 2022, it sent shock waves through the industry, and drove a major push to efficiency.

This trend has placed a strong focus on management structures. For one thing, in a period of rapid growth, onboarding tons of new team members, norming team operations, and just generally managing clarity through fast change, a rich heavy management team was a benefit. But now with more thoughtful growth and steady-state execution, the argument goes that we need far fewer managers. This is a central explanation given by Meta, for example, as they’ve thinned their management team.

Additionally, the argument goes that too many layers of management slow down communication and dilute clarity. Think about cascading a strategic communication in a large organization with classic middle management structure. First you want the exec team to be of one mind and one voice, otherwise you’re just going to create cross-functional confusion. Next, you want to make sure that the VP layer is read in, clearly understands the decision, and has time to reconcile the new information with their organizational priorities. They bring it to their directors, who later bring it to their line managers, and finally to the teams on the ground, all likely with some back and forth for clarification, refinement, etc. The sequencing is important so that you don’t have any layers of management giving conflicting messages or talking across one another. But all that propagation takes time! And along the way, the message probably gets diluted, if not outright distorted. The drive to leaner management poses the idea, what if we could eliminate some of those layers, and drive the organization with more real-time communication and decision making, all with higher fidelity to true goals?

Beyond improving communication, the drive to efficiency has brought a return to the idea of focusing our investments more squarely on the direct technical contributors. Part of this implies a renewed focus on performance management, ensuring that the technical team is all A players. These engineers produce the most, and require the least amount of management attention. This all leads companies to focus on the idea of “builder ratio” – the ratio of engineers to other roles.

Smaller teams that are more self sufficient leads us once again to leaner management structures. The promise of the Great Flattening is clear: more capacity for direct value creation, with less communication friction, bringing faster and better clarity for our best engineers, and enabling the agency that affords.

The AI Effect

At the same time as we’re seeing a strong push towards smaller, flatter management structures, the advent of AI is providing a compelling picture of how teams can work effectively in this new model.

Leverage for Management and Individuals

AI directly influences how we think about management structures by making it possible to get the work of management done with fewer people. There’s no denying that a significant part of middle management roles revolves around being a communications connector to the rest of the organization. Managers take direction from above and translate it to activity on their team, typically in strong collaboration with the team itself, but ensuring the outcome that the team is aligned with higher level directives. And managers communicate plans and status up the organization, ensuring visibility and alignment.

If we dig into the actual work involved in those types of activities, we can see that AI helps with much of it. We can use AI to process large amounts of context – everything from product feedback, production issues, ticket backlogs, etc. – and propose task backlogs. AI can look at our ticketing system and update status tracking spreadsheets or compose status update messages.

The idea goes that by shrinking or largely eliminating middle management, individuals can make more timely and informed decisions, making teams faster and more responsive to changing conditions, and increasing the productivity of the organization – less time in Slack and meetings, more time actually doing the work that matters! And the org can unlock faster cycle times to testing ideas, making them more innovative and productive. Meanwhile, the communication, task definition, status reporting, etc., of management need not suffer, all thanks to AI automation.

Smaller AI-powered Teams

There’s also growing evidence that teams utilizing AI for software development can operate more productively with fewer people. Data is clearly pointing to the conclusion that AI speeds up core software engineering tasks. For example, Jellyfish looked at core engineering systems data (e.g., from Jira and Github) and found clear evidence of growing AI impact, such as PR cycle times for tasks where AI was employed being 16% faster in Q2 2025, and steadily speeding up month after month.

The speedups from AI have a potential knock-on effect for engineering team structures. With some of the less interesting workload offloaded to AI, and team members more productive and faster, the idea is that a smaller team can handle the same scope of ownership without sacrificing quality or developer experience. And furthermore, the idea is that smaller teams simply operate better. There’s less communication overhead, less room for miscommunication, and less opportunity for disagreement or conflict. Smaller is both faster and happier!

In turn, these better executing teams impose a lower management tax. There are fewer people to manage and fewer fires to fight. Again, all roads seem to point to being able to operate better with a leaner management structure.

Whither Engineering Management?

So how will this all net out in terms of software organization design? Will we continue to see the IC to Engineering Manager (EM) ratio grow from the 6:1 range of a few years ago, to the 8:1 or 10:1 ratios we’re seeing more regularly today, to who knows where – 20:1? More? And what will happen to management layers? What’s the future of the Engineering Director role, as traditionally imagined as a manager of around three to six managers and teams?

The Future Is Hybrid

I’ve previously written about why I believe the future of software engineering is fundamentally bound to be a hybrid of human and AI-driven work. For the foreseeable future, we will need humans to be accountable for our software systems, including aspects like quality, design evolvability, stability, etc. This means we’ll need significant teams of real practicing software engineers, complemented by AI, not replaced by AI. So as much as I believe there are very real benefits to adopting a leaner, more AI-assisted management structure, I believe that as a baseline assumption, we will still need reasonable human management structures.

The Nature of the EM Role

If you buy the hybrid argument, then you have to believe that the future of software development includes some people management work. But what is that work, really? Some of the arguments that AI will replace middle management characterize the work as pretty basic – essentially translating directives from above to tasks for the team, assigning those tasks, monitoring progress, and communicating status up and out.

Those are certainly some of the more basic parts of the role, but far from the most interesting or important. Engineering management is fundamentally about confronting the complexity and challenge of real people building and maintaining real software over extended periods of time, and having the experience be one that unlocks the team's potential to solve hard problems with innovative solutions. The EM may indeed fill out spreadsheets and update Jira tickets. But that’s not the job.

Software engineering at real scale is inherently collaborative. Interesting systems grow beyond the cognitive capacity of individuals, even exceptionally smart engineers augmented by AI. This means that teams matter, and will continue to matter. And even the most capable and experienced teams need the leadership of a manager.

One way to understand the richness of the EM role is to consider the idea of EM Archetypes. Various versions of this concept have been written up, but probably the clearest version was written by Pat Kua here. He describes five types of Engineering Manager styles, and from these we gain a good sense of the different types of needs that the EM role fills:

• Tech Lead EM: This is the Engineering Manager who is deep in the technology that the team works on, often acting as a player-coach and participating directly in development work. This is often the first role taken on by ICs experimenting with the idea of pursuing team management. Typically a Tech Lead EM will manage a smaller team, making this style ideal for instantiating new teams in new areas. A small team with a manager involved directly in the development work is great for getting something new established.

• Team Lead Manager: This style of EM is best at people issues, such as communication, rallying the team, working to build an environment of trust and growth, and ensuring that the team is performing at their best. In my experience, this is the most common and important EM style, since effectively unlocking the potential of the team, as well as managing performance, being great at recruiting, etc. – these are the core concerns of running a long-term healthy team that develops a product or technical area well over the long haul.

• Delivery-oriented Manager: This style EM is great at process and execution. While the people focused Team Lead is so often the right fit for innovation teams in high performing organizations, there are also commonly situations where process is the key concern. For example, some teams may own an area that is reactive and fundamentally more date driven, for example a team maintaining a large number of integrations with partner products that change with some regularity. In cases like this, having someone who is great at process ensuring both that the process is followed – and also that the process is well designed – can make a huge difference.

• Product-oriented EM: This style of EM complements or fulfills the role of a product manager or product owner for the team. On the one hand, this can be helpful in real world situations where there is not adequate product management coverage. But it can also be valuable in emerging or highly technical areas that are difficult to product manage without being in the engineering details.

• Manager of Managers: This type of EM represents the higher layers of engineering management, such as the Engineering Director role, where the position acts as a manager of managers. This role is critical to achieve scale while maintaining quality mentorship for the line EMs. In an org with 10 teams, can the head of engineering really thoughtfully mentor all of those managers?

Looking at these archetypes uncovers a deeper view of the role of engineering management. The highest value EM roles, and most of the work performed by these roles, isn’t “paper pushing.” A Team Lead EM may not write all (or any, in some cases) of the code, but they may be the person that forces the right conversation between two senior engineers to reconcile a common direction for the team. They may run the team meeting where the team decides on its next project and gets really excited about it.

All of the manager archetypes fulfill important need for the typical engineering org, and part of org design is thoughtfully selecting team and manager styles by product and technical area.

The truth is, we may value only the code, but the code is not inevitable. The problem selected doesn’t appear in neon on a big sign. Some of the best software engineers don’t start out with highly developed sensibilities about working well with others. Or about what is the best next area to focus on to reach even higher levels of ability. EMs enable the team function and growth that enables the right code to be created.

In other words, much as we don’t expect AI to replace all of software engineering, and probably not the most interesting parts of software engineering, I believe we also don’t expect AI to replace the need for engineering management, nor will it displace the highest impact “human factors” parts of the job.

Hypothesis

I land on the hypothesis that the drive to flatten and shrink engineering management structures is valid and valuable, but it should reach an equilibrium point beyond which I would expect negative impact. Personally, when we see teams with 10:1 IC to EM ratios, I suspect we’re already in that neck of the woods, depending on the type of team and the EM archetype.

Looking at org design, I believe it’s healthy for us to be pushing on the ratios, since AI should be giving our EMs growing superpowers, and should be greatly reducing the toil in the job. But at the same time, much as has been the case for ICs, I believe we need to look hard at performance management and expectations for EMs. I’ve seen a wide range of EM performance in my career, and the difference between a good EM and an OK EM is enormous. We need great EMs, especially if we’ll have fewer to go around.

The full range of EM archetypes continues to solve enduring problems in engineering organizations. And, contrary to the ideas of the Great Flattening, one could argue that in this time of AI transformation, which represents a major disruption for our industry, we need strong people leaders more than ever to help navigate the change.