The Human System: Applying Engineering to Leadership

The Transfer of Fundamentals

In a recent article, Mallika Rao (Engineering Manager at Netflix) revisits a familiar friction point in our industry: the transition from maker to manager. She argues that when engineers move into leadership roles, they often stop applying the systems thinking they developed through years of hands-on engineering.

This is a massive missed opportunity.

We spend years learning how to optimize throughput, manage load, and debug complex interactions. Yet, when we step into management, we often treat the team as something entirely different, governed by vague intuition rather than structural logic. Rao suggests that systems thinking isn’t just for code—it is an essential toolkit for leadership.

Debugging the Organization

There is a fear that treating a team like a system might feel cold or mechanical. But the reality is the opposite.

“Thinking like an engineer about your team does not dehumanize it; it gives you clearer language and sharper tools to reduce friction for the humans inside the system.”

By applying engineering rigor to organizational problems, we can identify bottlenecks and failures without blaming individuals.

People Leaks

Consider the concept of a memory leak. In software, this is a failure to release resources that are no longer needed, eventually draining the system’s capacity until it crashes.

Rao uses this analogy to describe “people leaks”—situations where organizational energy is gradually drained due to structural issues:

• Zombie Projects: Long-running initiatives with no active stakeholders.
• Ritual Waste: Recurring meetings or documents that deliver zero value but consume hours.
• Role Collisions: Unclear or overlapping responsibilities that cause friction.

Just like a memory leak, these issues are silent killers. They don’t break the build immediately, but they degrade performance over time until the team burns out.

Latency and Load

The article also touches on the impact of overcommitting. In distributed systems, if you flood a service beyond its capacity, you don’t just get slower performance; you get timeouts, errors, and cascading failures.

The same applies to teams. Pushing utilization to 100% guarantees that “latency” (delivery time) and “error rates” (bugs/mistakes) will spike. Good leadership, like good engineering, is about managing load to ensure reliability.

Conclusion

If you are leading a team, you are essentially the architect of a distributed system made of people. You need to care about “organizational hygiene” and communication protocols just as much as you care about API contracts.

If these ideas resonate with you—or if you’re currently trying to debug your own team—I highly recommend reading Mallika Rao’s full article.¹