Pavleur for engineering managers: the underrated workflow

Most meeting copilot marketing — including, in places, our own — talks about the individual contributor's experience. Engineer joins a meeting, copilot helps them, engineer leaves the meeting more productive. This framing isn't wrong, but it's incomplete.

The person on a typical engineering team who gets the most value from a meeting copilot is not the IC. It's the engineering manager. The reasons are mechanical: EMs sit in 2-3x more meetings than their reports, manage 5-10 parallel conversations across 1:1s and team meetings, and carry the cognitive load of remembering who committed to what across an entire team. The marginal value of a tool that helps with all three of those is dramatically higher for them than for an IC who has three meetings a week.

We've spent the last six months specifically optimizing the EM workflow in Pavleur. This is what we've learned about what actually helps.

The math of an EM's calendar

A typical engineering manager with 6-8 reports has:

6-8 weekly 1:1s with reports (30 minutes each)
1-2 weekly skip-levels with their own manager and possibly with their grand-reports
A daily team standup
A weekly team retro or planning meeting
3-5 cross-team coordination meetings per week
Ad-hoc meetings for hiring, performance reviews, design reviews, etc.

Total: typically 18-25 hours per week in scheduled meetings. About double an IC's load.

Each of those meetings produces commitments, decisions, context, and follow-ups. The EM is the single point of remembering for most of this. Their job, mechanically, is to be the place where the threads come together.

This is hard. It's hard at any scale, and it gets exponentially harder with team size. A 4-person team is manageable in your head. An 8-person team is right at the edge. A 12-person team is not actually possible to hold in working memory; you're going to drop things.

This is the gap a meeting copilot fills for an EM, in a way it doesn't quite fill for an IC.

The workflow that actually matters

For an IC, the typical meeting copilot workflow is:

Join meeting.
Have copilot transcribe.
Receive recap after meeting.
Maybe re-read the recap once.

For an EM, the workflow we've found actually delivers value is structurally different:

