The Engineering Manager's First 90 Days Playbook

The Engineering Manager’s First 90 Days Playbook is a field guide for new engineering leaders stepping into a team, product, or organisation. It is not a checklist, but a sequence of focused, actionable workstreams — each tied to a clear outcome — that define the manager’s priorities from day one through quarter one. The playbook assumes no prior knowledge of the team’s systems, processes, or culture. It guides the manager through discovery, alignment, and early impact, with concrete inputs, outputs, and decision points derived from real engineering workflows.

Days 1–14: Immersion and Diagnosis

Map the Engineering Ecosystem

Begin with a 24-hour deep dive into the current state of the engineering function. Use git to clone the core repositories, kubectl to inspect running clusters, and psql to query production databases.

kubectl get deployments -A
kubectl get pods -n production --show-labels

# Find the most recent deployment for the user service
kubectl rollout status deployment/user-service -n production --timeout=30s

Check the build and deployment history using git log with a structured format:

git log --graph --oneline --decorate --all --since="2 weeks ago" --grep="merge"

Use psql to extract failure data:

SELECT
  count(*) AS failures,
  avg(duration) AS avg_duration_ms,
  max(duration) AS max_duration_ms
FROM
  error_logs
WHERE
  timestamp > now() - interval '7 days'
  AND service = 'auth'
  AND level = 'error';

Conduct 1:1s with the Engineering Team

Schedule 45-minute 1:1s with every engineer, product manager, and engineering lead. Use the same template for consistency:

• What’s working well in your role?
• What’s frustrating or blocking you?
• What’s one thing you wish you had changed about the engineering process?
• What’s the single most important thing you’d want me to know about your work?

Transcribe key themes using a shared Google Doc with section headings: *People*, *Process*, *Tooling*, *Systems*, *Challenges*. Identify recurring pain points: “slow CI”, “poor onboarding”, “missing documentation”, “frequent deploys breaking production”.

Diagnose the Development Workflow

Trace a single code change from commit to production. Start with a PR in GitHub or GitLab.

# Inspect the CI pipeline for a recent PR
curl -H "Authorization: Bearer $CI_TOKEN" \
  "https://api.github.com/repos/organization/project/actions/runs?per_page=10"

Check the logs of the build job:

# Fetch logs from a specific workflow run
curl -H "Authorization: Bearer $CI_TOKEN" \
  "https://api.github.com/repos/organization/project/actions/runs/123458/logs" \
  -o build-logs.tar.gz
tar -xzf build-logs.tar.gz
cat build/logs/build.out

Look for failure patterns:

• “Build succeeds but test suite fails”: verify test configuration in jest.config.js.

// jest.config.js
module.exports = {
  testEnvironment: 'node',
  testMatch: ['**/test/**/*.js'],
  collectCoverageFrom: ['src/**/*.js'],
  coverageDirectory: 'coverage',
  reporters: ['default', 'jest-junit'],
  setupFilesAfterEnv: ['<rootDir>/test/setup.js']
};

• “Deployment succeeds but service is down”: check systemctl status app.service on the target server.

# Check systemd unit for the app
systemctl status app.service --no-pager -l
journalctl -u app.service --since="2 hours ago" --no-pager

> Sharp Edge: A deploy logs Success but the service is unreachable. The cause is often a missing restart in the systemd unit file. The ExecStart command runs but ExecStartPre or ExecStop is misconfigured. Always verify systemctl status output and journalctl logs after deployment.

Days 15–45: Alignment and Planning

Facilitate a Team Workshop: “How We Ship”

Gather all engineers and product leads for a half-day workshop to define and align on the core engineering practices. Use a whiteboard or Miro, and follow this structure:

1. Map the current workflow in real time: *From idea → code → test → deploy → monitor → feedback*.
2. Identify pain points using sticky notes: one per issue, grouped by theme (e.g., “CI/CD”, “Onboarding”, “Monitoring”).
3. Define the ideal state for each phase, using the same format as the current state.

Use git to version the output:

