Christian F. Rojas
ENES
All cases

Case 04

A 360° evaluation portal, with its scoring model corrected

HR's 360° evaluation lived in a 10-sheet spreadsheet. I directed three architecture generations and an analysis that cut one questionnaire from 62 to 26 questions and corrected how people are scored.

62 → 26
questions for one role once the role-to-level matrix was recovered (−58%)
149 → 57
workflow nodes after the move from the first to the second architecture
41 · 7
findings fixed in two adversarial verification rounds, 7 of them blocking
System diagram: how the career portal was diagnosed and reframedThe HR instrument is a 10-sheet spreadsheet. The proof of concept migrated 3 of the 10 sheets. The diagnosis, highlighted, found 7 sheets not migrated and 62 questions against a design of 26. The project was reframed as a recovery of work HR had already done; the corrected model runs in the third generation, in production.HR instrument10 sheetsproof of conceptmigrated 3diagnosis7 sheets not migrated62 vs 26 questionsrecoveryof work HR already didGen 3 · in productionSystem diagram: how the career portal was diagnosed and reframedThe HR instrument is a 10-sheet spreadsheet. The proof of concept migrated 3 of the 10 sheets. The diagnosis, highlighted, found 7 sheets not migrated and 62 questions against a design of 26. The project was reframed as a recovery of work HR had already done; the corrected model runs in the third generation, in production.HR instrument10 sheetsproof of conceptmigrated 3diagnosis7 sheets not migrated62 vs 26 questionsrecoveryof work HR already didGen 3 · in production
Fig. 04 · System diagram

My decisions 04

  • Recover the role-to-level matrix and the weights that the first proof of concept had left out.
  • Redistribute a missing evaluator's weight instead of counting it as zero.
  • Always show score and compliance together, because the total alone misleads.
  • Answer threshold noise with a near-threshold alert, not with more evaluators.

Assisted execution 02

  • Claude Code generated the n8n workflows, the fictional demo data and the migrations, with about 30 Python scripts in the first generation.
  • Claude Code built the portal, ran the threshold simulation and carried out two adversarial verification rounds.

Context

HR’s 360° evaluation instrument lived in a 10-sheet spreadsheet. The constraints were strict: zero cost, operable by HR without a technical profile, and no backend of our own.

What I decided

When I compared the first proof of concept with the spreadsheet, it had migrated only 3 of the 10 sheets. The role-to-level matrix and the weights were missing. I chose to recover them before building anything else.

I weighed that choice by its cost of reversal. Adopting the corrected model early costs almost nothing. Changing it once the whole organization has been evaluated means telling everyone the model changed.

How it works

Three architecture generations:

  1. Proof of concept. A static front end, 19 n8n webhooks and Airtable with 10 tables. Development suggestions came from an Anthropic model inside n8n, with a prompt HR can edit without touching code.
  2. Postgres. The same 19 workflows, regenerated. The nodes went from 149 to 57.
  3. Portal. A modular single-page app with no framework, a written design system and 8 views, packaged as one offline HTML file: 817 KB, one network request and zero errors in 14 walkthroughs by role.

Recovering the missing sheets changed the scoring model:

  • The questionnaire. For one role it went from 62 to 26 questions (−58%).
  • The scale. 40/70/90/100 instead of a linear 2/3/4/5.
  • The weights. Leader 0.35, peer 0.35, employee 0.30, instead of equal weights.
  • Redistribution. When an evaluator is missing, their weight is redistributed instead of counted as zero. A skill rated 4 and 4 with no peer used to score 2.6 (“Low”); now it scores 4.0.

A threshold simulation showed that a person at the edge of a band changes band about 50% of the time, with 3, 4 or 6 evaluators. Going from 3 to 6 evaluators cuts that noise by only 29%, for twice the effort. So the portal shows a near-threshold alert.

The total alone misleads: one profile with 44.88 points meets 18 of 18 skills, and another with 70.00 meets 3 of 18. Score and compliance always appear together.

What it produced

The version in production is the third generation: a self-contained portal, one offline HTML file with no backend. The first generation was retired when the Airtable license expired.

The catalog holds 283 skills, each with 4 described levels, and 15 roles with an expected level. Each person answers 18 to 34 questions, depending on the role. Two adversarial verification rounds fixed 41 findings, 7 of them blocking. The work also documented errors in the source spreadsheet: a broken lookup, missing roles and duplicates in the catalog.

What it does not prove yet

The demo data uses fictional profiles. I have not yet measured real users, completed evaluations or the completion rate per round. The scoring is corrected on paper and in the portal; how it behaves across a full evaluation round is still unknown.

What I would do next

Run a full round and measure real users, completed evaluations and the completion rate. Then check how many people fall near a threshold and whether the alert changes how leaders read the results.