E2E hiring: finding and keeping junior AI-comfortable operators — conversion report

What the file claims

86 propositions, 86 roles, 57 relationships, 4 assumptions, 0 assessments.

goal 39 · current_reality 20 · conflict 16 · prerequisite 11

Revision 8 (2026-09-28) records comment 8. The YAML is unchanged; the drafts are updated.

• The rate is $10–20/hr, negotiated down for a full-time offer.
• The overlap peak is accepted, mostly part-time. This largely settles conflict 1 (call 13). It is not recorded as a breaks_conflict assessment, because the reviewer accepted a number without drawing that conclusion.
• The mentor for profile B is João or Ola.
• Asdra is not relevant as a profile example (see call 9).

Revision 7 (2026-09-28) records comment 7.

• The reviewer accepts the trial guards and adds three requirements. Each is a new necessary condition under "named people assess against stated criteria":
  • more definable criteria;
  • at least two people assessing;
  • an apprenticeship or training programme, in which one or two people see the apprentice's work, with a strict assessment at the end.
• Current reality gets the problem these answer: Datopian often doesn't know whether a hire's work is good, and some hires work autonomously with minimal check-in. No link is drawn between the two (see call 12).
• Two adverts, one per profile. The reviewer raised this as a question; Claude recommended it.
• The prerequisite view's objectives now point to drafts: brief, Upwork adverts, selection and apprenticeship. Those drafts replace the rev 1 plan.

Revision 6 (2026-09-28) records comment 6: hire ahead of need. The reviewer states a causal chain, so it is linked with causes. Datopian hires when it needs someone right now. So the hire goes directly onto a client project. So Datopian becomes dependent on them. So it can't get rid of them when they don't work out (r-e-kept-too-long). Hiring ahead of need is added in three places:

• in the goal tree, as a necessary condition for deciding directly;
• in conflict 2, as the reviewer's own injection;
• as a stated reason to hire now.

See call 11.

Revision 5 (2026-09-28) records comment 5.

• Why hires were kept too long: the team is distributed, and Datopian often thinks it needs the person ("we need a PM for now"). Both are root_causes that contributes_to r-e-kept-too-long. Comment 5 gives them as reasons, and neither is said to be the whole explanation.
• This gives a second conflict, drafted: keep them versus let them go. See Drafted conflict 2.
• Channels: Upwork only. Reach into unusual markets therefore depends on how the advert is written and how Upwork is searched, not on new channels.
• The offer (CSF4) is stated: an established but small company, open to growing people in a major way, with fast promotion, at a time when the job market is tough and changing because of AI.

Revision 4 (2026-09-28) records comment 4.

• CSF1 is filled. A good junior operator has the three Is: intelligent, interested and shows initiative. Being coachable is preferred. Daniela and Asdra are the examples, recorded as evidence. Not delivering is the main sign of a poor fit.
• CSF3 gets a new condition: decide directly and quickly when someone is not delivering.
• Current reality gets the history it answers: Datopian has often kept hires who could not deliver for too long, PMs especially, and made excuses for them.
• The budget is restated as an end state: about 2 new people at 1.5–2k USD a month each. Spend may run higher at the start.
• The conflict is re-drafted to match. See Drafted conflict.

Revision 3 (2026-09-28) records comment 3. The reviewer accepts the tree's structure ("the rest is good") with two changes.

• CSF3 is reframed from "tell good early" to "filter cheaply, then trial". Basic tests, IQ-style ones included, make the first filter. The reviewer says these are highly predictive and legal in Datopian's jurisdiction. The trial is what really shows fit.
• "Diamonds in the rough" is added under CSF2: people outside the major Europe and US markets (the Global South included) and outside traditional coding professions. Two refinements of the profiles are added under CSF1: a talent area plus an AI orientation, trained to build; or dev-oriented and growing into other stages.

Three current_reality observations are added from the comment. See calls 7–8.

Revision 2 (2026-09-28) records comment 2. The reviewer wants the goal tree developed in detail before any action. The reviewer also said the key question is "how do we find good people in general". The goal view is redrafted around that question: a repeatable way of finding, selecting and growing people, not a one-off cohort. See Drafted goal tree (rev 2). The drafted plan is parked until the goal tree settles. The first cohort's target (keep 1–2) becomes an observation. So does the "why" (more operators in biz dev). See call 5.

