The Sunday evening check was supposed to take 30 minutes. Pull up GitHub,
scan open PRs, check CI status, look at Jira for any tickets that had gone
stale, open Vercel to confirm nothing was broken in production. Ninety minutes
later, I'd have a picture of the team's state — and I'd have to reconstruct
it again Tuesday after anything changed. This is a walkthrough of how I got
that 6 hours per week back.
What my week looked like before
I was managing a 25-person engineering team across three squads. The team was
healthy — good engineers, reasonable process, no major fires. But my EM overhead
was quietly consuming a significant portion of every week.
The recurring manual processes:
Sunday evening state check (90 minutes): GitHub for open PRs
and CI status, Jira for sprint board health and stale tickets, Vercel for
deployment status, Slack scan for anything I'd missed over the weekend.
By the time I finished, I had a mental model of team health that would be
partially stale by Monday standup.
Monday morning CI triage (45 minutes): Reviewing which CI
failures had accumulated over the weekend, figuring out which were real and
which were flaky, manually creating Jira tickets for anything that needed
tracking, pasting links into Slack for the relevant engineers.
Wednesday stale PR review (30 minutes): Checking the PR queue
for anything that had gone quiet — PRs that were open but hadn't received
review activity in 2+ days. Manually nudging engineers in Slack.
Friday velocity summary (60 minutes): Pulling together a
weekly summary of sprint progress, CI health, and deployment frequency for
my VP. All manual: GitHub API queries, Jira searches, copy-paste into a doc.
Total: approximately 6 hours per week of work that was entirely information
retrieval and routing — nothing that required my judgment, just my time.
Recommended for you
Automate your Monday check-in
The templates in this post run on Deviera. Connect GitHub and it watches for stale PRs, CI failures, and deploy issues — routing each as a ticket, hands-free.
The four manual processes I automated first (and why that order)
I didn't automate everything at once. I started with the highest time cost
and worked down. Here's the order and the reasoning:
1. CI failure → Jira ticket (automated first).
The Monday CI triage was the most painful because it combined high time cost
with high context-dependency — by Monday morning, the CI failure context
from Friday's deploys was already decaying. Automating this meant the ticket
was created within minutes of the failure, pre-populated with the CI run link,
the failing test, the commit, and the responsible engineer. I went from
45 minutes of Monday triage to reviewing a pre-populated Jira board.
Trigger: CI failure on main. Action: create Jira ticket with structured context.
2. Stale PR → Slack escalation (automated second).
The Wednesday stale PR check was pure information retrieval with no decision
required. A PR open for more than 48 hours without review activity needs a
nudge — automatically, not when I remember to check.
Trigger: PR open >48 hours without review. Action: Slack message to the PR
author and to me with the PR link and age. I stopped checking the PR queue
manually entirely.
3. Weekly health report (automated third).
The Friday velocity summary was 60 minutes of manual data retrieval producing
information that could be generated automatically. Deviera's weekly health
report replaced the entire process: CI pass rate, deployment frequency,
PR cycle time, stale PR count, and Friction Score — delivered to my email
automatically every Monday morning. I forwarded it to my VP with one sentence
of commentary. Sixty minutes became five.
4. Deployment failure → incident notification (automated fourth).
Production deployment failures were being discovered ad hoc — sometimes
immediately, sometimes 30 minutes later when an engineer happened to check
Vercel. Automating a structured Slack notification to #on-call with the
failing PR, commit, and merging engineer meant production issues were visible
within 60 seconds of occurrence. No more Sunday evening "let me just check
if anything broke over the weekend."
The exact automation templates I set up
These are the four Deviera automation rules that replaced the 6 hours of weekly
overhead. Each is a trigger + condition + action, configured once.
Automation 1: CI failure on main → Jira ticket
Trigger: CI check run failure
Condition: branch = main (production failures only, not every feature branch)
Action: Create Jira ticket — title "CI failure: [failing check] on main", description includes commit SHA, CI run link, responsible engineer, timestamp
Severity: P2 (escalated to P1 if CI has been failing for >2 hours)
Automation 2: Stale PR → Slack escalation
Trigger: PR open without review for 48 hours
Condition: PR is not a draft
Action: Slack message to PR author ("Your PR [link] has been open 48 hours without a review. Want me to reassign?") + DM to me with the PR details
Secondary trigger: if PR reaches 72 hours without review, escalate to the tech lead for that squad
Automation 3: Vercel production failure → Slack + Jira
Trigger: Vercel deployment failure
Condition: environment = production
Action 1: Slack notification to #on-call with deployment failure details, failing build step, commit, and PR link
Action 2: Create Jira P1 ticket with same context + Vercel build log link
Auto-resolve: when subsequent deployment succeeds on the same branch, ticket closes automatically
Automation 4: Weekly health report delivery
Trigger: Recurring — every Monday at 7:00am
Action: Deviera health report email to me and my VP — CI pass rate (7-day), deployment frequency, PR cycle time median, stale PR count, Friction Score with trend arrow
This is the report I used to spend 60 minutes building manually
What my week looks like now: the 40-minute Monday check-in
Monday morning starts with the automated health report in my inbox.
I spend 5 minutes reading it. If the Friction Score is stable and nothing
is red, I go to standup with context already loaded. If something is amber
or red, I have the specific signal — "CI pass rate dropped to 84% this week,
3 stale PRs in Squad B, one open P1 incident" — before I've opened a single
dashboard.
The full week breakdown now:
Monday morning: 5 minutes reading the health report, 15 minutes in standup. Previously: 90-minute Sunday check + 45-minute Monday CI triage.
Mid-week: Stale PR escalations arrive in Slack automatically. I act on them as they arrive instead of doing a batch review. Net time: roughly the same, but distributed rather than batched — and I'm never more than 48 hours behind.
Friday: 5 minutes forwarding the health report to my VP with a one-sentence commentary. Previously: 60 minutes of manual compilation.
Weekend: Nothing. Production alerts fire automatically if something breaks. I get a structured notification if I need to act. I don't check dashboards.
Total EM overhead for information retrieval and routing: approximately 40 minutes
per week, down from 6 hours.
What I would do differently (and what I'd set up on day one)
If I were starting this setup again, I'd do three things differently:
Set the stale PR threshold to 36 hours, not 48.
By 48 hours, a PR is already disrupting merge queue planning. The 36-hour
trigger catches the drift earlier, when a nudge is quick and low-cost.
At 48 hours, the conversation is more involved.
Start with the health report on day one.
I set up the CI failure automation first because it felt most urgent.
In hindsight, the weekly health report should have been set up first —
it immediately changes how you perceive the team's health and makes the
priority of other automations obvious. Without the weekly report, I was
making automation priority decisions without the baseline data.
Add squad-level segmentation sooner.
I ran team-level metrics for the first three months. When I added squad-level
segmentation — separate Friction Scores and stale PR counts per squad — I
discovered that Squad B was carrying 70% of the team's stale PRs while
Squads A and C were fine. The team-level average had hidden a localized
problem for months.
The compounding effect of these automations isn't just the 6 hours I got back.
It's that I stopped being reactive. I stopped learning about problems at standup.
I started getting ahead of issues because the system was watching the queue
continuously and telling me when something needed attention — not when it had
already been a problem for 3 days.
What weekly engineering management tasks are worth automating first?
The ones that are recurring, mechanical, and have a clear trigger — status collection, CI failure triage, stale PR chasing, and assembling the weekly report. These share a shape: a human is acting as a router, moving information between systems without adding judgement. Anything requiring judgement, such as deciding what to prioritise or how to handle a struggling team member, should stay manual and is where the recovered hours are best spent.
How much time can an engineering manager realistically recover?
Five to six hours a week is achievable for a manager currently doing status collection and triage by hand, which is roughly a full working day. The gain comes less from any single automation than from eliminating the repeated context switches: checking six dashboards to answer 'is anything wrong' costs more in aggregate than the individual checks suggest, because each one interrupts whatever else was happening.
Does automating status updates hurt team communication?
It helps, provided you automate the collection rather than the conversation. Asking engineers to restate in a meeting what is already visible in the pull request is not communication — it is manual data entry with an audience. Automating the factual layer frees the meeting for the parts that genuinely need people: blockers, trade-offs, and decisions. Teams that automate the discussion instead of the reporting do lose something real.
Where should a manager start if everything feels manual?
Log one week honestly, then pick the single most frequent recurring task. Starting with the most annoying task is the common instinct and usually the wrong one, because annoyance correlates poorly with time consumed. The highest-frequency item almost always wins on total hours, and automating one thing successfully makes the next attempt considerably easier than trying to redesign the whole week at once.