mkdir -p workshop/outputs
git add workshop/outputs
git commit -m "Workshop output: How We Ship (2024-10-15)"
git push origin main

Draft the Team Charter

Create a team-charter.md file in the shared documentation repository. Use this structure:

# Team Charter: User Service

## Mission
Deliver a reliable, scalable, and user-centric identity and authentication system.

## Key Responsibilities
- Design and implement new auth features
- Maintain and improve the user profile service
- Handle user onboarding flows

## Success Metrics
- 99.9% uptime (monthly)
- < 2s average request latency (P95)
- 80% of onboarding steps completed by users

## Core Engineering Practices
- All PRs must include a `docs/changes.md` file
- CI must pass before merge
- All services must have a `healthcheck` endpoint at `/health`

## Team Norms
- Daily standups at 9:30 AM
- Biweekly retrospectives with action items tracked in Jira
- Code reviews completed within 48 hours

Review the charter with the team in a synchronous session. Use git to capture feedback:

git checkout -b draft-charter
git add team-charter.md
git commit -m "Updated team charter with feedback"
git push origin draft-charter

Define the First 30-Day Delivery Goal

Choose one high-impact, well-scoped initiative to deliver in the first 30 days. It should be:

• Clear in outcome (not just effort)
• Owned by a single team or person
• Deliverable within 4 weeks
• Visible to stakeholders

Use Jira, GitHub Projects, or a Notion board to track it.

Create a milestone:

{
  "title": "First 30-Day Goal",
  "description": "Improve user onboarding completion from 60% to 75% in Q4.",
  "due_date": "2024-11-15",
  "target": "75%",
  "status": "in-progress",
  "owner": "user-service-team",
  "linked_issues": [
    "https://jira.example.com/browse/ONB-123",
    "https://github.com/organization/user-service/pull/456"
  ]
}

Days 46–90: Execution and Influence

Launch a Biweekly Engineering Sync

Set up a recurring sync that is not a status update but a forum for decision-making and problem-solving.

• Agenda template (shared in Google Calendar and Confluence):

## Engineering Sync — October 30, 2024

### 1. Priorities for the Next Two Weeks
- [ ] Update on onboarding completion project
- [ ] Review proposal for new monitoring stack

### 2. Open Forum
- [ ] What’s blocking you?
- [ ] What’s new in your domain?

### 3. Decision Review
- [ ] Proposal: Move from Docker Compose to Kubernetes for staging
- [ ] Action: Finalize onboarding flow design

Use curl to automate status updates:

# Post update to Slack using webhook
curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Engineering Sync: Onboarding completion project is now at 70%.",
    "channel": "#engineering"
  }' \
  https://hooks.slack.com/services/ABC123/DEF456/GHI789

Identify and Resolve a Critical Bottleneck

Select one recurring issue from the 1:1s and workshop. For example: *“Onboarding takes too long, and users abandon the flow.”*

Define the problem with data:

-- Count users who started onboarding but didn't complete
SELECT
  count(*) AS total_started,
  count(CASE WHEN completed = true THEN 1 END) AS completed,
  round(
    (count(CASE WHEN completed = true THEN 1 END) * 100.0) / count(*),
    1
  ) AS completion_rate
FROM
  user_onboarding_sessions
WHERE
  created_at > now() - interval '30 days';

Then, define the solution:

• Propose a solution: add a progress bar and save state between sessions.
• Assign ownership: a senior engineer leads the effort.
• Set a deadline: deliver by end of quarter.

Create a decision record in decisions/:

# Decision Record: Onboarding Progress Bar

## Context
Users abandon onboarding flow before completion. Current completion rate: 60%.

## Options
1. Add progress bar only
2. Add progress bar + auto-save
3. Add progress bar + auto-save + email reminders

## Decision
Implement option 2: progress bar + auto-save.

## Rationale
- Increases user confidence
- Reduces friction
- Low effort to implement
- Aligns with team’s focus on user experience

## Owner
Alice Chen (Senior Frontend Engineer)

