Engineering at Scale - Leading a Tribe Without Micromanaging It

Abstract

Three AI-written briefs a day: a practical guide on how to stay accountable for a tribe without dragging every decision up to you. If you’re here for the prompts, skip to How to Adapt This to Your Org: fill in one config block and the three templates follow.

One caveat: the templates are mostly rules, and every rule exists because a brief once got something wrong. Section 03 explains why. Skip it and your briefs will likely make the same mistakes mine did.

Bad Mornings

One started with an on-call escalation: a client’s services had gone down from overuse. The other started with a call I hadn’t planned to be on: a release change made in another timezone had gone wrong, and the early morning clients felt the issues first.

It’s not my first rodeo. The instinct after mornings like those is to reach for control: more status calls, 1o1s that devolve into progress interrogations, more sign-offs, more “keep me in the loop”. It feels like leadership but it’s not. It pulls decisions away from the people who have the context, robs them of autonomy, and it teaches a tribe to wait for you. It doesn’t scale.

This article suggests an alternative.

Once you manage multiple managers managing global teams (that’s a lot of management!), your problem is no longer a shortage of information. You get hundreds of tickets, dozens of chat threads, back-to-back meetings and an inbox that refills while you read it. The old coping strategies are blunt: mark all as read, write a rule that files it out of sight, and trust that anything important will find you. That’s what good escalation paths are for, but by the time something escalates, it’s on fire — usually at 2am, or halfway through a beach vacation. The smoke was there earlier, in a thread nobody was reading. The work is triage: knowing which five things need you today, which of them have quietly closed, and which ones are about to land on someone else.

This year I’ve had an AI assistant write three short briefs for me every working day. They have genuinely changed how I spend the first and last hour of each day more than any other habit. They’re also how I stay accountable for a tribe without looming ominously over it. This post explains how they’re designed, iterated on, and why, and to keep it practical: gives you the prompts so you can build your own.

The prompts are templates. Fill in one configuration block describing your org, and adjust the parts that don’t fit how your teams work.

Information was never the constraint.

Attention is.

The Rhythm: Three Briefs, Three Jobs

The most important design decision is that the three briefs do not overlap. Each one answers a different question at a different point in the day.

Brief	When	Faces	Answers
Start of day	Before your first meeting	Forward	What needs me before the day starts? What shape is my day? What do I need to know walking into the two or three meetings that matter?
Mid-morning	After overnight reports have landed	Backward	What happened overnight? What was decided in yesterday’s late meetings and this morning’s early ones? What do I now owe people?
End of day	At your close of business	Backward, then forward	What actually closed today? What changed since the morning? What carries overnight, and who is holding it?

When the briefs overlap, you read the same item three times and start skimming. Once you skim, you miss the one line that mattered. So each template tells the assistant what the other briefs own and tells it to stay out of their territory.

Map my two bad mornings onto the table. The overuse outage is a start-of-day question: what needs me before the day starts? The release that went wrong overnight is an end-of-day one: what carries overnight, who is holding it, and what are they blocked on that only I can unblock? Different questions, different moments, different briefs.

Context Without Control

This series has one idea running through it: performance at scale is always about getting decisions closer to where the context lives. In Engineering at Scale - Tribes, Squads, and Agentic Cliques that meant optimizing for autonomy, not control. Squads decide because squads have the context.

That leaves the tribe lead with an awkward job. You’re accountable for everything and closest to almost none of it. There are two ways to close that gap. You can pull the decisions up to you, which is micromanagement. Or you can bring a thin slice of the context to you and leave the decisions where they are. The briefs are the second option.

I learned the cost of the other extreme the hard way. Earlier in my career, a manager I respected told me my teams were well organized and well drilled, but that I had one pace. I’d leaned so far into trust, partly out of my own aversion to micromanagement, that I had no second gear when things went wrong. I wrote about that in The Player Coach, and the lesson still holds: trust without context is blind trust. The briefs are how that lesson have become a daily habit and how judicious use of AI aids with effective management. They give me enough context that my trust isn’t blind, and enough early warning that I know when to change pace before the team needs me to.

Knowledge that used to live only in my head (who owns what, which alerts to ignore, which channel is where a fix is really announced) becomes encoded as a reusable capability. I design the intent and the constraints; the assistant does the gathering.

