E2E Hiring: First Apprentice Cohort

Hire a small cohort of relatively junior, AI-comfortable people who can grow into one or more e2e stages and then expand across the cycle.

This is a spin-off of e2e operators, run as its own project because it has its own decisions, budget and timeline.

Context for a fresh start

The e2e operator model. Datopian is moving away from specialist roles (PM, coder, sales) towards operators. An operator is one person who, with agents doing the labour, owns more and more of the client cycle, from outreach to renewal. The near-term goal is that each operator expands the stages they own beyond their current narrow zone. It is not that everyone owns every stage. Background: vision memo (July 2026).

The stage model (e2e-stages):

BIZ DEV    1 Content & marketing (optional, low priority)
           2 Outbound & qualification  ★ top priority
             2a PoC-led outreach (demo built from the target's own public data)  ★
           3 Proposal, quote & RFP
             3a Contracting (supervised)
DELIVERY   4 Build & delivery  ★
             4a Build (engineering, agents do the labour)
             4b Engagement lead (client side: plan, cadence, scope, sign-off)
           5 Launch & run (DevOps/SRE)  ─┐ in parallel
           6 Expansion & renewal        ─┘

There are four levels per stage: 0 not yet, 1 with help, 2 owns it, 3 improves it. Stages 2 and 4 have detailed, assessable definitions: stage 2 and stage 4.

The constraint is biz dev (stages 2 and 3). It has to run constantly. From 9 Oct 2026 there is a weekly Friday biz dev day, with Daniela as proposed champion. Actions are in beads epic da-3y4 (beads epic da-3y4).

Current team and where each is developing (2026-09-28):

Full analysis: LTP report.

The idea (Rufus, 2026-09-28)

• Numbers: hire about 3 over the coming period, possibly up to 6, expecting only 2–3 to stay. (Revised 2026-09-28: 3–4 on trial, 1–2 kept. See Decisions.)
• Level: relatively junior. Not necessarily experienced coders, but experienced in something.
• Two profiles:
  • Coders who can grow into good communicators. Natural entry: 2a (PoC-led outreach) and 4a (build), growing into 4b (engagement lead).
  • Non-coders hungry to build, like Daniela. Natural entry: 2 (outbound) and 3 (proposals), growing into 4a with agents.
• Common to both: comfortable with AI, and wanting range and ownership rather than a specialism (vision L53: "Recruit for range and ownership").
• Why it helps: more operators in the biz dev constraint (2 and 2a), and fewer handoffs as they grow.

Headcount freeze: resolved (Rufus, 2026-09-28)

The vision memo asks to freeze headcount for four quarters (vision L14, L68). The memo is left as written. This hiring fits within it, for two reasons:

• Some hires replace people who have left.
• A small net increase in headcount is acceptable.

Why hire now, before we need anyone (Rufus, 2026-09-28)

If we hire when we need someone right now, we put them straight onto a client project. That is when the problems start: we become dependent on them, so when they don't work out we can't let them go. Hiring ahead of need means each trial is a real test, and we can decide keep-or-go on the merits.

Decisions: owner, budget, timeline (Rufus, 2026-09-28)

• Owner: Anuar (agreed).
• Budget: aim to end with about 2 new people at $1.5–2k a month each (so ~$3–4k a month), including Upwork fees. Apprenticeships at $10–20/hr, mostly part-time; a peak of ~$3.5–7k a month while waves overlap is OK. Negotiate down for full-time offers.
• Shape: 3–4 people on trial for 2–3 months; keep about 2 at the end.
• Sourcing and timeline: Upwork only, about a month from posting to hire. One advert, tweaked as we learn ("prospecting for diamonds"). Start in staggered waves.
• What good looks like: the three Is: intelligent, interested, initiative; preferably coachable. Be direct: decide quickly when someone isn't delivering.
• The offer: an established but small company, open to growing people in a major way, with fast promotion (in a tough, AI-changing job market).
• Guard against past mistakes: we have kept people who couldn't deliver too long (distributed team, "we need them for now"). Hiring ahead of need is the main guard. In addition, each trial ends on a fixed date with a keep-or-go decision, and trialists stay off the critical path until kept (drafted, to confirm).
• Contract: not decided. Leaning towards a paid trial and then an offer, or a fixed-term contract. Part-time trials are optional.

Drafts (2026-09-28): one-page brief · two Upwork adverts · selection and apprenticeship (filter, 12-week apprenticeship with two assessors, strict end assessment).

Analysis: LTP report (beads da-9fw).

Actions (beads epic da-xzt, owner Anuar)

 1 Finalise adverts ──▶ 5 Post adverts ──┬──▶ 6 Review + tune (30 Oct)
                        (16 Oct)         └──▶ 7 Filter wave 1 ──┐
 2 Choose tests ────────────────────────────▶   (13 Nov)        ├──▶ 8 Wave 1 starts,
 3 Ask mentors (9 Oct) ─────────────────────────────────────────┤     decision date set
 4 Evidence-log + update templates (6 Nov) ─────────────────────┘     (16 Nov)

Wave 2 and the end assessments get beads once wave 1 is running.

Open questions

• Timeline and budget: when, and at what cost? Decided above; the drafted timeline is in the LTP report.
• Profile mix: how many coders versus non-coders in the first cohort?
• Where to find them, and what the job ad says, framed around stages rather than a role title.
• Trial format: how do we find the 2–3 who stay? For example, a paid trial on a real 2a PoC, assessed against the stage 2 levels.
• Onboarding: which stage each hire starts in, who they pair with, and do they join the Friday biz dev day from week one?
• Who owns it? Anuar.

Suggested first steps

1. Decide the owner, budget and timeline. Done 2026-09-28.
2. Write the two profiles as a one-page brief, using the stage model and levels as the language.
3. Design the trial task (e.g. a 2a PoC plus outreach message for a real target).