Entry, Exit, and Portability Terms 2.3B.1-2

Why Entry, Exit, and Portability Matter

A member joined. Three months later, she wants to leave. She has written code, built client relationships, created system architecture. She asks to take the code with her. The team says no — the code is intellectual property. The relationships stay with the organization. She leaves with nothing but what she memorized.

This is dependency power at maximum. The member contributed, but cannot access or leverage that contribution elsewhere. The threat of forfeiture shapes every decision she makes while on the team. She does not negotiate terms freely. She does not challenge unfair practices. She stays captured — not by agreement, but by structural cost.

Bounded interdependence limits dependency power by defining, in advance, what happens when someone joins, what happens when they leave, and what they can take with them — not because a departing member is owed these terms as an entitlement, but because a team whose best people cannot safely leave is a team whose best people also hesitate to fully join, negotiate honestly, or stay past the point where staying serves them. When these terms are transparent and reasonable, membership remains genuinely worth choosing throughout the relationship. When they are opaque or punitive, the team has built a structure that degrades its own cooperation, whatever the participation agreement says.

Entry: Making Joining Transparent

Most teams have hiring criteria but no entry standards. A candidate is hired for credentials. Then she arrives and is lost — she does not know how decisions work, what quality standards apply, what systems she needs access to, or who to ask. This is not onboarding. It is sorting for people who navigate ambiguity through informal relationships, and it pushes out people who need clarity.

Entry standards specify what knowledge a new member needs before day one, what knowledge the team provides during onboarding, and who is responsible for what. They are transparent: a candidate can review them before joining and assess whether the team's expectations align with her capacity.

Entry Criteria Template

For each role, specify four layers:

Pre-hire expectations — what the candidate must bring. Screening criteria. Be specific about what is measured: "five years building stateless microservices deployed to Kubernetes" is testable; "five years of backend experience" is not.

Pre-day-one knowledge — what the candidate should learn before joining. Product overview, architecture overview, team structure, tools. Provide a reading list or a thirty-minute overview call.

First-week onboarding — what the team teaches. System access, development environment, codebase walkthrough, process walkthrough, team introductions. Assign an onboarding owner responsible for completion.

First-month learning goals — what the new member should be able to do independently. Deploy a feature to staging, run and interpret the test suite, participate meaningfully in code review, resolve a production incident with guidance. Assess at the end of month one: where does the member still need support?

Performance Expectations: Structural Clarity

A member works for three months. In her review, the manager says her performance is below expectations. She is shocked — no one told her what the expectations were, no one gave feedback, no standards were published against which her work would be measured. This is consent theater applied to evaluation: the appearance of assessment without the structural conditions for honest assessment.

Performance expectations are standards that are public, testable, and reviewed regularly. They answer four questions: What does this role produce? (output, not activities). At what level, and how is it measured? (standard — testable, not vague). What feedback will you get, and when? (review cycle — continuous, check-in, and formal). If you fall short, what happens? (recourse — structured improvement plan, not informal conversation).

Performance Expectations Template

For each role, specify:

Table 2.3B.1-6 — Performance measurement: outputs, standards, and review

Review cycle: Continuous feedback on specific work (code review, design review). Weekly or biweekly check-in. Quarterly formal assessment against the performance table.

Below-standard recourse: First instance — feedback and a thirty-day improvement plan with specific targets. Persists after thirty days — the team and the member discuss whether the role is the right fit. The exit process engages. Above-standard recognition happens within thirty days — not at the next annual review.

Exit: Designing Clean Departure

Clean exit is the structural test of bounded interdependence. A member who cannot leave without forfeiting what she built is not participating voluntarily — she is captured. The exit process makes departure structured, the terms visible, and the member's portable work retrievable.

Exit Terms Template

Notice period: [Number of weeks.] Specify what counts as notice, and what happens if notice is not given. If the notice requirement is punitive — designed to make leaving costly rather than to enable orderly transition — it fails the bounded interdependence test.

Handoff protocol:

Table 2.3B.1-7 — Handoff: knowledge, assets, and relationships

Data Portability

Specify what the departing member can take. The structural principle follows privacy by design (1.2.4): personal data and personal work product are the member's. Shared systems and organizational data stay with the team. The boundary must be explicit — not discovered during the exit conversation.

Table 2.3B.1-8 — Portability: what leaves and what stays

Reference and reputation. What the team says about a departing member affects her next opportunity. Specify: standard references are tied to performance against the payoff table (positive, neutral, or negative based on evidence). Non-standard references are discussed in the exit meeting. Public statements about a departing member are cleared with the member before publication.

Non-compete and IP. Specify the legal boundaries: scope, duration, and enforceability. Overly broad non-competes that prevent a member from working in her field are coercive structure — they fail the bounded interdependence test regardless of whether they are signed. IP assignment should distinguish between work produced during paid hours on team commitments (belongs to the team) and work produced on personal time with personal tools (belongs to the member).

Structural Coherence

The team charter (2.3B.1-1) specifies roles, decision rights, and interfaces. Entry, exit, and portability terms specify what joining, staying, and leaving look like. Together, they define the full scope of bounded interdependence:

Entry makes joining transparent — here is what the team expects, here is what the team provides, here is how the member will know if she is succeeding. The charter makes staying transparent — here is the scope, here are the standards, here is how conflicts are resolved. Exit makes leaving transparent — here is what is portable, here is the handoff process, here is what the team will say about the work.

When all three are coherent, a team member can answer the participation test. When any element is missing or ambiguous, the test identifies exactly where the structural gap is — and the team can repair it before the gap becomes a crisis.