The End of the People Manager
Why Engineering Leaders Must Become Designers
First, Anthropic says the AI is capable of taking on a manager’s job. Now, Airbnb CEO Brian Chesky puts a target, stating that the era of the pure people manager is over. (see the recent interview: How Brian Chesky Is Redesigning Airbnb for the AI Era)
For the last decade, the tech industry has popularized a very specific archetype of leadership: the detached people manager.
As organizations scaled, a clear divide emerged. Engineers built the product. Managers built spreadsheets, facilitated 1-on-1s, and acted as organizational therapists. The conventional wisdom was that as you climbed the leadership ladder, you had to step back, delegate, and leave the craft behind.
In the interview, Chesky introduced what he calls “AI Founder Mode,” and his core argument is a wake-up call for the industry:
In a future accelerated by AI, leaders who only manage people—without direct contact with the reality of the work—will not survive.
The leaders who thrive will be makers, creators, and engineers who manage through the work itself.
Why Now? The Return of the Maker
For years, stepping away from the codebase made logistical sense. An Engineering Director couldn’t realistically code a feature because scaffolding the boilerplate, setting up the environment, and debugging took 40 hours. We had to delegate.
Stepping away from coding for long months was also my experience. Even though it felt bad to me, the only thing I was capable of doing during a work week was fetching the latest version of the app and launching/debugging it. In more complex projects, I wasn’t able to do even that - local env setup was so complex, I couldn’t spin it up for hours.
AI destroys that bottleneck. Tools like Copilot or Claude Code drastically lower the cost of creation. What used to take a week of engineering time can now be prototyped in 15 minutes. AI gives leaders their maker tools back.
There is no longer an excuse to be out of the details. The future belongs to those who embrace the full identity of a maker, creator, designer, and engineer.
The Engineering Leader as an Industrial Designer
Chesky didn’t compare this new leadership style to traditional software architecture. He compared it to Industrial Design.
Industrial design is a deeply technical, empathy-driven field. You don’t just design a machine; you design how a human interacts with it in the physical messy world.
Chesky shared a story about designing a child’s ventilator. The technical requirement was simple: pump oxygen. But the design requirement was intensely human: the machine couldn’t look terrifying to a six-year-old, it couldn’t induce panic in the parents, and it had to be perfectly usable by hospital staff.
In industrial design, there is no assembly line where “Product” hands over a spec and “Engineering” blindly implements it. The creator is the problem solver.
When mapping the physical-to-digital journey for RunArt’s 3D-printed topographies, or architecting the core flows for the ScoreLabs platform, I hit this exact reality. A clean database schema and green CI/CD pipelines weren’t enough. Absolutely no single customer cares about that.
You have to think like an industrial designer making a physical product. You have to look at the entire ecosystem and ask: How does this actually feel in the user’s hands?
We Are Already Doing This (We Just Need the Language)
When I listened to Chesky’s thoughts, I realized this is exactly what the Product Engineering philosophy advocates for.
Some time ago, I also codified this into The User-Friendly Engineering Framework. Engineers are taught to think in systems, inputs, and edge cases. We often view design as subjective or emotional. But good design isn’t about taste—it’s about reducing human confusion. And reducing confusion is a highly technical discipline.
Here is how the industrial design mindset maps directly to the realities of software engineering:
1. Wear the User’s Skin (The Empathy Gap) In software, engineers carry invisible context—we know the architecture, the naming conventions, and the latency expectations. Users don’t. When a user stares at a “Processing...” screen and refreshes the page, they aren’t using the system wrong. We failed to provide the right feedback. You have to strip away your insider knowledge to see the design bugs.
The Monday Morning Litmus Test: Tomorrow morning, block 30 minutes. Use your product end-to-end. No debugger. No admin access. No shortcuts. Write down every single moment you hesitate. Those aren’t user errors; those are your design bugs.
2. Design Across Time, Not Screens (The User Journey) Industrial design is taught through continuous user journeys, not isolated touchpoints. In software, we often obsess over a single flow—a working “Export to CSV” button. But UX outages almost always occur in the gaps between steps, sessions, and teams. A feature can work perfectly in isolation, but if the overarching journey is broken, the product fails.
3. Engineering Doesn’t Ship Code. It Ships Behavior. You can design a perfectly working backend system, but if it teaches the user the wrong mental model, you have broken the contract. If your UI looks like a timeline, users expect a history. If it looks like a checklist, they expect an undo function. The new era of engineering leaders must own the “why” and the “what” just as much as the “how.”
The Best Engineering Disappears
Chesky noted that the magic of great design is distillation—stripping a system down to its absolute, fundamental essence.
When a product feels simple, it is never because the system itself is simple. It feels simple because someone did the hard thinking upfront, making the complexity invisible.
But you cannot distill what you cannot see. Industrial designers use physical prototypes to find friction; Product Engineers use telemetry. Distilling a product to its essence requires leaning heavily on modern observability—leveraging OpenTelemetry and DORA metrics to see exactly where users get stuck and where the system drags. Telemetry is the software equivalent of watching a human struggle with a physical prototype.
That is the true job of an engineering leader in the AI era. You cannot lead the builders if you have forgotten how to build. You must be a product engineer. You must be a designer of systems.
Ready to dive deeper?
The concepts above are just the surface. If you want the operational manual for building like an industrial designer, I have codified all 8 pillars of this mindset into The User-Friendly Engineering Framework.
I agree that AI will likely replace large parts of administrative management work such as reporting, coordination and performance tracking. And I also think many organizations have layers of management that add too little real value today.
At the same time, I wonder if this perspective may underestimate a very human need that still seems highly relevant, especially among younger employees entering the workforce.
Many are not necessarily asking for less leadership. In my experience, quite a few are actually looking for clearer expectations, more frequent feedback, stronger recognition, measurable progress and closer guidance in navigating complexity and uncertainty.
It also makes me reflect on whether we sometimes mix up ineffective management with leadership itself. There is probably a meaningful difference between managers mainly focused on coordination and reporting, and leaders who help create clarity, trust, direction and growth.
Being seen, understood, challenged and encouraged by another person feels fundamentally different from receiving automated insights or recommendations.
It actually makes me wonder whether the rise of AI could increase the value of good people leaders rather than reduce it. Especially leaders who are able to create belonging, psychological safety and meaning in increasingly complex organizations.
This way of rethinking the management role is actually quite invigorating. Though I think if we reduce the manager purely to maker and product designer, the counterargument becomes that every IC should become this builder too, so why need manager.
I think what comes with the leadership role is an extra layer of orchestration: between the customer you're building for, the organisational vision, commercial viability, and the peers and parallel workstreams across departments. And the users that require empathy aren't just end customers, they are the team, the stakeholders, the peers. As they develop not a product but an entire department they lead within other complex systems.