From Developer to Project Manager: What Changes

What changes when a software developer becomes a project manager: new measures of success, communication, estimation, delegation and staying technical.

I wrote code full time for years before I started leading delivery. The move from developer to project manager looked like a promotion on the same path. It is closer to a change of profession. These are the changes I noticed, and what I would tell someone about to make the same move.

Your output is no longer your own work

As a developer, a good day was a feature finished. As a project manager, a good day might be a meeting that removed a blocker for three other people, and you have nothing to show for it in the repository. It took me a while to accept that the team's progress is the result, and that unblocking others is the work.

Communication becomes the main tool

Most project problems I have seen were not technical. Someone assumed, nobody confirmed. The habits that help are simple and unglamorous.

• Write decisions down the same day and send them to everyone affected.
• Report status in the same format every week: done, next, blocked, risks.
• Tell stakeholders bad news early, with options, not at the deadline.
• Translate in both directions: business needs into technical tasks, technical limits into business terms.

Estimates become commitments

A developer's estimate is a guess about effort. Once a manager repeats it to the business, it becomes a date people plan around. I learned to estimate in ranges, to state the assumptions behind each number and to add time for testing, UAT and rollout, which developers tend to leave out.

Delegation is harder than it sounds

The strongest temptation is to fix the hard problem yourself because it would be faster. It is faster today and slower forever. Every problem you take back is one a team member did not learn from. Explain the goal, agree a checkpoint and let them reach the solution. I wrote more about this in mentoring junior developers.

Requirements move to the centre

As a developer I received requirements. As a manager I am responsible for whether they are right. Time spent with the people who do the work, before any design, saves more than any technical optimization. My approach is in requirements gathering for business software.

Stay technical, on purpose

A technical background is an advantage: you can judge estimates, spot risky designs and earn the team's trust. Keep it alive by reviewing architecture and code, even if you rarely write production features. But stay out of the critical path. A manager who owns a key module becomes the bottleneck.

What I would tell my earlier self

Expect to feel less productive for the first months. Measure yourself by what the team ships and how few surprises the business gets. And keep one small technical project of your own, so the part of you that enjoys building things stays happy.