Coder Levels: Origami Framework

Coder Levels: A Judgment-Based Assessment Framework

What is this?

A framework for understanding how engineers grow at Cadence OneFive — and for having honest, structured conversations about it.

In an AI-enabled team, everyone benefits from the same scaffolding: AI tools, OpenSpecs, CI checks, code review bots. What differentiates engineers is judgment — the scope of problems they identify, the independence with which they solve them, and whether their work multiplies the team.

This framework measures judgment across six domains on a 4-point scale. Each engineer’s scores produce an origami plot — a visual profile where the area tells you the tier and the shape tells you the person. A security-heavy profile looks different from an infrastructure-heavy profile, and that’s the point. We’re not ranking people on a single ladder. We’re mapping the different shapes of contribution that make the team work.

Engineers run their own assessment as part of our existing 360 process — it gives structure to the engineering-specific part of those conversations. Anyone who wants to can also run it quarterly as a self-check between 360 cycles.

The Six Domains

1. Engineering Craft

Taking product requirements to shipped, secure, well-structured code. Includes scoping implementation work, making sound architecture decisions (DDD boundaries, design patterns, module structure), handling edge cases, writing defensive code, and identifying security vulnerabilities. The question is: does this person build things that are correct, maintainable, and safe?

2. Infrastructure & Quality Systems

Deployment pipelines, monitoring, disaster recovery, scaling, test strategy, CI policy, release workflows, and bug prevention mechanisms. The operational backbone — keeping the platform running, preventing classes of problems before they reach users, and making releases reliable. This domain recognizes that a 10-line Cloudflare config change can be higher-impact than a 1000-line feature.

3. Domain Knowledge

Understanding the business domain — not just the code, but why the code works this way. Why buildings have confidence scores, what a co-op is, how LL97 compliance works, why CalcService fills defaults with confidence 0.2 instead of null. This is the knowledge that separates “writes correct code” from “writes the right code.” Domain knowledge is hard to game and compounds over time.

4. Decomposition

Turning ambiguity into structured, sequenced action. Includes writing OpenSpecs, scoping vague requirements into phased implementation plans, reading Sentry and diagnosing root causes, filing structured tickets from noise, identifying dependencies between work items, and routing work to the right person. The full arc from “we need X” to “here’s what we’ll build, in what order, and why.”

5. Team Systems

Designing how the team works — workflow design, bottleneck identification and removal, measurement and feedback loops (team-pulse reports, bug trend analysis, velocity tracking), automation, tooling strategy, CI policy decisions. Building the systems that make the whole team faster. This is the meta-layer: not doing the work, but designing how the work gets done.

6. Peer Development

Making individual people better through direct interaction. PR review quality and depth, post-merge review, teaching through code feedback, pairing, knowledge transfer, unblocking others. This is distinct from Team Systems — Team Systems is “I built a CI check that catches N+1s for everyone” (systems leverage). Peer Development is “I sat with a teammate and walked through DDD boundaries until they could make the call themselves” (people leverage). Both multiply the team. Different shapes of leadership.

Scoring Rubric (1–4)

Each score level is defined by observable behaviors, not subjective assessment. The question at each level is: “What is this person’s relationship to work in this domain?”

Score	Label	Relationship to work	Observable behavior
1	Following	Completes assigned work within established patterns	Works tickets that exist, follows examples, output is consistent and correct within known patterns
2	Owning	Self-directs without tickets	Finds and fixes problems without being asked, authors tickets from own observations, picks up unassigned work
3	Driving	Generates work for others, sets standards	Creates reusable mechanisms that prevent problem classes, reviews others’ work with depth, generates work streams, sets standards others follow
4	Shaping	Defines the team’s approach	Writes the specs and frameworks others use, defines the team’s methodology in this domain, makes strategic decisions about direction

How to read the levels

These are patterns, not checklists. The question at each boundary is about someone’s typical relationship to work in this domain over the assessment period, not whether they’ve ever done a specific thing.

1 → 2 (Following → Owning): The characteristic shift is from consuming work to generating it. Someone operating at level 2 tends to identify problems and create tickets, not just close them. But ticket authorship alone doesn’t make someone a 2 — the deeper signal is whether they’re self-directing in this domain.

