Returning to the Craft Is Not Moving Backwards

In software, we still have a strange habit of reading careers as arrows.

More scope means up. More distance from the code means seniority. More time spent on strategy, planning, and people systems means progress. The further you move from the work itself, the easier it becomes for the industry to recognise the movement as growth.

So when someone moves in the other direction — from management back into an individual contributor role — the story often gets confused.

It can look like a step back.

After a year-long career break, that is the move I made. I returned to professional work as an IC, after years leading engineering teams. From the outside, that kind of move can be hard to place. The title looks smaller. The org chart looks flatter. The usual grammar of career progression does not quite know what to do with it.

But from the inside, it did not feel like moving backwards. It felt like moving closer.

That gap — between how a move reads from the outside and how it actually feels — is the thing worth sitting with here. Not as personal justification, but because the reflex to read it as regression points to a story about engineering careers that has never been entirely right. A story that quietly shapes who gets promoted, who gets sidelined, and what we think growth actually looks like.

The incomplete grammar of the career ladder

There is a shape we tend to give to careers in software. Junior engineer → senior engineer → tech lead → engineering manager → director → VP → whatever comes next. Each step moves you further from the code and closer to the org chart. Each step is framed as progress — as if proximity to people and process were inherently more evolved than proximity to the actual work.

This is a convenient story. It gives ladders somewhere to point. It gives performance reviews a shared frame. It gives people a direction, which is not nothing.

But it collapses under inspection.

Management is not a more advanced form of engineering. It is a different kind of work — with different skills, different failure modes, and a fundamentally different relationship to what is being built. Charity Majors has written clearly about this for years: management is not a promotion, it is a lateral move into a different profession. The problem, she argues, is not the move itself — it is that people make it for the wrong reasons, because it looks like "up" rather than because they genuinely want to do that work. The confusion has real costs: for people who enter management by default, it becomes slow misery; for teams led by people who would rather be coding, it becomes quiet neglect.

The career ladder is a useful metaphor for titles. It is a poor metaphor for growth.

Growth is not always vertical. Sometimes it means returning to a place you already know, but with better questions.

What management teaches you

I want to be careful here. The opposite error — treating management as something you outgrow, or escape from, or merely survive — would be equally wrong.

Managing engineering teams taught me things I could not have learned staying close to code. Some of them are obvious: how to run a hiring process, how to give feedback that lands without damaging trust, how to hold a performance conversation that is both honest and kind. Those are skills. They take time and they are worth having.

But the less obvious lesson is harder to describe and more durable. Management changed the way I see software itself. Before leading teams, I mostly understood systems through architecture, code quality, constraints, and delivery. I thought about what the system did and how well it did it. After leading teams, I started seeing the invisible layer around the system — the incentives shaping how it grows, the ambiguity producing the edge cases nobody wants to own, the alignment failures that surface as bugs, the ownership gaps that slowly become debt.

Most technical problems have a human antecedent.

The API no one loves was designed under time pressure by someone who never talked to the people consuming it. The service boundary that creates friction mirrors an org structure that changed three years ago. The documentation always out of date belongs to everyone, which means it belongs to no one. That reading — systems through people, not just through code — is one of the more valuable things a few years in management will leave behind. It sharpens the judgment you bring back to the work. I did not come back as an IC to discard that. I came back to carry it into a different kind of proximity.

The cost of distance

And yet. Something else happens when you spend years away from hands-on engineering work, and it is worth naming honestly.

Your feedback loop changes.

As an IC, you encounter constraints directly. You feel the friction of the tools. You discover trade-offs by hitting them. You learn where a system is brittle by trying to change it. The work gives you signals in real time — frustrating, inconvenient, often illuminating — and those signals keep your understanding grounded in what is actually true right now. Not what was true last quarter. Right now.

As a manager, that loop gets longer. You still understand the work. But your understanding becomes one step removed from the experience of doing it. You hear about constraints through what engineers report in standups and retros. You understand friction through what slows delivery, not through having lived it that week. You form models of how the system behaves, but those models are built increasingly from descriptions of the system rather than direct contact with it.

This is not a failure mode. It is a structural feature of the role — widening your lens is necessary to do the job well. But over time, without attention, the distance accumulates. You can stay fluent in the language of engineering work while slowly losing contact with its texture. The vocabulary stays sharp. The instincts drift. What I noticed in myself — after years as an engineering lead, then a career break — was not that I had stopped thinking technically. I had not. It was that my sense of how building actually feels had grown abstract in ways I could not always see until I tried to build something again.

