What I Learned Moving From Frontend Developer to Technical Project Manager

For years my job was to close tickets. Now my job is to make sure the right tickets exist, that someone can close them, and that closing them actually ships something. Five months in, here's what that shift has taught me.

I started as a UI/UX designer, moved into frontend, then full-stack. In January 2026 I took on the Technical Project Manager role at NovaNext, where I lead web products from architecture and sprint planning through deployment. I still write code and review pull requests. I also mentor developers and interns, which is the part I underestimated the most.

This isn't a "how to become a manager" guide. I'm still figuring it out. These are the things I wish someone had told me in December.

Your output is no longer your code

The first few weeks felt unproductive in a way I didn't expect. I'd finish a day of planning calls, unblocking people and rewriting a spec, and my commit history would be nearly empty. My brain read that as a wasted day.

It took a while to accept that the measure had changed. If a developer on the team ships a feature two days earlier because I spotted a missing API field during planning, that's my output. It just doesn't show up in a contribution graph.

The work that matters most in this role is mostly invisible: the confusion that never happened, the rework nobody had to do.

I now keep a short daily note of decisions made and blockers cleared. Partly for status updates, mostly so I can see that the day wasn't empty.

I still code, but differently

I didn't want to become the lead who can't open the repo. But I also learned quickly that taking the hardest ticket on the board is a mistake. If I'm deep in a tricky feature and three people need me, either the feature stalls or the team does.

So I've shifted what I pick up:

• Scaffolding and architecture spikes. Setting up the project structure, auth flow, or the first version of a data model, where getting it right early saves everyone time.
• Small, unblocking fixes. A broken build, a missing env var, a migration conflict.
• Prototypes to settle debates. Thirty minutes of code often ends a discussion that would otherwise take three meetings.
• Nothing on the critical path. If a ticket blocks a release and I'm the owner, I've made myself the bottleneck.

AI tools help a lot here. I can use coding agents to get through the small fixes quickly, which keeps me in the code without eating my whole day.

Code review became my main design tool

As a frontend developer I treated reviews as a checkpoint. Now they're where I do a lot of my actual leading. A review is the one place where I see exactly how someone thinks about a problem.

What changed in how I review:

1. I read the ticket and the PR description before the diff, so I'm judging the solution against the problem, not against how I'd have written it.
2. I separate "must fix" from "consider" explicitly. Juniors can't tell which of my twelve comments are blockers unless I say so.
3. I ask questions instead of issuing instructions when the person can figure it out. "What happens if this request fails?" teaches more than "add error handling."
4. I approve things that aren't how I'd do them, as long as they're correct and readable. Style preferences don't justify a second round trip.

Estimates are a conversation, not a number

As a developer I'd give estimates and quietly pad them. As the person who has to communicate timelines upward and to clients, I've learned that the number matters less than the assumptions behind it.

Now when someone says "three days," I ask what's in those three days. Does it include the API? Tests? The empty state? Responsive behavior? The answer usually reveals a day or two of hidden work, and it's much better to find that in planning than on day four.

I also break features down further than I used to. On a project like NovaRestro, "table reservations" is not a ticket. It's a data model, a booking flow, a staff view, conflict handling, notifications, and a cancellation path. Each of those can be estimated. The whole thing can only be guessed.

Saying no is part of the job

Frontend developers get handed scope. Project managers have to push back on it. This was uncomfortable at first because my instinct, from years of being the one doing the work, was to say "sure, we can add that."

What helped was reframing "no" as "not this sprint, and here's what it would cost." When a request comes in mid-sprint, I lay out the trade: we can add it, and this other thing moves to next sprint. Most of the time the person asking picks the original plan once they see the cost. Sometimes they don't, and that's fine too, because now it's a decision rather than a surprise.

Mentoring is slower than doing, and that's the point

When an intern is stuck, it's always faster for me to just fix it. I did this a lot in my first month. It felt helpful. It wasn't.

What I try to do now:

• Pair, don't take over. I let them drive and ask questions until they find the issue.
• Explain the why behind conventions. "We put permission checks in the backend because the frontend can be bypassed" sticks better than "put it in the backend."
• Give tasks with a clear finish line. Vague tickets are hard for anyone, but they're crushing for someone in their first months.
• Let them present their own work. In demos, the person who built it explains it. It builds confidence and shows the rest of the team who to ask.

My time interning at Nobel Learning PBC, sitting in on project discussions and capstone presentations, helped me here. I remember what it's like to be the least experienced person in the room, and how much a patient explanation changes things.

Communication is the actual product

I used to think the job was mostly technical with some meetings attached. It's the other way round. Most problems I deal with aren't "how do we build this" but "these two people understood the requirement differently."

A few habits that have reduced that:

• Write decisions down the same day. A two-line message in the project channel after a call beats everyone's memory of it.
• Use the same words everywhere. If the client says "order" and the backend says "ticket" and the frontend says "cart," someone will build the wrong thing. On RBAC-heavy work like designing roles for 15+ staff types, a shared vocabulary for role names saved us real confusion.
• Show, don't describe. A Figma frame or a quick screen recording ends most arguments. My design background turns out to be one of my most useful management skills.

What surprised me

My frontend background helps more than I expected. Frontend is where every other part of the system becomes visible. You see when the API shape is awkward, when a loading state was never designed, when permissions don't match what the UI assumes. That habit of noticing integration gaps is most of what good planning is.

What I miss is long stretches of focus. My days are more fragmented now. I protect one or two mornings a week for deep work, and I'm strict about it.

Where I've landed

If you're a developer thinking about a lead or TPM role, here's the honest version. You'll write less code and feel less productive for a while. Your wins will be quieter. But you get to shape how things are built, not just build them, and you get to watch people you've helped get better at their jobs. For me, that trade has been worth it.

Keep one foot in the code. Write things down. Say no with a cost attached. And when someone is stuck, resist the urge to grab the keyboard.