Losing Your Identity as an Engineer

The Day the Code Stopped

There is a specific moment most new engineering leads remember, even if they can't name it at the time. It's the day they close their laptop at 6pm, exhausted, and realize they haven't written a single line of code. Not a function. Not a test. Not even a meaningful comment in a pull request.

For the first few weeks, this feels temporary. You tell yourself you're in a transition period, that once the team stabilizes, once the roadmap gets cleaner, once the hiring freeze lifts, you'll get back to the work that made you good at your job. That moment rarely comes the way you expect it to.

What nobody tells you in the promotion conversation is that the identity you built over five, eight, ten years of engineering is quietly being dismantled. The skills that earned you the role are no longer the primary currency of the role itself. That gap — between who you were and what you're now supposed to be — is where the hidden crisis lives.

It doesn't announce itself. It accumulates. It looks like low energy on Monday mornings, a vague irritability in standups, a creeping sense that you're performing competence rather than demonstrating it. Engineers are trained to solve well-defined problems. Leadership, especially early leadership, is almost entirely undefined problems.

Role Reality — Meetings, Escalations, and the Invisible Work

The calendar is the first thing that changes. Where you once had long blocks of focus time, you now have a mosaic of thirty-minute slots — a sprint planning here, a 1:1 there, a cross-functional sync that could have been an email but wasn't. Each meeting feels individually justifiable and collectively suffocating.

Escalations are the second shock. An engineer on your team is blocked by a dependency in another org. A product manager is pushing a scope change that will break the sprint. A senior IC is quietly disengaged and you're the only one who's noticed. None of these problems have clean solutions, and none of them produce anything you can point to at the end of the day.

This is the trap of invisible work. When you shipped a feature, there was a deploy. When you fixed a bug, there was a closed ticket. When you mentored someone through a difficult problem and they unblocked themselves, there is nothing. No artifact. No metric. No commit hash. The work happened entirely inside a relationship, and relationships don't show up on velocity dashboards.

New leads almost universally underestimate how disorienting this is. It's not just that the work is different — it's that the feedback loops are broken. Engineering gives you fast, honest feedback. Code either compiles or it doesn't. Leadership gives you slow, ambiguous feedback. You won't know if your decision to shield the team from a reorg was the right call for six months, and even then, the counterfactual is invisible.

The dangerous response to this disorientation is regression. You start reviewing PRs too deeply, not because the team needs it, but because you need the dopamine hit of catching something. You volunteer to take on a technical spike that an IC should own. You stay in the weeds of architecture decisions that you've already delegated, because being in the weeds is the only place you've ever felt competent. This isn't leadership. It's anxiety wearing a leadership costume.

The Reframe — You Are Now a Force Multiplier

The most useful cognitive shift I've seen new leads make is this: stop measuring your output in artifacts and start measuring it in leverage. A senior engineer who ships two features a sprint is valuable. A lead who removes the organizational friction that allows five engineers to each ship two features a sprint is operating at a fundamentally different scale. The math is obvious. The emotional acceptance of it takes much longer.

This isn't just motivational reframing. It's architecturally accurate. Your job is now to be a better analyst of the system than any individual contributor can be, precisely because you sit at the intersection of technical reality, organizational dynamics, and product intent. No IC has that vantage point. You do. The question is whether you're using it.

Consider what a lead actually produces in a single week when they're operating well. They identify that two engineers are duplicating work because of a miscommunication in a planning doc, and they fix it in one conversation. They notice that a junior engineer is being consistently talked over in architecture discussions, and they create a structural change that gives that engineer a voice. They read the subtext of a product ask and translate it into a technical framing the team can actually execute against. None of this shows up in Jira. All of it compounds.

The reframe requires you to get honest about where your analysis is actually sharper now than it was as an IC. You understand the team's capacity constraints in a way no single engineer does. You understand the political dependencies between your team and adjacent ones. You understand the career trajectories of your reports in a way that shapes how you assign work. This is not soft skill territory. This is systems thinking applied to human and organizational systems, and it is genuinely hard.

What You're Actually Grieving

The identity crisis of a new lead is partly a grief process, and naming it as such is not dramatic — it's precise. You are grieving a version of yourself that was legible. The engineer you were had a clear value proposition: you could build things, debug things, design things. Other people could see it. You could see it. That clarity is gone, and its absence is genuinely disorienting.

There's also a competence grief that's harder to talk about. As a senior IC, you were probably in the top quartile of your peer group. You had strong opinions and the track record to back them. As a new lead, you are a beginner again. You don't know how to run a performance conversation. You don't know how to navigate a roadmap negotiation with a VP who has more organizational power than you. You don't know how to hold a team together through a layoff. You are incompetent at the new job, and that is a deeply uncomfortable place for someone who built their identity on competence.

What makes this particularly insidious is that most engineering cultures do not give leads permission to be beginners. There's an implicit expectation that promotion means readiness. So new leads perform confidence they don't have, avoid asking questions that might reveal their inexperience, and white-knuckle their way through situations that would benefit enormously from honest conversation.

The leads who navigate this best are not the ones who suppress the grief. They're the ones who find a container for it — a peer, a mentor, a structured conversation — where they can say 'I don't actually know what I'm doing here' without it becoming a career liability. That container is rarer than it should be.

The Peer Conversation You Keep Postponing

There is a specific kind of conversation that accelerates the development of new leads faster than any book, course, or manager feedback cycle. It's the lateral conversation — lead to lead, peer to peer — where both people are close enough to the same problem to skip the setup and get to the real thing. 'I don't know how to handle this engineer who's technically strong but organizably toxic.' 'I'm being asked to commit to a timeline I think is a lie.' These conversations happen in hallways and Slack DMs, and they are underrated as a development mechanism.

The reason they work is not just emotional support, though that matters. It's that a peer who is living the same transition can offer pattern recognition that a manager or a mentor often can't. They remember what it felt like to lose the code identity. They have fresh examples of what worked and what didn't. They are not evaluating you while they talk to you, which changes the quality of what you're willing to say.

Most engineering organizations don't structure this. They assume it happens organically, and sometimes it does. But the leads who are most isolated — often the ones who need it most — are the ones who won't initiate it because it feels like admitting weakness. The first move is usually the hardest one.

Why Personality Science Makes This Structural, Not Personal

Here is what makes the identity crisis of new leads predictable rather than random: the traits that make someone an exceptional individual contributor are not the same traits that make the transition to leadership smooth. This isn't a flaw in the person. It's a mismatch in the system, and it's measurable.

The HEXACO model of personality — which maps six core dimensions including Honesty-Humility, Emotionality, Extraversion, Agreeableness, Conscientiousness, and Openness — gives you a structural lens for understanding why certain leads struggle with specific aspects of the transition. A high-Conscientiousness engineer who built their identity on precision and closure will find the ambiguity of leadership disproportionately painful. A low-Agreeableness lead will find the constant negotiation and conflict navigation of cross-functional work costly in ways they didn't anticipate. These aren't character defects. They are predictable friction points.

LU Teams uses HEXACO science to surface exactly this kind of structural self-awareness — not as a label, but as a map. When a new lead understands that their discomfort with the role isn't a signal that they're wrong for it, but rather a signal about which specific transitions require the most deliberate investment, the crisis becomes workable. The grief doesn't disappear, but it gets a name and a direction.

The most effective thing a CTO or VP of Engineering can do for a new lead is not give them more feedback on their performance. It's give them a structural understanding of their own personality dynamics and put them in a room — virtual or otherwise — with peers who are navigating the same terrain. The identity crisis of new leads is not a personal failing. It is a systems problem, and it has a systems solution.