What they don’t do is act. A brief never pings a lead, reassigns a ticket or joins a meeting. It tells me what’s mine to decide and stays quiet about what isn’t. When two meetings clash, which they often do, it names both, says which has the stronger claim, and lets me choose. Accountability stays with me. Autonomy stays with the squads.

Read widely.

Intervene rarely.

Know exactly when.

Intervening rarely isn’t the same as not at all. When the “Flag at the Top” says a client is down, and perhaps not for the first time, that’s the signal to come down from the stands. Not to give the team talk (that’s my lead’s job) but to stand behind them so they can give it: the right people, the time, and the pressure diverted. When the brief is quiet, that’s permission to stay in the stands and let the squads play.

The briefs aren’t only about the tribe, either. Much of an engineering director’s day comes from above and beside: asks from your own manager, peers, program leads, cross-org dependencies, a calendar that double-books itself. The same briefs triage those too. They flag the conflict and say which meeting has the stronger claim, put your manager’s asks first, track what you owe.

The Effective Executive, subtitled the definitive guide to getting the right things done, makes the case: effective executives don’t start with their tasks. They start by “finding out where their time actually goes”, then consolidate what’s left into the largest blocks they can, because the work that matters most at this level doesn’t fit in the gaps between meetings. The briefs help with both halves. They show me the real shape of each day, they find the longest free block, and then, they stop me fragmenting it. When three reads a day cover everything, there’s no reason to keep obsessively glancing at multiple chats “just in case.”

What they give back isn’t just fewer status requests, it’s time for the work only you can do, and some evenings back for everything else.

Design Principles - Lessons that shaped my briefs

Each of these exists because a brief once got something wrong in a way that wasted my time or, worse, reassured me falsely — it’s AI, after all. They’re now written into the templates as rules, with the reason attached. Assistants apply a rule better when they know why it exists.

In the language of this series, these rules are how I built my own sympathy for the assistant: a working mental model of where it fails, so I can trust what it tells me when it doesn’t. Trust in agentic systems is earned, not imposed. These rules are the receipts.

1. Analysis, not transcription. I can read a ticket list myself. Each line has to tell me something I wouldn’t just get from glancing at the tracker: what is stuck, who is blocked, what I personally owe, what was decided. “Initiative X is the one to worry about, because both of its children are unassigned” is useful. A table of twenty tickets is not.

2. “Quiet” is a claim about contents, not metadata. If the assistant didn’t open a source, it must say “not checked” and give the reason. In one case, a chat’s “last updated” timestamp turned out to reflect when it was renamed, not when someone last posted in it. A thread with dozens of fresh messages was reported as idle. A blind spot dressed as reassurance is worse than an honest gap.

A blind spot dressed as reassurance is worse than an honest gap.

3. Prove it’s still open before you tell me to chase it. Every “unassigned”, “unanswered” or “still outstanding” claim must be backed by the newest message in the forum that owns the item, with a timestamp. The channel where an incident is worked is often not the channel where its fix is announced. One brief once sent me chasing a deliverable that had been shipped and acknowledged two days earlier.

4. Channel membership is not the same as being asked. Being in a channel doesn’t make every post in it my problem. Something only goes in my action list if it’s in my org’s scope, or someone asked me by name, 1:1 or with a mention. “Flagged directly to you” may only be written when that literally happened.

5. No “no record” claim without a lookup. “There’s no transcript of that meeting” is a factual claim. It must rest on an actual lookup that came back empty, quoted, and not on the meeting chat looking quiet, because the chat and the transcript are stored separately. The renderer enforces this: a meeting without a recorded lookup result shows a red “NOT CHECKED” badge instead of a calm “No transcript”.

Sidenote

If you don’t want to lose useful context but practically can’t be in every meeting “Follow, Record and Transcribe” those meetings, don’t just decline them, (or worse: leave them tentative in your calendar)

6. Never attribute a topic to a meeting without confirming it in that meeting’s own record. Long transcripts often get truncated. If the assistant only read half, it has to say so, and it may not borrow a topic from a different source. This one bit me more than once.

7. Specific or absent. For meeting prep, restating the invite or listing attendees is worse than writing nothing, because it trains you to skim. An empty prep section on a day of nothing but stand-ups is a correct answer.

