Agency Project Management: The System That Keeps Everyone Sane ![rw-book-cover](https://www.agencymavericks.com/wp-content/uploads/2026/07/agency-project-management-the-system-that-keeps-ev-featured.jpg) ๐Ÿ”— **Source:** [Agency Project Management: The System That Keeps Everyone Sane](https://www.agencymavericks.com/agency-project-management-the-system-that-keeps-everyone-sane/) > [!note]+ Document Notes > tags: [agency-operations, project-management, client-communication, resource-planning, scope-creep] > author: Troy Dean > source: Agency Mavericks > reference: https://www.agencymavericks.com/agency-project-management-the-system-that-keeps-everyone-sane/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # ๐Ÿท๏ธ Title: Agency Project Management: The System That Keeps Everyone Sane > <!-- deep-read:sections start --> ## ๐Ÿงญ Table of Contents - [๐Ÿ“ Summary](#-summary) - [๐Ÿ“– Main Content](#-main-content) - [๐Ÿ—’๏ธ Notes](#๏ธ-notes) - [๐Ÿ“š References](#-references) - [๐Ÿ—ฃ๏ธ Paraphrase](#๏ธ-paraphrase) - [๐Ÿ“ฐ Newsletter](#-newsletter) - [โœ… Action Items](#-action-items) - [๐Ÿงช Hypotheses](#-hypotheses) - [๐Ÿ“Š Methodology](#-methodology) - [โ“ Questions](#-questions) - [๐Ÿ”ฎ Future Research](#-future-research) - [๐Ÿ’ก Implications](#-implications) - [๐Ÿง  Learning Styles Assessment](#-learning-styles-assessment) - [๐Ÿ“Š Accessibility Assessment](#-accessibility-assessment) - [๐ŸŒ DEIB Assessment](#-deib-assessment) - [โœ… Logical Validity](#-logical-validity) - [๐Ÿ›ก๏ธ DARVO Analysis](#-darvo-analysis) - [๐ŸŽฏ Conclusion](#-conclusion) ### ๐Ÿ”— References - [Agency Mavericks โ€” Agency Project Management article](https://www.agencymavericks.com/agency-project-management-the-system-that-keeps-everyone-sane/) - [Headless business system offer](https://mvrx.link/headless-blog) - [Request a Call โ€” Mavericks Club](https://scale.agencymavericks.com/?utm_source=website&utm_medium=blog-post-footer&utm_campaign=gptc&utm_content=request-a-call) ## ๐Ÿ“ Summary - Troy Dean (Agency Mavericks) argues agency chaos isn't caused by a missing tool โ€” it's caused by an undefined process. Switching from ClickUp to Monday to Asana doesn't fix a broken workflow; it just moves the same mess into a new interface. - Why it matters: agency owners who feel like the permanent bottleneck โ€” holding all the context, making all the decisions, firefighting daily โ€” have usually mistaken a software problem for what's actually a systems-and-culture problem. - Key stakeholders: agency owners/founders, project managers, designers and developers, clients receiving deliverables. - Risks and tradeoffs: building SOPs, a resource buffer (70-80% capacity target), and a "no-surprise" client communication policy costs upfront discipline and some short-term throughput, in exchange for lower burnout, less scope creep, and margin protection. - Bottom line: agency project management is a set of rules of engagement (visibility, accountability, repeatability, a defined "done") that must exist on paper before any tool can enforce them; the owner's job is to become the "director" of that system rather than its chief firefighter. ## ๐Ÿ“– Main Content - **The tool trap.** The article opens by naming a common agency behavior: repeatedly migrating PM tools (ClickUp, Monday.com, Asana, Jira) hoping new features will create order. Dean calls the tool "a digital filing cabinet" โ€” it reflects whatever process (or lack of one) you feed it. The fix has to happen on a whiteboard, mapping what happens from signed contract to approved deliverable, before it's encoded into software. - **Three pillars of a sane workflow.** Visibility (anyone can check project status in under 30 seconds without a Slack scavenger hunt), Accountability (one owner per task โ€” "when everyone is responsible, nobody is responsible"), and Repeatability (SOPs and templates covering roughly 80% of any project, even "custom" work, to protect margin). - **Definition of Done.** Most PM failures trace back to an undefined "done": the designer means the mockup is finished, the developer means the code shipped, the client means three unaccounted revision rounds are complete. Dean prescribes defining, per task, the deliverable, the quality standard, and the approval process (who signs off, how many revisions are included) up front โ€” this is also positioned as the primary scope-creep defense, letting a team say "great idea for Phase 2" instead of silently absorbing extra work. - **Resource planning.** Selling work on Friday and expecting a Monday start without checking capacity is named as the fastest way to lose good staff โ€” not because the work is hard, but because the workload is unpredictable. The prescribed fix is a "Resource View" (booked hours vs. capacity) and a "Buffer Policy" that caps planned utilization at 70-80%, leaving headroom for emergencies, training, and deep work. - **Weekly rhythm.** Meetings should carry strategy, not status (status belongs in the tool). The recommended cadence: a Monday Kickoff (15-30 min, prioritization โ€” three big wins, bottlenecks, who needs help), a Daily Standup (10 min, yesterday/today/blockers, team-facing not owner-facing), and a Friday Retrospective (30 min, what worked, what didn't, SOP refinement). - **Client communication as a PM function.** Clients don't care about the tool; they care about feeling safe about their investment. Silence โ€” not bad news โ€” is framed as the main driver of client friction. The "No-Surprise" policy bundles three practices: templated Friday weekly progress reports, a Red-Amber-Green visual health status (proactively surfaced, especially when Red), and centralizing all feedback into one channel so it can't get lost across Slack/WhatsApp/email. - **Doer to Director.** The hardest shift for most owners: they're usually the agency's best designer/coder/strategist, but as long as they personally manage projects, they're the ceiling on growth. Every time the owner "jumps in" to rescue a project, it teaches the team the system doesn't actually matter. The real job is building a machine that works without the owner's hands on it. - **Closing argument.** Sanity comes from disciplined process definition and follow-through, not from another software subscription โ€” and the piece ends with a pitch for Dean's own "headless" agency system and a Mavericks Club call-to-action. ### ๐Ÿ—’๏ธ Notes - Not a transcript and contains no timestamps; dense notes only, no timestamp subheadings per template rule. - Recurring rhetorical device: "Let's be direct with you" / "This is the part nobody talks about" โ€” used twice, functions as a credibility/urgency marker rather than new information each time. - The article is structured as a stacked list of prescriptions (three pillars, three Definition-of-Done components, three meeting types, three No-Surprise practices) โ€” a "rule of three" pattern repeated at nearly every section, likely deliberate for scannability and memorability rather than evidence of a rigid taxonomy. - No case study, client name, dollar figure, or before/after metric is cited anywhere in the piece โ€” all claims rest on Dean's stated "18 years" and "hundreds of agency owners" experience, not documented data. - The single external proof point offered is self-referential: "the same one operating right now in my own business," pointing to Dean's own paid offer rather than a third-party audit or case study. ## ๐Ÿ“š References - [Agency Project Management: The System That Keeps Everyone Sane](https://www.agencymavericks.com/agency-project-management-the-system-that-keeps-everyone-sane/) - [Headless business system (linked CTA)](https://mvrx.link/headless-blog) - [Mavericks Club โ€” Request a Call](https://scale.agencymavericks.com/?utm_source=website&utm_medium=blog-post-footer&utm_campaign=gptc&utm_content=request-a-call) - Tools named in the piece (context, not endorsements): ClickUp, Monday.com, Asana, Jira, Slack, WhatsApp. ## ๐Ÿ—ฃ๏ธ Paraphrase - Paragraph A: Agencies don't fail because they lack software โ€” they fail because nobody wrote down how work is actually supposed to move from a signed contract to an approved deliverable. Buying a new PM tool without first defining that process just gives the same chaos a new coat of paint. - Paragraph B: A workable system rests on three things holding together at once โ€” everyone can see project status at a glance, every task has exactly one accountable owner, and most of the work follows a repeatable template instead of being reinvented per client. Layer on a hard definition of "done," a real capacity buffer instead of 100%-booked teams, meetings that carry strategy instead of status, and proactive client updates instead of reactive damage control โ€” and the owner can finally stop being the one holding the whole business together by hand. ## ๐Ÿ“ฐ Newsletter - This piece isn't WordPress-specific, so the blurb below is adapted for an agency-ops / developer-services audience rather than a WordPress plugin/community angle. - Friendly professional-services blurb: "If your project management tool feels like a graveyard of overdue tasks, the fix probably isn't tool #4 โ€” it's the process you never wrote down. Troy Dean's latest breaks agency delivery into three things worth stealing this week: give every task exactly one owner, cap your team's booked capacity at 70-80% instead of 100%, and move 'status' out of meetings and into your tool so meetings can actually be about strategy. Worth 10 minutes if you've ever had a client ask 'where are we at?' and you had to go check three different apps to answer." - Helpful links: [full article](https://www.agencymavericks.com/agency-project-management-the-system-that-keeps-everyone-sane/). ## โœ… Action Items - The fixed subteam taxonomy below (DevRel/OSPO/Community/WordPress/WPCC/FAIR) is built for open-source/WordPress-ecosystem content; this article is generic agency-operations advice with no WordPress, OSS governance, or DevRel content, so most subteams have nothing genuine to attach. Agency-relevant action items are listed once, up front, instead of forced into ecosystem-specific buckets. - **Agency operations (source-relevant items):** - Map the full project lifecycle (contract signed โ†’ deliverable approved) on a whiteboard before evaluating or migrating any PM tool. - Define "Done" per task type (deliverable, quality bar, approval/revision count) before work starts, to pre-empt scope creep. - Stand up a Resource View showing booked hours vs. capacity; cap planned utilization at 70-80%. - Replace ad hoc status meetings with a three-meeting weekly rhythm (Monday kickoff, daily standup, Friday retro) and move status reporting into the PM tool. - Centralize client feedback into one channel (PM tool or dedicated feedback tool) and institute a templated Friday progress report plus a Red-Amber-Green health indicator. #### DevRel - Not applicable to this source โ€” the article contains no developer advocacy, education, or DevRel-specific content. #### OSPO - Not applicable to this source โ€” no open-source program office, licensing, or governance content is present. #### Community - Not applicable to this source โ€” the "community" discussed is an agency's internal team and clients, not an OSS contributor community; the template's maintainer/contributor/sponsor framing doesn't map. #### WordPress - Not applicable to this source โ€” the article never mentions WordPress, WordPress core, or the WordPress project. #### The WPCC - Not applicable to this source โ€” no WPCC, fellowship, or grant-related content appears. ### FAIR - Not applicable to this source โ€” no FAIR governance, provenance, or funding-covenant content appears. ## ๐Ÿงช Hypotheses - H1: Agencies that define a written "Definition of Done" per task type will report fewer client-initiated scope-creep requests than agencies without one. - H2: Capping team utilization at 70-80% (vs. 100%) correlates with lower staff turnover in service agencies over a 12-month period. - H3: Moving status reporting out of meetings and into a PM tool reduces total weekly meeting time without reducing perceived project visibility. - H4: Proactive weekly client status reports (a "No-Surprise" policy) reduce the volume of unscheduled client check-in emails/calls. - H5: Agencies where the owner is the sole "task rescuer" show slower revenue growth per employee than agencies where task ownership is distributed and enforced. ### ๐Ÿ“Š Methodology - H1/H4: A/B or before-after comparison across a cohort of Mavericks Club member agencies โ€” track scope-change-request counts and unscheduled client contacts for 90 days before and after adopting a written Definition-of-Done and a weekly progress-report template. - H2: Survey or payroll-record analysis correlating self-reported or tool-reported utilization rates with 12-month staff attrition, controlling for agency size and vertical. - H3: Time-tracking diary study measuring total meeting hours and a separate stakeholder-rated "I know where every active project stands" score, pre/post moving status into the PM tool. - H5: Comparative case study of agencies self-identifying as "owner is the bottleneck" vs. "owner delegates task ownership," matched on size/revenue band, tracking revenue-per-employee over 2 years. ### โ“ Questions - What's the actual failure rate of agencies that adopt SOPs and buffer policies but never change PM software โ€” does process alone move the needle without a tool change? - How do you enforce "one owner per task" when work genuinely requires two disciplines (e.g., design + dev handoff) without creating a false single point of accountability? - At what agency size does the "Monday kickoff / daily standup / Friday retro" rhythm start breaking down (too many projects for one shared cadence)? - Does a 70-80% buffer policy hold across project-based and retainer-based agency models equally, or does it need to flex by engagement type? - How much of the "silence causes client friction" claim is specific to service/agency relationships vs. generalizable to any vendor relationship? ### ๐Ÿ”ฎ Future Research - Empirical study distinguishing which of the three pillars (visibility, accountability, repeatability) has the largest independent effect on project delivery time and margin. - Comparative research on optimal buffer percentage by agency discipline (dev-heavy vs. design-heavy vs. marketing/strategy agencies). - Research on the actual cost (in dollars, not just "burnout") of owner-as-bottleneck management versus delegated task-ownership models. - Study of client-perceived trust as a function of communication cadence (daily vs. weekly vs. milestone-only updates). ### ๐Ÿ’ก Implications - Practice: agencies adopting this framework would need to invest time in SOP-writing and whiteboard process mapping before any tool migration โ€” a near-term productivity cost for a claimed long-term margin and retention benefit. - Policy (internal HR): a formal 70-80% buffer policy changes how sales and delivery teams price and staff projects, likely requiring updated capacity-planning tooling or spreadsheets. - Security/compliance: centralizing all client feedback into a single channel reduces the risk of missed or contradictory instructions but creates a single point of failure if that channel or tool goes down. - Education/onboarding: SOP-based repeatability implies new hires can be onboarded against documented templates rather than tribal knowledge held by the owner โ€” a durable knowledge-transfer benefit if executed. - Funding/business model: the article doubles as a lead-generation vehicle for Dean's paid "Mavericks Club" coaching and a "headless agency" product, so its prescriptions should be read as marketing content backed by unverified anecdote, not as audited case-study evidence. ### ๐Ÿง  Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade approximately 9-10 (conversational, short-to-medium sentences, some compound sentences and rhetorical repetition; accessible to a general business-reader audience). #### ๐Ÿ‘€ Visual learners - Present: bolded key terms (Visibility, Accountability, Repeatability; Red-Amber-Green), bulleted lists breaking down multi-part concepts. - Improve: an actual workflow diagram (contract โ†’ discovery โ†’ build โ†’ review โ†’ handover), a capacity-utilization chart illustrating the 70-80% buffer concept, and a sample Red-Amber-Green status-report screenshot. #### ๐Ÿ”Š Aural learners - Present: no audio or podcast version linked from the article. - Improve: a 3-5 minute audio summary or a companion podcast episode walking through the three pillars and the weekly meeting rhythm. #### ๐Ÿ—ฃ๏ธ Verbal learners - Present: analogies ("digital filing cabinet," "inventing fire for the first time"), plain-language definitions of jargon like "scope creep" and "Definition of Done." - Improve: a short glossary box defining SOP, Resource View, and Buffer Policy in one line each for readers new to agency-ops vocabulary. #### ๐Ÿงฉ Kinesthetic learners - Present: concrete templates implied (weekly progress report, RAG status, Definition-of-Done checklist) though none are provided as fill-in artifacts. - Improve: a downloadable Definition-of-Done template, a sample weekly-report email, and a starter SOP checklist readers could apply immediately. #### ๐Ÿง  Logical learners - Present: the three-pillar structure and the numbered Definition-of-Done components function as an implicit decision framework. - Improve: a decision tree or table showing "if X symptom (e.g., client silence complaints) โ†’ apply Y fix (No-Surprise policy)" to make the diagnostic logic explicit. #### ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ Social learners - Present: none โ€” no forum, discussion prompt, or community Q&A is embedded in the article. - Improve: a discussion prompt inviting readers to share their own buffer-policy percentage or Definition-of-Done template in a comments section or community group. #### ๐Ÿง˜โ€โ™€๏ธ Solitary learners - Present: none explicit, though the piece implicitly invites self-audit ("if you can't map that out on a whiteboard..."). - Improve: a short self-assessment checklist ("Do you have one owner per task? Y/N") readers could work through alone before acting. #### ๐ŸŒฟ Naturalistic learners - Present: no sustainability, environmental, or ecosystem analogy present. - Improve: not a natural fit for this content; omit rather than force an ecosystem metaphor. ### ๐Ÿ“Š Accessibility Assessment #### Screen reader semantics - Present: clear H2/H3 heading hierarchy in the source article, descriptive section titles. - Improve: verify bolded inline terms (e.g., "Visibility," "The Deliverable") are not the only signal of structure โ€” ensure they're also wrapped in proper heading or list markup, not just bold text, for screen-reader landmark navigation. #### Keyboard navigation - Present: standard blog layout, no evidence of custom interactive widgets that would introduce keyboard traps. - Improve: not assessable further without rendering the live page in a browser; no per-source action beyond standard site-wide keyboard-nav QA. #### Contrast and readability - Present: not directly assessable from extracted text content alone. - Improve: standard site-wide check recommended (4.5:1 text contrast, adequate line-height) โ€” not specific to this article's content. #### Text resizing and reflow - Present: not assessable from text extraction; standard blog template presumed responsive. - Improve: verify bullet lists and blockquote-style CTA don't clip at 200% zoom. #### Media and captions - Not applicable to this source โ€” the article contains no video, audio, or embedded media requiring captions or transcripts. #### Forms and interactions - Not applicable to this source โ€” the only interactive elements are outbound text links ("Check it out here," "Request a Call"), not forms. #### Standards reference - Gaps map to WCAG 2.2 AA 1.3.1 (Info and Relationships โ€” heading/bold semantics) and 1.4.4 (Resize text); other criteria are not assessable from extracted content alone. ### ๐ŸŒ DEIB Assessment #### Cultural breadth - Present: no region-specific examples or currency; generic "agency" framing that could apply in most English-speaking markets. - Improve: include international case examples (agency norms and labor practices vary by region, especially around overtime/buffer expectations). #### Inclusive language - Present: gender-neutral language throughout ("your designer," "your developer," "the team"); no gendered pronouns used for hypothetical staff. - Improve: minor jargon (SOP, RAG status) is defined in context but a short glossary would help non-native English readers. #### Neurodiversity support - Present: consistent three-part list structure (three pillars, three meeting types, three No-Surprise practices) aids predictability and chunking. - Improve: heavier use of numbered steps rather than prose-embedded lists in some sections (e.g., the "Doer to Director" section is dense prose with no supporting bullets). #### Representation - Present: no named individuals, client examples, or demographic references โ€” the piece is abstracted to "the agency owner" and "the team" without representation issues either way. - Improve: if case studies are added in future revisions, ensure varied agency types/founders (not just one archetype) are represented. #### Psychological safety - Present: acknowledges owner burnout and staff attrition ("They quit because the workload is unpredictable") with a non-blaming, structural framing. - Improve: could more explicitly validate the emotional toll on staff (not just owners) rather than centering the owner's experience throughout. ### โœ… Logical Validity #### Strong reasoning - Causal argument (tool-trap section): the claim "the tool is a digital filing cabinet" supports a coherent causal chain โ€” undefined process โ†’ same problems regardless of software โ€” reinforced by the anecdote of agencies migrating tools three times a year without resolution. This is a reasonable inductive generalization from experience, though not empirically tested. - Analogical reasoning (Definition of Done section): the three-way disagreement example (designer/developer/client each defining "done" differently) is a clear, relatable illustration that strengthens the argument's persuasiveness even without hard data. #### Fallacies - **Anecdotal evidence / appeal to authority:** The entire piece rests on "I've watched hundreds of agency owners..." and "18 years" of experience as its evidentiary base, with no cited data, survey, or third-party source. Location: opening paragraph and recurring throughout. Fix: cite even one anonymized client metric (e.g., "one member cut overdue tasks by X% after implementing...") to move from pure anecdote toward supported claim. - **False dichotomy (implicit):** The tool-vs-process framing ("ClickUp... will not fix a broken process") edges toward suggesting tools are irrelevant, when in practice tool choice does affect how easily a defined process can be enforced (e.g., dependency tracking, automation). Fix: acknowledge that a good process still benefits from tooling that supports it, rather than framing tools as purely inert. - **Commercial bias (undisclosed conflict of interest, soft form):** The article's prescriptions ultimately funnel to a paid offer ("I built the complete system... Check it out here" and a "Request a Call" CTA), meaning the diagnostic framing (three pillars, buffer policy, etc.) is not neutral advice but a funnel into Dean's own product. Location: closing section. Fix: transparent framing already exists (it's clearly a CTA), but readers should weight the advice as marketing content, not audited methodology. #### Tone of voice - Direct, confident, occasionally confrontational ("Let me be direct with you," "Period."). Second-person address throughout ("your agency," "you have to stop"). Motivational-coaching register with short punchy sentences mixed with longer explanatory ones โ€” consistent with a founder/consultant thought-leadership voice. ### ๐Ÿ›ก๏ธ DARVO Analysis Not applicable to this source โ€” DARVO (Deny, Attack, Reverse Victim and Offender) analysis requires an accusation-and-defense dynamic between parties. This article is single-voice business advice content with no accusation being denied, no accuser being attacked, and no victim/offender reversal at play. ## ๐ŸŽฏ Conclusion - Bottom line: agency chaos is a process-definition problem wearing a software costume โ€” visibility, single-owner accountability, and repeatable SOPs have to be designed on a whiteboard before any tool can enforce them, and the owner's real job is building a system that survives without their personal heroics. - Practical next steps for readers: (1) whiteboard the full project lifecycle from signed contract to approved deliverable before touching any PM tool settings; (2) write a one-page Definition of Done template covering deliverable, quality bar, and approval/revision count per task type; (3) audit current team utilization and adopt a 70-80% capacity buffer; (4) restructure weekly meetings into kickoff/standup/retro and move status reporting into the PM tool; (5) stand up a single client feedback channel and a templated weekly progress report before the next project kicks off. ## ๐Ÿ”„ Refactor Appendix โ€” Agency Project Management: The System That Keeps Everyone Sane > Density: 2โ€“5 Literature atoms (H3), 0โ€“3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, โ‰ค10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" โ†’ split. > > Tag pool: #bmf ยท #addendum ยท #xref ยท #articleseed ยท #storystem ยท #share ยท #aphorisms ### ๐Ÿ“š Literature Atoms (H3) #### One task owner prevents diffused accountability > [!quote] ID:rw_pending-1 > "When everyone is responsible, nobody is responsible." **Context & use**: - From the "Accountability" pillar section of the article. - Load-bearing claim for the whole piece: every downstream fix (Definition of Done, weekly rhythm) assumes single-owner task assignment as a precondition. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea โœ“ --> #### Tool migration can't fix an undefined process > [!quote] ID:rw_pending-2 > "The tool is just a digital filing cabinet. If you put garbage in, you get organised garbage out." **Context & use**: - From "The Tool Trap" section, the article's central thesis. - Useful cross-reference for any note on PM-tool selection or agency-ops audits โ€” reframes "which tool" questions as "which process" questions. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea โœ“ --> #### Silence, not bad news, drives client friction > [!quote] ID:rw_pending-3 > "The biggest cause of client friction is silence. When a client hasn't heard from you in four days, they assume nothing is happening." **Context & use**: - From "Client Communication as a Project Management Function." - Actionable for any client-services or account-management workflow note โ€” supports proactive-communication SOPs over reactive firefighting. **Tags**: #xref #share <!-- atomicity: 1 idea โœ“ --> ### ๐Ÿง  Permanent Candidates (H4) #### [P1] A system needs one owner per task to function **Claim** (one sentence, Courtney's voice): A task assigned to more than one person has no real owner, so I default every task โ€” mine or delegated โ€” to exactly one named accountable person. **Evidence pointer**: [[#One task owner prevents diffused accountability]] **Scope & conditions**: Holds for discrete tasks and milestones; breaks down for genuinely joint deliverables (e.g., design-to-dev handoff) where a single RACI "owner" role, not a single doer, is still required. **Links** (โ‰ฅ1 with annotation): - [[Loop-engineering OS]] โ€” because applies-in maker/checker loop design, where each loop needs one accountable owner, not a shared one. <!-- atomicity: 1 idea โœ“ --> ### โœ๏ธ Fleeting Queue - [F1] Compare the article's "70-80% buffer policy" against Courtney's own scheduler-reliability notes (routines missing runs) โ€” is under-buffering capacity a root cause there too? โ€” internal cross-reference #xref - [F2] Consider whether the "Red-Amber-Green" client-status pattern is worth adopting for courtneyr.dev project status updates to clients/collaborators #articleseed ### โ†’ Things 3 (max 2 actions) - [ ] Draft a one-page Definition-of-Done template (deliverable / quality bar / approval count) for use on the next client or content project โ€” agency-ops #things <!-- deep-read:sections end --> ๐Ÿ“„ **Full text:** [[Full Document Contents/Articles/Agency Project Management The System That Keeps Everyone Sane.md|Agency Project Management: The System That Keeps Everyone Sane by agencymavericks.com]] ## Highlights - The tool is just a digital filing cabinet. If you put garbage in, you get organised garbage out. The reason your project management feels like a mess is that you haven't defined the *behaviour* of how work moves through your agency. Youโ€™re looking for a technical solution to a cultural and procedural problem. ([View Highlight](https://read.readwise.io/read/01kxh9c8yfgepp416b6jgcc4tz)) - Tags: atom/literature/h2 - I see this mistake constantly: tasks assigned to โ€œThe Teamโ€ or multiple people. When everyone is responsible, nobody is responsible. Every single milestone, task, and sub-task must have one name attached to it. That person is the owner. They are the one who ensures it gets done or flags it early if itโ€™s going off the rails. ([View Highlight](https://read.readwise.io/read/01kxh9c7h36b0vya08cnc9zkx5)) - Tags: atom/literature/h1 - The biggest cause of client friction is silence. When a client hasn't heard from you in four days, they assume nothing is happening. Then they email you. Then you have to stop what you're doing to reply. This is reactive management, and it's exhausting. ([View Highlight](https://read.readwise.io/read/01kxh9cbpzt6cq8xh9m4jpybeq)) - Tags: atom/literature/h3 - Your job is to build the machine that does the work, not to do the work yourself. This means you have to stop โ€œjumping inโ€ to fix things. Every time you jump in to save a project, you undermine your system and your team. You teach them that the system doesn't matter because โ€œTroy will fix it if it breaks.โ€ ([View Highlight](https://read.readwise.io/read/01kxh9cc6dr0b90p2838877nqj)) - Tags: atom/literature/h4