I joined Reblaze as a senior full-stack IC on a team building a reverse proxy for private cloud networks. The tech lead had just left. A major version release was coming. The team was experienced, but the release had been under pressure for a while and the usual signs were showing. Code review was polite, nobody wanted to touch the hard parts, architectural debates kept getting deferred.
No one appointed me to anything. There was no formal plan for the role. If I had asked for it in the first week I would not have earned it. The team did not know me yet. The release still had to ship.
What I did instead was pick the moves that would most help the release, in the order that would help it most.
What I Fixed First
I set code conventions. Not a style guide document. Specific decisions that had been drifting from PR to PR. When different reviewers were asking for opposite things in the same spot, I picked one, wrote it down, closed the question. The reviews got faster the same week.
I refactored the modules nobody wanted to touch. These existed on every team I had been on. In a mature codebase they are always the same shape: too much state in one place, unclear ownership, implicit assumptions nobody wrote down. The team had been routing around them. A few focused refactors made them touchable again.
I revised the architectural calls that were cooking into bigger problems. Not a redesign. Specific decisions that looked fine individually but were starting to combine into something the team would regret the quarter after the release. The honest conversation about “do we actually want to keep doing this” does not happen on its own. Someone has to name the pattern.
I reorganized the frontend. Shared folders had become a landing zone for anything that did not fit elsewhere. People were stepping on each other on every merge. The reorg was mechanical, not opinionated, and freed up weeks of friction.
None of these moves were heroic. Each one was the thing a senior engineer who was going to stay would have wanted done.
When The Title Caught Up
A few weeks in, the pattern had shifted. People were asking me how to approach the next complex area before they wrote the design. Code review was flowing because the conventions had names. The architecture debates were resolved or scheduled, not drifting. The release went out.
At that point the title landed. Nobody debated it. The work had made it obvious.
From there I ran the Agile meetings, prioritized the tasks, held the milestones, and started mentoring a specific teammate who was going to inherit the role. When I eventually left, that person took over. The handoff worked for the same reason the step-up had. The authority was in what they had already been fixing, not in the announcement.
What This Means When You Hire A Senior Engineer
I see this pattern repeating at seed stage. A founder makes their first senior hire. They know they want “leadership” eventually but they are not sure when. They either name the person lead on day one, which puts weight on a title that has not been earned yet and creates friction with the team, or they wait indefinitely for a formal moment that never comes.
The answer is a month of real work.
Give the senior engineer the problem that most needs fixing, not a management mandate. Watch what they pick. If they go to the ugliest parts of the codebase and start closing debates, the title is already earned. If they do not, a title would not fix it. You have a different problem to solve, and promoting them would mask it.
The things that earn a lead role on a working engineering team have not changed in the time I have been doing this. Set the conventions nobody is willing to decide. Fix the hot spots other people are routing around. Name the architectural problems other people see but do not say out loud. Reduce the friction between teammates. These were the moves at Reblaze and they are the moves now.
The 2026 Version Is The Same, With One Addition
The one thing I would add in 2026 is where the leverage sits when AI agents are in the loop. A senior engineer who is going to lead a small team now also owns the system the agents are improving. The code conventions, the architecture notes, the test coverage, the invariants: these are what the agents push into and what the human reviewer measures their output against. When those are tight, the agents produce good work. When they are drifting, the agents produce faster drift.
Which means the first-few-weeks moves I made at Reblaze matter more now, not less. The agents amplify the state of the codebase they land in. A senior IC who shapes that state in the first month is multiplying every PR the team ships afterward, human or agent.
The Short Version
Reblaze did not need me to ask for the lead role. It needed me to fix the four things that were going to otherwise sink the release. The title followed the work by about a month. Later it followed the next person’s work the same way. If a title ever has to lead the work, something else is wrong.
Let’s Talk
If you have just hired your first senior engineer and are trying to figure out what they should actually own in the first ninety days, or your team is heading into a release without clear technical direction, that is the kind of thing I work through with founders. Happy to look at the specific moves worth making in your codebase first. Reach out.