Revision 1 (2026-09-28). The goal view holds the README's idea with the reviewer's decisions from comment 1: owner, budget and trial size. The conflict view and the prerequisite view were drafted by Claude at the reviewer's request ("help me work through the open questions"). No part of them is ratified. There is no future reality view and no transition view yet. The drafted sequence is under Drafted plan and waits on the questions at the end.

Items

Relationships asserted

The drafted links break the skill's burden-of-proof rule on purpose: the reviewer asked for help working the questions through, not for a pure extraction. They are listed here so they can be confirmed or struck.

Drafted goal tree (rev 2)

Drafted by Claude from comment 2 P5. Nothing is ratified. Items marked † come from a source. Everything else is a proposal for the reviewer to fill in, correct or strike.

GOAL  Datopian repeatedly finds, selects and grows good junior, AI-comfortable operators within its means
│
├─ CSF1 We know what "good" looks like                           ◀ the key open question
│    ├─ the three Is: intelligent, interested, initiative †      comment 4 P2
│    │    (evidence: Daniela, Asdra †)
│    ├─ preferably coachable †                                   comment 4 P2
│    ├─ not delivering is the main sign of a poor fit †          comment 4 P3
│    ├─ recruit for range and ownership, not a specialism †      vision L53
│    ├─ two profiles: coder→communicator, non-coder→builder †     README L50
│    │    ├─ talent area (marketing, lead gen) + AI, trained to build †  comment 3 P3
│    │    └─ dev-oriented, grows into other stages †             comment 3 P3
│    └─ "good" described in stage and level language †           README L74
│
├─ CSF2 Enough of the right people see it and apply
│    ├─ diamonds in the rough: people others overlook †          comment 3 P2
│    │    ├─ outside major EU/US markets, incl. Global South †   comment 3 P2
│    │    └─ outside traditional coding professions †            comment 3 P2
│    ├─ Upwork is the channel †                                  comment 5 P2
│    ├─ advert attracts the right people, puts off the wrong ones
│    └─ advert tuned from responses †                            comment 1 P2
│
├─ CSF3 Filter cheaply, then trial the best to learn who fits †  comment 3 P1
│    ├─ basic tests incl. IQ-style filter applicants first †     comment 3 P1
│    ├─ a trial on real work shows fit †                         comment 3 P1
│    ├─ decide directly and quickly when someone isn't delivering †  comment 4 P3
│    │    └─ hire ahead of need, not when we need someone now †  comment 6 P1
│    │    └─ 3–4 on trial for 2–3 months †                       comment 1 P3
│    └─ named people assess against stated criteria
│
├─ CSF4 Good candidates want to join and stay
│    └─ offer: established but small, will grow you in a major way,
│         fast promotion †                                        comment 5 P3
│
├─ CSF5 Hires grow into owning e2e stages
│    └─ start stage, named pair, Friday biz dev day †            README L68
│
└─ CSF6 Stays within our means
     ├─ ends with ~2 people at $1.5–2k/month each; more at start †  comment 4 P1
     ├─ replaces leavers; small net increase at most †           README L58
     └─ Anuar owns it (agreed) †                                 comment 2 P2

observations: first cohort keeps 1–2 †; purpose is more operators in biz dev 2/2a †

The goal says "repeatedly" because comment 2 P5 asks about finding good people "in general". Advert tuning (comment 1 P2) also implies a process that learns. If the reviewer means only this one cohort, drop the word, and CSF2 and CSF3 get simpler. See question Q5.

Drafted gap scan (rev 4)

Drafted by Claude, for the reviewer to correct. This is the first step of the current reality tree. For each condition in the goal tree it asks: is this true today? The conditions that are "not met" become candidate undesirable effects. Nothing here is in the YAML yet.

Where the gaps cluster:

1. Nothing for finding people exists yet. There is no brief, advert, test or trial task. These are gaps to build, not problems to diagnose.
2. Reach. The goal says "diamonds in the rough, outside EU/US". Upwork is the only channel, by choice (comment 5 P2). Reach therefore comes from the advert's wording and from searching and inviting on Upwork across markets.
3. Decisiveness. The one gap with a history: hires who could not deliver were kept too long. Comment 5 gives two causes: the team is distributed, and "we need them". See Drafted conflict 2.
4. CSF4 is stated, not tested (comment 5 P3).

Drafted conflict

The budget and the trial size pull against each other.

                         ┌─ B: trial enough candidates ── D: 3–4 trialists full time at once
