For most of my career, the honest answer to "what did you do today" was a diff. Some days a good one, some days a mess, but always a thing you could point at: lines changed, tests passing, a merge request with my name on it.
Then the job changed — a six-engineer team, and a release train that runs across a set of repositories instead of one. Nobody handed me a document explaining what had actually changed. So this is that document, written late.
The unit of work is now a decision
A diff has infrastructure. It gets reviewed, it runs through CI, it either merges or it does not. A decision has none of that. Which of the two offer patterns does the new supplier module follow. Does this schema change go out ahead of the consumer or bundled with it. Is this bug worth holding the train for. There is no pipeline that turns red when a decision is wrong — the feedback arrives weeks later, wearing a costume, usually as somebody else's bug.
The output of my day is now often a paragraph: here is what we are doing, here is why, here is what we are explicitly not doing. It took me embarrassingly long to accept that writing that paragraph well is the work, and not the overhead around the work.
Review stopped being an interruption
As a senior engineer, review was the tax between me and my own branch. I did it responsibly and resented it quietly.
With six people merging, review is not a tax on the job. It is the job. It is the one place where six people's local decisions become one system's design instead of six adjacent ones. When I skim a review to get back to "my" work, I am not saving time — I am deferring a divergence that will cost far more to walk back later. I stopped booking review into the gaps and started treating it as the first-class block of the day. What did not survive the transition was the idea that my calendar's default state is "writing code".
The cheapest conversation happens before the branch exists
The pattern I now enforce on myself and the team: when a piece of work has any design freedom in it, we talk before the branch is created, not after the merge request is open. A conversation before the branch costs a conversation. The same conversation after the code exists costs a rewrite — plus the part nobody prices in, which is telling a person their finished thing is the wrong thing. That conversation goes worse every single time, and the code fights back: once it exists, it argues for itself.
Someone has to hold the merge order
The release train is the part that has no equivalent in single-repo work. The unit of release is the set of repositories, not the repository. A go-live can span eleven of them, and when it does, the merge order is part of the design: backend contracts land before the consumers that read them. Run it backwards and there is a window where a consumer asks for a shape that is not there yet — and in this domain that rarely crashes anything. It computes a wrong number, confidently.
That order does not hold itself. Somebody has to be the person who knows it, writes it down with the feature, and checks it on the day. That is not a skill I possessed as an engineer, because as an engineer I never had to — my repo was my world, and the order of everyone else's merges was weather.
What got harder
Being the bottleneck, first. Decisions queue on me the way requests queue on an under-provisioned service, and unlike a service I cannot scale horizontally. Some days the most useful thing I do is ruthlessly answer the queue in the right order.
Second, the urge to just fix it myself. I can often fix the thing in an hour. Every time I do, the hour is cheap and the lesson is expensive: the module stays mine forever, and the engineer who should own it learns that hard problems get escalated rather than solved. Sitting on my hands during someone else's debugging session is a skill I am still bad at.
Third — and this one costs the most — answering instead of writing. Answer a question in chat and the answer evaporates on delivery; the question comes back, from someone else, next month. Write the answer down once and the question dies. The fastest way to lose a week is to answer the same question verbally, repeatedly, while telling yourself you are being helpful.
What I can count
I will not put a productivity number here. I never measured one, and this site does not publish figures I cannot re-derive.
What I can point at is what exists because the job changed: packs of runbooks that used to be answers I gave out one at a time; documented flows for systems that previously lived in commit history; an approval engine whose behaviour is now written down as eleven documented error codes, seven flow diagrams, and eighteen user stories — written back from the code, because the code shipped before the stories did, and the next person should not have to reverse-engineer what I already knew.
None of that is a diff. All of it is the job now.