8. Write down your standing exclusions. Every org has a noisy alert that isn’t yours. Name it in the template as permanently out of scope, so it never appears again however alarming its numbers look. Knowing your SEPs, Douglas Adams’ “Somebody Else’s Problems”, matters nearly as much as knowing your own. Just review the list now and then — you don’t want your SEP field hiding a spaceship.

9. Keep links intact. Document links often only open in the browser if their query string survives (looking at you: Sharepoint). Trim it to tidy a URL and you get a download prompt instead, or lose the sharing token altogether. Copy URLs verbatim.

10. Deliver the finished file in one step. If delivery runs through a watcher (a folder that triggers an email, a webhook, a bot), it fires the moment a file appears. Write the file in one piece, never chunk by chunk. Correct a mistake by sending a new “(Corrected)” version, not by editing the one already sent. One of my briefs once arrived cut off partway through a table for exactly this reason.

11. No emoji, and severity carried by labels. This one is down to personal taste, but a consistent visual language (CRITICAL, ACTION, WATCH, FYI) beats decoration when you’re scanning on a phone. It’s also ages better: Gen Z has already cancelled the thumbs-up as passive-aggressive — your favorite emoji could be next.

12. The brief replaces the status request. This last one is a rule for me, not the assistant. If the brief already shows it, I don’t ask a lead or IC for it. I act on the flags, not on everything I can see. The moment a brief becomes just a list of people to chase, it’s surveillance with better formatting.

Quote

”Every action you take is a vote for the type of person you wish to become.”

Each status request you don’t send, because the brief already answered it, is a vote for being the leader who trusts.

How to Adapt This to Your Org

Everything specific to your organization lives in one configuration block, shared by all three templates. Change the block and the briefs follow.

Some common topologies and what to change:

Line-of-teams (a director with several team leads). This is the default, classic tribe of squads shape. Give each team its own entry, with its lead and how to identify that team’s work in your tracker (a component, label, project or custom field).
Flat org (you manage engineers directly, no managers in between). Treat each engineer, or each pod of two or three, as a “team”. Drop the escalation emphasis, raise the weight on unanswered direct questions, and consider shrinking to two briefs.
Matrix org (people report to you, but work is directed by product or programme leads). Add the program leads to the config as “work direction contacts”. Tell the briefs to watch for conflicting asks between a program lead and a team lead, because that’s the decision only you can make.
Platform or infrastructure group. Your “clients” are internal teams. Replace “client-affecting incident” with “consumer-affecting incident”, and list your top consuming teams the way the default lists external customers.
Follow-the-sun or multi-region. The end-of-day handoff matters more. Name which region picks up overnight and what they can’t unblock without you.
Smaller scope. Run only the mid-morning brief. It carries most of the value.
Let the briefs grow with the role. Teams move, priorities shift, and the threads that matter today go quiet tomorrow. A brief that never changes slowly fills with sediment. So ask the question from Engineering at Scale - Why Flow Matters More Than Vibes: when did you last change the filters?

Identifying team ownership of work. Use whatever your tracker treats as authoritative, and tell the assistant never to infer ownership from ticket text.

Delivery. The briefs render to HTML. You can have them emailed directly, or by a file-watcher automation, posted to a chat channel, or just opened in a browser. The only hard rule is principle 10.

The Shared Configuration Block

Fill this in once. All three templates refer to it as {{CONFIG}}.

## CONFIG
 
### Me
- Name: {{your name}}
- Role: {{e.g. Director of Engineering, Payments}}
- Time zone: {{e.g. America/New_York}}
 
### Reporting lines (treat as authoritative; never assert a reporting line not listed here)
- Manager: {{name}}  -> anything they ask me directly is the top item in any brief
- Skip-level: {{name}}
- Peers: {{names}}  (complete list; do not add to it)
 
### Teams I own
For each team:
- Team: {{team name}}
  - Lead: {{name}}
  - How to identify its work in the tracker: {{e.g. project = PAY AND component = Ledger, or field "Team" = "Ledger"}}
  - Colour for rendering (optional): {{hex}}
- (repeat per team)
- Work with no team identified goes under "Team not tagged". Never guess.
 
### Other people who show up a lot
- Cross-org delivery contacts (not peers, not reports): {{names}}. Lead with the dependency they own, not their level.
- Everyone else: list under "Other notable traffic" with no level asserted.
 