A: find and keep ~2 ─────┤    to find the rare fit                        ▲
   good junior operators │                                               ✕ conflict
                         └─ C: settle at ~3–4k a month ── D': trial spend only modestly above 3–4k

Rev 4: comment 4 P1 allows more spend at the start, and the end state is about 2 people at 1.5–2k each. The conflict is now between D and D'. 3–4 full-time trialists at that rate cost 4.5–8k a month, up to about twice the end state. Whether that is "a bit more" is the reviewer's call. The rev 1 arithmetic below is kept for the record.

The arithmetic (rev 1): 3–4 trialists within 3–4k a month is about 1k a month each. That is roughly 20 hours a week at about 12 an hour. The figures are illustrative, not quoted Upwork rates. Someone junior who is "experienced in something" (README L49) working full time costs more than that in most places.

Assumptions under the arrows (in the YAML):

• B → D: only full-time work on real engagements shows whether someone can own a stage.
• B → D: all 3–4 have to overlap in time to be compared.
• D ✕ D': a full-time junior costs well over 1k a month, even on Upwork.

Injections, both the reviewer's own ideas:

1. Part-time trials (P4). Comment 1 raised them for people who have jobs they won't leave. The budget points the same way: part time is what makes 3–4 trialists affordable. This breaks the first assumption if a fixed weekly allotment of real 2/2a work is enough to see ownership.
2. Staggered waves of 1–2 (P2). This breaks the second assumption. Peak cost stays under the cap, and wave 2 benefits from what wave 1 teaches about the advert.

Together, the two dissolve the conflict without dropping either need. Nothing is asserted as breaks_conflict until the reviewer agrees.

Drafted conflict 2

Keep them or let them go. Drafted from comment 5 P1. The reviewer gave the causes, not the cloud.

                        ┌─ B: every role on client work is covered ── D: keep a hire who isn't delivering
A: Datopian runs its ───┤                                             ("we need a PM for now")
   client work well     │                                                  ✕
                        └─ C: everyone on the team delivers ───────── D': let them go, quickly

Assumption under B → D (in the YAML): no one else can cover the role soon enough.

Why it bites more in a distributed team: poor delivery is less visible, and so is the gap it leaves. That is the reviewer's first cause, read as contributes_to.

Injections. Each attacks the assumption.