2 → 3 (Owning → Driving): The characteristic shift is from fixing instances to preventing classes. Someone operating at level 3 tends to create reusable mechanisms — a PHPStan rule that catches N+1 patterns for everyone, not just the one they found. The deeper signal is whether their work in this domain multiplies the team.

3 → 4 (Driving → Shaping): The characteristic shift is from setting standards to defining the approach. Someone operating at level 4 tends to write the frameworks others work within — the OpenSpec format, the review process, the CI pipeline philosophy. The deeper signal is whether the team’s methodology in this domain bears their fingerprint.

One-off behaviors don’t define a level. Look for sustained patterns — 3+ instances over the assessment period. The rubric describes what each level looks like, not what someone needs to do to get there. The moment someone optimizes for specific behaviors (“I need to write a PHPStan rule to get to level 3”), the behaviors become targets rather than indicators.

Tier Thresholds

These F/E/D/C tiers are the same ones the Coder role uses for its mastery levels and pay tiers — this assessment is how an engineer’s judgment maps onto them. The role page describes the responsibilities and competencies expected at each tier; the thresholds below describe the origami shape that typically accompanies them.

Tier F — Building foundations

No domain above 1 / Predominantly at 1
Consistently executing assigned work across Engineering Craft and one or two other domains
Learning the codebase, team patterns, and AI-assisted workflows
Total score: roughly 6–8

Tier E — Owning a domain

At least one domain at 2 (self-directs in something)
Demonstrating judgment about whether they’re solving the right problem
Starting to generate work, not just consume it
Total score: roughly 8–12

Tier D — Driving impact

At least two domains at 3 (drives standards in multiple areas)
Generating work that multiplies the team
Work in their specialty domains prevents problems for everyone
Total score: roughly 14–18

Tier C — Shaping the approach

At least three domains at 3+ with breadth across the chart
Must score 2+ in Team Systems — this is the distinguishing domain between D and C. A D engineer drives their own domain; a C engineer thinks about how the whole team operates.
Covers enough ground to lead the engineering function
Shapes team methodology, not just team output
Total score: 18+

Depth vs. breadth

Tier is determined by depth (peak scores), not just total. A D engineer who’s 3-3-2-1-1-1 in Craft + Peer Development is more valuable than someone who’s 2-2-2-2-2-2 across everything. The tier recognizes driving impact in specific domains.

However, breadth matters for advancement. Moving from D to C requires expanding coverage, not just deepening existing strengths. This is the “make yourself replaceable” principle: you can’t lead the team if you only understand two domains.

Growth Signals and Maturity Signals

Growth signals (leading indicators — “starting to think differently”)

These are early behaviors that predict tier transition. Peers and 360 stakeholders should watch for these and call them out when they appear.

Signal	What it looks like	Tier transition it predicts
Authors own tickets	Writes the issue, not just the PR. Defines the problem, not just the solution.	F → E
Records domain reasoning	Documents “why” from conversations, not just “what” — shows mental model building	F → E
Decomposes independently	Breaks work into phases with clear dependency reasoning (“why first,” “why together”)	F → E
Picks up ambiguous work	Takes “something’s broken” and produces root cause + fix, not just a patch	F → E
Reverts own work	Recognizes when an approach is wrong and backs out instead of piling on fixes	F → E
Fixes the class, not the instance	PHPStan rules, shared traits, base components instead of one-off fixes	E → D
Writes specs for others	Produces OpenSpecs or technical designs that define work for teammates	E → D
Creates preventive tooling	CI checks, static analysis rules, post-merge review patterns	E → D
Generates work streams	Identifies a systemic issue and creates a campaign of tickets	E → D
Shapes team process	Creates or significantly improves release workflows, review practices, testing strategy	D → C
Cross-domain triage	Triages and routes work outside their specialty domain	D → C
Thinks about team velocity	Proposes a measurement, identifies a bottleneck, or builds tooling aimed at making the team faster	D → C
Designs development methodology	Creates reusable scaffolding (spec templates, AI skill libraries, review checklists) that changes how the whole team approaches work	D → C

Maturity signals (sustained patterns — “consistently operates at this level”)

These confirm that growth signals have become durable patterns, not one-offs.

