What does a technical project manager do? A plain guide

If you ask ten people what does a technical project manager do, you will get ten slightly different answers, and most of them will be partly right. I was a Technical Project Manager at Vagaro from 2020 to 2026, and before that an Assistant Project Lead and Mobile Engineer at Silver Touch Technologies. This is the plain version of the role, written for developers wondering whether it is for them.

What does a technical project manager do, in one paragraph

A technical project manager (TPM) is responsible for getting technical work delivered: planned, coordinated, unblocked and finished, in a way that the engineers respect and the business can rely on. The "technical" part matters. A TPM is expected to understand the system well enough to spot risks in a design, follow an engineering debate, and judge whether an estimate is realistic. They usually do not write the production code themselves. Their output is a project that moves, and people on every side who know where it stands.

The exact shape varies a lot by company. In some places a TPM runs one large programme across many teams. In others they sit with one or two teams and handle everything from sprint planning to release. The title is the same; the day can be very different.

How it differs from a developer and a product manager

The easiest way to understand the role is to see who owns which question.

A developer owns the solution. They design, write and test the code, and they are judged on whether it works and lasts.

A product manager owns the problem and the priority. They talk to customers, decide what matters most, and define what success looks like.

A technical project manager owns the path between those two. Once a team knows what to build and roughly how, the TPM makes sure the work is sequenced sensibly, dependencies are visible, risks are named early, and nobody is surprised on release day.

In smaller companies these lines blur, and one person may do two of these jobs. That is normal. It still helps to know which hat you are wearing.

The day-to-day

There is no single typical day, but most weeks include some version of the following.

• Planning. Breaking a large piece of work into steps, working out what depends on what, and agreeing on a realistic order with the people doing it.
• Following progress. Not by chasing people for updates, but by knowing the work well enough to notice when something is quietly stuck.
• Unblocking. Getting a decision from the right person, finding the team that owns a missing piece, clearing a question that has been sitting for three days.
• Managing risk. Writing down what could go wrong, how likely it is, and what the plan is if it does. Saying risks out loud early, while they are still cheap.
• Communicating. Turning engineering detail into a status that a non-technical stakeholder can act on, and turning business pressure into something engineers can plan around.
• Releases. Coordinating what ships, when, and what has to be ready around it: testing, support, documentation, rollback plans.

In a company that works across countries, a lot of this happens in writing. People read your update hours after you send it, in a different time zone, so it has to stand on its own. I found that clear written communication is not a side skill in this role. It is most of the job.

Skills that matter more than the title suggests

Some skills are obvious: planning, organisation, comfort with tracking tools. The ones that separate a good TPM from an average one are less visible.

Technical judgement. You do not need to be the best engineer in the room, but you need to understand enough to ask the right question. "What happens if this service is slow?" is worth more than a perfect Gantt chart.

Translation. Engineers and stakeholders often describe the same problem in different words. One says "we need to refactor this first". The other hears "delay". A TPM turns each side's language into something the other can act on, without bending the truth in either direction.

Calm under moving deadlines. Plans change. A TPM who panics passes the panic on. One who stays calm and re-plans helps the whole team think.

Saying no, or "not yet". Protecting a team from scope that keeps growing is part of the job. It is easier when you can explain the trade-off in plain words.

Trust. Engineers share bad news early with a TPM they trust. That early warning is the most valuable input you will ever get, and it only comes if you have never punished someone for giving it.

How a developer moves into the role

My own path went through a dual role. At Silver Touch I was both an Assistant Project Lead and a Mobile Engineer, which meant staying close to the code while being responsible for how the work moved. That kind of hybrid role is a common bridge, and if your company offers something like it, it is a good way to test the waters. I wrote more about those years in nine years at Silver Touch.

If you are a developer thinking about the move, a few things help:

• Start doing parts of the job now. Volunteer to plan a release, write the risk list for a feature, or run a cross-team dependency. You will learn quickly whether you enjoy it.
• Practise writing for non-engineers. Explain a technical problem to someone in sales or support, in writing, and see if they understand it the first time.
• Learn the business side. Ask why a deadline exists, who is waiting on the work, and what happens if it slips. A TPM who understands the "why" makes better trade-offs.
• Keep your technical edge. Read design documents, sit in on reviews, stay curious about how the system works. Your credibility with engineers depends on it.

When it is not the right move

I want to be honest here, because the role is sometimes presented as the natural next step for every senior developer. It is not.

It may not suit you if the part of the job you love most is building things with your own hands. A TPM's satisfaction comes from the team shipping, not from the code you wrote. Some people find that rewarding. Others miss the craft within months.

It may not suit you if you dislike meetings, conflict or ambiguity. A lot of the work is getting people with different goals to agree, and some of those conversations are uncomfortable.

And it is not the only way to grow. Many companies have a strong technical track for senior engineers, staff engineers and architects, which can carry as much influence as management. Moving into project management just to get a bigger title is a poor reason.

The habits from the role do travel well. Planning in small steps, naming risks early and writing clearly have helped me well beyond it, including in going from project manager to founder. But a role should fit the work you actually enjoy. If you try it and find you miss building, going back is not a failure. It is information, and good information is what this whole job runs on.