The Visible Job vs. The Real Job
An engineering manager's calendar is a testament to the visible parts of the job. It's packed with recurring meetings: one-on-one check-ins to support team members' growth, planning sessions to map out the next sprint, and stakeholder updates to ensure
everyone is aligned. They are responsible for hiring, project execution, and maintaining technical quality. These are the tangible, necessary, and often urgent tasks that keep a team functioning. They are the tactical treadmill of management. But focusing only on these tasks is like judging a chef only by how well they chop vegetables. It's essential, but it’s not the whole recipe. The real, higher-leverage work happens in a different gear. The most effective managers understand that their primary role isn't just to manage tasks, but to build and tune the machine that executes those tasks.
The Practice: Architecting The Human System
The hidden practice behind the most successful engineering managers is this: they treat the team itself as a complex system to be designed, debugged, and optimized. This is often called "systems thinking." Instead of just solving isolated problems—a missed deadline, a conflict between two engineers, a buggy release—they look for the underlying patterns and interconnected forces that caused them. Poor communication isn't just a single event; it's a symptom of a flawed information flow. Burnout isn't just one person's problem; it's a sign of a system with unsustainable load. Their job transitions from being the best coder or problem-solver to becoming an architect of the human system. They ask different questions: Where are the communication bottlenecks? Are our review processes creating psychological safety or fear? Is knowledge concentrated in one person, creating a single point of failure? They are, in essence, applying engineering principles to the organization itself.
Why This Practice Stays Hidden
This practice remains largely hidden for a few key reasons. First, it's invisible when done well. A team with excellent communication flows, clear roles, and high trust doesn't look extraordinary from the outside; it just looks like it works. The manager's efforts in preventing chaos are much harder to see than their actions in fighting fires. Second, this work is not urgent, though it is incredibly important. The pressure to ship the next feature or fix the immediate bug always feels more pressing than redesigning the team's onboarding process. Finally, this work is hard to measure. You can track tickets closed and features shipped, but it's much harder to put a number on improved psychological safety or the long-term benefit of resolving a recurring source of team friction. As a result, many managers—especially those promoted from senior engineering roles—revert to the tangible, technical work they know, rather than embracing the ambiguous, human-centric systems work that truly defines great leadership.
Putting the Practice into Play
Cultivating this systems-thinking approach is an intentional act. It starts with shifting from a reactive to a proactive mindset. Instead of just running 1-on-1s, great managers use them to map out individual motivations and career goals, aligning them with team needs. Instead of just leading meetings, they audit them, asking if each one is necessary and if the right people are in the room. They treat recurring problems like bugs in a codebase: they are triaged, investigated to find the root cause, and a systemic fix is implemented. This could mean creating a new process for code reviews, establishing clearer communication channels between teams, or deliberately creating opportunities for junior engineers to grow their skills and reduce knowledge silos. They act as a "force multiplier," creating an environment where the entire team's effectiveness is amplified, rather than just adding their own individual output.