Signal	F	E	D	C
Ticket authorship ratio	~0% self-authored	20–30% self-authored	50%+ self-authored	50%+, spanning multiple domains
Spec relationship	Follows specs faithfully	Follows specs but flags gaps	Writes specs, or turns vague input into specs	Writes specs that define work across the team; creates the spec process itself
Bug fix depth	Fixes the reported symptom	Fixes root cause + related instances	Prevents the category	Designs the system that prevents categories
Ambiguity tolerance	Needs clear requirements to start	Starts with a problem statement, asks clarifying questions	Starts with “something feels wrong” and defines the problem	Identifies problems no one has articulated yet
Work generation	Assigned tickets only	“Up for grabs” + tickets from own observations	Creates work streams from systematic review	Creates work streams across domains

Self-assessment: the Starfish format

For growth conversations (1:1s, self-evals), the retrospective starfish format works well at the tactical level:

Keep doing: Behaviors that are working and should continue
More of: Emerging growth signals to lean into
Less of: Habits that aren’t serving them at the next level
Stop: Patterns that actively hold them back
Start: Specific new behaviors to try this quarter

This separates the conversation about growth from the assessment of level. The origami plot shows where someone is. The starfish shows where they’re going.

Visualization: The Origami Plot

Each engineer’s assessment produces a six-axis origami plot. Unlike a radar chart:

Area scales linearly with scores — no visual distortion
Shape comparison is honest — a security-heavy profile vs. an infrastructure-heavy profile reflects real differences, not axis-ordering artifacts
The area tells you the tier, the shape tells you the person

Six axes at a 4-point scale produces clean, readable plots. Side-by-side comparison of team members reveals coverage gaps and delegation opportunities — where one person’s 4 should become someone else’s 3.

How to Run Your Assessment

Open Claude Code in the team-pulse repo and run:

/origami yourname

The skill pulls your recent commits, PRs, and issues from the team-pulse database, classifies the work across the six domains, and generates an initial scored assessment with an origami plot visualization.

From there it walks you through an interactive calibration — domain by domain, you review the score, agree or adjust, and add context the data might have missed. The output is a calibrated assessment with growth targets, saved to origami-assessments/ in the team-pulse repo.

The whole thing takes about 15–20 minutes. The Assessment Playbook has the full details on scoring, domain-specific guidance, and how to use your results.

Methodology

The design choices behind this framework address known failure modes in competency assessment.

Why six domains

Cognitive load research (NASA-TLX uses six dimensions) shows that assessment quality degrades as the number of judgments increases. Six domains keeps each assessment thoughtful and avoids fatigue effects where late-assessed domains get less careful scoring.

The domains are grouped to minimize overlap: Engineering Craft covers the full arc of building (architecture, security, implementation). Infrastructure & Quality Systems covers everything that keeps it running and prevents problem classes. Decomposition covers the translation of ambiguity into structured work. Team Systems and Peer Development are deliberately separated because systems leverage and people leverage are different shapes of leadership. Domain Knowledge is its own domain because understanding why the code works this way is orthogonal to writing correct code.

Why a 4-point scale

Research on rating scales consistently finds central tendency bias — raters avoid extremes. A 5-point scale compresses to 2–4 in practice, making tier thresholds ride on single-point distinctions that raters find hardest to make consistently. A 4-point scale with no middle forces a directional choice at every boundary.

Why origami plots, not radar charts

Radar charts distort data — area depends on axis ordering, making visual comparison unreliable. The origami plot (Cañadas-Gómez et al., 2023) scales area linearly with scores, so the visual honestly represents the data.

Failure modes addressed

Scale compression → 4-point forced-choice eliminates the “safe middle”
Visual distortion → Origami plots instead of radar charts
Cognitive overload → 6 domains instead of more
Goodhart’s Law → Rubric describes what levels look like, not what to target; scores emerge from self-assessment and peer feedback, not checklist self-demonstration
Inter-rater reliability → Assessment Playbook provides evidence collection steps and calibration process
Dreyfus model limitations → Levels describe relationship to work in each domain, not universal stages of expertise
Equity risk → Six domains capture different shapes of contribution; Domain Knowledge and Peer Development credit less-visible work; calibration explicitly adjusts for observability gaps

References

Internal & Confidential: This page is only available in the internal handbook and contains confidential information.