Ask HN: Switching from developer to project manager. What to keep in mind?

When I made the switch from developer to product/program/project management, the biggest mistake I made was still trying to write code.

It's one thing to keep your coding skills sharp, but there is so much to do as a PM other than writing code that will more than make up for the 40 hours a week you gave up by switching jobs. In theory your role as a PM at your company exists because the developers and designers are no longer able to sustain the managerial/organizational overhead coming from team and scope growth.

This really depends on the needs of the organization, but my rule of thumb is to only write code if (1) it's to get data you need or (2) you're bored and can't find anything to do.

I did the switch. The most important thing is reading these 2 books:

* Peopleware

* The Mythical Man-Month

I can't think of better books on managing software projects and software developers.

My experience stems a relatively brief period (~8months) of managing a resource strapped team of 5 devs to deliver pretty complex and largely vaguely specd out products for my venture. (For reference this included a real estate platform, a client facing android app, plus an enterprise management system all complete with Data ingestion / Machine Learning pipelines, built from the ground up.) Here are my learnings 1) chart your plan. Sprints have feature groups, feature groups have features each with defined dependencies. and each feature has tasks. How clearly you map this dependency graph not just in terms of to-do items, but also in time, and by human resource required will define how on time your product gets shipped.

2) Rightfully Estimating Time Overestimate keeping in mind shipping a feature is usually making it + testing it out a bit.

3) Know what features can be chopped off when push comes to shove.

4) communicate clearly and with as much supporting documentation as possible. We still can't vulcan mind meld. So as a PM you need to convey your prioritised vision to your devs. motivation, how a feature fits on the roadmap, dependent features, Screenshots/ mocks, process flows, test cases to check against, all this will make sure features shipped don't need reiteration.

4) Architect for longevity If you are working with an architect, he will probably be responsible for this. But remember, its ok to delay the initial stages of your product if you are spending time building up the core. Think build systems, continuous integration and deployment cycles, just the API layers and business logic, UI work happening totally independent as functional mocks etc etc.

5) Trying to stay away from the temptation of coding. Code when you need to, assign tasks to yourself as and when required but not as a norm. It takes a lot to see the bigger picture and keep track of so many moving parts of a project. Doesn't help overloading your system with dev tasks too. These two worlds are pretty different beasts.

PS: One tool which I relied heavily on over the last year was Omniplan. We not just tracked dev items, but also things like deployment timelines, adoption rate within the org, training schedules for employees and how all this tied up into the features which needed to be rolled at and at what time. A sample of dev wise sprint plan which helps people plan their workload , keeps meetings to the point, and lets people take vacations when they are relatively less occupied :) http://imgur.com/a/1b2mH

I'll assume that PM is a real role in your company and not a glorified status metrics report generator.

The first thing to keep in mind is that being a PM has nothing to do with the skills of a developer other than to judge estimates and evaluate design decisions. It's a DIFFERENT job. You're not the developers' peer and you're not s super lead (anyone who says those things is telling you they just want to be left alone to do whatever they want). So, here's the simplest version:

A PM is responsible for WHAT everyone on the team is doing, a dev (team member) is responsible for HOW they will do the work assigned. That division of responsibility is not black and white but it's a good razor to start with. Anyone who tells you it's not a real management role or you're not a people manager is badly mistaken. Because the PM role in most companies wields authority through persuasion, you are the only true people manager there is.

As the primary conduit between the world outside the project (with its many, often conflicting, stakeholders), and the world inside the project (with its many, often conflicting personalities, styles, and levels of experience), the PM has to deconflict both worlds and harmonize the two. That means you will always have to choose who to disappoint at any given moment.

The job of the PM is to maximize the value of the project for the company. Everything else is secondary. Note that value, in this case, covers a lot of ground from economics to morale and increased capability to tackle the next project. Always be prepared to explain your decisions on that basis, and, if you can't, why are you deciding that way?

The final thing I would tell you to expect is to spend 2+ years at the role before you begin to become comfortable with it, if you ever do. You are either wired to be a good PM or you are not. The mechanics aren't hard, the social dynamics and the situational awareness are.

Good luck!

1. Don't take anything personally.

2. Always remain calm and patient.

3. When people make bad decisions against your strong advice don't feel the need to make their bad decisions a success.

4. Don't own the failure of people who don't understand software development. You'll always be doing the best you can with what you're given.

5. You'll be remembered for your grace and professionalism.

6. Never tell a lie. Never get hand wavy.

7. Never use the word "should". Normative speech has no place in software development. It will embarrass you.

8. Always protect your team from the bullshit that rolls down hill. They'll notice. Then one day when you have to ask them to do something ridiculous they'll know you fought like hell before you had to bring it to them.

9 & 10. This goes without saying but don't write checks (make commitments) you can't cash. Projects will succeed or fail no matter how easy or hard they look at the outset.