Engineering Manager Anti-Patterns

TL;DR

Effective engineering managers are crucial for team productivity and morale. However, common anti-patterns like the hero manager, absence manager, yes manager, micromanager, and metrics obsessed manager can severely impact team performance and lead to burnout. This guide provides a comprehensive overview of these anti-patterns, their impacts, and practical steps to address them.

Why This Matters

Engineering managers play a pivotal role in shaping the success of their teams. According to a survey by the State of DevOps Report, teams with effective leadership are 2.5 times more likely to meet their release goals and are 3.3 times more likely to achieve their service level objectives. Poor management practices can lead to decreased productivity, high attrition rates, and a decline in overall team morale. By recognizing and addressing these anti-patterns, managers can create a more productive, engaged, and successful engineering team.

Core Concepts

The Hero Manager

The hero manager is a manager who writes most of the critical code. While this may seem productive, it leads to a single point of failure and stunted team growth. Managers should delegate the hardest work and focus on coaching rather than coding.

The Absence Manager

The absence manager is never available, always in meetings. This leads to a lack of direction and decision-making paralysis. Managers need to block time for their team and be available to make strategic decisions.

The Yes Manager

The yes manager accepts every stakeholder request, leading to scope creep and missed deadlines. Managers should prioritize their team’s capacity and protect the sprint from unnecessary work.

The Micromanager

The micromanager reviews every pull request (PR) and decision, stifling independent thinking and innovation. Managers should define quality standards and trust their team to meet them.

The Metrics Obsessed Manager

The metrics obsessed manager focuses on quantity over quality, leading to meaningless data and poor decision-making. Managers should use metrics to inform, not dictate, their decisions.

Implementation Guide

Code Example: Defining Quality Standards

Let’s define a simple quality standard for a pull request (PR) review process using GitLab CI/CD. This example will include a code block with proper syntax highlighting.

# .gitlab-ci.yml
stages:
  - build
  - test

build:
  stage: build
  script:
    - echo "Building the project..."
  artifacts:
    paths:
      - build/

test:
  stage: test
  script:
    - echo "Running tests..."
  only:
    changes:
      - src/**/*.js
    - src/**/*.py

This configuration ensures that all code changes are built and tested before merging. Managers should trust their team to meet these quality standards.

Code Example: Protecting the Sprint

To protect the sprint from scope creep, managers can use a velocity planning board with GitLab. This example demonstrates how to set and track sprint goals.

# Sprint Planning Board
sprint-1:
  - feature-a: "Implement feature A"
  - feature-b: "Implement feature B"
  - bug-fix: "Fix critical bugs"
  - design-review: "Review design for next sprint"

sprint-2:
  - feature-c: "Implement feature C"
  - feature-d: "Implement feature D"
  - bug-fix: "Fix critical bugs"
  - design-review: "Review design for next sprint"

This planning board helps managers and teams to stay on track and avoid scope creep.

Anti-Patterns

1. The Hero Manager

Symptom: Manager writes most of the critical code. Feels like: “I’m the only one who can do this right.” Result: Team never grows, manager burns out.

Bus Factor: 1 (the manager) Team Skill Growth: Zero Manager Availability: Zero (always coding)

Fix: Delegate the hardest work. Coach, don’t code. “If it scares you to let someone else do it, that’s exactly the thing you should delegate.”

2. The Absence Manager

Symptom: Never available, always in meetings. Feels like: “I’m so busy with strategy and stakeholders.” Result: Team has no air cover, decisions stall.

Team Blockers: Pile up Decision Latency: Days instead of hours Team Trust: Eroding

Fix: Block 2 hours daily for team. Cancel one meeting.

3. The Yes Manager

Symptom: Accepts every stakeholder request. Feels like: “I don’t want to disappoint anyone.” Result: Team drowns in work, nothing ships.

Sprint Scope: Grows 2x by mid-sprint Team Morale: Declining Delivery: Consistently late

Fix: “Let me check team capacity” → protect the sprint

4. The Micromanager

Symptom: Reviews every PR, approves every decision. Feels like: “I need to maintain quality standards.” Result: Team stops thinking independently.

PR Review Bottleneck: 2-3 day wait Innovation: Zero (why bother, manager will change it) Attrition: High performers leave first

Fix: Define quality standards, trust the team to meet them

5. The Metrics Obsessed Manager

Symptom: Measures everything, understands nothing. Feels like: “We need data-driven management.” Result: G

Decision Framework

Criteria	Option A	Option B	Option C
Team Growth	Low	Medium	High
Decision Latency	High	Medium	Low
Team Morale	Low	Medium	High
Attrition Rate	High	Medium	Low
Quality of Work	Low	Medium	High

This table helps managers make informed decisions by weighing the impact of each option on team growth, decision latency, team morale, attrition rate, and quality of work.

Summary

Key Takeaways

• Delegate the Hard Work: Encourage team members to take on challenging tasks to grow and develop.
• Block Time for Team: Ensure managers are available to provide direction and make strategic decisions.
• Prioritize Team Capacity: Protect the sprint from unnecessary work by checking team capacity before accepting new requests.
• Define Quality Standards: Trust your team to meet quality standards, but define clear expectations.
• Use Metrics Wisely: Use metrics to inform, not dictate, decisions. Focus on meaningful data that impacts team performance.

By recognizing and addressing these anti-patterns, engineering managers can create a more productive, engaged, and successful team. Managers who adopt these practices will see a significant improvement in their team’s productivity and overall success.

Example of a code review process

def code_review(pr): if not pr.code_quality: return “Code quality issues found. Please address them.” if not pr.security_issues: return “Security issues found. Please address them.” return “Code review passed.”

Example of a pull request object

class PullRequest: def init(self, code_quality, security_issues): self.code_quality = code_quality self.security_issues = security_issues

Example usage

pr = PullRequest(False, True) result = code_review(pr) print(result) # Output: “Code quality issues found. Please address them.”

# Example of a meeting scheduling script
import datetime

def schedule_meeting():
    meeting_time = datetime.datetime.now() + datetime.timedelta(hours=1)
    print(f"Meeting scheduled for {meeting_time.strftime('%Y-%m-%d %H:%M')}")

# Example of a capacity management script
def check_capacity():
    if check_team_capacity():
        print("Team capacity is sufficient. Proceed with request.")
    else:
        print("Team capacity is low. Request cannot be accepted.")

def check_team_capacity():
    # Simulate a capacity check
    return False  # Assume low capacity

# Example of an automated PR review process
def auto_review(pr):
    if pr.meets_quality_standards():
        print("PR approved. Merge now.")
    else:
        print("PR needs improvements. Address issues before merging.")

class PullRequest:
    def __init__(self, meets_quality_standards):
        self.meets_quality_standards = meets_quality_standards

# Example of a balanced scorecard implementation
def balanced_scorecard():
    metrics = {
        "productivity": 0.4,
        "customer_satisfaction": 0.3,
        "innovation": 0.2,
        "quality": 0.1
    }
    scores = {
        "productivity": 85,
        "customer_satisfaction": 90,
        "innovation": 70,
        "quality": 95
    }
    scorecard = {metric: metrics[metric] * scores[metric] for metric in metrics}
    print(scorecard)