Why Most Tech Managers Are Incompetent – Lessons from Real‑World Experience

Incompetent Behavior 1 – Using Engineer Mindset as a Manager

Many newly promoted technical managers continue to compare whose code is better, similar to a chef who focuses on knife skills instead of kitchen efficiency. The author’s first boss was technically strong—quickly locating root causes of incidents and articulating trade‑offs—but he demanded detailed implementation instructions, performed line‑by‑line reviews, and repeatedly sent back screens of change requests. When the author presented a week‑long design, the boss dismissed it with “direction is wrong, redo” without explaining why. This micromanagement made the author feel like a tool, leading to self‑doubt.

Some managers avoid management duties by writing code, ignoring team atmosphere problems, conflicts, and uncomfortable performance talks, rationalizing that code will not get upset with them. Management, however, requires confronting conflict, handling emotions, and accepting short‑term invisible effort, which the author describes as “anti‑human” and harder than coding.

Incompetent Behavior 2 – Focusing Only on Tasks, Ignoring People

The author describes a high‑intensity delivery period where the team worked day and night, delivered the project, but many members left because no one asked whether they were exhausted or saw a future for them. Treating the team as a machine—assigning requirements, accepting code, launching the project, and considering the job done—ignores emotions, career anxiety, and personal circumstances that never appear on boards or daily reports.

A competent manager must proactively learn who wants to change direction, who has new family responsibilities, who is bored with the tech stack, or who silently resists tasks. This information requires direct conversation, not automatic metrics.

Incompetent Behavior 3 – Only Managing Downward, Not Upward

Technical managers often excel at solving problems individually but forget that teams need resources, executive support, and cross‑department collaboration. The author observed a manager of five people responsible for three business lines who “floated” because he rarely reported progress. Leadership only saw occasional incidents; other departments perceived the team as a blocker. Without upward management—making effort visible, communicating risks, and advocating for support—the team suffers.

Why the Gap Exists

The article cites the Peter Principle: people are promoted based on past performance until they reach a role they are not competent in. In tech teams, strong engineers are repeatedly promoted to larger scopes (virtual leads → small group lead → whole business line) because past success does not automatically translate to managerial competence.

Technical excellence encourages reliance on familiar solutions, leading to a habit of personally handling issues, giving direct answers, and imposing personal standards on others. This creates a systemic “promotion inertia” where the best problem‑solvers are placed in roles that require solving people and organization problems.

Lack of Systematic Management Methodology

Most technical managers lack formal training in management practices. While design patterns and architectural principles exist for engineering, management knowledge often comes from ad‑hoc sources: copying a boss’s style, repeating overtime‑driven projects, or equating personal firefighting with managerial ability. Consequently, skills such as one‑on‑ones, performance conversations, feedback, rejecting unreasonable requests, upward resource negotiation, and balanced incident post‑mortems are learned through trial and error.

Suggested Practices (as described by the author)

Accept that personal coding excellence is no longer the primary value metric; the team’s ability to continue delivering without you is the key indicator.

Reserve regular weekly time for one‑on‑ones to discuss work, ideas, personal status, and any concerns such as family or workload.

Report progress, obstacles, and resource needs transparently to the appropriate stakeholders, ensuring the team’s effort and risks are visible.

Recognize and own mistakes, correct them promptly, and avoid persisting on a wrong path.

Conclusion

The author, with over a decade of technical experience and six years of management, observes that most tech managers are ineffective not because they lack ability but because promotions happen too quickly and systematic learning is too slow. Recognizing this mismatch is the first step toward change. Management, like coding, is a craft that requires deliberate practice.