### Sources
- Issue tracker: {{e.g. Jira}}; projects in scope: {{keys}}; cross-project tickets count only if genuinely tied to my scope
- Calendar: {{e.g. Outlook}}
- Chat: {{e.g. Teams / Slack}}
- Mail: {{e.g. Outlook / Gmail}}
- Meeting transcripts / AI meeting notes: {{where they live, if anywhere}}
- Daily health report (if your org has one): {{what it is, when it lands, who sends it}}
 
### High-signal threads (read in full every run; never skip because of a "last updated" field)
- {{e.g. the escalation channel for your biggest customer}}
- {{e.g. your manager's leadership chat}}
- {{e.g. the incident channel}}
 
### Standing exclusions (never report, regardless of how alarming)
- {{e.g. the nightly batch-job alert owned by another team}}
 
### Working conventions worth knowing
- {{e.g. "Investigation tickets are typed Support; the fix is a separate Bug linked. Two same-titled tickets like that are not duplicates."}}
- {{e.g. "Tickets in the INTAKE project are future work, not active work; they only matter if linked to an active ticket."}}
 
### Delivery
- Output: HTML file named "{{Brief Name}} - <YYYY-MM-DD>.html"
- Where it goes: {{e.g. a watched folder that emails it to me / a chat channel / nowhere, I'll open it}}
- Deliver the finished file in one write. Corrections go out as "<name> (Corrected).html".

Template 1: Start-of-Day Brief (Forward-Looking)

You are my executive assistant. Using {{CONFIG}}, produce my short Start-of-Day Brief.
 
It runs before my first meeting and is deliberately lean. It answers four questions:
 
1. Is there anything I need to know or do before the day starts?
2. What shape is my day, and does the calendar itself need a decision from me?
3. For the two to four meetings that actually warrant it, what do I need to know walking in?
4. (Optional) Is there anything wrong with my travel today?
 
This brief is FORWARD-looking. A separate mid-morning brief reviews meetings that already happened. Never summarise a meeting as though it were done, and don't re-read yesterday's transcripts here.
 
## Rules
- No emoji. Severity is shown with a text label and colour.
- Keep it short. A quiet night honestly reported is four lines.
- "Quiet" or "clear" may only describe a source you opened. Otherwise write "not checked" and give the reason.
- Scope: only treat something as mine if it's in my teams' scope, or someone asked me by name. Being in a channel isn't being asked.
- Prep is specific or absent. A prep line must say something the invite doesn't: a decision waiting on me, a number, a name, what changed since last time, an open ticket that will come up. Never restate the subject or list attendees.
- Budget: one calendar search, at most five full event reads, at most two prior-meeting transcript reads. If you run long, drop prep before you thin out the incident section.
- Copy URLs verbatim; never trim query strings.
- Never report anything on the standing-exclusions list.
 
## Steps
1. Overnight: tracker items in scope updated since my previous close; mail and chat keyword sweeps for incidents and escalations. Compress noise (build mail, digests, self-healing alerts) to one line at most. Label production vs test environments explicitly.
2. Open high-priority work, grouped by team using the tracker field in CONFIG. For the hardest few, say what is actually blocking each.
3. The day ahead. Classify before you count: all-day entries are markers, not meetings; "free" entries are not commitments. Then report:
   - The shape: first and last commitment, committed hours.
   - Conflicts, the most valuable line. Name both meetings, and say which has the stronger claim (I'm organiser > required > optional; external > internal; small > large; live agenda > standing stand-up).
     Let me choose.
   - Decisions the calendar needs: unanswered invites, meetings I organise, high-importance items.
   - The longest free block.
1. Meeting prep for the top two to four meetings, ranked by: external attendees; I organise it; a 1:1 with a direct report; a real agenda or pre-read; my manager attends; it maps to an open incident or high-priority item.
   Read the full event, then fill only the slots with real content: what it decides, what changed since last time, what I owe, live context from this run, and the pre-read link.
   Then look ACROSS the day for sequencing. An earlier meeting is often where I can close something a later one needs. Say so in one line.
2. Action needed before the day starts: a live customer-affecting incident; a top-priority defect with nobody on it; an outage blocking a team; a hard calendar conflict; a prep gap due today. If there's nothing, say so. Don't manufacture urgency.
 
## Output
Sections: Action Needed First, Overnight Incidents, The Day Ahead, Meeting Prep, Open High-Priority Work,
Data Source Notes (always last; name what you couldn't check).
Deliver per CONFIG in a single write. End with a two-line chat summary that says whether delivery succeeded.

Template 2: Mid-Morning Brief (Backward-Looking, Main)

You are my executive assistant. Using {{CONFIG}}, produce my full Daily Brief.
 
It runs mid-morning, after overnight reports have landed. Window: my previous close through now (on Mondays, from Friday's close). It is BACKWARD-looking: what happened, what was decided, what I now owe.
 
## Rules
- No emoji.
- Analysis, not transcription. Each line tells me something I wouldn't get from glancing at the tracker.
- Never pad. Empty sections get one line.
- "Quiet" or "clean" may only describe a source you actually opened. Otherwise write "not checked" and give the reason.
- Never assert a reporting line not in CONFIG.
- Scope: something is mine only if it's in my teams' scope or someone asked me by name. Channel membership isn't being asked. Never write "flagged directly to you" unless it literally was.
- Prove it's still open: every "unassigned", "unanswered" or "outstanding" claim cites the newest message in the forum that owns the item, with a timestamp.
- Every meeting that ended in the window gets its transcript looked up, before you write any meeting summary. Record the literal outcome of that lookup for each meeting. "No transcript" may only be written if the lookup said so. A quiet meeting chat proves nothing about the transcript.
- Never attribute a topic to a meeting without confirming it in that meeting's own record. If you only read part of a transcript, say how much.
- Copy URLs verbatim. Never report anything on the standing-exclusions list.
 
## Steps
1. Find the real current time first.
2. Enumerate meetings from BOTH the calendar and chat (meeting chats, ad-hoc calls). Many real meetings never reach the calendar. Call out anything found only in chat; that's the kind of meeting I'm most likely to have missed.
3. The daily health, SLI report, if your org has one: report its status line, and say if something you found elsewhere isn't reflected in it.
4. Tracker: open high-priority work grouped by team. Read the latest comments on the top items so you can say what's blocking them. Treat an unassigned top-priority item as a finding, not a table row. Before calling two same-titled tickets duplicates, check their types and links (see working conventions in CONFIG).
   Then overnight movement, then cross-project items genuinely tied to my scope.
5. Read the rooms, in this order, until something returns content:
   a. the meeting transcript (start from the full calendar event, not the chat)
   b. the meeting chat thread (for ad-hoc sessions it IS the record; any message asking me by name is a direct ask)
   c. AI meeting notes, if you use them (allow for indexing lag; "notes not indexed yet" is a different finding from "not recorded")
   Write 3 to 9 sentences per meeting: decisions, commitments, slips, numbers, attributed by name. Group routine stand-ups into one entry.
6. Read every high-signal thread in CONFIG in full. Sort by sent time yourself.
7. Mail sweep. One line at most for automated noise, unless a repeating alert's number is getting steadily worse.
8. Action items that are actually MINE: things I owe, decisions waiting on me, asks from my manager or skip-level, gaps where my team was named as the blocker and nobody owns it. Check each forward to its newest message first.
9. Communications review, grouped by Leadership, Reports, Peers, Cross-org, Other. Flag "needs reply" sparingly.
10. Flag at the Top, written LAST: one to four items, hardest first, each with timestamped evidence.
 
## Output
Sections: Flag at the Top, Health Report, Overnight Incidents, Open High-Priority Work, Meetings Review,
Action Items, Communications Review, Data Source Notes (always last).
Before rendering, check: every flag cites dated evidence; every "quiet" refers to an opened source; every
meeting has a recorded lookup result; no exclusions; no emoji; URLs intact.
Deliver per CONFIG in a single write.

Template 3: End-of-Day Brief (Closing the Loop)

You are my executive assistant. Using {{CONFIG}}, produce my End-of-Day Brief.
 
It runs at my close of business and owns the rest of the working day, especially the afternoon meetings, which nothing else reads. Window: from shortly before the mid-morning brief through now. It answers: what changed since the morning, what actually closed today, and what carries overnight.
 
## Rules
All of the mid-morning brief's rules apply, plus:
- Don't re-report the morning brief. An item earns a line only if it CHANGED: resolved, escalated, reassigned, missed a commitment, or went quiet when it shouldn't have.
- Prove-it's-still-open matters more here. Anything you hand off overnight is something someone will act on at 2am. A stale "still outstanding" sends them chasing something that closed hours ago.
- A ticket's priority field can understate a live incident. If chat shows an active fire and the ticket says "low", report the real state first and say the field is wrong.
 
## Steps
1. Real current time first. On Fridays, the handoff covers the weekend.
2. Afternoon meetings from both calendar and chat; same record-lookup discipline as the mid-morning brief.
   AI notes from meetings that just ended often haven't indexed yet. Say so; don't call them unrecorded.
3. Health report reconciliation: did the day contradict this morning's status line? That is the useful sentence.
4. Tracker: what was RESOLVED today (lead with anything that was flagged this morning), what's still open at high priority, and the day's overall movement.
5. Close the loop on the morning brief: for each of its flags, closed, moved or unchanged? If a morning flag had already closed when it was written, say so plainly. (If a "(Corrected)" version exists, use that.)
6. High-signal threads, read in full. Watch for monitoring numbers trending the wrong way through the day, and quote the progression.
7. Action items: split into "before you log off" and "carries to tomorrow". Be strict about "today".
8. Handoff and overnight watch, scannable in fifteen seconds:
   - live incidents still open at the close and who owns each
   - unowned top-priority work going into the night
   - what the overnight or other-region teams will pick up, and what they're blocked on that only I can unblock
   - deadlines, releases and change windows landing tomorrow
   - backlogs trending the wrong way
   If the night looks quiet, say so in one line.
9. Flag at the Top, written last, biased toward what's still unresolved at the close.
 
## Output
Sections: Flag at the Top, Health Report Reconciliation, Changes Since the Morning, Resolved Today,
Meetings Review, Action Items, Communications Review, Handoff and Overnight Watch,
Still Open High-Priority Work (reference, near the bottom), Data Source Notes (always last).
Deliver per CONFIG in a single write. End with a short chat summary biased toward what's open going into the night.

Practical Experiments

A few things I’d advise anyone starting out:

Start with the mid-morning brief. It carries most of the value. Add the other two once it’s earning its keep.
Treat every miss as a new rule. When a brief gets something wrong, don’t just fix that day’s output. Add a line to the template saying what happened and why it matters. Most of my rules began as one bad morning.
Render to a fixed format. A small, version-controlled renderer, fed structured data, stops the briefs drifting in layout and makes “NOT CHECKED” impossible to hide.
Read the data source notes once a week. They tell you where your assistant is blind. Those gaps are usually access problems you can fix.
Let it tell you nothing happened. The most valuable brief is sometimes “nothing needs you before the open”. If yours never says that, it’s padding.
Count your status requests. Before you start, note how often you message a lead to ask where something is. Check again after a month. If the briefs are working, that number should fall. If it doesn’t, you’re using them to chase, not to trust.

I still get bad mornings. A brief doesn’t stop a client’s services buckling under load, or a release going wrong overnight. What it changes is my response. I don’t need to drag everyone into a room to find out what happened: the context is already in front of me, the owner is already named, and the question is narrowed to the one thing only I can decide. Everything else stays with the squads that own it.

The goal isn’t to read more. It’s to know, within five minutes of sitting down, the three things only you can do today, and to trust that the brief would have told you if there were a fourth.

Micromanagement drags the decisions up to you.

A good brief brings the context to you, and leaves the decisions where the context lives.

The teams that scale in the age of AI won’t be the ones with the most oversight.

They’ll be the ones whose leader knows when to stay in the stands, and when to go down to the dressing room.

Engineering at Scale - Leading a Tribe Without Micromanaging It

Bad Mornings

The Rhythm: Three Briefs, Three Jobs

Context Without Control

Design Principles - Lessons that shaped my briefs

How to Adapt This to Your Org

The Shared Configuration Block

Template 1: Start-of-Day Brief (Forward-Looking)

Template 2: Mid-Morning Brief (Backward-Looking, Main)

Template 3: End-of-Day Brief (Closing the Loop)

Practical Experiments

Recommended Reading

Articles:

Next