← BlogEngineering

The ECO Framework: How to Turn Vague Effort Into Undeniable Evidence

Event, Contribution, Outcome — a three-part structure that transforms 'I worked on the API' into the kind of evidence that gets promotions approved.

Reme TeamCareer Advocacy8 min read

There's a specific kind of frustration that comes from knowing you did good work — and being unable to articulate it when it counts.

"I worked on the checkout API refactor."

That sentence is technically accurate. It is also completely useless in a performance review. It doesn't answer the question that every manager and calibration panel is actually trying to answer: *What did you contribute, and why did it matter?*

The ECO framework is our answer to that question.

What ECO stands for

E — Event. The triggering context. What was happening? What was the problem, the opportunity, the constraint? The Event gives your contribution a stage.

C — Contribution. What *you specifically* did. Not the team, not the sprint, not the quarter — you. What decision did you make, what code did you write, what people did you unblock, what risk did you call out?

O — Outcome. What changed as a result? Preferably in numbers. Latency, conversion, error rate, cost, time saved, risk reduced. If numbers aren't available yet, describe the directional impact and flag it for follow-up.

Why this works

Most engineers describe their work in one of two broken ways:

Too vague: "Worked on performance improvements across the platform." Too task-based: "Completed 14 Jira tickets in Q3."

Neither of these is a career narrative. Neither gives a calibration panel evidence they can defend.

ECO forces you to answer the question behind the question. It's not "what did you do?" — it's "what decision did you make, what did it accomplish, and how do we know?"

An example

Here's a raw log entry a Reme user might type immediately after a significant moment:

"Rewrote the auth service because the old one was causing intermittent timeouts. Migrated it over two sprints without downtime. Latency dropped and the on-call load basically disappeared."

Here's what ECO pulls out of that:

  • **Event:** Auth service causing intermittent production timeouts; on-call load increasing.
  • **Contribution:** Designed and executed a zero-downtime auth service migration over two sprints.
  • **Outcome:** P95 latency reduced by 40%; on-call incidents related to auth dropped to zero.

The second version is promotable. The first is forgettable.

The habit that makes it stick

The biggest mistake engineers make with self-reflection is trying to do it quarterly. Quarterly recollection is archaeology — you're excavating half-memories from three months ago.

The ECO habit works best at the daily or weekly cadence:

1. Something meaningful happens — a ship, a decision, a tough conversation. 2. You spend 2–3 minutes logging the raw context in Reme. 3. The structuring layer surfaces your E, C, and O — and prompts you for the outcome metric if you haven't added it yet.

By review season, your Manager Calibration Brief is already 80% written. You've just been building it all year.

One more thing

ECO isn't just for review season. It's a real-time record of your judgment. The decisions you document become a portfolio of evidence that you operate at a certain level — *before* you're asking for promotion to that level.

The best engineers aren't promoted because they perform at the next level during review season. They're promoted because they've been *demonstrating* next-level judgment throughout the year, and the evidence is undeniable.

Start logging today. One entry, right now, about the most meaningful thing you did this week.

Start building your ledger today.

Everything in this post works better when your logs are already waiting for you.

Get Early Access (Free)