What is the design problem?
The design problem is that a Digital FTE is a new kind of team member, a worker that does a function daily and proposes rather than acts, and existing team designs have no place for it. Treated as a tool, it has no owner and sits idle at Level 0. Treated as a person, it is reviewed on things it is designed to escalate. Treated as a replacement, it damages the people around it and loses the judgement work that only they can do.
Hybrid team design gives it the right place: a direct report with a named manager, a remit that owns the repetitive evidence-based work, and lines to the people who own everything else. This whitepaper sets out the design in six parts: the work sort, the reporting patterns, the approval routing, the change to people's roles, the review model, and the evolution of the design over time. Each part is a decision the manager makes, and the ftes.ai workspace records the decisions as they are made.
How is the work sorted?
The work is sorted by listing everything a function does and dividing it into two groups. Repetitive and evidence-based, with a checkable right answer: reconciling transactions, screening against a scorecard, answering from a knowledge base, keeping the CRM current, drafting from sources, measuring, monitoring, reporting. These the Digital FTE owns and proposes, with the evidence attached. Judgement, relationship, and decisions about people: deciding exceptions, interviewing, handling complaints, negotiating, coaching, and anything that changes a person's outcome. These stay human, and the FTE prepares the evidence for them.
The sorted list becomes the FTE's remit on one side and the people's role descriptions on the other. It is revisited quarterly from the send-back reasons: work that keeps coming back from the FTE was judgement work mis-sorted, and work people find themselves doing by hand was FTE work left out. The sort is the foundation of the design; every other decision follows from it, and getting it wrong is the most common cause of a hybrid team that feels unfair to its people.
Which reporting pattern fits?
Three reporting patterns fit different organizations, and all share the rule that a Digital FTE has exactly one named manager who reads its brief, approves its proposals, sets its targets, decides its autonomy, and reviews it. One FTE per function, reporting to that function's lead, suits established teams: the Finance Controller FTE reports to the finance lead, the Support FTE to the support lead, each manager judging proposals in a function they know. A pod of several FTEs under one operations manager suits small companies without functional leads, concentrating the management skill and the standards in one person, with the cost that their approval time is the bottleneck.
The apprentice pattern pairs an FTE with a junior who reviews its proposals under a senior's supervision, learns the standard from approvals and send-backs, and grows into the FTE's manager. It suits teams developing people and turns the FTE into a training instrument. Patterns evolve: a pod splits into per-function FTEs as leads are hired, each inheriting an FTE whose remit, memory, and record already exist; an apprentice becomes a manager and takes the FTE along. Changing the manager is a permissioned, logged action, and nothing about the FTE restarts.
How are approvals and escalations routed?
Approvals are routed by category to the person closest to that judgement. Routine categories, such as exact-match reconciliations or interview scheduling, go to the team member nearest the work, which is fast and is also how they learn the standard. Sensitive categories, such as accounting adjustments, clinical content, or anything on the always-escalate list, go to the manager or a named specialist. The approver's name is in the audit trail for every decision, and the remit can enforce routing so that a sensitive category cannot be approved by the wrong person.
Escalations are routed the same way, and they arrive as summaries: what was asked, what the FTE found, why it did not resolve, and a suggested next step. Each escalation category maps to the person who owns that judgement, and that person knows to expect the summary rather than a raw item. As routine classes earn autonomy on the ladder, the routing thins: the team member who approved a hundred exact matches unchanged sees none of them once the class is promoted, and their time moves to the exceptions. The routing is a living map that the monthly review updates.
How do people's roles change and how should it be said?
People's roles change toward the work only people can do, and the change should be said early, explicitly, and in each person's own terms. A finance team member who matched bank lines now decides the exceptions the FTE surfaced, from evidence. A support agent who answered password resets now handles the complaints the FTE escalated, with the summary in hand. A recruiter who screened résumés now interviews from a shortlist with evidence per score. A junior who updated the CRM now reviews the FTE's hygiene proposals and learns what good data looks like.
The comparison with a junior hire is instructive: the repetitive work was never what the people were for, and a design that gives it to the FTE gives the people the job they were hired to grow into. Managers who let the change happen silently find their people anxious and their design resisted; managers who name it, and who show each person the judgement work now available to them, find the opposite. The FTE's arrival is a development event for the people around it, and it should be managed as one.
How is each kind of team member reviewed?
Each kind of team member is reviewed on what only it can do, and the two reviews are kept distinct. The Digital FTE is reviewed on its outcomes against targets with evidence, its approval rate with send-back reasons, its cost per outcome from usage per role, and its own first-person monthly report, which states what it delivered, what it missed and why, what is unmeasured, and what it recommends. The manager decides three things at each review: targets, remit, and autonomy per class.
People are reviewed on the quality of their judgement on exceptions, their handling of escalations and relationships, and their growth into the decisions they now own. They are not reviewed on the volume the FTE now handles, and the FTE is not reviewed on judgement it is designed to escalate. Where an FTE's quality review function exists, as with support ticket scoring, its output goes to the team lead as coaching notes to approve and deliver in person, never to the agent directly, because feedback about a person's work is a decision about a person. Keeping the reviews distinct is most of what makes a hybrid team fair.
How does the design evolve?
The design evolves with the company, and the FTE's persistence is what makes evolution cheap. When a functional lead is hired, they inherit an FTE with an existing remit, a confirmed Brand Brain, a target history, and an audit trail; the handover is a change of approver rather than a restart, and the new manager may reasonably step autonomy back until they have seen the record. When a second FTE is added, the platform pre-fills what it already knows, the wallet is shared, and the manager's habits transfer, so the second is faster to run than the first.
When roles are paired, such as a Search Visibility FTE finding topics and a Content FTE writing them, or an SDR FTE qualifying leads that a Marketing Strategist FTE's campaigns generate, the pairing shows up in each FTE's targets and in the workforce view. When a role ends, offboarding revokes its connections, retains its trail and optionally its memory for a successor, and records the handover, with the FTE writing its own final review. The design is never finished, and it does not need to be; it needs to be honest about the sort, clear about the manager, and kind about the change.
What are the principles to hold onto?
Five principles hold the design together. Sort the work before drawing the chart, and revisit the sort from the send-back reasons. Give every Digital FTE exactly one named manager, whatever the pattern. Route approvals and escalations by category to the person closest to that judgement, and let the ladder thin the routing as classes earn autonomy. Redirect people toward judgement explicitly and early, as a development event. Review each kind of team member on what only it can do, and keep the two reviews apart.
These principles are ordinary management applied to a new kind of direct report, and the ftes.ai workspace is built so that following them is the default: the remit in Setup and Targets, the routing in Approvals, the ladder in Setup, the review in Performance, and the workforce view across all of them. The rest of the operations cluster in the library covers each principle in depth, from the delegation framework to the monthly review to running multiple FTEs. A hybrid team designed this way is not a team with fewer people; it is a team whose people do the work that needed people all along.
How do you apply the design in the first quarter?
Apply the design in the first quarter in three steps. In the first month, sort the work with the team: two weeks of time recording, divided into repetitive evidence-based tasks and judgement, relationship, and people decisions, written into the Digital FTE's remit on one side and each person's one-sentence role on the other, agreed with the people before the FTE's first proposal. Choose the reporting pattern, name the FTE's manager, and route approvals by category to the team member closest to each. Record the baseline for both the function and the people's time.
In the second month, run the FTE at Level 0, read the send-back reasons weekly with the person who approves each category as a coaching conversation about the standard, and adjust the sort where work keeps coming back or keeps being done by hand. In the third month, hold the first monthly reviews with the two kinds of review kept apart: the FTE on targets, approval rate, and cost per outcome from its own report; the people on the judgement work they now own and their growth into it. Promote the one class with a clean record, and write down what the quarter changed in each person's role. A team that has done this has a design it can defend to its people, which is the only kind that lasts.
What objections does the design meet, and what are the honest answers?
The first objection is that people will see the FTE as a threat. The honest answer is that they will if the change is silent and will not if the sort is done with them, their new one-sentence role is agreed before the first proposal, and decisions about people are visibly and permanently human; the design's first month is mostly this conversation. The second is that approving proposals is boring work. The honest answer is that it is fast work, minutes a day, that thins as classes are promoted, and that reviewing evidence with a senior is how a junior learns a function faster than by producing the work.
The third is that one manager cannot run several FTEs and a team. The honest answer is the workforce view, routing by category, and the ladder: the manager's own items are the sensitive categories and the escalations, and the rest is distributed and then automated from a record. The fourth is that the org chart will need redrawing every time the company grows. The honest answer is yes, and that the FTE's remit, memory, targets, and trail persist through every redraw, so a change of manager is a change of approver rather than a restart. The design does not promise a static structure; it promises one that can change without losing its record.