What building during the break reminded me

One of the easiest things to underestimate from a distance is how much the day-to-day rhythm of building keeps changing.

You can follow the tools. You can read the discussions. You can watch the demos. But until you are responsible for turning an idea into something real — with all the small compromises, unclear decisions, and half-visible constraints that come with it — part of your understanding remains theoretical.

During my career break, building Avenida put me back inside that loop.

It reminded me of things that are hard to explain to someone who has not been away from shipping for a while. The specific texture of a decision made under uncertainty, at the intersection of what is technically possible and what users actually need. The way a real deadline reshapes your relationship to quality in ways that planning sessions do not. The way a user complaint lands differently from a bug report — sharper, more direct, harder to defer to next quarter.

But something else surprised me more than the familiarity: how much the craft itself had changed. Not the fundamentals — those hold. What had shifted was the daily rhythm of building. AI-assisted workflows had restructured the relationship between writing and reviewing, between generating and understanding, between moving fast and knowing why you moved. The leverage points had changed. The trade-offs nobody had bothered to put in a framework yet were real and immediate.

I had read about this. I had managed teams navigating it. But reading about it and managing around it are both one step removed from the thing itself.

The ground truth in a shifting craft

This is the part of the pendulum argument that feels most pressing right now, and most specific to this particular moment in the industry.

The shift AI is producing in how software gets built is not primarily a tooling story. It is a workflow story. It changes what requires judgment and what does not. It changes where bottlenecks form, where attention needs to go, and what "done" actually means when generation is fast but understanding is still slow. The teams and leaders who are adapting best are not the ones with the most capable models — they are the ones who have redesigned how they explore, plan, build, and ship around what AI actually changes about the process. I wrote about this in The Real AI Advantage Is the Workflow.

There were mornings building Avenida where I generated a working implementation in twenty minutes — and then spent the next two hours understanding what I had actually built, whether the trade-offs were right, and whether it would hold. The speed was real. The judgment required to use that speed well had not changed at all. If anything, it had become more important, because the distance between intention and artifact had collapsed in ways that removed the natural checkpoints.

You can get useful signal from a distance — through curious engineers who narrate what they notice, through retrospectives that go deeper than blockers, through teams with enough safety to say what is actually happening. But the deepest version of that understanding comes from being inside the feedback loop. Not one step outside of it.

Returning to hands-on engineering is not nostalgia for the craft. It is access to something closer to the ground truth.

Leadership without position

There is a quiet kind of leadership that happens when people follow your judgment before they follow your title. It is less visible in org charts, but very visible in the work. And for many senior engineers, it can feel more honest — less positional, more earned.

One thing worth resisting is the framing that IC and leader sit at opposite ends of a single dial — as if more of one necessarily means less of the other.

A senior individual contributor still leads. The authority is earned rather than positional. It shows up in the quality of decisions made, in the trade-offs named early enough to matter, in the way complex work gets simplified without losing what actually counts. It shows up in how a code review becomes a teaching moment — not by adding a comment, but by asking the question that makes the author see something they had not seen. It shows up in making the path a little more visible for the engineers still finding their footing, not through a one-on-one but through the work itself.

This kind of leadership does not require direct reports or a calendar heavy with check-ins. It requires judgment, generosity with what you know, and the discipline to do good work in a way that makes it easier for others to do theirs. The goal is not to lead less. It is to lead from a different place.

Senior IC work is not the absence of leadership. It is a different expression of the same underlying thing — earned rather than assigned, material rather than positional.

The scope narrows. The mode shifts from people systems to technical systems. But the orientation toward the work — toward what is being built, and for whom, and at what cost — does not change. If anything, it sharpens. You are closer to the decisions that shape what actually ships. And after a few years with a wider lens, that closeness feels less like a narrowing and more like a return to precision.

Final thoughts

I am starting to think of my career less as a ladder and more as a pendulum.

Management gave me range — a wider view of how organizations, people, and incentives interact inside the systems we build. Returning to engineering gives me contact — direct exposure to the friction, the trade-offs, the texture of the work as it actually is right now. One side teaches you how systems of people work. The other reminds you how systems of software feel when you are actually inside them. The value is not in choosing one forever. The value is in knowing when you need to move.

This chapter is not a retreat from leadership. It is a return to the source that keeps leadership honest. And in a moment when the craft is being restructured faster than most organizations can track — when the process of building software is changing in ways that are only fully visible from inside the process — that closeness feels less like a personal preference and more like a professional responsibility.

There is no "just" in building useful things well.