# The Job Nobody Wrote Down

*Published 2026-10-01* | Author: brad-webb

> **tl;dr** If you are the whole growth team, you do not have a job. You have a department with one name on it, and nobody wrote that department down, including you. So every conversation about what to stop, what to automate, or who to hire next starts from a guess. Before you subtract or delegate anything, write the job down. Not by function, by recurrence: what happens every day, every week, every month, and every time something specific occurs. Then tag each line: only you, could run on a rule, or nobody owns it. The list is longer than you think, and the longest column is the one nobody owns.

*This opens The Growth Team of One, a series in four parts. This is part 1 of 4: write the job down.*

Here is what took me too long to admit. The first time I took a job as the only growth person in a company, the posting had a responsibilities section with six bullets, and the first one was "own growth." The other five were examples of the first one. I read it as a compliment.

About a month in, somebody asked what I was working on that week and I could not answer in under a minute. Not because it was complicated. Because it was a list, and I had never seen the list. That night I tried to write it out. I stopped at the bottom of the second page, not because I was done, but because I noticed that half of what I had written was work I did not remember choosing.

"Own growth" was not a job description. It was a container. Nobody had written down what went in it, including the person filling it.

## The title is a container

If you are the whole growth team, your title is doing the work of an org chart. That is true whether you are a founder running GTM between product calls, a head of growth with no reports, or the first GTM hire at a company that just noticed it needed one.

Open the title up and look at the parts. The website, and the pixel on it, and the form that feeds the CRM. CRM hygiene: the duplicates, the owner field, the lifecycle stage nobody updates. Lifecycle email. Outbound, when there is outbound. Paid, when there is budget. Partner intros. The weekly report. The board slide. The pricing page test that has been "next week" since spring. Sales assist, which mostly means the one-pager somebody needs by two o'clock. Tool admin: seats, renewals, the integration that broke on Friday. Data plumbing, which is the part of the job where you are an engineer nobody hired.

None of those is a category. Each one is a role that somebody at a larger company does full time, with a manager, a title, and a job description of their own. At yours it is a Tuesday afternoon.

That is the first thing to see clearly. Not that it is a lot. Everyone already knows it is a lot. It is that each part is a real role, and every one of them resolves to the same name.

OPEN THE ORG CHART (interactive: the growth org chart, one role at a time; six role buttons each open a box, and every box has the same name in it)
Head of Growth: You
- Demand: You. The website, and the pixel on it. Paid, when there is budget. Outbound, when there is outbound. Partner intros.
- Lifecycle: You. Trial follow-up. Lifecycle email. The Thursday email. The pricing page test.
- Sales assist: You. The one-pager somebody needs by two. Demo prep. The call the founder wants you on.
- Ops and data: You. CRM hygiene: duplicates, owners, stages. The form that feeds the CRM. Data plumbing.
- Reporting: You. The weekly pipeline note. The monthly board number. The board slide.
- Tools: You. Seats and renewals. The integration that broke on Friday. Tool admin.
Roles and parts are examples; your chart will differ. Nothing here is scored.
Figure 1. The growth org chart, opened one role at a time. Every box resolves to the same name.

## Write it by recurrence, not by function

The instinct, when you finally sit down to write the job out, is to write it by function. Demand. Lifecycle. Ops. Reporting. It looks tidy. It is also close to useless, because a function list hides the load. "Reporting" is one word on the page. It is also a Monday morning, a Thursday afternoon, and the last two days of every month.

Write it by recurrence instead. What happens every day. What happens every week. What happens every month. And what happens every time a specific thing occurs.

Every day: the check of who visited the site overnight. The scan of new signups. The look at the ad account to make sure nothing is on fire.

Every week: the pipeline note to the founder. The CRM cleanup. The list for outbound. The email that goes out on Thursdays because it went out last Thursday.

Every month: the board number. The spend reconciliation. The renewal that is somehow always a surprise.

Every time something happens: a trial starts, and somebody should follow up. A deal closes, and somebody should update the CRM and the case study list. A known account comes back to the pricing page, and somebody should notice. An integration breaks, and somebody has to be the one who finds out.

That last group is where the list gets long. It is also the group that never shows up in a function list, because a trigger does not have a function. It has an occurrence. You only see it when you write the words "every time."

THE JOB, BY RECURRENCE (interactive: sixteen recurring growth jobs as checkboxes in four groups; tick every job you did in the last month, whether or not it is in your title; the tally is the only output)
Every day: Check who visited the site overnight. Scan new signups and trials. Check ad spend and pacing. Triage form fills and the inbound inbox.
Every week: Write the pipeline note for the founder. Clean up the CRM (duplicates, owners, stages). Build the outbound list. Send the weekly email.
Every month: Pull the board number and build the slide. Reconcile tool and ad spend. Run or review the pricing page test. Fix attribution and the broken UTMs.
Every time something happens: Follow up when a trial starts. Update the CRM and case study list when a deal closes. Notice when a known account comes back to pricing. Find out when an integration breaks.
Tally: You ticked N recurring jobs. Every one of them sits under the same title.
Sixteen common jobs, grouped by how often they happen. Yours will include some that are not here; write those down too. Nothing here is scored.
Figure 2. Tick what you actually do. The count is the only output.

## Three tags

A list is not a finding yet. Tag every line with one of these.

