Why does IT ownership produce vague targets?
A Digital FTE owned by IT tends to get excellent access configuration and vague targets, because the people configuring it do not live with the output. That is not a criticism of IT; it is a predictable consequence of distance from the work.
Targets get sharp when the person setting them feels the cost of getting them wrong. A marketing owner who has to explain a thin content quarter writes a sharper remit than someone who will never be asked about it.
What exactly does the function owner manage?
The function owner manages the remit, the targets, the approvals, and the autonomy level. They decide what the role is accountable for, what good looks like, what gets approved, and when a class of action has earned promotion.
They are also the person who notices drift. A manager reading the approvals queue daily sees a standard slipping long before it shows up in a metric, which is the kind of early signal that no dashboard provides.
What exactly does security own?
Security and IT own which systems the Digital FTE can reach, with what scope, and how that access is revoked. They also own the access record: what was granted, by whom, and when it gets reviewed.
This separation is the point. The function owner cannot quietly widen access to make a target easier, and security cannot quietly narrow it and break the work without a conversation. Each group is accountable for the thing it can actually control.
- Function owner: remit, targets, approvals, autonomy level, review rhythm
- Security and IT: system access, permission scope, credential handling, revocation
- Both: the periodic review of whether the access still matches the remit
Should the owner be a manager or an individual contributor?
The owner should be whoever is accountable for the function's outcome, which is often a senior individual contributor rather than a manager. The test is not seniority but consequence: who gets asked when this function underperforms.
What matters more is that it is one named person. Shared ownership between two people reliably produces an unread approvals queue, because each assumes the other is clearing it.
What happens when the owner leaves?
Ownership should transfer explicitly when someone leaves, in the same way a direct report would be reassigned. An unowned Digital FTE keeps producing proposals into a queue nobody reads, which is the quietest failure mode there is.
Add it to the standard leaver checklist alongside systems and responsibilities. The one-page role document makes the handover short, because the new owner inherits a written remit rather than folklore.
How does this scale to several roles?
As the number of Digital FTEs grows, keep one named owner per role rather than creating a central team that manages all of them. A central team recreates the distance problem that made IT ownership produce vague targets.
What can usefully centralise is the standard: the access review, the audit expectations, the autonomy policy, and the template for the one-page role document. Centralise the governance, distribute the management.
What does the manager actually do each week, in hours?
The manager of a Digital FTE spends about five minutes a day on the morning brief and the approvals it lists, which in the first weeks of a role at Level 0 may be closer to fifteen because every proposal is gated. They spend perhaps half an hour a week reading the send-back reasons grouped by category and adjusting the remit. Once a month they spend about thirty minutes on the review: the FTE's own report, the targets against evidence, usage and cost per outcome, and the three decisions on targets, remit, and autonomy.
Those hours fall as routine classes earn autonomy and approvals are routed to team members close to the work. They are also hours the function owner already understands, because they are the same decisions they would make about a person doing the job: is the work right, is the scope right, can this be trusted with more. Security's hours are different and smaller: reviewing connections at setup and quarterly, and reading the audit trail on request. The split is what keeps ownership with the person who can judge the work, and control with the person who can judge the access.