Project manager in IT: the job and how to enter it

How it differs from product management

Briefly: a project manager owns "how and when", a product manager owns "what and why".

The first keeps the work moving: tasks assigned, timelines clear, obstacles removed, everyone knowing what they're doing. The second decides what should be built at all and why it will pay off.

At small companies these are often one person. At large ones they're separate roles with separate responsibilities.

What the work consists of

Planning. Breaking a large goal into stages, estimating with the team, agreeing priorities.

Removing obstacles. A developer waiting for access, a designer without requirements, a neighbouring team that doesn't reply — all of it lands here.

Communication. With the team, the client, adjacent teams, management. A substantial part of the day is conversation and correspondence.

Tracking. Who's doing what, what's stuck, whether you'll make it. And an honest report upwards when you won't.

Resolving conflicts. Between people, between deadlines and quality, between what the client wants and what the team can do.

What the job isn't

Issuing orders. A good manager doesn't tell developers how to write code. They create the conditions in which the team can work.

Magical acceleration. You can't do in a week what takes a month. The manager's job is to say so in time, not to promise the impossible.

What technical knowledge is needed

Not programming. But enough to:

• follow what the team is discussing;
• tell "this is hard" from "I don't fancy it";
• judge orders of magnitude: what takes a day and what takes a month;
• ask the right questions about technical debt and risk.

The minimum: roughly how web development works, what a database and a service call are, what the path from ticket to release looks like, why tests and code review exist.

A manager who understands nothing of the subject loses the team's respect quickly. So does one who meddles in the code. The middle is required.

Where people come from

From the team. A tester, analyst, developer or designer who started taking on the organising. The most natural route.

From project management elsewhere. Construction, events, manufacturing — the methods are similar and the specifics get added.

From nothing. Possible but harder: without subject understanding there's little trust. People usually start as a coordinator or assistant.

Which skills decide it

Asking questions. "And what happens if there's no data?" during planning saves a week of rework.

Saying unwelcome things. Telling a client you won't make the date is part of the job. Staying silent until the last moment is the profession's most expensive mistake.

Writing. Half the work is correspondence. An unclear message generates three clarifying ones.

Resilience. You stand between the people who want it faster and the people who build it. Pressure arrives from both sides.

Building experience before employment

Take on the organising in any team project: planning, assigning tasks, check-ins, tracking deadlines.

Few people want to do it, so you'll be welcomed. And afterwards you'll have a specific account: a team of four, an eight-week deadline, what was planned, where the estimates were wrong, how it was corrected. Far more convincing than any certificate.