RAI Framework
Ready · Aligned · Integrated
A framework for how we believe remote teams should be integrated into real projects. Targeting operational autonomy within the first two weeks.
What is this framework for?
RAI is a framework we're building at Devlights around how we believe external remote teams should be integrated into real projects. It's not about testing whether they can code — it's about how we think teams reach true operational autonomy. The end goal: the CTO reviews output, not tasks.
Overview
Days 1–3
READY
Technical foundations
Days 4–7
ALIGNED
First deliverables
Days 8–10
INTEGRATED
Real autonomy
~2
Weeks to target operational autonomy
3
Phases with validation criteria
0
Micromanagement meetings at the end
READY
Phase 1 · Days 1 to 3
Phase Objective
Give the team everything they need to work without asking for permission: access, technical context, and clear expectations from day one.
Phase checklist
- Access configured: repos, CI/CD, project management tools, and communication channels
- Architecture document shared and reviewed together
- Code standards defined: naming conventions, branch structure, code review guidelines
- Definition of Done agreed upon and documented, not assumed
- Tech stack presented to the external team with design decision explanations
- First real task assigned (not a test, not a tutorial)
Validation questions. Can we move to Phase 2?
- 01
Can every team member open the project and run it locally without help?
- 02
Can the team explain in their own words what the system does and what their role is?
- 03
Do they know who to ask what, without needing to ask who to ask?
Red flags
- The team is requesting access on day 3 that they should have had on day 1
- Nobody asked any questions in the first two days (that's not a good sign, it's silence)
- The first assigned task hasn't been touched by end of day 3
ALIGNED
Phase 2 · Days 4 to 7
Phase Objective
The team delivers real work, receives fast feedback, and calibrates their pace with the internal team. Communication friction gets resolved now, not in sprint 4.
Phase checklist
- Daily rhythm established: fixed time, max 15 minutes, agreed-upon format
- Async communication channel defined (Slack, Teams) with expected response times
- At least one PR approved through the code review process with detailed feedback
- First retrospective held: What friction came up? How was it resolved?
- External team actively participated in at least one technical decision (not just executed)
- Internal CTO received at least one proactive update from the team (without having to ask)
Validation questions. Can we move to Phase 3?
- 01
Did the external team deliver at least one complete task without requiring internal team intervention?
- 02
Were blockers communicated before they became problems?
- 03
Is the work rhythm predictable? Do we know how much this team can advance per sprint?
Red flags
- The team only speaks when spoken to, communication is not bidirectional
- PRs are too large or arrive without context
- The first retro was "all good" with no concrete improvement points
INTEGRATED
Phase 3 · Days 8 to 10
Phase Objective
The team operates autonomously. They make low/medium-level technical decisions without needing approval. The CTO reviews results, not individual tasks.
Phase checklist
- The team can pull from the backlog and estimate without the CTO breaking down each task
- They identified and resolved at least one technical problem without escalating
- The team proposed at least one technical or process improvement on their own initiative
- The CTO spent less than 2 hours in the day on direct interactions with the external team
- The team knows when to escalate and when to resolve, and applies it correctly
Validation questions. Is the team truly integrated?
- 01
If the CTO is unavailable for a full day, can the team keep advancing without blocking?
- 02
Does the external team understand the business well enough to prioritize between equivalent technical options?
- 03
Would you trust this team to run a full sprint independently?
Red flags
- The CTO is still the tiebreaker for every minor technical decision
- The team asks before attempting to resolve on their own
- No team initiative in these 3 days, only passive execution
📌Important note: This framework isn't linear. If a phase doesn't close well, it gets extended. The criteria for advancing are the validation questions, not the calendar. Two weeks is our target when the process runs well, but the goal is genuine autonomy, not hitting a date.
Additional Resources
Want to apply this to your team?
Looking to apply this framework to your team or discuss how to adapt it to your context? At Devlights we support remote team integration processes from day one.
Connect with Federico on LinkedIn