About three months ago, I made a formal move from senior engineer to engineering manager.
I knew this was coming. The team had grown and someone needed to own the coordination layer. I had been informally doing a lot of it anyway, running the technical direction, mentoring the newer engineers, being in every architecture conversation. The title change wasn’t a surprise. But actually living the role has been different from what I expected, in ways I’m still sorting through.
The thing that’s been hardest to adjust to isn’t the meetings. It’s the feeling that my relationship with the technical work has changed in a way I can’t quite describe yet. I still read code every day. I still have strong opinions about architecture. But I’m no longer the one writing most of it, and that creates a kind of distance I want to be deliberate about closing.
This is me thinking through it out loud. I don’t have this figured out. But writing it helps.
The standard advice and why I’m suspicious of it
The common framing I keep hearing is: accept that you will code less. Focus on leverage. Your job now is to make the team better, not to be the best individual contributor.
That’s true, as far as it goes. I do code less. I should code less. My time is used more effectively in the right conversation at the right moment than in building a feature I could hand to someone on the team.
But there’s a quiet extension that sometimes gets added: that over time, the right thing is to float above the technical work. To trust the team to own the details. To become more “strategic.”
I’m suspicious of that part. Not because I think managers should still be the primary implementers, they shouldn’t. But because I think the value a technical manager adds is precisely that they stay close enough to make good calls: who to hire, what architecture is actually risky, whether a two-week estimate is reasonable, whether a proposal that sounds sensible in a document will fall apart when someone tries to build it.
If you lose that proximity, you’re guessing. And the team can probably tell when you’re guessing.
What happened to my calendar
Three months in, my calendar has changed more than I expected. Not in volume, I knew meetings would go up, but in type.
Before the role change, I’d have two or three hours of meetings on a typical day, mostly technical discussions. The rest was building. Now it’s nearly inverted. There are hiring conversations, 1:1s, planning sessions, product alignment calls, HR processes I didn’t know existed. The actual building time, the time when I’m writing or reading code without interruption, has shrunk to something I have to actively protect.
That was a real adjustment. I didn’t fully appreciate how much of my sense of forward progress came from shipping things. When you’re building, you have a clear measure of whether the day was productive. When you’re managing, the impact is diffuse and often delayed. You have a good 1:1, you give useful feedback, you unblock a decision, and none of that feels like an artifact of your work the way a feature does.
I’m still getting comfortable with that shift.
Code review as a non-negotiable
The one technical habit I’ve kept completely intact is code review.
Not purely as a quality gate, we have processes for that. As a way of staying in the code. Reading pull requests every day keeps me in touch with how the codebase is evolving, what patterns the team is reaching for, where pain points are emerging. You see what people are struggling with. You notice when the same workaround appears three times in two weeks. You catch when a model that made sense six months ago is quietly accumulating exceptions.
Code review is also a completely defensible use of time even as the calendar fills up. Nobody questions whether the manager should be reviewing PRs. And it’s genuinely useful, not just for my own orientation but for the engineers who mostly want feedback from someone with context on where the system is going.
I’ve tried to make my reviews more specific since moving into the role. Less “looks good” and more “have you considered the edge case where we add a second user per organization?” or “this pattern will create a problem when we add the notification layer.” It’s an opportunity to model architectural thinking without blocking anything.
Personal projects and internal tooling
The other thing I’ve been leaning on is side projects, things I’m building myself, outside the core product work.
Right now that’s mostly the design system. We’re rebuilding Plato’s frontend and the Atom component library has been something I’ve kept hands-on with, not because the team needs me in the implementation, but because it keeps me sharp in a way I can’t get from reading other people’s code. Atom is a monorepo: packages/core for the web component library, packages/widgets, packages/icons-16, packages/icons-24, and apps/AtomMobile for the React Native side. Building across those surfaces forces real decisions, API consistency between web and native, token management, distribution model.
There’s something about building from scratch that exercises a different muscle. You have to make decisions. You have to live with them. You encounter gaps in your own knowledge directly rather than mediated through someone else’s pull request.
I don’t know if this scales indefinitely. There will probably be a point where even personal project time is hard to defend. But right now it feels like an important part of maintaining the technical credibility that makes the management job work.
Architecture involvement without being in the way
One thing I’ve tried to be careful about: staying involved in architecture without becoming a bottleneck or a shadow implementer who can’t let go.
The distinction I’ve been working on is between setting direction and owning decisions. I think the manager’s job is to be clear about what problems matter and what constraints are real (performance, maintainability, team velocity). The specific design choices, how to structure the data model, which library to use, how to handle the edge cases, those should belong to the engineer who has to build it and live with it.
When I have an opinion about the specific design (which I often do), I’ve been trying to frame it as a question or concern rather than a direction. “What happens when we need to add multi-org support?” versus “you should use a join table here.” The first opens a conversation. The second makes the engineer feel like they’re implementing my idea rather than solving the problem.
I’m not consistent about this. Sometimes I default to telling rather than asking, especially when I have strong conviction. It’s a habit I’m still building.
The line between contributing and blocking
This is the part I think about most.
Staying technical is valuable right until it becomes control disguised as contribution. If I’m constantly pulling the interesting work toward myself, overriding engineers in design discussions, or making myself the path through which too many decisions flow, I’m not helping the team, I’m creating dependency and probably frustrating good engineers who have better context than I do.
The goal I’ve been trying to hold: stay technically present without becoming the bottleneck. Be in the room, contribute real perspective, but leave the ownership with the person who has to ship it.
That’s harder than it sounds on the days when I have a clear opinion and the team is moving toward something I think is wrong. The right move is usually to make the concern explicit and then trust the team to address it, not to take the decision back.
What I’m genuinely uncertain about
Three months in, there are things I’m still genuinely unsure about.
I don’t know how much technical depth a manager at my level needs to maintain to do the job well five years from now. The honest version: the industry doesn’t agree on this. Some of the managers I’ve most respected have stayed very technical. Others have drifted and still made great calls. The mechanism isn’t as clear to me as I’d like.
I’m not sure I’ve found the right balance yet. Three months isn’t long enough to know if the current approach works, it might be that I’m still running on IC-phase momentum, and the real test comes when that burns down.
And I don’t fully know yet what the team needs from this role. I have a working theory, but it’s still a theory.
What staying technical actually means to me right now
I’ve been trying to define it more precisely, because the phrase is vague enough to justify almost anything.
My current working definition: staying technical means being able to walk into any architecture conversation on the team and have a credible opinion, not because I’ve memorized the codebase, but because I’ve kept the mental models current. I understand the tradeoffs. I can follow the debate and contribute something real.
That’s different from being able to implement things quickly, which I’m already less good at than I was six months ago. And it’s different from having approval over technical decisions, which I’m consciously trying not to need.
It’s the ability to stay in the room as a technical peer rather than just as the person who owns the headcount.
Whether I can hold onto that as the role scales and the calendar keeps filling, I genuinely don’t know yet. But it’s the thing I’m trying to protect.