Pre-meeting brief. Before each 1:1 or team meeting, get a 30-second summary of what's open from previous meetings with this person/team. Surfaces forgotten threads.
In-meeting context surface. When a topic comes up, surface relevant prior context — past decisions, related conversations, action items still open.
Post-meeting action capture. Extract every commitment (yours, theirs, anyone's) with explicit owners and ideally deadlines.
Weekly cross-meeting digest. Each Monday, a summary of patterns across the EM's meetings the previous week: themes that came up multiple times, action items getting old, decisions made but not yet acted on.
Theme detection across reports. Anonymized pattern detection across 1:1s — "three of your reports mentioned the design review process this week" — without exposing which reports.

This is a much richer workflow than the IC version. It involves at least three distinct artifacts (pre-meeting brief, post-meeting capture, weekly digest) and one ambient feature (in-meeting context surface). The value comes from how they compose, not from any single one.

The weekly digest is the killer feature

If we had to pick one feature to defend as "the reason an EM should use a copilot", it'd be the weekly digest.

Here's what it looks like in practice for an EM with 8 reports:

Your week: Apr 28 - May 2

Action items waiting on you (5):

Send architecture doc to Alice (committed Apr 22, 11 days overdue)

Follow up with Mike about staging environment (committed Apr 24, 9 days overdue)

Schedule skip-level with Bob (committed Apr 28, 5 days overdue)

Write up the on-call rotation proposal (committed Apr 29, 4 days overdue)

Review Jin's promotion case (committed Apr 30, 3 days overdue)

Themes across your 1:1s this week:

Three reports mentioned feeling unclear about the Q3 roadmap

Two reports raised concerns about meeting load

One report (you'll remember who) is considering a sabbatical

Decisions made by your team this week:

Migration timeline pushed to Q3 (from platform sync, Apr 30)

Adopting new design review template (from team retro, May 1)

Standup time moving to 9:45 (from team standup discussion, May 2)

Decisions still open from earlier:

On-call rotation rework (raised 3 weeks ago, no decision yet)

Hiring plan for Q3 (raised 2 weeks ago, no decision yet)

That digest captures, in 200 words, what an EM would otherwise need to reconstruct by re-reading every meeting's notes. It surfaces specifically the things that an EM is supposed to be holding: commitments they've made, themes they should respond to, decisions they should follow up on.

The digest replaces, in our internal measurements, about 2-3 hours of weekly catch-up reading with 15 minutes of skimming.

The action-item discipline

The thing that compounds is action-item capture. We've measured this carefully.

Without a copilot, EMs in our internal sample remember about 60-65% of the commitments they make in meetings. The forgotten 35-40% gets dropped, re-raised by the report, or quietly stops being expected.

With a copilot that captures action items aggressively, EMs remember 90-95% of commitments. The remaining 5-10% they consciously decide not to do.

The behavioral effect of this is real. Reports of EMs using copilots describe their managers as "more reliable" and "easier to track on commitments." This isn't because the EMs are working harder. It's because the tool is doing a thing the EM was bad at — keeping a perfect ledger of "things I said I'd do" — and freeing the EM to do the things they're good at, like making judgement calls and reading the room.

The action-item discipline propagates downward. When your reports see that you reliably follow through on everything you commit to, they raise their own commitment standards. The whole team gets more accountable. We've watched this happen on multiple teams.

Theme detection: the unexpected feature

This one snuck up on us. Theme detection — the feature where the copilot surfaces patterns across an EM's 1:1s — was originally a minor feature. It's turned into something many EMs cite as their favorite.

The mechanic is simple: if a topic comes up in three or more 1:1s within a four-week window, the copilot flags it (anonymously, without naming which reports raised it). The EM sees the theme and can decide what to do.

What we've watched EMs do with this:

Burnout signals. When three reports mention feeling stretched thin in unrelated 1:1s, the EM can investigate quietly before any single report escalates.
Process pain points. When multiple reports mention the same broken process (slow design reviews, brittle on-call, painful deploy pipeline), the EM has a stronger case to push for fixing it.
Compensation concerns. When two or three reports mention feeling underpaid in the same window — particularly common around perf review cycles — the EM can prep a stronger pitch upward.
Recurring tensions. When the same conflict shows up across multiple 1:1s (e.g., friction between two teams), the EM can address it as a structural issue rather than handling it as isolated incidents.

The privacy story matters. Theme detection only works if reports trust that their individual 1:1 content isn't being surfaced. Our implementation specifically prevents naming reports in the theme summary; the EM sees "this came up in three of your 1:1s" without seeing which three. If they want to know more, they have to ask people directly.

What we got wrong on the first version

A few things we initially built that didn't work for EMs:

Per-meeting recaps were too noisy. EMs are in too many meetings for per-meeting recaps to be useful on their own. The signal/noise ratio is wrong. We had to add the weekly digest as an aggregation layer; without it, EMs were drowning in individual recaps.

Sentiment scores felt surveillance-flavored. We initially shipped a "meeting sentiment" feature that scored how positive or negative each meeting was. EMs hated it. It felt like a judgement on their relationships with their reports. We removed it.

Action items without deadlines were almost useless. The first version of our action-item extraction would pull commitments without dates. This produced a long list of "things to maybe do" that grew without bound. We had to make the model more aggressive about extracting or inferring deadlines, and to age out commitments without deadlines after a couple weeks.

Threading 1:1s by report wasn't enough. EMs wanted to see one report's 1:1 history in one place. We built this. It turned out they actually wanted to see patterns across reports, not deep history of individual reports. The cross-report view (with anonymized theme detection) is more useful than the per-report timeline.

The pitch to an EM-skeptical org

If you're an EM evaluating whether to bring a copilot into your meetings, the case is:

You will follow through on more of your commitments. That's a credibility win that compounds.
You will see patterns across your team faster. Burnout signals, process pain points, recurring tensions surface weeks earlier than they otherwise would.
You will spend less time catching up on meetings you missed. The weekly digest replaces 2-3 hours of reading with 15 minutes.
Your reports will trust the system. Provided you handle the consent and privacy correctly. This is the hard part.

The case against:

There's a real consent problem with 1:1s. Your reports need to genuinely opt in, not pressure-opt in.
Surveillance-flavored features will damage trust faster than productivity features build it. Avoid sentiment scores, avoid attendance tracking, avoid anything that smells like measuring people.
The weekly digest takes a couple weeks to become useful. The pattern detection needs enough data. Don't judge it on week one.
The tool is a multiplier on a working relationship. It can't fix a broken team. If your meetings are bad, more notes won't make them better.

The bigger pattern

Engineering management is, mechanically, a problem of holding many threads in parallel. It's the part of the job that scales worst with team size, because human working memory doesn't scale. The reason senior EMs are valuable is not that they're smarter than junior EMs — it's that they've built personal systems for not dropping threads.

A meeting copilot is a partial automation of those personal systems. It captures commitments, surfaces patterns, reminds you of things you should follow up on, aggregates context across meetings. None of these are individually revolutionary. Together, they let an EM operate at a slightly larger scale than they otherwise could.

The under-marketed truth is that this is the role where a meeting copilot has the highest leverage. ICs benefit; managers benefit more. If you're an EM, the question to ask is not "is this useful?" — it's "how am I currently doing all this in my head, and what is that costing me?"

Most EMs we talk to, when they actually sit down and answer that question, conclude that the cost of doing it in their head is much higher than the cost of the tool. The math is just not close.