As an industry, we like to shout a lot about experiments when we kick them off, all confident swagger that this time our superior intellects have landed from first principles on the correct reimagining of this or that piece of conventional wisdom. For a long time I had the idea of maintaining a receipts index for tech blogs, “Company X has declared Y is dead, do Z”, two years later, “Z is dead do Alpha!”. So many many examples in our industry it’s hard to choose just one example, but you could do worse than the Spotify management model, which continues to take the industry by storm over a decade later, despite wide acknowledgment that it didn’t work, and was never fully rolled out at Spotify.

Recently there has been a loud declaration that management is dead. Organizations should flatten. Managers retrain as ICs or be let go. Etc. Facebook has been one of the loudest advocates of this approach. Six months in, they’re asking ICs to move back into management.

A different thread running through the industry is the large number of managers opting out. There’s a sense that the work has gotten harder and less rewarding at the same time, with a mix of layoffs, tighter budgets, and typical founder psychosis turned to 11 by AI. (And fomo over those generating generational wealth)

These are two sides of the same coin. When organizations don’t understand why we have management, the role is undervalued and underinvested in.

And to be honest it’s easy to see how we got here. Much has been written (including by me) on how the 2010s was the industry on easy mode, money and customers were plentiful, technical challenges were minimal and largely outsourced to cloud providers, and the primary technique for improving a team’s capacity was to hire more people. (And then we speed ran this whole dynamic again during the pandemic, extending the 2010s even as the underlying conditions changed). It just wasn’t that important to be that good at engineering leadership (or really any form of leadership) for many teams for a long time.

But now it is.

The point of a technology company is to create change. The point of engineering leadership is to increase your team’s capacity to create change. And managers? Managers are catalysts.

“Catalyst” has a colloquial definition, but it also has a technical one: a catalyst lowers the activation energy necessary for a reaction to occur. That’s what good management does.

Without a catalyst you can still create change. You add heat and pressure. Mandates. They work some of the time, and damage the system 100% of the time. Sometimes that’s the right call. A little damage now, do the expensive repair work later. If you invest in management you have a choice. If you don’t, you don’t.

In Facebook’s case the move to dramatically reduce managers (some teams moving to a 50:1 ratio) at a time they were rolling out a radical revision to their software development process resulted in a 40% YoY increase in incidents, and a drop in team sentiment from 74% to 55% over a 6 month period. Code changes were up 220%, but new value delivered to customers didn’t follow in line. That is not the type of change any of us are hoping to create.

How managers go about lowering activation energy is not a secret. It’s your standard laundry list of manager virtues. Build trust, lower cynicism. Connect the team’s local goals to larger strategic priorities, and adapt larger directional guidance to local context. Invest in both team cohesion, and development. Apple pie stuff.

We’ve known this for decades btw. There’s a classic paper, In Praise of Middle Managers, built on a 3 year field study looking at what it takes to produce radical change. There are two failure modes: low commitment to the change produced inertia, and high commitment without attention to the people living through it produced chaos. Heat and pressure is the second one. Managers who don’t understand that lowering the cost of change is their job can be part of the first problem.

Many extremely well intentioned managers can end up impeding vs accelerating change. Managers who have internalized the “shit umbrella” archetype for example are likely to understand their role primarily as protecting the team from change versus increasing the team’s capacity to drive that change. That leads to a team that is underdelivering, and a burned-out manager. High performing “local optimizers” often resist change because they’ve got the system working the way they want it. Pass-through leaders who are doing none of the local adaptation of changes breed cynicism.

Your job, as a manager, is lowering that activation energy. Growth, learning and evolution are the work that you’re here to facilitate. Especially in times of change.

Your job as a leader is to invest in managers who can do this work. Train, celebrate, empower. There is a near-infinite list of new programs and processes that need to be managed, new training, new rituals, new anxieties. The idea that at this moment you need fewer managers because AI can summarize Jira is a fundamental leadership error.

If you’re seeing resistance to change. If you’re seeing burnout increasing. If you see individuals generating more code, but the impact isn’t accelerating at the same rate. If you want to transform your system of software development, the first thing you need is managers who understand the job.