One Year After the Layoff: Rebuilding as a Technical Lead

Twelve months ago, I wrote a post raw with shock and anger. I had been cut off mid-meeting, locked out of tools, and left to piece together what had happened through whatever channels I could reach. That post was true to what I felt in the moment. It is not what I want to be remembered for.

What I have learned in the year since is more useful than what I felt that day.

The title was not the thing.

For weeks after the layoff, my sense of self was tangled up in my job title. When someone asked what I did, I stumbled. Without the role, who was I? The question felt unanswerable in a way that surprised me. A friend asked me, point blank, what I would still do if no one would ever pay me for it again. I answered without hesitation. That answer had nothing to do with a title. It had to do with how I think, what I care about, and the problems I find interesting. The role had been a vehicle for those things, not the source of them. The vehicle can be replaced.

Systems beat heroes.

In my previous organization, I had been the person who knew where the bodies were buried. I knew why a particular library was pinned at an old version. I knew which service would crash under which load. I knew the unwritten agreements between teams. That knowledge made me valuable in the short term, but it also made the team fragile. When I left, so did the institutional memory. A year later, the thing I want to build, and the thing I look for in teams I join, is the opposite: runbooks, decision records, post-mortems that are actually read. A team that survives the loss of any one person is a team that does not punish the next person who joins.

Transparency is not the same as oversharing.

Leading through uncertainty is mostly a practice of telling people what you know, what you do not know, and what you are going to do next. I used to think that withholding bad news protected teams from worry. What it actually did was leave space for worse stories to grow. In the past year, I have defaulted to writing things down. Decisions, trade-offs, the reasoning behind a deadline. If I cannot explain a decision in a document, I am probably not ready to defend it in a meeting.

I choose teams that document their decisions.

This sounds small. It is not. A team that writes things down signals that it expects to outlast any one contributor. It signals that the next person matters. When I evaluate a role now, the question I ask in the first conversation is not about compensation or scope. It is: where is your design doc? Can I read one of your retrospectives? Show me a decision you changed your mind about. If the answer is that nothing is written down, I know the team runs on heroics, and I know how that ends.

The irony is not lost on me. The layoff was a severance from a system that did not document itself. The rebuilding has been a slow, deliberate practice of doing the opposite.

A year on, I am not bitter. I am grateful. Grateful that the cut came early enough that I had energy to start over. Grateful that I have learned to value what I bring over what I am called. Grateful to the small handful of people who took my calls, read my drafts, and reminded me that the work I cared about had not disappeared just because the org chart had.

If you are reading this from a similar moment, give yourself a year. Not because a year fixes anything, but because a year is enough time to learn the difference between the wound and the lesson.