Can Your Engineering Work Be Measured in Numbers?

An evidence-first workflow for turning engineering records into a useful year-end review.

Your Git history tells you what changed. Your issue tracker tells you what was planned. Your incident reports tell you what broke.

None of them, on their own, tells the full story of your engineering contribution.

A year-end review asks you to connect those records: what you delivered, why it mattered, what you learned, and what should change next.

That becomes difficult when your work spans feature development, code reviews, migrations, incident response, and maintenance. Some outcomes have clear metrics. Others need a documented explanation.

This article walks through a workflow using NoteGPT AI Agent’s five Skills to organize that evidence, analyze it, and turn it into a report and presentation. The prompts below are examples you can adapt, rather than results from a benchmark or a completed case study.

Start with evidence you can inspect

Prepare a small collection of records that you are authorized to use:

• Issue exports containing scope, status, and completion dates.
• Pull request metadata, such as timestamps, descriptions, and linked issues.
• Release notes and project summaries.
• Aggregated reliability or performance reports.
• Incident reviews and architecture decision records.

Exporting selected records gives you control over what enters the workflow. Remove credentials, customer data, and confidential details that are unnecessary for the review.

Define the review period and your role before analysis begins. A project delivered this year may have started earlier; a team outcome may include contributions from several engineers.

These distinctions belong in the evidence from the start.

1. AI Sheets: Create a traceable work inventory

Use AI Sheets to organize the records into a table you can verify.

A useful structure might include:

Field	Purpose
Work item	Identifies the project, change, or incident
Category	Feature, maintenance, reliability, migration, or developer experience
Intended outcome	Explains the problem being addressed
Contribution	Describes your specific role
Observed result	Records what actually happened
Evidence reference	Points to a source document or record
Verification status	Marks what still needs checking

The distinction between intended outcome and observed result is important. Shipping a caching layer is a deliverable. Demonstrating a latency reduction requires measurements.

Try this prompt:

Organize these engineering records into an annual work inventory. Include the intended outcome, my documented contribution, observed results, and evidence references. Flag possible duplicates across issues, pull requests, and release notes. Do not count them as separate accomplishments without checking. Mark missing information as “Needs verification.”

Review the inventory before moving on. Check whether linked issues and pull requests describe the same work, whether abandoned projects are clearly labeled, and whether team results are being attributed accurately.

2. Data Analysis & Charts: Define metrics before plotting them

Numbers become useful when their definitions are explicit.

Suppose you want to analyze pull request turnaround. The interval from opening to merging may include draft time, weekends, dependency delays, and time spent waiting for review. It does not automatically measure coding effort or individual productivity.

Write down the definition first:

Metric: PR elapsed time
Start: opened_at
End: merged_at
Population: merged, non-bot PRs in the review period
Exclusions: documented explicitly
Unit: hours

Limitation:
Includes waiting time and may include time spent in draft.

Use Data Analysis & Charts to explore the data with those constraints:

Analyze quarterly PR elapsed time using this definition. Report sample counts, missing timestamps, and excluded records. Show the median and distribution where the data supports it. Separate observed changes from explanations that require additional evidence. Do not interpret PR count or elapsed time as an individual productivity score.

The same discipline applies to reliability and performance claims.

If you report a latency improvement, specify the endpoint, percentile, measurement window, and workload conditions. If you report fewer incidents, check whether incident definitions or reporting practices changed.

Useful charts answer a question:

• Did a migration reduce latency under comparable conditions?
• Did a release process change reduce deployment failures?
• Where did work spend the most time waiting?

Every chart should have a metric definition, a population, and a limitation.

3. Deep Research: Add technical context selectively

Internal records explain what your team did. External research can help explain the constraints around those decisions.

Deep Research can support questions such as:

• What migration guidance did a dependency maintainer publish?
• Which upstream changes affected a planned upgrade?
• What documented tradeoffs should inform next year’s architecture work?

For example:

Research the official migration guidance and release notes for the dependency versions listed in this document. Summarize changes relevant to our upgrade plan. Cite primary sources, include publication dates where available, and distinguish documented facts from recommendations.

Keep external findings separate from internal results.

A vendor’s benchmark may help frame an investigation. It does not demonstrate that your own system achieved the same performance.

Similarly, research published after a technical decision can inform a retrospective, but it should not be presented as information the team had at the time.

4. AI Documents: Turn the records into an engineering narrative

Once the inventory and analysis have been checked, use AI Documents to draft the review.

For each major contribution, a compact structure works well:

Problem
Constraints
My contribution
Observed outcome
Supporting evidence
Remaining limitations
Next step

This also works for contributions that resist simple measurement.

For example, an architecture decision record may document why the team rejected a risky migration path. A runbook may clarify incident ownership. A review may catch a compatibility issue before release.

Those contributions can be described through their recorded context and outcome, without inventing hours saved or incidents prevented.

Try this prompt:

Draft an engineering year-end review from the verified inventory and analysis. Organize major contributions by problem, constraints, contribution, outcome, and evidence. Distinguish individual contributions from team results. Preserve uncertainty and list unsupported claims for follow-up. Do not invent savings, percentages, or prevented incidents.

Then review the draft as you would a technical proposal.

Can each important claim be traced to a source? Does the wording imply causation the evidence cannot establish? Are unresolved tradeoffs still visible?

5. AI Slides: Build the presentation from the verified report

Use AI Slides after the underlying narrative is stable.

A presentation for engineering leadership might cover:

1. Scope and responsibilities.
2. Three major contributions.
3. Selected delivery and reliability results.
4. Technical tradeoffs and lessons.
5. Unresolved risks.
6. Priorities for the coming year.

For example:

Create a 10-slide engineering year-end presentation from this approved report. Keep the essential chart labels and measurement periods. Separate team outcomes from my contributions. Include a slide on limitations and unresolved risks. Keep detailed evidence references in supporting notes or an appendix where supported.

Review the slides for meaning as well as appearance. A shortened chart title can change what a metric appears to measure. Removing a qualifier can turn an observation into an unsupported claim.

You can iterate through follow-up requests such as:

Make the distinction between migration completion and measured performance improvement clearer.

Or:

Reduce the background section and give more space to the remaining reliability risks.

Treat the workflow like a small data pipeline

The overall process is straightforward:

Selected records
      ↓
Structured inventory
      ↓
Defined metrics and analysis
      ↓
Verified claims
      ↓
Written review
      ↓
Presentation

External research joins the process where it answers a specific question.

NoteGPT AI Agent can help plan and execute the steps while carrying context between them. You still need to establish the definitions, verify the evidence, and decide which conclusions are justified.

A starting request could be:

Help me prepare an engineering year-end review from these selected records. Build a traceable work inventory, identify duplicates, and propose metric definitions for approval before analysis. Analyze the agreed metrics, draft an evidence-based report, and create a presentation from the reviewed content. Use external research only when needed, citing primary sources. Flag missing evidence and distinguish my contributions from team outcomes.

Review the output with explicit acceptance criteria

Before using the result, check that:

• Major accomplishments have supporting references.
• Metrics include definitions and measurement periods.
• Missing data and exclusions are visible.
• Team outcomes and individual contributions are distinguished.
• Observations are not presented as proven causes.
• The slides preserve the meaning of the approved report.

An engineering review is more useful when someone else can inspect how its conclusions were reached.

Some of your work will be represented well by metrics. Other work will need a technical explanation and a concrete example. The goal is to make both understandable and verifiable.

You can use NoteGPT AI Agent to help organize that process—from the first work inventory to the final presentation.