Agency Operating Model for 5-50 Person Agencies
Agency owners ask me two questions that sound like one. The first is how far along the operation is, a maturity question covered separately in the operations maturity model. The second is how the operation is shaped, which is orthogonal to the first: a ten-person agency can run a well-documented functional model or a badly-documented pod model. Maturity is how developed the operation is. This piece is about the shape it takes: pods, functional teams, or a hybrid, and where that shape has to change as headcount grows.
I will lay out the trade-offs of each and how each tends to fail, not tell you which to run. None of the three is best in general. Each fits a particular mix of client work and misfits a different mix, and most of the pain I see comes from running last year’s right structure against this year’s roster.
What is a functional operating model, and where does it fail?
A functional model organizes people by discipline: strategy, design, build, media. Work moves through departments in sequence, and an account manager coordinates the handoffs. This is close to how most agencies start once one founder can no longer do everything, because it mirrors how the roles were hired, a designer, then a developer, then a media buyer, each joining the group already doing that work.
The strength is depth. A designer sitting among other designers gets reviewed by people who can judge the work, picks up technique from the person next to them, and has somewhere to go when a brief is ambiguous. Specialists get better inside a functional group in a way they rarely do sitting alone in a dedicated team.
The failure mode is the handoff. Work queues at each department boundary, and nobody owns the whole client relationship end to end. When a deadline slips, each department points at the one before it, and the account manager, who owns the relationship but not the work, is left explaining a delay they cannot fully diagnose. A designer working across ten accounts answers to ten sets of shifting priorities, and whoever manages that queue has no visibility into any client’s full picture.
What is a pod model, and where does it fail?
A pod model builds small cross-functional teams, a strategist, one or two producers, a coordinator, and gives each pod a fixed set of clients it owns from intake through reporting. There is no handoff between departments because there is no department. The pod is the department, sized for a handful of accounts.
The strength is ownership. One group holds the whole picture for its clients, and delays are visible immediately rather than after passing through two other teams. For agencies whose client work is similar enough that any pod could run any account, this is usually the more honest structure, because it matches the org chart to how accountability needs to work.
The failure mode is unevenness. Client work never arrives in equal parcels, so one pod runs overloaded while another sits underused, with no shared pool to draw from because every specialist belongs to exactly one pod. A designer inside a pod has no peer doing the same job to learn from, and the agency ends up with generalists instead of specialists sharpened by peers. Pods also reinvent the same processes independently, and a client who outgrows their pod inherits whatever the new one does differently.
What is a hybrid model, and where does it fail?
A hybrid keeps client-facing pods but adds a shared functional layer for work that does not divide evenly: a strategy lead supporting every pod, a QA function reviewing everyone’s output against one standard, a shared pool of specialists covering overflow no single pod can staff alone. The pod still owns the client relationship; the function underneath supplies the capacity a pod cannot generate by itself.
The strength is that it solves what pods and functional teams each create in isolation. Overload in one pod draws on the shared pool instead of sitting unaddressed. A specialist inside the shared function gets the peer group a pod cannot offer, and the client still deals with one owning team rather than a chain of departments.
The failure mode is authority. A hybrid model gives many people two lines of reporting: a pod lead who owns the client, and a functional head who owns the discipline. Both have a legitimate claim on the same time, and when priorities conflict, whoever is louder or senior wins by default. This produces the worst of both worlds: functional handoff friction underneath the appearance of pod-level ownership. A hybrid model that has not written down which lead’s call wins in a conflict is not a hybrid model; it is a functional model wearing a pod-shaped costume.
Who should own the client, the pod lead or the account manager?
This is really two questions collapsed into one: who the client trusts and calls first, and who is accountable for what gets produced. In a functional model these are almost always two different people, an account manager for the relationship and a department lead for the work, and the model depends on a fast translation between them. In a pod model they are frequently the same person, and that translation cost disappears.
The trade-off is not about which arrangement is more professional. It is about where you are willing to put the risk. Splitting the two roles protects against a single point of failure: if the account manager leaves, delivery knowledge stays with the team that did the work. Combining them removes a layer of retelling that reliably loses detail, but recreates a founder-led risk at pod scale: the pod lead is the one person who can explain both what was promised and built, and if they leave, the pod loses both halves of the account at once.
Where account management sits follows the same choice. In a functional model it sits as its own function, translating between departments that do not talk to each other. In a pod model it dissolves into the pod, because the pod lead already holds the relationship. In a hybrid model it must be explicitly assigned to the pod side of the authority split above, or it becomes a third claimant on the same time.
What has to change around fifteen people?
Below roughly fifteen people, the choice between functional and pod barely matters, because there are not enough concurrent clients for either failure mode to show up. A functional team of a few small departments does not generate meaningful handoff queues, and two pods do not generate meaningful unevenness, because there is not enough volume for load to diverge.
Around fifteen, that changes. There is enough concurrent client work that a functional model’s handoff queues start costing real days, and enough accounts that a founder can no longer smooth the gaps between departments informally. This is the first point where the structural choice becomes a decision rather than an accident of hiring order: does the roster look similar enough that a pod could run any account, or does the work split cleanly by discipline. Agencies that drift past fifteen without deciding end up with an accidental hybrid, carrying a hybrid’s failure mode without its deliberate structure.
What has to change around thirty people?
If an agency chose pods at fifteen, thirty is where the pod model’s own failure mode bites. There are now enough pods that unevenness between them is close to guaranteed most weeks, and enough specialists spread thin across pods that skill development has stalled for people who used to have a peer group. This is where the shared functional layer of a hybrid model starts to earn its overhead, because there is finally enough volume to justify a shared pool.
If an agency chose functional at fifteen and stayed there, thirty is where the handoff cost compounds instead of staying flat: more concurrent clients means more simultaneous handoffs competing for the same queue, and account managers do more coordination than actual account work. The same hybrid question applies in reverse: which accounts are similar enough to hand to a dedicated pod, freeing functional departments to hold only the work that benefits from staying grouped by discipline.
Either direction, thirty is where the authority question from the hybrid section stops being theoretical. An agency this size has enough people with two plausible bosses that an unresolved conflict stalls projects while two leads each wait for the other to make the call. Deciding this is exactly the kind of diagnosis I do inside operations consulting, because it is rarely obvious which lead should win a given conflict until someone maps where the conflicts actually happen.
So which model should an agency actually run?
I am not going to tell you, because the honest answer depends on your roster: how similar the accounts are, and how much of the work benefits from specialists near their peers versus close to the client. Look at your worst week last quarter and ask which failure mode it matches: a missed handoff, a mistake nobody caught because the specialist who could have caught it was in another pod, or a stalled decision because two leads each assumed the other owned the call. That failure names the model you are running, whatever the org chart says.
This decision is not permanent, and revisiting it is not a sign the last choice was wrong. The mix that made pods right at twenty people is not the mix at forty, and how those responsibilities redistribute as headcount changes is covered in the full operations guide. Structure is a decision you make again every time the roster or headcount shifts underneath it, not a decision you make once.
Where to start
Diagnosing which failure mode you are paying for is most of the work, and it is hard to see from inside the agency you run every day, because whichever structure you have always run feels like the only sane option until something forces a comparison. The Agency Ops Audit is $1,500 fixed, two weeks, ending in a written 90-day roadmap and a 60-minute readout on what to change first. The fractional retainer starts at $3,000 a month, 10 to 15 hours a week, 60-day minimum, and bigger build work is quoted at a fixed price per workflow. If your current model fits your roster, I would rather say so in the readout than sell you a restructure you do not need.
