The marketing team: queues, roles and work costs

Altynai runs marketing at an Almaty analytics reporting service, and her team turns out eight pieces a week: ads, emails, sample reports for the website. Talgat, the owner, has time to approve three. Twenty finished pieces are already sitting there waiting for him. At the planning meeting someone suggests hiring another designer: "Marketing is always late." But the new person would join the same queue to Talgat, and it would only get longer.

This is the same service for small retail chains as in the 3-5 year strategy; the numbers in this lesson are made up. Fixed costs in its monthly P&L are 6,800,000 ₸: 6,000,000 ₸ of payroll for a team of 11 including employer charges, the rest rent and shared services. Before you open a vacancy, answer two questions: what work the team must deliver, and what the new person will cost.

Trace one piece of work

Take a few recent pieces and use the chat history and task log to rebuild when each step happened: request in, brief ready, designer started, first version shown, sent for approval, edits back, piece published. Next to that, write down how long people worked on it and how long it just sat there. A banner drawn in an hour and approved a week later and a banner reworked for a week need different fixes: the first is a queue problem, the second a brief problem.

You will not get a shared queue while everyone means something different by "ready". The designer calls a layout with a rough price ready, Altynai is still waiting for final copy, and Talgat sees a promise he never made. Agree what a piece must carry when it goes for approval: the final offer, checked numbers, the right format and a link to where the terms come from. Then Talgat reviews the work instead of finishing it.

Sometimes the delay starts before the designer. Talgat has not picked a segment, sales has added a new service, product has not confirmed the pilot length. A second designer will draw faster, but will not make those decisions for anyone. So in the task log, every stuck piece says which decision it is waiting for and from whom.

Calculate flow and backlog

Say the pieces are roughly the same size, arrive and get approved within the same week, and nothing is cancelled. Then the queue grows by 8 - 3 = 5 pieces a week. After one week there are 25, after four weeks 40: 20 + 4 × 5. That is flow arithmetic, and it says nothing about who on the team is slow.

Producing eight when only three get approved is also expensive because terms change. Copy that has sat in the queue for a month may be out of date and need rewriting. Before you speed up output, sort the queue into three piles: still current, needs an update, safe to drop.

If Talgat starts approving eight a week, the queue stops growing, but the old twenty stay where they are. There are three ways to clear them: approve more for a while, produce less for a while, or drop what is no longer needed. Record the effect of each one separately, or in a month you will not know what worked.

Compare the cost of two options

For the estimate, assume one piece takes an hour of work and an hour of internal time is worth 5,000 ₸. Four more pieces a week is 20,000 ₸ a week, 80,000 ₸ over four weeks. If Talgat still approves three, twelve will arrive for approval and the queue will grow by nine a week. The extra money buys you a faster pile-up of unfinished work.

The second option is to let one employee sign off standard pieces that stay within the agreed offer, and leave Talgat the exceptions. Say the sign-off criteria and reviewing borderline cases take two extra hours a week; at the same rate that is 10,000 ₸. This change has a goal you can check: more pieces accepted and published at the same quality.

Both amounts are estimates of time, not money in the bank. If salaries are fixed, the freed hours go to other work, but no tenge comes back to the account by itself. If a contractor does part of the work, the budget takes the amount on their invoice. The 5,000 ₸ rate is there to compare workload. It is not the market price of a designer or a manager.

After the change, watch four numbers: how many pieces went out, how long they waited, how many came back for rework and how many errors reached published work. If approval got faster because wrong prices now slip through, you do not want that speed. And if the queue now builds up at the designer and holds back launches that matter, that is when a request for extra hours has a case.

What the team is missing

Several causes can show up at once. A packed calendar will not tell you whom to hire. A list of stuck work with its cause and consequence tells you far more: which launch, customer reply or check did not happen because of it.

Define the function before the title

The service wants customers to get the right messages on time after a pilot. "We need a CRM marketer" is too broad until the outcome is described. These messages need an audience, the events that move a customer into and out of the flow, copy, exclusions, test records and error monitoring. Someone signs off the offer and the contact rules, someone prepares the data, someone accepts the finished flow.

The function owner keeps it moving but does not have to do every part. Bekzat, the developer, wires up the events, Zhanar's sales managers confirm deal stages, Altynai's team writes the copy. Hire for the part that, after this review, still has no one to do it or no time for it.

In Atlassian's roles exercise a team compares what people expect from each other and finds duties nobody owns. A small company only needs a table: the work, who does it, who accepts it, who covers. The "who accepts" column needs a person who can settle the question that is holding the work up. Otherwise the assignment stays on paper.

Staff, contractors and knowledge transfer

Ongoing product work needs someone who is at hand and remembers the context. A one-off integration can go to an outside specialist. A regular but partial workload fits a part-time arrangement. Pick the format after you have described the work, and confirm quality through the result and a clear acceptance step.

A new person costs more than their pay: tools, task setting, getting up to speed, review, holiday cover. An agency invoice and one employee's salary may cover different amounts of work, so compare them against the same task list. An outside contractor also needs a client inside the company who makes business decisions, or they will end up in the same queue to Talgat.

Work accounts, source files and the change log must belong to the company. The new role gets the access it needs, and handing the work over to someone else is part of acceptance. Raising this on someone's last day is too late: the process already lives in their memory.

Exercise: a resource request

Pick one recurring piece of work in your own project or a client's and draw its path from request to accepted result. For each step, write down working time, waiting time, rework and who owns the step. Prepare two options: change the process or add a resource. Each one needs a cost and a way you will compare them.

Back to Talgat's queue. Say that after handing over sign-off rights, ten pieces a week get approved while production stays at eight. Quality is the same, with no cancellations or rework. What happens to the queue of twenty, and how long will it take to clear?

After one week the queue holds 20 + 8 - 10 = 18 pieces. It shrinks by two a week, so at the same pace it takes ten weeks to clear. If Talgat wants the backlog gone within a month, something else has to change: cut incoming work for a while, approve more or drop what is out of date. A new designer does not get him closer to that goal: they add pieces at the input, and approval runs at the same speed.