Anyone who has worked in tech long enough knows that troubleshooting a distributed system is usually straightforward compared to troubleshooting human communication. When a BGP session fails to come up or a Kubernetes pod refuses to schedule, the logs give you an error code, a trace ID, and a clear path to a fix. People management rarely offers that level of observability.
Recently, a colleague ran into a classic workplace scenario that highlighted the stark difference between someone who knows how to lead people and someone who simply holds a management title. In this post, I want to walk through what happened with a manager we will call Carl, compare two very different management responses to the exact same issue, examine why micromanagers struggle with actual leadership, and look at a few practical ways to help an untrained manager improve.
The Scenario
It started with a brief comment from Carl to one of his direct reports. He told him that some of his recent remarks had come off as criticisms to the engineering team. That was the entirety of the feedback. There were no specific examples, no context around which conversation triggered the concern, and no suggestions on how he should adjust his approach moving forward.
In engineering terms, it was the equivalent of receiving an alert that says "something is broken" with no timestamp, no hostname, and no stack trace. You cannot fix a problem you cannot reproduce or inspect.
Since Carl had no details to offer, the direct report went straight to the source and spoke with the engineering manager where the feedback originated. That conversation took a completely different turn. The engineering manager pulled up an actual example, walked through the context, and explained the root cause. Because several of the engineers involved were not familiar with the direct report yet, his direct questions over Slack were missing vocal inflection and facial cues, making the tone feel uncertain or overly critical. More importantly, the engineering manager offered concrete ideas on how to soften the phrasing when asking those kinds of technical questions in text.
Comparing the Two Responses
Looking at both interactions side by side makes the contrast obvious. Both managers were looking at the exact same friction point, yet they handled it in fundamentally different ways.
| Attribute | Carl | The Engineering Manager |
|---|---|---|
| Role Played | Messenger / Relay | Coach / Problem Solver |
| Context Provided | None | Specific Slack thread and team background |
| Root Cause Analysis | Absent | Recognized remote-text tone ambiguity |
| Actionable Advice | None | Concrete tips on softening written questions |
| Outcome | Confusion and frustration | Clarity and immediate adjustment |
The engineering manager succeeded because he stayed close to the problem and focused on the outcome. He understood that cross-team collaboration breaks down easily over asynchronous text, especially when people do not know each other well. His goal was to keep the teams working smoothly, so giving practical tools to bridge that gap solved the issue for everyone.
Carl, on the other hand, acted as a simple packet forwarder. He took a secondhand complaint, passed it along raw without asking a single follow-up question, and considered his job done.
Micromanager Paradox
At first glance, it is easy to assume a manager who delivers vague feedback is simply hands-off or lazy. The catch in this case is that Carl is the exact opposite of hands-off. He micromanages down to the minute details of how work artifacts should look, nitpicking formatting, structure, and phrasing.
That combination, obsessing over trivial details while completely failing at people development, is a well-known pattern in technical organizations. It usually comes down to a few core shortcomings:
- Control as a coping mechanism. Managers like Carl, who were often promoted because they were strong individual contributors, frequently feel out of their depth when dealing with interpersonal dynamics, cross-team politics, or coaching. To feel useful, they retreat to what they know: controlling documents, layouts, and artifacts.
- Confusing "managing" with "doing." Instead of viewing their role as developing the people on their team, they treat every deliverable as their own personal work product. Their focus is on making sure an artifact looks the way they would have built it, rather than helping the engineer grow.
- Zero bandwidth for leadership. When a manager burns all their mental energy inspecting font sizes and slide layouts, they have nothing left over to investigate team friction, ask probing questions, or mentor their reports on communication.
Ways to Help Managers Improve
When working for someone who lacks formal management training, waiting around for them to suddenly develop coaching skills is a losing strategy. While you cannot force a manager to change overnight, a direct report can manage up in ways that steer them toward better habits and make day-to-day life easier in the process.
- Feed the detail habit early. Before investing hours perfecting a document or presentation, share a rough outline or wireframe with Carl upfront. Letting a micromanager weigh in on structure early satisfies their need for control before the heavy lifting happens, saving everyone from endless rework later.
- Prompt him to apply his detail orientation to feedback. When Carl brings vague, secondhand criticism, put the ball back in his court using his own strengths. Ask him directly to grab an exact example next time so there is concrete data to work with.
- Close the loop with facts. After resolving an issue directly, like speaking with the engineering manager, circle back and briefly summarize what was learned and how the approach was adjusted. Showing Carl what good resolution looks like sets a clear standard without making it confrontational.
- Outsource mentorship. Recognize his limitations for what they are. If a direct manager cannot provide career growth or communication coaching, lean on other engineering leaders, senior peers, and mentors across the organization who actually know how to develop people.
Wrapping Up
Good management is not about policing formatting or passing along unverified complaints. It is about providing context, removing blockers, and giving people the feedback they need to operate effectively. Until a manager learns the difference between controlling work and leading people, the best approach is to treat them like an unreliable network link: verify the packets yourself, route around the bottlenecks, and keep building direct connections with the people who actually want to solve problems.
