Recognize and avoid the most common engineering management failures. Covers hero culture, absence management, scope creep, meeting overload, and the leadership anti-patterns that silently destroy team velocity, trust, and retention.
Engineering managers are the glue between technical teams and strategic direction. This page documents recurring failures in how engineering managers execute their role—patterns that, once adopted, become deeply embedded, hard to change, and ultimately detrimental to team health, delivery velocity, and engineering quality. These anti-patterns emerge not from ignorance but from well-intentioned habits that misfire under pressure, scale, or time. They matter when teams grow beyond a few people, when managers take on more than one team, or when engineering shifts from reactive maintenance to proactive innovation.
A quarterly roadmap is a planning document that outlines goals, initiatives, and expected delivery dates. It is not a contract. When engineering managers treat it as such, teams are locked into fixed timelines, feature sets, and priorities—often with no mechanism to adapt mid-quarter.
A typical roadmap is a spreadsheet with columns for initiative, owner, status, start, end, and notes. The manager exports it to PDF, shares it via email, and sets a quarterly planning meeting to review progress. The meeting starts with a slide titled “Q3 Roadmap Review,” and the first item is “Status: 72% complete.” The team reports: “We’ve completed 12 of 17 features.” But the manager asks: “What’s blocking the remaining 5?” and the team replies: “We don’t know. We’re just moving forward.”
The root issue: no feedback loop between roadmap execution and planning. The roadmap is static. Teams work through it without updating it. The manager checks off items but never validates if the work was valuable.
The anti-pattern is evident when teams submit pull requests with the exact commit message:
feat: implement user profile edit screen
[Q3-ROADMAP] #142The PR is merged, and the change is logged in the roadmap. But no one checks whether the new feature was used. No one measures if the change addressed the original problem. No one links the PR to a user story or a KPI. The roadmap becomes a backlog with dates, not a living plan.
1:1s are the primary tool for one-on-one development. Yet engineering managers often use them as status meetings. The structure is predictable: each team member reports on “what they did this week,” “what they plan next,” and “what’s blocking them.”
This leads to a pattern: a recurring meeting where the report is the goal, and the manager is a passive listener.
The typical 1:1 agenda is a Google Doc with the following sections:
The manager adds comments: “Nice job on X.” “Can you clarify Z?” “Please track time on Y.” But the conversation rarely goes beyond the checklist.
The failure mode: the 1:1 becomes a status report, not a growth forum. The engineer is not challenged. The manager does not probe deeper. They miss the opportunity to identify development needs, career goals, or systemic bottlenecks.
The sharp edge: the manager assumes that because the engineer has listed a blocker, it is being addressed. But no one owns the follow-up. The manager writes “Need approval on design doc” in the 1:1 notes but fails to create a task in the project tracker. The team member waits. The approval is delayed. The design doc collects dust.
Engineering managers often run team meetings that look like daily standups but are used for deep work. The agenda is: “Update on current sprint,” “Review PRs,” “Discuss blockers.” But the meeting is 90 minutes long, with no time for discussion.
The meeting starts with a slide titled “Sprint Review,” and each person gives a 3-minute update. The updates are read from notes. There is no discussion of trade-offs, risks, or design decisions.
The meeting structure is rigid:
But the team is not engaged. The manager asks: “What’s blocking you?” and gets a list. But no one asks: “Why did we choose this approach?” or “What if we had done it differently?”
The failure mode: meetings become ritualistic but not impactful. The team does not improve its practices. Decisions are made in silence. The meeting is a broadcast, not a dialogue.
The sharp edge: the team has a shared document—a Confluence page or a Notion dashboard—where all meeting notes are collected. But the document is rarely updated. The manager copies the agenda into the meeting notes, but the discussion is scattered across Slack threads, email replies, and whiteboard photos. No one connects the dots between the meeting decisions and their execution.
Promotion is a key career lever. But engineering managers often promote engineers based on technical skill alone, without defining what success looks like at the new level.
A typical promotion process involves:
But the promotion is not followed by a clear expectation document.
The result: the new Senior Engineer performs at a level expected of a mid-level engineer. They write good code, fix bugs, and review PRs. But they are not expected to lead design discussions, mentor junior engineers, or drive technical initiatives.
The manager assumes the new senior is “more senior” but does not articulate what “senior” means.
The sharp edge: the promotion packet includes a section titled “What does a Senior Engineer do?” but the manager never shares it with the team. The new senior engineer receives a LinkedIn post announcing their promotion but no onboarding plan. After three months, the manager asks: “How’s your first quarter as Senior Engineer?” The engineer replies: “I’ve been coding, reviewing, and fixing bugs. I feel like I’m doing well. But I’m not sure what I should be doing differently.”
The engineering manager declares: “All code must go through a PR.” This becomes a policy: “Every change must have a PR with at least two reviews before merge.”
But the PR is not the source of truth. The PR is a transactional artifact. The real source of truth is the team’s shared understanding, the codebase, and the team’s culture.
The manager sets up a GitHub repository with the following configuration:
---
title: "[Feature] <summary>"
assignees: []
labels: [enhancement, needs-review]
milestone: "Q3"And a check for required reviews:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/.github/workflows"
schedule:
interval: "weekly"
reviewers:
- "engineering-manager"
- "senior-engineer"The PR is created. Two engineers review it. The manager approves it. The PR is merged. The team celebrates.
But the manager never checks whether the PR was the starting point for the conversation. The discussion is scattered across comments, GitHub issues, Slack threads, and Zoom recordings.
The sharp edge: the PR is a checklist of tasks, but the team never links the PR to a user story or a design document. The manager assumes that because the PR is approved, the work is done. But the product team never validates the feature. The QA team finds bugs that were not discussed in the PR. The deployment fails because the PR did not include the database migration script.
The failure mode: the PR becomes the final artifact, not the beginning of a conversation. The team does not use the PR to document decisions, trade-offs, and learnings. The PR is a transaction, not a narrative.
JIRA is the central system of record. The manager assigns every task to a JIRA ticket. The team updates the status: To Do → In Progress → Review → Done → QA → Deployed.
But the manager relies on the ticket status without reading the content.
The ticket is created with a title and a description. The manager adds a due date and assigns it to a team member. The team member updates the status and adds a comment:
Updated database schema and added migration script. Ready for review.The manager checks the board: “All tickets in ‘Done’.” But they never open the ticket.
The sharp edge: the manager assumes that because the ticket is marked “Done,” the work is complete. But the description is vague. The team member wrote: “Fixed the login issue.” But the ticket has no acceptance criteria, no test cases, no links to designs.
The failure mode: the manager sees a completed ticket but does not know what was delivered. They cannot explain the feature to stakeholders. They cannot answer: “What problem does this ticket solve?”
The sharp edge: the manager exports the JIRA board to CSV and shares it with the executive team. The report shows: “52 tickets completed in Q3.” But the executives ask: “Which tickets were the most important?” and the manager replies: “The ones with the highest priority.” The report does not include the content of the tickets. The team’s work is invisible.
The engineering manager introduces decision records as a way to document technical decisions. Each decision is a Markdown file in the team’s documentation repository:
# DR-001: Choose PostgreSQL over MySQL for the new analytics service
## Problem
Our analytics service needs to support complex queries, time-series data, and JSON columns. MySQL has limitations in these areas.
## Options
- PostgreSQL: strong support for JSON, window functions, full-text search
- MySQL: mature, easy to scale, good for read-heavy workloads
- DynamoDB: serverless, highly scalable, but limited query flexibility
## Decision
We will use PostgreSQL as the primary database for the analytics service.
## Rationale
PostgreSQL supports JSON, window functions, and full-text search out of the box. It scales well with complex queries. The team has prior experience with it.
## Consequences
- Increased complexity in database operations
- Need to train team on advanced features
- Better query performance for analytics workloadsThe manager creates the file, links it in JIRA, and adds the decision to the team’s decision log. But the decision record is not published.
The sharp edge: the decision record is stored in the documentation folder, but no one reads it. The manager does not link it to the PR or the design document. The team does not use it to guide implementation.
The failure mode: the decision record is a static artifact. It is created once and forgotten. When a new engineer joins, they are not told about the decision. When a problem arises, the team does not refer to the decision record.
The sharp edge: the manager expects teams to use the decision record as a reference but never checks whether they do. The team continues to use MySQL for analytics, even though the decision was to use PostgreSQL. The decision is not followed.
A weekly engineering meeting is scheduled to make decisions. The agenda is posted: “Decisions: Choose database for new service, select CI/CD tool, define error budget for production.”
The meeting starts with a slide: “Today’s agenda: 3 decisions.” The team discusses each one. The manager facilitates. The team votes. They agree on PostgreSQL for the database, Jenkins for CI/CD, and 1% error budget.
But the meeting is not followed up.
The sharp edge: the meeting is recorded, but the recording is not transcribed. The team discusses the error budget, but the decision is not documented. The manager assumes that because the team agreed, the decision is made.
The failure mode: the meeting is a conversation, not a decision process. The team does not define the decision criteria. They do not capture the trade-offs. They do not assign owners to follow-up actions.
The sharp edge: the manager creates a JIRA ticket for each decision but does not link it to the meeting recording or the discussion notes. The team members do not know who is responsible for implementing the decision.
The sharp edge: the team agrees on PostgreSQL but does not update the decision record. The manager creates a new document but forgets to add the rationale, the options, and the consequences.
The result: decisions are made in meetings, but no one knows what was decided or why. The team repeats decisions every quarter, and the same problems reappear.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy