What changed when the title changed
Eleven days into the new title I took the hardest ticket on the board and finished it myself. That was the first thing I got wrong. An account of the year after, not a playbook.
eleven days in, I took the hardest ticket
It was a migration nobody wanted. Multi-tenant data, a column that had meant three different things across two years, a backfill that had to run without downtime. Exactly the kind of thing I'd been handed since I joined in 2023, and exactly the kind of thing I enjoy.
I finished it in three days and felt useful. That was May 2025, and it was the first thing I got wrong as a lead.
The team's output went up that fortnight. Of course it did — I'd removed the slowest item from the board and done it myself. What I'd also done was take the only piece of work that quarter that would have taught somebody the tenancy model properly. Two months later someone asked me a question about that column and I realised the answer existed in exactly one head, and it was mine, and I'd put it there on purpose without meaning to.
Nobody tells you that the seniority you're rewarded for is the thing you now have to stop doing.
what "senior" was, and what it stopped being
At SoftUp I've been backend-heavy since I joined: NestJS, Postgres, the queues, the deploys. As a senior engineer the loop was legible. A hard problem arrived, I understood it better than it wanted to be understood, I shipped it, and the evidence of a good week was in the diff.
There is no diff for a good week now. I've had weeks where I wrote almost nothing and they were clearly the right weeks, and weeks where I shipped a lot and I'm still not sure. The feedback moved from same-day to about six weeks out, and it arrives as something ambiguous — somebody handling a design decision on their own that they'd have escalated in March, or a bug that doesn't happen.
I don't find this satisfying. I've made peace with it. Those are different things and I'd rather be honest about which one I've got.
reviewing people you also unblock
The awkward part of leading a team of eight while still being the person they ping at 4pm is that both roles use the same text box.
I underestimated how much weight a comment gains when the person writing it also decides what you work on. I'd type "maybe consider extracting this" meaning maybe consider it, and get a force-push twenty minutes later. That happened enough times that I had to accept the words weren't the problem — the position was. I'd been reading my own comments in my voice. They were being read in the org chart's.
So I label them now. Not a process, just a habit that costs three characters:
blocking: this drops the tenant filter — every account sees row 4.
q: is the retry here intentional, or inherited from the old client?
nit: naming. take it or leave it.nit means it genuinely doesn't matter. I had to be caught not meaning that once before people believed it.
The bigger correction was reviewing less. For about four months I was the last approver on nearly everything, which I told myself was diligence. It was a queue. PRs sat overnight waiting on me, and worse, two people who should have been arguing with each other about a design were both quietly waiting for my line instead. I stopped reviewing anything in areas where two other people on the team know more than I do — which by now is most of the frontend and all of the mobile work — and the review latency halved without a single conversation about review latency.
the meetings
I deleted the daily standup in my second month. Fifteen minutes, eight people, most of it a status report to me that I could have read in the tracker. It became an async thread with a bot prompt, and eleven months later nobody has asked for it back. Meetings that exist so one person can be informed should not be meetings.
I also deleted the weekly engineering sync. Thirty minutes on Wednesday, no agenda most weeks, obvious filler. That one I was wrong about.
It took five weeks to notice. Two people built overlapping versions of the same upload handling for two different features, and the reason was almost boring: the sync was where those two people incidentally heard what the other was doing. Nobody had ever written that down as the purpose of the meeting, because it wasn't the purpose — it was the side effect, and it was the only valuable thing in it. Every real decision had migrated into DMs, where it was correct, fast, and invisible to everyone else.
It's back. Twenty-five minutes, and I've stopped trying to give it an agenda, because the agenda was never the point.
why I still write code every day
I still do. Somewhere between an hour and three, most days.
The honest reason is calibration. My sense of how expensive a change is goes stale fast — I'd guess a quarter is enough for it to be actively misleading. If I haven't touched the code in three months, I'm estimating against the version of the system in my memory, which was easier to work in and had fewer edge cases than the real one, because memory sands things down. When I write code, my guesses stay roughly attached to reality, and about half my job is guessing.
The argument against is real, and I've heard it from people I respect. My code is the code least likely to be challenged in review, which makes it the code most likely to be wrong for the longest. I'm a bad owner of anything with a date, because my calendar can eat a Tuesday without warning. And an engineering lead writing features is an engineering lead who isn't doing the parts of the job only they can do.
The compromise I've settled on: I take work that's off the critical path and unpleasant. Build times. The flaky test everyone routes around. The observability nobody prioritises. Nothing with a deadline that another person's work depends on. It keeps my hands in without putting me between anyone and their sprint.
Teispace helps here too. It's small, it's part-time, and I'm the only engineer on it — @teispace/next-themes sits around eleven thousand downloads a week now, which is a number I still find slightly funny for a package I wrote to stop a flash of white on my own site. Working somewhere I'm the whole team is where I make the mistakes that would be expensive to make with eight people watching.
what I'm still bad at
Negative feedback in the moment. I save it. I tell myself I'm choosing the right time, and what I'm actually doing is waiting until it's big enough to feel worth the discomfort — by which point the person has been doing the thing for six weeks and is entitled to ask why I didn't say so in week one. I know exactly what the fix is. I do it maybe half the time.
Dates. When a client asks whether something lands by the 20th, I give them the honest estimate and then absorb the gap myself instead of holding the line, which is a way of lying slowly.
And restraint, still. Somebody on the team shipped a queue design in April that was better than mine would have been. My first instinct was to list the three things I'd have done differently. I said one, and it was the one that mattered, and I only knew that was the right number because I'd said all three on the previous few occasions and watched what it did to the room.
Two years in as a senior engineer, one as a lead. The title changed on a Monday. I'm still finding out what else did.