Middle Management is Cooked, The Great Flattening Is Upon Us
Tremble all ye in middle management, the end is nigh!
Or, that’s at least what a lot of headlines would have you believe.
Good news, bad news, management as a practice isn’t going away, but the role itself is shifting quite a bit. If you’re an engineering manager or middle manager in an organization, know that the days of focusing only on forming, storming, norming and performing are behind us.
Now, there are certainly some corporate worlds where the 18 levels between an IC and the CEO will continue to have the padding, but small to mid-size companies (1-500 employees) are likely to see those layers shrink.
The recent Coinbase layoff had me thinking about this quite a bit. Snippets below are from Brian Armstrong’s post on X.
As more and more companies put in AI adoption strategies and initiatives, they’re realizing that the world of hierarchy gets pretty clunky pretty fast. Meta, Coinbase, and more point to operational efficiencies they want to see from the flattening of the org structure.
Fewer layers, faster decisions
The dream! We all want to make faster decisions and with The Great Flattening there’s never been a better time.
Fewer layers, faster decisions: We are flattening our org structure to 5 layers max below CEO/COO. Layers slow things down and create coordination tax. The future is small, high context teams that can move quickly. Leaders will own much more, with as many as 15+ direct reports. Fewer layers also means a leaner cost structure that is built to perform through all market cycles.
Leaner cost, lower coordination tax, but a higher mental tax for those leaders owning “much more.” I’ve managed 22 direct reports across multiple disciplines. It’s doable until any one of them has a problem.
The counter-point is this: most ICs don’t want the hierarchy to begin with. In many cases senior leadership creates layers to ward off the people problems and not have to deal with tasks deemed as “not highest use.” And honestly, I agree with that stance!
A CEO should not need to determine if an employee can take a sick day to take their cat to its dance recital. As much as we’d love to watch Donut pirouette amongst the cat trees, a CEO probably doesn’t want to spend any brain cells thinking about it. (yes, I’m reading Dungeon Crawler Carl)
We’ve been in the town halls where an IC asks why their work-from-home budget doesn’t cover their Funko Pop collection. That is not a “best use” question for any executive.
Tactically, figure out what are the right chains of communication and how do you optimize those. As you optimize you’ll find that each layer of communication needs a filter. Someone has to manage those filters and suddenly you’re back to a management layer. “All employees should communicate the same,” I hear you grumble. That may be true, but if you’ve ever talked to anyone, ever, you know it’s not the case.
I wouldn’t be surprised if we eventually see many of these layers start popping back up over time. New titles, or lightly re-invented titles, but a management layer regardless.
No pure managers
No pure managers: Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams.
Again, lovely thought. The tools at our disposal make IC work much more accessible for managers and having a sense of the struggles in a CI/CD pipeline aren’t readily noticeable until you as a manager are feeling that pain as well.
It’s another point where I don’t disagree, but it also depends on the size of the team and what you’re looking for long-term. A manager is not just an employee that deals with people, they’re also:
Hiring Manager
Resource Manager
Delivery Manager
Quality Assurance Checker
Analytics Looker
Cross-functional Point Person
Facilitator (meetings, mentorship, and more)
Culture Cultivator
Technical Debt Farmer
Stakeholder Connector
Temperature Checker
Ceremony Czar
Squeaky Wheel
Tracker Downer of the Unreachables
General Umbrella For Everything Else
People problems take careful consideration and many times when I’ve been a player-coach, I found myself spending longer hours working in order to catch up on my IC work. People are messy and don’t really fit into nice little boxes.
Code problems are finite, all the other problems are broad explosions with ripple effects.
If you don’t care about most of those bullets, then by all means, your managers can be way more hands on. But that is where they will struggle. Many times we say it takes engineers 20 minutes to get back into the flow after a disruption, same for a manager, except they’re normally hopping around between meetings throughout the day.
Kill the meetings, create more space, and player-coaches can thrive. Keep things status quo and they’ll burn out quick.
There’s a reason the era of baseball with player-managers ended with Pete Rose. With a heavier focus on data and analytics, managers need to focus exclusively on in-game strategy and matchups, rather than physically playing the game.
So what can you do about it as a manager?
In all likelihood, you have no control over what your company decides to do in The Great Flattening. You’re merely along for the ride.
What you can control is how can you prepare for tomorrow and the future. Honestly, I’d suggest doing most of these regardless of the Flattening status of your business.
Get Familiar with the tools your team uses
If you’re not in there already, get your team’s repos set up locally and make sure you can pull the latest code. Get your setup up to par with what you would expect of a new hire and get comfortable wandering around.
Is there a CLAUDE.md file yet? Create one. README.md out of date? Update it.
Follow best practices
Please, please, please follow best practices. Your team already has these (most likely) and you should already be monitoring to make sure they are sticking to best practices (you’re already doing that, right?). The worst thing you can do is come in and be a “rules for thee, but not for me” type, so hold yourself to that standard.
Start tackling triage and P2s
Do not take the most important work. If you were technical previously, it may seem fun to assign yourself the best, most fun work, but resist the urge. Check out your Triage queue and grab some work from there. Learn how all the systems connect together, review diagrams, and ask dumb questions (to Claude or humans).
Learn to dig! Track down those pesky bugs through the stack and figure out how to solve unsolvable problems.
Whatever the path, take work that needs doing, but is not critical feature work. Your engineers are smart and if you’ve built your team right, they’re all better ICs than you. Leave it for them.
Form Opinions About Management In The AI Era
Any interview you go to is going to ask you your stance on AI and productivity. You need to have an opinion, and there’s no better way to form an opinion than by looking at your current setup. If you want more details on this topic comment below and I’ll write another post about it specifically.
Learn
Read blog posts, listen to podcasts, take some courses, build some apps. Explore and understand where you think AI should and shouldn’t be used, both in code and in management.
For becoming a solid player-coach, that’s probably it’s own post in the future, but hopefully this gives you some ideas on how to survive The Great Flattening. Stay safe out there.