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.
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.
Set up these automations in under an hour. Start your free 14-day Deviera trial.