Ask HN: How can I become a proper Project Manager from a Programmer?

99% of the time "Project Manager" means "Project Facilitator."

The key aspects of project management are gating, communicating up, and communicating down.

Gating: Keeping things that aren't The Project from becoming The Project without being properly defined (time, deliverables, budget, resources).

Communicating Up: Letting business owners and stakeholders know the status and cadence of the project, what the project team needs to get the job done, what ambiguities need to be cleared up, etc. It's very difficult to hold someone's who is generally your boss feet to the fire, but it's am important skill to learn.

Communicating Down: Deliverables, roadblocks, obligations, morale, etc.

The most important skill in a project manager is humility. Many PMs see themselves as captains of some giant see-faring vessel, but have no respect for the vessel or the sea.

I've recently gone from Developer to Technical Product Manager, and I believe the following traits are important:

1) Communication on both a technical and product level. This allows you to act as a bridge between sales/marketing/management and the developers. See #2

2) Speaking two languages: Code and Product. This is where being a former developer comes in quite handy, as you can only learn Code through writing it, but you can implicitly pick up the Product by thinking like a non-techie and paying attention to what they care about.

3) Keeping a focus on the big picture during a project duration. As a Product/project Manager, you need to understand timelines beyond 3-6 months and make sure you're not shooting yourself in the foot for later. This is tangential to what you may have read in the Pragmatic Programmer.

4) Product/Project Manager can be squishy terms, meaning that the responsibilities can vary by company. Often you'll be left to ensure all the ends of a project are wrapper up: testing, documentation, communication on releases, etc.

There are probably many more things, but those are off the top of my head. Good luck!

This is one of the best, most concise summaries of project management I have seen!

I'm in the process of making this transition. One of the most important things I'm trying to hold on to is a passion for programming that goes beyond writing code. I see my new role as leveraging the 13+ years of professional development I've invested in by providing my team with guidance and critical feedback while ensuring business takes on less risk by making sure the software my team produces follows industry state-of-the-art practices and meets our deadlines. I tend to look at software development as an ongoing process and I hack the process itself to get the results I want rather than relying on my own immediate intuitions and knowledge about programming. In essence I set up the guidelines and processes that let my team be the best developers they can be and help them any way I can.

The other face of my role is being the intermediary between the stake holders and the team. While I am not a licensed engineer I try to behave as though I were: if I let bad code slide into production I might lose my license. The stake holders I collaborate with know this and they agree its an important position. However the business wouldn't move forward quickly if we were developing software like NASA. Instead I imagine there is an actuary assessing my technical decisions who will increase my insurance rates if I make poor decisions or lower them if I make good ones. This creates a risk-vs-reward balance that I need to consider when making decisions on behalf of the business... it might be worthwhile to accept some risk in choosing a software platform my imaginary actuary would asses as risky for the sake of the team who are familiar with it most. While I might enforce certain practices that will lower my rates like extensive fuzzing tests and formal specifications of critical components. It requires some balancing between correctness vs agility. While I don't see the two as mutually exclusive (in fact designing for correctness tends to make a team more agile in the long term) there is some give and take in terms of timelines and budgets that I need to be aware of. I act as the buffer between these concerns and the rest of the team whose focus should be on making software that fulfills our requirements and intentions. I attend the meetings and negotiate the timelines and handle the interactions with the rest of the business.

I think it's crucial for a manager of developers to have been a successful developer themselves with a wide range of experience. It's equally important to gain the trust of the team in your technical acumen: mandatory code reviews have been an invaluable tool in my experience so far. If you can give a good review it demonstrates your knowledge and wisdom while giving someone the opportunity to learn something new. It also lets you become familiar with everyone's skill level which is invaluable when trying to give estimates and quotes to stakeholders. Get out there and get some public credibility by contributing to open source projects, speaking at conferences, and even try your hand at writing. I've spoken at several conferences, have been a technical reviewer on a published book, and have contributed to the WebGL spec, Mozilla Firefox, Openstack, Python, and others. I'll be giving a talk at a local JS conference later this year. It will help if you can develop a reputation as someone trustworthy and wise.

Most of all... and this is universal; be aware of what you don't know. I've led teams in the past in the role of senior/principle/etc developer but I've always been sheltered from budgets, timelines, product scope, etc. I've been asked to interview people for positions but I've never been in charge of setting the policy on how we hire. I've learned how to adapt to social situations but leading people, especially creative and talented people, is like herding cats (I'm also quite introverted so it takes extra effort on my part to keep up). When you don't know how to deal with these things be honest and develop a plan of action to fill those gaps.

For me that means contacting people who I know are great managers (and not necessarily managers of technical teams either: one friend is a genius at running her fathers restaurant and her advice has been invaluable). It also means I keep a log of terms and advice I've been given that I don't understand. I use this log to do keyword searches and find books and blogs on the topics I'm missing out on.

Just keep at it and learn to look at the process of making software as one big software system itself. It can be quite entertaining and interesting.