A Weekly Artist Management Meeting Agenda That Keeps Work Moving

A 30-minute weekly manager meeting works when it runs on decisions, owners, due dates, and exceptions — not on a status readout of every artist. The agenda below is time-boxed to eight short blocks, each one built to end with something recorded: an approver named for a decision, an exception resolved, a follow-up scheduled, or a task written down with one owner and one due date. Copy the agenda CSV and start next Monday.

Who this is for

This is for an artist manager running a small roster — one to five artists — who already meets weekly (with a co-manager, an assistant, or the artist themselves) and wants the meeting to end with commitments instead of a longer to-do list. If you're a solo artist, the same shape works for a weekly review with yourself; you don't need every block, but the "one owner, one due date, one definition of done" rule still applies.

What the 30-minute constraint is for

The problem most weekly meetings solve for isn't information — it's decisions. Harvard Business Review's 2017 examination of meeting practice reports that executives averaged nearly 23 hours a week in meetings, up from less than 10 hours in the 1960s, and that interviews across hundreds of executives found many felt overwhelmed by them. Thirty minutes is a practical operating constraint, not a research-backed universal duration: it forces the meeting toward the roster's exceptions and decisions, with action items named, owned, and dated before anyone leaves.

The 30-minute agenda

Eight blocks. Each block has a time box, a specific set of things to cover, and a decision or output the block has to end with. Skip a block if there's nothing genuinely to cover — a missed release approval is not a "we'll circle back" item, but an on-plan release with no approvals due doesn't need airtime.

That's 30 minutes on paper. If the same block repeatedly overruns, do not quietly stretch the whole meeting. Capture the unresolved decision, name who will gather the missing information, and move it to a separate decision session with the people who actually need to be there.

Use one Driver and one Approver for decisions; one owner and due date for tasks

Blocks 2 through 7 produce decisions or actions, but those outputs need different ownership rules. For a decision, Atlassian's DACI framework names a Driver who gathers stakeholders and information and moves the decision toward its agreed date, plus one Approver who makes the decision. For a task created after the decision, name one owner and one due date. DACI also defines Contributors, who advise without a vote, and Informed stakeholders, who need the outcome; add those roles when the decision genuinely needs them.

Two failure modes to watch for:

• Two approvers. Atlassian defines the Approver as one person. If two people appear to have final say, decide who makes the call and who contributes evidence.
• No named approver. "The team will look at it" is not an approver. Deliverables in this state don't get rejected; they just stall.

Turning every action into a task before the meeting ends

Block 8 removes a second handoff between agreeing the work and recording it. Do the write-up during the meeting, not later. For each action, capture:

1. What. One sentence, imperative — "Send press pitch to [publication]," not "look at press outreach."
2. Owner. One person. Not a role, not a team.
3. Due date. A specific date, not "next week" or "when possible."
4. Definition of done. What piece of evidence proves it's finished — a link, a message sent, a file uploaded, a payment received.

If any of those four fields is empty when someone tries to move on, hold the meeting on that action until they're filled. Ambiguity here is what a weekly meeting exists to remove.

A worked example: what the log looks like on Monday afternoon

Below is a fictional operating example — not real client data — of what a filled action log looks like at the end of one 30-minute Monday meeting for a five-artist roster.

Nine actions, every one with a named owner, a due date this week, and something specific that has to exist before it counts as done. The decisions and sign-offs also have one named approver. That's the deliverable the meeting produces — not the notes.

Where this breaks down

• Status narration creeps in. If block 1 stretches past 2 minutes, the whole agenda slips. Keep it factual — "master delivered Wednesday" — and move on.
• Discussion replaces decision. Blocks 2, 4, 5, and 6 exist to produce a decision, not to explore the problem. If a topic clearly needs more information to decide, don't debate it — assign one person to gather that information by a specific date, then move on.
• Actions leave without an owner. If block 8 finishes with a task missing its owner or due date, or a decision missing its Driver or Approver, fix the gap in the room or remove the item from the committed action log.
• The same three blockers appear every week. A recurring blocker isn't a meeting item — it's a decision that needs to be escalated, a process that needs to change, or work that needs to be paused. Naming it as recurring is the escalation.
• The meeting grows to fit the roster. A five-artist roster meeting shouldn't be twice as long as a two-artist one — the discipline is exception-based review, not roster-wide status. If your meeting keeps growing with the roster, revisit the roster-review structure first.

How MNGR supports this workflow, and where it stops

MNGR's shared workspace is built around the same exception-based reading the meeting agenda depends on: the artist-managers workspace surfaces cross-artist dates and priorities and lets a manager review exceptions across releases, shows, contacts, and finance without reading every task. A task can carry one assignee, one due date, links to an artist, release, or show, and internal notes. Tasks can be filtered by artist or assignee and are sorted by due date, which lets block 8's action log live in the same view the next meeting will scan first.

MNGR does not currently ship a formal approver role separate from a task assignee, a private-view or granular-permissions layer, or a meeting-notes or transcript feature. The "Driver / Approver" naming above is a discipline you run in the meeting — MNGR tracks who owns a task and its due date, and the approver is a name you write into the task's title or notes yourself. If your team needs a formal sign-off chain with restricted visibility, verify that need against your actual plan before assuming it's covered.

Sources: Atlassian, "DACI: A Decision-Making Framework" (Team Playbook); Perlow, Hadley, Eun, "Stop the Meeting Madness," Harvard Business Review, July–August 2017. Reviewed and current as of July 2026.

Sources

1. Atlassian Team Playbook: DACI — A Decision-Making Framework
2. Harvard Business Review: Stop the Meeting Madness (Perlow, Hadley, Eun, 2017)