Why write a job description for software?
Writing a job description for a Digital FTE is worth doing because the exercise forces decisions the business has been leaving implicit. Who owns this function, what does success look like, which decisions need a person, and what would count as out of bounds.
Teams that skip it usually make the same decisions anyway, one send-back at a time, over the first month. Writing it down compresses that month into an hour.
What goes in the outcome section?
The outcome section states what the role is accountable for in terms the business already uses, not in terms of activity. Be the answer for our buyer questions. Keep the ledger reconciled and exceptions surfaced within a day. Keep the pipeline covered without unapproved sends.
Then add the measures. Three to five, each paired so that volume alone cannot satisfy them, with the baseline recorded as it stands today.
What goes in the scope and systems section?
The scope section names the systems the role works in and the property it works on. A property means a specific site, store, ad account, or ledger rather than the whole estate, which keeps results attributable and mistakes contained.
List the permissions each system requires and who granted them. This is the section IT and security will actually read, and having it written means the access conversation happens once rather than repeatedly.
- Outcome: what this role is accountable for, in business terms
- Measures: three to five paired targets, with today's baseline
- Scope: which systems and which property, with permissions
- Decisions: what it decides alone and what it escalates
- Prohibitions: what it must never do, stated plainly
- Management: who owns it, who approves, and the review rhythm
How do you write the decision rights section?
The decision rights section states what the Digital FTE decides alone, what it proposes for approval, and what it must escalate to a named person. All three lines are necessary; omitting the third is how sensitive cases get handled automatically.
Write escalation triggers as concrete situations rather than as categories. A customer threatening legal action, a payment to a recipient never paid before, a claim that cannot be sourced, a topic on the excluded list. Concrete triggers fire reliably; abstract ones are interpreted.
What does the management section cover?
The management section names the human owner, the approver for each class of action, the review rhythm, and the current autonomy level. Naming individuals rather than teams matters, because a team does not clear an approvals queue.
Include the review rhythm explicitly: a daily pass over approvals, a weekly look at targets and exceptions, a monthly autonomy review. Writing it down is what turns it from an intention into a commitment someone can be held to.
How long should it be?
Keep the whole thing to one page, because a document nobody reads provides no clarity regardless of how complete it is. One page forces the prioritisation that makes the remit sharp.
Revisit it after the first month of send-backs. Add the one or two clarifying sentences that would have prevented the most common rejections, and delete anything that turned out not to matter.
Where does the job description live once it is written?
Once written, the job description does not sit in a document nobody opens; it becomes the Digital FTE's configuration. The outcome section becomes the Targets tab, each item with a status and evidence. The scope and systems section becomes the connections in Setup, each scoped to a tool and a property with the permissions granted. The decision rights section becomes the remit and the always-escalate list, and the starting point on the autonomy ladder, which is Level 0 for every class. The management section names the approver per category and the review cadence.
This is why the description is worth writing carefully: it is executed, not filed. When the send-back reasons at the weekly review show a repeated pattern, the fix is a line in the description, applied to the remit. When the monthly review promotes a class of action, the decision rights section changes and the change is logged. A job description that lives in the workspace stays true, because the workspace is where the job is actually done, and a successor manager reads the current version rather than the original.