Establish a Feedback Loop with Stakeholders

Create a monthly engineering review with product, design, and business stakeholders.

Use pgAdmin or DBeaver to extract metrics from the database:

-- Generate monthly user engagement metrics
SELECT
  date_trunc('month', created_at) AS month,
  count(DISTINCT user_id) AS active_users,
  avg(duration_seconds) AS avg_session_duration,
  count(*) AS total_sessions
FROM
  user_sessions
GROUP BY
  date_trunc('month', created_at)
ORDER BY
  month DESC
LIMIT 12;

Export to CSV and share via email or Slack:

# Export query result to CSV
psql -c "
  SELECT
    date_trunc('month', created_at) AS month,
    count(DISTINCT user_id) AS active_users
  FROM user_sessions
  GROUP BY date_trunc('month', created_at)
  ORDER BY month DESC
  LIMIT 12;
" -A -F ',' -o monthly-engagement.csv

Present the data in a simple dashboard:

• Top line: active users, session duration
• Second line: onboarding completion rate
• Third line: deployment frequency (number of deploys per week)

Use git to version the dashboard:

git add dashboard/
git commit -m "Monthly engineering review: October 2024"
git push origin main

Key Patterns and Failure Modes

The “Checklist That Isn’t” Problem

Managers often create a 90-day checklist but fail to execute it. The key failure is lack of ownership and visibility.

• Solution: attach a *live* status tracker to the team’s main documentation page.
• Use a table in docs/90-day-plan.md:

| Week | Focus Area         | Status     | Owner         | Next Steps                    |
|------|--------------------|------------|---------------|-------------------------------|
| 1–2  | Ecosystem Mapping  | ✅ Complete| Jane Doe      | Finalize team charter         |
| 3–4  | Team Workshop      | 🔵 In Progress | John Smith | Draft decision records       |
| 5–6  | First 30-Day Goal  | ⬜ Not Started | Alice Chen | Define success criteria       |

Update it weekly. Link to relevant PRs, issues, and decisions.

Silent Failure in CI: “Green Builds, Broken Deployments”

A common pattern: CI passes, deploy script runs, service starts — but users see errors.

• Diagnosis:
• systemctl status app.service shows active (running) but journalctl reveals connection refused errors.
• Check config.yml in /etc/app/:

app:
  port: 3000
  database:
    url: "postgresql://user:[email protected]:5432/app"
    pool_size: 10
  logging:
    level: "info"
    file: "/var/log/app.log"

• Root cause: database.url points to a service that is not reachable. The db.prod.internal DNS name is not resolved in the container or VM.

• Fix:
• Add ping db.prod.internal in the app.service unit file.
• Add a healthcheck endpoint at /health that verifies database connectivity.

{
  "status": "ok",
  "services": {
    "database": {
      "reachable": true,
      "latency_ms": 12
    },
    "cache": {
      "reachable": false,
      "latency_ms": null
    }
  }
}

The “Too Many 1:1s, Too Little Follow-Up”

Engineers report that their 1:1s are productive, but nothing happens after.

• Solution: create a shared 1-1s folder with a follow-up.md for each meeting.

# 1:1 — October 10, 2024

## Key Takeaways
- CI pipeline is slow (avg 12 min)
- Test suite is flaky, especially on PRs
- Need better error reporting in production

## Action Items
- [ ] Add `test:ci` script to `package.json` (by Oct 20)
- [ ] Draft RFC for test runner migration (by Oct 25)
- [ ] Review onboarding UX with design team (by Nov 1)

## Links
- [PR #123: Improve CI performance](https://github.com/organization/project/pull/123)
- [Design Figma: Onboarding flow](https://figma.com/file/abc123)

Use git to link follow-up actions to Jira issues and track completion.

The playbook is not a static document. It evolves with the manager’s understanding of the team. By the end of 90 days, the manager has diagnosed the engineering culture, aligned on core practices, delivered a visible outcome, and established feedback loops that sustain momentum.

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.