How to Be a Super Good Engineering Manager (Without Becoming a Status Robot)
At 9:03 on Monday morning, a lot of engineering managers open Slack and become human middleware.
They collect updates from developers, repackage them for leadership, then retranslate decisions back to the team. It looks responsible. It looks organized. It even feels productive for a while.
But it is the wrong job.
If your best contribution every week is writing cleaner status summaries than everyone else, your team is paying executive rates for clerical throughput.
A super good engineering manager does something harder and way more valuable. They design a team operating system that creates clarity without constant supervision. They make work easier to start, easier to review, and easier to finish. They coach people into higher leverage instead of becoming the central routing layer for every detail.
The first shift: stop being the status collector
The biggest trap in engineering management is mistaking visibility work for leadership work.
Visibility matters. Nobody is arguing that leaders should fly blind. But if visibility depends on your manual effort, the system is broken. You are buffering a process problem with your personal stamina.
Google's Project Oxygen work became influential for a reason. The behaviors tied to stronger managers were not “attend more status calls.” They were coaching, empowering without micromanaging, clarifying strategy, and helping people grow.1
That is the point. Good managers do not hoard context. They create conditions where context is legible to everyone who needs it.
When updates are only trustworthy after your interpretation, your team has built dependency on you, not trust in the system.
The second shift: manage the system, not every person
Most management advice still reads like “be a better communicator” and “care about people.” True, but incomplete. You can care deeply and still run a chaotic team.
What changes outcomes is system design.
Who owns scope at each layer? What does “in progress” actually mean? Where do decisions live after a meeting ends? How does an engineer understand why a task matters before writing code?
If those answers are fuzzy, everything slows down. One team means “in progress” as soon as a branch is opened; another means “in progress” only after testable code is in review. Both think they are aligned, until roadmap updates stop matching delivery reality. Developers spend extra cycles guessing intent, reviews become debates about missing context, and planning turns into archaeology.
Team Topologies frames this cleanly: organization design exists to enable fast flow of value, and teams have cognitive limits you have to respect.2 In practice that means fewer ambiguous handoffs, clearer boundaries, and less random work sprayed across the same people.
Super good managers are obsessive about these boring foundations. They know that undefined language and unclear ownership create more delivery drag than any framework choice.
The third shift: turn one-on-ones into leverage, not therapy theater
One-on-ones are where most managers either compound trust or quietly lose it.
A weak one-on-one is mostly a status recap that could have been a comment. A decent one is emotional support plus tactical unblockers. A great one is career calibration in motion.
Your job in a one-on-one is to increase the other person's range.
That means sharpening decision quality, not just listening politely. It means finding repeated failure patterns before they turn into performance problems. It means giving specific feedback while there is still time to act on it. It means making sure people understand what “great” looks like in their current role and what evidence gets them to the next one.
When these conversations are good, they change behavior inside the same week. A mid-level engineer starts writing clearer problem statements before coding. A senior engineer delegates design work instead of hoarding it. A new hire asks for context earlier instead of going dark for three days and surfacing risk late.
Great engineering managers are coaches with standards. They are empathetic and direct at the same time. They do not choose between care and accountability.
The fourth shift: make quality a team habit, not a last-minute inspection
A surprising amount of management stress is self-inflicted by review debt.
When work arrives in giant, ambiguous chunks, every merge feels risky. People stop trusting estimates. Everyone starts hedging. You get “almost done” projects with no clear finish line.
The fix is not heroics. It is tighter flow.
Work needs to move in smaller, clearer chunks with a definition of done that everyone understands the same way. Review expectations should be explicit before coding starts, and feedback loops should stay short after merge so errors do not fossilize into architecture.
DORA's recent AI-assisted development research makes this even more urgent. AI tends to amplify the underlying system, not rescue it.3 If your execution model is sloppy, you will now create sloppy output faster.
A super good manager treats this as operating reality. They do not ask, “How do I squeeze more tickets out of the team this sprint?” They ask, “How do we reduce ambiguity so the same team can ship with less friction and less rework?”
The fifth shift: protect attention like it is production infrastructure
You cannot get high-quality engineering from a team that is constantly context-switching.
Yet many teams run like this by default: fragmented priorities, meeting sprawl, and endless “quick questions” that interrupt deep work all day. Then leadership asks why velocity feels unpredictable.
Because attention got shredded.
Super good managers defend focus on purpose. They limit work in progress, cut meetings that only restate ticket activity, and force priority decisions early instead of dumping every request into active work.
This is not about becoming rigid. It is about making tradeoffs explicit so engineers can actually finish meaningful work. The team should feel challenged, not scattered, and tired because they shipped hard things, not because they spent all day jumping between half-started tasks.
What being "super good" really means
Being a great engineering manager is not about charisma. It is not about being the nicest person in the room. It is not about having the most polished roadmap update.
It is about building a team system that remains clear under pressure. In that system, people know why they are doing the work, priorities stay stable long enough to finish something real, feedback is fast and specific, and ownership is visible without forcing everyone into reporting theater.
If you do that, your team will look calmer than other teams at the same growth stage. They will also ship more meaningful work with less theater.
If you want a practical starting move this week, pick one chronic confusion point and kill it completely. Make one status definition unambiguous, or make one decision trail impossible to lose, or make one review expectation explicit before coding starts. Great engineering management is built in these small operating contracts, repeated until the team stops depending on heroics.
That is what a super good engineering manager looks like.
And if you are building that kind of operating layer right now, that is exactly the problem we care about at One Horizon.
Footnotes
-
David A. Garvin, “How Google Sold Its Engineers on Management,” Harvard Business Review (2013), https://hbr.org/2013/12/how-google-sold-its-engineers-on-management ↩
-
Team Topologies, “Key concepts and practices for applying a Team Topologies approach to team-of-teams org design,” https://teamtopologies.com/key-concepts ↩
-
DORA, “State of AI-assisted Software Development 2025,” https://dora.dev/research/2025/dora-report/ ↩