**Only you.** Judgment. The pricing call, the positioning call, the conversation with the customer who is about to leave. Work where the value is that you did it.

**Could run on a rule.** Repeatable, triggered, and time-sensitive. The follow-up when a trial starts. The weekly pipeline note assembled from the same few places. If you can write down when it happens and what should happen next, it can run without you.

**Nobody owns it.** It happens when you remember. The accurate version of this tag is "it happens when I remember, which is sometimes."

If a line fits two tags, use the one that is true today. "Could run on a rule" describes the work. "Nobody owns it" describes your week.

Most planning conversations live in the first two columns. The third column is the finding. It is always longer than you want, and it is where most of the value quietly leaks out. I wrote about one line of it in [Follow-Up Has No Owner](https://www.civic.com/field-notes/follow-up-has-no-owner): the signup that goes on a mental list titled "maybe today" and is on no list at all three days later. That was one line. Your third column has several.

Look at what ends up there. Not the hard work. The hard work has an owner, because it is hard and you know it is yours. What ends up in the third column is small, triggered, and time-sensitive: the note, the update, the check. Work too small to assign and too frequent to remember.

SORT THE WORK (interactive: one job at a time from the list you ticked in Figure 2, or the default sixteen; three buttons, Only you, Could run on a rule, Nobody owns it; three bins fill and count; no verdict)
One possible sort of the sixteen jobs (illustrative, one possible sort, not a benchmark; yours will differ):
Only you: Pull the board number and build the slide. Run or review the pricing page test.
Could run on a rule: Check who visited the site overnight. Scan new signups and trials. Check ad spend and pacing. Write the pipeline note for the founder. Clean up the CRM (duplicates, owners, stages). Build the outbound list. Send the weekly email. Reconcile tool and ad spend.
Nobody owns it: Triage form fills and the inbound inbox. Fix attribution and the broken UTMs. Follow up when a trial starts. Update the CRM and case study list when a deal closes. Notice when a known account comes back to pricing. Find out when an integration breaks.
Keep this list. Part 2 picks it up to decide what you stop doing, and part 3 picks up the "could run on a rule" bin.
No tag is better than another, and nothing here is scored. The tags describe where the work sits today.
Figure 3. Sort the work you ticked into the three tags. Keep the list; the next two parts use it.

## Why write it down first

You cannot subtract what you have not listed. You cannot delegate what you cannot describe. You cannot hand over what only lives in your head.

Most of the advice aimed at the growth team of one skips this step. It goes straight to "automate the busywork" or "hire your second person," and both of those assume you know what the work is. You probably do not, not really. I did not. You know what you did this week. That is a different list.

Chris wrote last week about how to [plan 2027 with the team you already have](https://www.civic.com/field-notes/plan-2027-with-the-team-you-already-have), and his question was which repetitive, time-sensitive work the team should stop doing by hand. It is the right question. It only has an answer if the work is written down. On a team of one, the team you already have is you, and the plan starts with your list.

The list matters later for a less obvious reason. Some of this work will eventually run without you, and when it does, somebody will ask what it did. Chris put it plainly in his piece yesterday: who else will need to trust what this system did? You cannot answer that about work nobody listed. [Thirteen Agents, One Owner](https://www.civic.com/field-notes/thirteen-agents-one-owner) made the same argument about agents: every one needs an answer to who approved it, who audits it, and who can stop it. The job list is where those answers start. A line that was never written down has no approver, because nobody knew it existed.

Tuesday's piece, on [onboarding run by an agent](https://www.civic.com/field-notes/onboarding-run-by-an-agent), makes the point from the other side: a step is safe to hand an agent when it is described well enough to be refused. That holds for anything you hand to a rule. The description is most of the delegation.

## What the record already knows

If some of the job already runs, you have a head start, and it is sitting in a log. We ran Bryn on ourselves before anyone else, and [we still do](https://www.civic.com/field-notes/we-are-customer-zero). When you sit down to write your own list, the audit log is the first place to look, because it is a partial inventory of work that already happened without you: every Play that ran, what triggered it, what it did, and when. Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack, and the record it keeps is the part of your job description that has already been written. It will not write the rest. That part is still yours.

## The gift

Do this Monday. Block an hour. You will want to stop at twenty minutes, which is about when the "every time" lines start showing up.

Write the job description you actually have. One line per recurring task. For each line, write what it is, how often it happens, what triggers it, and who would notice if it stopped.

Then tag every line: only you, could run on a rule, or nobody owns it.

Read the "who would notice" column twice. Some lines nobody would notice for a month; hold on to those, they matter next week. Some lines a customer would notice by lunch. If one of those is tagged "nobody owns it," you have found the first thing to fix, before anything else in this series.

Keep the list. The rest of the series works from it.

## Where this goes

Part 2, The Work You Stop Doing: subtraction, and how to tell the work nobody would miss from the work that only looks optional.

Part 3, The Work That Runs Without You: what can run as a Play, what should sit in Approve mode, and what stays yours.

Part 4, The Stack You Hand Over: the day hire number two, or your successor, inherits the stack, and the record becomes the onboarding doc.

*Part 1 of 4 of The Growth Team of One.*

**Stop watching signals. Start running them.**

Source: https://www.civic.com/field-notes/the-job-nobody-wrote-down