0. Hire ahead of need (the reviewer's, comment 6 P1). This is the main one. It removes the dependency at its source: the reason to hire now is so that no new person starts on a client project that Datopian depends on. The drafted ones below are how the trial keeps it that way:

1. Each trial ends on a fixed date with a keep-or-go decision against stated criteria. The default becomes a decision, not drift.

2. Trialists are not on the critical path. Their work is real, but no client deadline depends on them alone until they are kept. So "we need them" cannot build up during the trial.

3. A bench. Staggered waves and the live advert keep next candidates in view, so no one hire feels irreplaceable.

The causal chain behind D (comment 6 P1, in the current reality view):

hire when we need someone now ──▶ straight onto a client project ──▶ dependent on them ──▶ kept too long
        (root cause)                                                                     ▲
                                              distributed team ── contributes ───────────┘

This is also a risk in the plan itself. Trialists on real 2a/4a work are exactly how "we need them" starts. Injection 2 is the guard.

Drafted plan

Rev 7: the prerequisites are now drafted as documents: brief (the profiles), Upwork adverts (two), and selection and apprenticeship (the filter, the 12 weeks, the end assessment, the budget check). The timeline below is still parked.

Parked in rev 2 (comment 2 P4: develop the goal tree first). Kept for reference; the dates are not agreed.

Implementation objective (p-e-first-trialists): the first trialists start real work in stages 2 and 2a.

Timeline (drafted; anchored on P2's one month from posting to hire):

 by 9 Oct   Anuar confirms he owns it · brief drafted
 by 16 Oct  trial task + terms agreed · advert posted on Upwork
 ~30 Oct    first tweak of the advert (fits the end-Oct Friday review, da-3y4.9)
 mid Nov    wave 1: 1–2 trialists start, part time
 Dec        wave 2: 1–2 more start (peak 3–4 on trial)
 Feb 2027   decide on wave 1 (after 2–3 months)
 Mar 2027   decide on wave 2 → 1–2 kept

Spend shape (illustrative; rev 1, before comment 4 P1): peak about 3.5–4k a month from December to February. About 15–20k in total over the trial. After that, 1–2 kept people within the same 3–4k.

Deliberately omitted

Judgment calls for the reviewer

1. Keep 1–2, not 2–3. Comment 1 P3 says "retaining only 1–2", while README L48 says "2–3 to stay". The file uses the later figure. The README is updated to match.
2. The conflict is drafted, not extracted. It follows from P3's numbers, but the reviewer never framed it as a conflict. If 1k a month buys enough time where these candidates live, the conflict is not real, and the view should shrink to an observation.
3. Contract shape is left open (P4: "not sure here"). The file records part-time trials as an injection only. Paid trial then offer, and fixed-term contractor, both stay open.
4. The trial is a necessary condition. README L67 asks "how do we find them?" as a question. Comment 1 P3 treats a 2–3 month trial as given, so it was read as decided. In rev 2 it moved from CSF to NC under CSF3.
5. Two statements left the goal tree's chain (rev 2). "Keep 1–2" is the first cohort's target, not what the hiring is for, and "more operators in biz dev" is the reason for hiring, which sits above the goal. The format has no role for a higher objective, so both are now observations. Alternative: make "more operators in biz dev" the goal, with finding good people as one CSF. That would be a tree about the biz dev constraint rather than about hiring.
6. Part-time trials are optional (comment 2 P3). The conflict's injection stays, but it is one lever among several, not the default.
7. The budget conflict may be weaker than drafted. Comment 3 P2 aims the search at markets outside Europe and the US. There, about 1k USD a month may buy substantial hours from someone experienced. That challenges the assumption c-a-rates-fixed. The conflict is kept until real advert responses show actual rates.
8. Test choice matters for the diamonds. A test that is verbal or culturally loaded, or only in English, may screen out exactly the people from unusual markets that P2 wants. A non-verbal reasoning test and a short practical task fit P2 better. Candidates on Upwork also sit in many jurisdictions, not only Datopian's. The file records the test only as a filter, with no named instrument.
9. Evidence-backed traits, not a proven predictor. Comment 8 P4: Asdra worked with Rufus as a PA and is not relevant as a profile example. Asdra stays in g-e-exemplars as an example of the three Is only, since that is how comment 4 used the name; strike it if that isn't meant either. The three Is come from two examples, Daniela and Asdra, and from the reviewer's experience. The reviewer named other people who worked out. At the reviewer's request they are not recorded, to avoid tension with those not mentioned. The traits are a working hypothesis for the trial to test.
10. Kept too long, and the excuses. The source puts the two side by side ("spent too long … and we often make excuses") without saying that one causes the other. No link is drawn. It is plausible that the excuses cause the delay; confirm that before adding a causes link.
11. "We need them" and "dependent on them" overlap. Comment 5's "often thinking we need them" (r-e-think-we-need-them) and comment 6's dependency (r-e-dependent) may be one cause stated twice. Both are kept: the first is a belief, the second is the structural fact that produces it. A reviewer could merge them, or link dependent → causes → think-we-need-them.
12. Not knowing and minimal check-in. Comment 7 puts "we don't even know" next to "working … fairly autonomously with minimal check-in, which is not great". This reads as a cause, but the comment doesn't say so. No link is drawn; confirm it and it becomes contributes_to.
13. The budget peak. With apprentice waves overlapping, the selection draft estimates a peak of $6–8k a month full time, or about half that part time. This is the conflict-1 question again, now with numbers. It is for Anuar to confirm.

Validator output

bun run check:import was not run, because no Reason Commons checkout is available. A local script checked unique ids across the flat namespace, resolved references, single-source relationships, same-view relationships, vocabulary, and role/view coherence:

86 entities, 86 designations, 57 relationships, 4 assumptions, 0 assessments
{'goal': 39, 'current_reality': 20, 'conflict': 16, 'prerequisite': 11}
OK: no structural errors

That script does not replace the importer's planning analysis. Attach the file in the app before relying on it.

Not in this file

• Future reality view: what changes once 1–2 operators are kept (more stage 2/2a throughput, fewer handoffs). Deferred until the trial design is settled.
• Transition view: parked until the goal tree settles (comment 2 P4).
• Profile mix, sourcing, onboarding detail: the next questions.

Reviewer comment 1 2026-09-28

Answers to the first round of questions (owner, timeline, budget, contract shape), recorded close to verbatim.

• P1 (owner): Anuar.
• P2 (timeline): "we'll hire off upwork and normally will take 1m from posting to hire i suspect (though could be quicker). probably staggered … but worth doing one advert - we may need to tweak to find the right thing we want. it is a kind of prospecting for diamonds effort …"
• P3 (budget): "i think we want to be around 3-4k a month to start with with a bit of flex. i think we are assuming retaining only 1-2 people at end of this effort but maybe having 3-4 for 2-3 months on the trial …"
• P4 (contract): "not sure yet … maybe we can allow parttime trial in case people have existing jobs they don't want to leave. not sure here so probably more like [paid trial then offer] or [contractors, 3-month]."

Reviewer comment 2 2026-09-28

• P1 (currency): "usd and that includes upwork fees probably"
• P2 (Anuar): has agreed to own it.
• P3 (part time): "optional (not important)"
• P4 (timeline): "i think we need to develop our goal tree and much more here in detail b4 moving to action …"
• P5 (profile mix): "this is key and more about how do we find good people in general …"

Reviewer comment 3 2026-09-28

On CSF3, summarised closely:

• P1 (CSF3): "Bit dubious about this one." The reviewer would love to use IQ tests: "I think that and some other basic tests are highly predictive, and they're legal in our jurisdiction." But "I don't think we often can tell that well before you trial some people … you can do an initial filter that gets you a long way … but you often have to try people to really know whether they're a fit or not." "CSF 3, I guess yes, it's kind of roughly true."
• P2 (diamonds in the rough): "we're looking for diamonds in the rough … people outside of the major Europe-US markets, even South … unusual markets where there's talent and an interest, and also people outside of traditionally coding professions. Suddenly, anyone can be a kind of coder or deliverer here."
• P3 (profiles): "people who might have a particular talent area they're AI-oriented, but they can do marketing well, or lead generation. We can train them to build some software. They're people who are dev-oriented, but they can grow into other things."
• P4: "The rest is good."

Reviewer comment 4 2026-09-28

Summarised closely. The names of other people who worked out are deliberately left out, at the reviewer's request.

• P1 (budget): "we may spend a bit more at the beginning but aiming to end up with e.g. 2 new people which means $1.5-2k a month per person to start with"
• P2 (CSF1, what good looks like): "Daniela is smart, also think of Rufus new hire Asdra. Intelligent, interested, initiative (the 3 'I's). and preferably also coachable". Other people who worked were also named, and are not recorded here.
• P3 (poor fit): "we have often spent too long especially with PMs but also others who couldn't deliver and we often make excuses. we probably need to be relatively direct"

Reviewer comment 5 2026-09-28

Answers to the gap-scan questions.

• P1 (why hires were kept too long): "distributed team, often thinking we need them … (e.g. we need PM for now …)"
• P2 (reach beyond Upwork): "really just upwork …"
• P3 (the offer): "that we can work out … but basically we are established but small and open to growing them in a major way … they can promote fast (and in a tough ai changing job market)"

Reviewer comment 6 2026-09-28

• P1 (hire ahead of need): "One of the reasons to hire now and not hire when we need someone right now: if we hire when we need someone right now, we put them directly onto a client project. That's when the problems arise: 'Oh, we're dependent on them, so they didn't work out. We can't get rid of them.' That's a kind of key point to mention."

Reviewer comment 7 2026-09-28

• P1 (guards and assessment): "the trial guards here could work really well, plus much more definable criteria for ourselves to assess against, and possibly at least two eyes. Often it's like, 'Oh, they work,' and we don't even know. Some might be working on a project fairly autonomously with minimal check-in, which is not great."
• P2 (apprenticeship): "we want a bit more of an apprentice programme or training programme where, at least maybe, they're seen by one or two people, and there's a fairly strict assessment at the end." Go ahead with the brief, the Upwork advert, the filter and the trial design.
• P3 (adverts): "Do we need two Upwork adverts? It's not expensive to put them both out. One is hiring maybe more for people who can even do contenty stuff on the biz dev end, but who then we could train up to do coding and delivery. The other is the other way around, like the coding types you have, with real ability to communicate and kind of design feel or something. I don't know, but that's a question."

Reviewer comment 8 2026-09-28

• P1 (rate): "$10-20h is ok and one can negotiate down for full time offer."
• P2 (overlap peak): "that's ok and probably part time"
• P3 (profile B mentor): "joao or ola potentially"
• P4 (Asdra): "asdra isn't relevant here … (wkred with rufus as pa)"
• Also: two adverts agreed after Claude's pros and cons. Post A first if screening time is tight.