How to turn your work log into a useful 1:1 update

You have a 1:1 with your manager tomorrow.

You open Jira. Then Slack. Then your pull requests. Maybe a half-finished document with three bullet points from last week.

You did real work. You remember being busy. You remember a difficult decision, a bug that took longer than expected, and a teammate you helped unblock.

But when the meeting starts, you say:

I worked on the billing migration, helped with the dashboard, and fixed a few bugs.

That is a work log. It is not yet a useful update.

A useful 1:1 update helps your manager understand four things:

• what changed;
• why it mattered;
• what evidence supports the change;
• where you need help or want to go next.

You do not need to report everything. Start with three recent work moments and turn them into conversation points.

The real problem is usually not the 1:1

Most engineers do not struggle because they cannot talk about their work, they struggle because the work is scattered across places that were never designed to tell a career story.

The pull request explains the implementation. The incident channel explains the urgency. The design document explains the tradeoff. The ticket explains the original request.

Your manager may have seen pieces of all of this. They still need a short explanation of what changed and why it deserves attention.

That translation is your job in the 1:1.

It is also why reading through every tool the night before the meeting is such a bad system. You are trying to reconstruct the context at the exact moment you need to discuss the outcome.

A real example: the promotion conversation happened every week

Software engineer Sheldon Sandbekkhaug wrote about his promotion journey after being promoted during a difficult job market. He does not describe one heroic project that secured the result. He describes a collection of behaviors and small accomplishments over time.

One part of his approach was a weekly conversation with his manager. He told his manager that he wanted to work toward promotion, then kept asking questions such as:

• What should I keep doing?
• What should I do differently?
• How can I help the team and the product area?
• What would it take to reach the next rating?

He also scheduled a 30-minute weekly block to think about performance and collect evidence during the six months before writing his review.

The important detail is not that a weekly 1:1 guarantees a promotion.

It does not.

The useful part is the feedback loop: work happened, the conversation connected that work to expectations, and the evidence was collected before review season. That is the kind of loop your 1:1 update should support.

What a good 1:1 update should do

A 1:1 update has three jobs.

1. Make progress visible

Your manager should understand what moved since the last conversation.

That might be a feature shipped. It might also be an incident prevented, a design decision made, a teammate who became independent, or a process that stopped depending on one person.

2. Surface risk early

Do not wait until a deadline is already in trouble to mention uncertainty.

Explain what you know, what you do not know, and what decision or support would reduce the risk.

3. Create a useful next step

An update should give the meeting somewhere to go. You might need a decision, an introduction, a priority tradeoff, feedback on your level, or permission to spend time on work that is currently invisible.

If the update ends with no question, no decision, and no follow-up, it may be a status report rather than a conversation.

Start with three work moments

Do not try to summarize the whole week. Pick three memories that are worth discussing. A simple selection test is:

1. Did something change because of this work?
2. Would my manager make a different decision with this context?
3. Is there an open question, risk, or next step attached to it?

If the answer is no to all three, leave it out of this week’s update. Or monthly. Depends on your schedule 😅

Your three moments can come from different categories:

• Shipped outcome: a feature, migration, release, or user-facing improvement.
• Reliability or risk: an incident, performance problem, test failure, alert, or failure mode you reduced.
• Technical decision: an architecture choice, design review, tradeoff, or simplification that changed the direction of the work.
• Team leverage: mentoring, unblocking, coordination, documentation, or process work that helped other people move.
• Ask or growth: feedback you need, a decision you want to make, or an area you want to develop.

Three is enough for most 1:1s. You can always keep the rest in your work log for later.

Use the change, evidence, mechanism, next step format

For each memory, write four short lines:

1. Change: what is different now?
2. Evidence: how do you know?
3. Mechanism: what did you do to create the change?
4. Next step: what should happen now?

This is close to the XYZ structure, but it is designed for a conversation rather than a resume bullet. The next step matters because your manager needs to know how to help.

Example: technical work

Raw work log:

• Investigated slow report exports.
• Found a query that became expensive for large accounts.
• Reworked the query and added a test for the large-account case.
• Product asked whether the monthly review export could be trusted again.

The technical work is still there. The difference is that the manager can now see the outcome, the mechanism, and the next decision.

Example: team leverage

Raw work log:

• Two engineers kept asking for help with the same deployment failure.
• I traced the failure to an undocumented environment assumption.
• Added the missing setup step and wrote a short troubleshooting note.
• The next two deployments completed without the same escalation.

This is what makes glue work legible. You name the repeated problem, the mechanism you changed, and the people who can now move without you.

Give the manager something to respond to

The last line of each update should create a useful opening.

Try one of these:

• Decision: “I see two reasonable options. I recommend A because it keeps the migration reversible. Do you agree?”
• Priority: “If we keep the release date, I need to move the reporting cleanup to next week. Is that the right tradeoff?”
• Feedback: “I have been operating across the API and frontend work. Am I showing the level of ownership you expect for the next level?”
• Support: “I need an introduction to the support lead so I can validate whether this reduced the repeated customer issue.”
• Growth: “I want to take more ownership of technical direction. Which upcoming project would give me a useful opportunity to practice that?”

This is where a work log becomes a manager conversation. You are not only proving that you were busy. You are making the next piece of work easier to decide.

Keep the 1:1 document alive between meetings

GitLab’s public 1:1 guidance uses a continuously modified agenda rather than starting a new document from zero every week. Its format includes career development, vision, and a “hallway” for ongoing topics. It also recommends linking relevant issues, chats, screenshots, documents, and merge requests.

That practice solves a familiar problem: the important detail appears on Tuesday, but the 1:1 happens on Friday.

Add the detail when it happens. Do not trust Friday-you to remember why Tuesday’s decision mattered.

The document does not need to be elegant. It needs to preserve enough context that you can turn it into a useful conversation later.

Prepare in 15 minutes

Here is the practical routine.

Minutes 1 to 4: collect

Look at the work you captured since the last 1:1. Scan recent memories, pull requests, incidents, design documents, and decisions.

Do not open every tab. You are collecting candidates, not reconstructing your entire career.

Minutes 5 to 8: select

Choose the three memories with the clearest change, evidence, or open question.

Remove duplicates. A feature, its bug fix, and its follow-up ticket may belong to one conversation point.

Minutes 9 to 12: shape

For each memory, write:

What changed:
Evidence:
What I did:
What I need or recommend next:

Minutes 13 to 15: order

Put the item that needs the most attention first. Then add the other two in the order that makes the story easiest to follow.

Your final document can be short:

## Progress and impact
- [Change] because [mechanism]. Evidence: [proof].

## Risk or decision
- [What is uncertain]. I recommend [option] because [reason].

## Ask or next step
- I need [support / feedback / decision] by [time].

The template is deliberately small. A 1:1 should leave room for the conversation itself.

Do not turn the 1:1 into a performance review

An update can support your career without making every weekly conversation feel like a formal evaluation. The goal is not to present a five-page case for your promotion every Friday. It is to keep important work, feedback, and decisions from disappearing.

Atlassian described a similar direction in its performance-review experiment: keep weekly 1:1s, then use one monthly conversation for performance and strengths instead of forcing every topic into one large annual event.

The practical version is simple:

• weekly 1:1s: recent progress, risks, decisions, and asks;
• occasional career conversation: expectations, feedback, growth, and promotion evidence;
• formal review: a summary built from the conversations and source material you already preserved.

Why this helps when review season arrives

Fidelity’s career guidance recommends keeping a running list of accomplishments and future goals, then using documentation from your work and 1:1s during the review conversation. That is the difference between preparing from evidence and preparing from a vague feeling that you were busy.

The same notes also help your manager. A manager cannot advocate for work they cannot remember or explain. A concise update gives them language they can reuse when priorities, staffing, calibration, or promotion discussions happen elsewhere. The same source material can later support a software engineer self-review or help you identify what counts as an accomplishment.

FAQ

The habit behind the update

The best time to prepare for a 1:1 is usually not the morning of the meeting.

It is the moment after the difficult decision, the successful deploy, the incident, the unblock, or the piece of work you almost forgot to count.

Capture the source material while it is still close. Then the 1:1 becomes a conversation about your work instead of an exercise in trying to remember it.

Where careercraft.ing fits

The hard part is not writing the final 1:1 update.

The hard part is having recent, specific source material available before the meeting starts.

That is why I think career capture needs to happen close to the work. A decision, incident, migration, unblock, or mentoring moment is easier to describe while the context is still fresh. Later, the same memory can become a 1:1 update, a self-review example, a promotion note, or a resume bullet. Implementing the weekly capture habit is what makes that reuse possible without a review-season scramble.

careercraft.ing is built around that workflow. You capture the work when you choose, keep the evidence in a private career vault, and reuse it when a manager conversation or review asks you to explain what changed.

You can start without a tool today.

Keep one living document.

Add the raw moment when it happens and before your next 1:1, choose three memories and give each one a change, evidence, mechanism, and next step.

That is enough to make the conversation more useful.

Career Notes

Get better at proving your work.

A short newsletter for engineers who want clearer career stories, stronger self reviews, and better evidence before the next big conversation.

Email address Subscribe

No spam. Just useful notes on career evidence and growth conversations.

You’re subscribed.

Check your inbox for the first note.