
Ask HN: How can I become a proper Project Manager from a Programmer? - wener
I was satisfied as a programmer, but sometime you have to manage some project, I want to be ready when I got a chance.<p>So, what should I do&#x2F;learn ? Is there any roadmap&#x2F;checklist for a programmer ?
======
stuaxo
The best project managers I've had have identified and removed obstacles for
me (including things like - attending mandatory meetings, so the devs don't
have to).

Other good managers have also reigned in my ideas enough so that we implement
what is attainable.

Bad project managers have had an obsession with statistics, spreadsheets and
tools like Jira.

Most project managers I've had have been bad/indifferent, but with about 2 or
3 out of around 16 roles/projects being good/great.

~~~
bitwize
If it can't be measured, it can't be managed.

Remember that your manager is accountable to someone else higher up the chain.
They don't know how dev works, but they want to see quantifiable progress.
Statistics, spreadsheets, and tools like Jira are how that progress gets
communicated. Like it or not, this is an essential part of the business.

~~~
quantumhobbit
The best measure of how a project is going is using the software it is
producing. Instead of using questionable data from Jira and the like, just try
to use the software. Ask for a demo, or run the code yourself, or look through
unit and acceptance tests.

~~~
bitwize
Direct supervisors can do that and get a detailed feel for how it's going. But
that's too touchy feely, too many variables. C-level execs want to know "are
we on track to ship version 3.0 by the end of the quarter?" and they need a
yes/no answer, justified by numbers and graphs. They don't know about unit
tests, and can't be bothered to walk through the software itself.

------
jwn
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!

~~~
blabla_blublu
What motivated your transition from Dev to Product manager? I am looking to
make a similar switch, would it be okay to reach out to you for guidance?
Advice on the transition would be incredibly useful!

Cheers!

------
debacle
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.

~~~
numlocked
To add one more: a sense of urgency. Your job isn't to whip the team, but you
should provide a steady drumbeat of progress, and be able to instill urgency
and speed into the team.

~~~
fsloth
"you should provide a steady drumbeat of progress, and be able to instill
urgency and speed into the team."

Just goading the team to go faster gives an air of testdriving ones new
position unless there is some obvious, real, time pressure.

Rather - people often behave as they are expected to behave. Treat them as
responsible, adult professionals, you get adult professionals. Treat them as
galley slaves, you get galley slaves.

Mind you, all this is just introspection and armchair psychology.

------
impostervt
You don't have to transition. Think hard before you do.

I became an engineering manager at around 26, and did it for another 5 years,
and thought that was my future. But I transitioned jobs and ended up getting
back into development, and realized a few things:

\- I hate meetings, and PMs go to meetings. A lot.

\- PMs have less control then you probably think.

\- Writing code means I get to actually make stuff. At the end of the day, as
a manger, it was often hard to point to anything as a real accomplishment.

I'm 37 now, and have no desire to go back to being a manager. Now, maybe being
a PM is what you really want to do, and if so, I wish you the best of luck. We
could use some PMs with actual development skills.

~~~
partycoder
I think it can be useful to have demonstrable working experience in
management, even if it wasn't your career choice.

~~~
r00fus
This. Seriously it does help when more senior coders understand the pressures
on project/product managers.

------
eclipse31
I'm in a similar position at the moment. Basically what you want to do is ask
for more responsibility from your PM, specifically to do work they'd normally
do. Over time, that work will become part of your responsibilities. As you
gain more confidence from doing those tasks, and as your team begins to
recognize you moving away from programming and taking on more leadership,
you'll put yourself in a good position to manage a sub-team on a small
project. If you can pull that off, you can build on that for a bigger
project/promotion to PM/SDM.

For example, we work in an Agile environment, so I've started running some of
the 'Agile ceremonies', such as story refinement, estimation etc. From there
my plan is to try and fully manage a sub team for a smaller project, as
mentioned above. On top of this, I've arranged to go on a Project Management
course in a few months. Doing all this should put me in a good position for a
PM/SDM role.

Hope this helps and good luck!

~~~
wener
Thanks, I think you are the lucky one. Our company got ~100 emp, but IT dept
only got 2 backend(includ me), 1 frontend, 1 android, 2 ios.There is no one I
can learn from,so,there is no real world practice or example.This is very
common in China, just get things done, we got people.

~~~
eclipse31
Ah ok, sorry to hear that. With such a small development team, it sounds like
it could be hard to move into management. However, this should also present
opportunities: if you see something that needs to be done and no one's dealing
with it, do it yourself, accept the responsibility and try and make sure some
one notices that you've gone to that effort (or ideally, point out the fact
that you're going to do this to whoever you report to).

------
dandare
You will have to pick up some general management skills and for that I can not
recommend enough The Mobile MBA by Jo Owen. Thin book, no BS, no fillers,
practical and useful advices from a successful manager. That book should have
been named MBA 101 for programmers.

------
ciucanu
I think it would be a great exercise to shadow your Project Manager(if you
have one) for a while. If you don't have one, maybe just try to virtually
manage the project you're working on. You'll find that the PM job is not
really what you expected to be.

I'm a sysadmin and I've tried to simulate this kind of change and I found that
there are a lot of bureaucracy tasks which I don't really like :). If you ask
me, the proper career path has the "team lead" position as the first step,
which brings you closer to a "* manager" feeling.

Good luck!!

~~~
wener
I can feel that at work, but the PM skill is required to improve myself, maybe
I don't need that skill in my work, I got some extra project out of work, I
hope I can manage that well, then we may build a studio or something.

Be ready is never ready.I just want to know what I'm missing and how to get
it.

------
Daviey
Decide if you really mean Project manager, Product manager or Programme
manager.

I don't see why there would be a specific list for programmers... but try and
see if you can take on greater control of the tasks in your current job to
build experience.

~~~
sidcool
Also, ensure it's one of the above and not an Engineering Manager. The
expectations are quite different for each roles. I have been burnt by my
mistakes when I tried to do everything whilst being a Technical Lead of a
project. It burnt me out, but taught a valuable lesson.

------
cpeterso
My favorite books on project management:

1\. "Project Management for the Unofficial Project Manager" is a high-level
but pretty complete introduction. It has good good examples from non-technical
projects based on the Project Management Institute's infamous "Project
Management Body of Knowledge" (PMBOK).
[https://amzn.com/194163110X](https://amzn.com/194163110X)

2\. Scott Berkun's "Making Things Happen: Mastering Project Management (Theory
in Practice)". Scott was a program manager at Microsoft and describes some of
the less process-oriented, more "in the trenches" aspects to managing a
project. [https://amzn.com/0596517718](https://amzn.com/0596517718)

3\. Steve McConnell's "Rapid Development: Taming Wild Software Schedules".
It's more of an encyclopedia of software project management and is now a bit
dated (1996), pre-dating Scrum and Agile but all those ideas have been known
for a long time. [https://amzn.com/1556159005](https://amzn.com/1556159005)

------
gadders
There are two aspects to project management. The first aspect is being able to
manage the methodologies and techniques popular at your employer EG managing a
sprint, building a gantt chart, creating the necessary project artifacts etc.

The second harder part is the mind set. Ultimately, you are responsible for
the success or failure of the project. That means you need to do what ever it
takes to make the project successful, and to be relentless in making this
happen. Sometimes that will mean persuading business sponsors, sometimes it
will mean chasing up why Developer Jane as the wrong version of the IDE
installed on her laptop.

As Stuaxo has said, if you have a good team a large part of the job is
removing obstacles for your developers. Another part of the job is attacking
project risks and ambiguity around the project.

You also have to be prepared to frequently give bad or uncomfortable news to
your senior management, and even tell them "No" sometimes.

I'd say learn what you can on the PM techniques, and then ask to shadow a good
PM for the latter.

------
realworldview
If only life were so easy then a roadmap or checklist would solve everything.

Experience is critical. Knowing what works is useful but more importantly
knowing what doesn't work is essential. Focus on solving the issues and not on
welcoming good news.

Start small. Do you have personal programming projects? Did you _project
manage_ them? No? Then start by critically managing your own work. Stand back
and introspect.

Do you want to manage any type of project or are you targeting technical
projects, client projects, web projects? There will inevitably be a mixture so
you need to understand that. Don't trust anyone. Keep asking for
justifications and proof. Remind everyone about the different responsibilities
that are present in any project and be specific about each individual's
responsibilities.

What are you waiting for?!

------
gtramont
My only advice is to not simply jump into a management role because it is the
only career path you see. You can still be technical and progress your career!
I definitely encourage you to try and experiment different roles, though, as
this brings you versatility and understanding the lifecycle of a project.

~~~
lawnchair_larry
Project management isn't really a management role. They are usually peers,
often on a lower payscale than engineers.

~~~
gtramont
Totally agree! I guess this is the point I tried to make. :)

------
katpas
If you'll be managing a technical product and other developers I'd recommend
reading 'Managing Humans' by Michael Lopp (aka rands) -
[https://www.amazon.co.uk/Managing-Humans-Humorous-
Software-E...](https://www.amazon.co.uk/Managing-Humans-Humorous-Software-
Engineering/dp/1430243147)

Short chapters so you can read it in chunks, its entertaining and based on his
experiences.

Included it in this list of start-up books I wrote ages ago but you've
reminded me its worth re-reading - [https://medium.com/@KatAlexPas/an-hour-
and-a-half-a-day-of-r...](https://medium.com/@KatAlexPas/an-hour-and-a-half-a-
day-of-reading-business-books-db503a79fa0f#.t023t1oai)

------
Jedd
It's tricky. As with any career (or just job-title) change you can try to
manipulate your current / next role into including the key responsibilities of
the new job title you're after -- in this case a PM -- and then try to
leverage that work experience into a formal PM role.

You may need to entertain taking a backwards or sideways step into a precursor
role - local vernacular doubtless varies, but maybe explore Project Officer or
Project Admin job titles. Or, of course, both.

You could start reading up on PMBOK, PRINCE2, Agile/Scrum, etc -- obtaining
accreditation on these tends to be expensive and a little tedious if you're
not actively using the methodologies (in my experience).

------
abhishekdesai
I highly recommend to improve your writing skills. You can start from here.

[http://www.covingtoninnovations.com/mc/WriteThinkLearn.pdf](http://www.covingtoninnovations.com/mc/WriteThinkLearn.pdf)

~~~
wener
Thanks, english is not my native language, as a normal family in China the
ability to read or write english is learned by myself, I will read and learn
what your suggest.

------
koolba
Do you mean project manager as in time keeping, planning steps, pipelining
operations to avoid roadblocks, and dealing with other teams?

Or, do you mean programming manager? (i.e. less nitty gritty, more design,
more delegation, presenting to higher ups)

------
spaceisballer
See if there are any certifications your organization prefers. My work values
people with PMP certifictations, or at the very least a Masters Certificate in
Project Management (which they offer on site).

------
nerdy
Understanding the types of things that prevent programmers from completing
their duties is the core of PM. That can be resources/access, requirements
understanding, scheduling, productivity, etc. It's most helpful if you can
achieve a deep understanding of the business objectives while understanding
technical capabilities and limitations. Most programmers are required to do
that anyhow, but it's especially important in PM because you'll be one of the
earliest people on the tech side to influence new projects.

For example:

\- If you're going to do an API integration in the coming days/weeks, make
sure you provide an account with access, documentation, and consider reading
the docs yourself to look for blockers. Don't focus too much on the
implementation or architecture, focus on the business goals.

\- If you're going to make a modification or new addition as the result of a
new business requirement, make sure you are intimately familiar with the
business domain and how the problem applies. It's important for the PM to
understand what the business _actually_ wants, not simply what they _say_ they
want.

\- Minimize task switching by maintaining a clear strategy with the business
side. When you hand off a task to a programmer the task should be in such a
prepared state that nothing further can be accomplished without writing code.
If business has an "emergency" that isn't, urge them to hold off until the
current development task is completed.

\- Build relationships. You want to be close to business and close to dev. I
would often talk to developers about their day, off-work activities, family
events, etc. They were more than happy to discuss their hobbies for a few
minutes, I feel like it's time much better spent than group meetings and it
gives them reprieve from work. Get to know them, having that connection is
great for them when they can openly make requests and likewise for you.
Sometimes they need vacation on short notice. Sometimes you have legitimate
emergency tasks and need to ask a little extra of them. Having a real
relationship to fall back upon is tremendously helpful, just be sure to
reciprocate.

As a PM you can advocate for engineers and protect them from waste like
excessive meetings and ensure they have everything they need to do their job.
You're in a position to suggest raises, hardware upgrades, etc. Sometimes you
have to fight for what they need.

You can practice many of these things before being a PM. Some of them are
better left for your first opportunity managing a project. Where that line is
drawn depends on the specifics of your circumstances. I was promoted to
management fast after making recommendations which dramatically increased
revenue, which doesn't seem like a bad way to make yourself more visible.
Solve business challenges or provide new revenue streams if you're extra
ambitious. If you want to manage, show initiative.

It's also worth considering you might not be happy as a PM. No longer coding,
it was easy for me to feel like I never got anything done. Entering
tasks/todos/bugs, talking with the business side, and writing emails doesn't
feel productive after programming. Being ready for that possible eventuality
is my best advice.

------
mmmBacon
Learn that you are merely a coordinator and are not "in-charge." Too many TPMs
try to be the boss.

------
SeanDav
I can recommend the book: The Phoenix Project: A Novel About IT, DevOps, and
Helping Your Business Win

------
known
Depends on whether you really like to "manage" the "expectations" of stake
holders
[https://en.wikipedia.org/wiki/Project_stakeholder](https://en.wikipedia.org/wiki/Project_stakeholder)

~~~
wener
Isn't it stakeholder is the result of good manager ? What's the different ?

~~~
jackson23
>According to the Project Management Institute (PMI), the term project
stakeholder refers to, ‘an individual, group, or organization, who may affect,
be affected by, or perceive itself to be affected by a decision, activity, or
outcome of a project’ (Project Management Institute, 2013).

As a PM, I usually refer to the stakeholders as the people that requested the
project, the people that pay for the project, and the people that need to be
informed about any changes related to schedule, scope, cost, impediments, etc.

>What's the difference? A Project Manager is rarely a stakeholder, though it
could happen if the stakeholder is actually managing all aspects of the
project.

It may benefit you to read the PMBOK and read some books on Agile and Scrum
techniques. There are still many projects that use waterfall methodologies and
are successfully on-time and on-budget. I was once a Portfolio Manager for a
large insurance company in charge of data migrations from acquired
insurers...there is nothing that stand-ups and scrum could have done to make
the migration process any faster or better. Point: learn the basic
methodologies first, then build on your knowledge. Agile and Scrum in the
wrong hands can be terribly destructive. Knowing which methodologies may work
best for different teams/projects/situations is key. Sometimes the overhead
and bloat of Agile isn't necessary for simple projects. I once briefly worked
as a subcontracted developer for a crappy consulting/recruiting company. The
company wanted to "provide value" to the client by mandating that the client's
IT Director and I had daily conference calls with the company's scrum master
who only had 6 months of PM experience (I had 8 years of exp at the time).
Which wouldn't have been unusual except I was the only developer, the IT
Director wasn't involved other than "get it done" and gave two shits less
about the daily stand-ups and agile process to design a 3-page site and a
couple of forms, all of which had excellent requirements docs. I ripped
through the work and got out of there in a week. Why apply such a ridiculous
process/methodology to something so simple?

------
clueless123
Always remember: You work FOR the developers... not the other way around.

------
agentultra
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.

------
timwaagh
i recommend poisoning the current project manager and offering to step in.
when you are a manager you cannot afford the luxury of a consciousness so this
is a great way to start!

~~~
sokoloff
You probably mean conscience, not consciousness, but your word is amusing in a
different way.

------
partycoder
Please take a look at the IEEE's Software Engineering body of knowledge. It
will give you an outline of the topic as well as pointers to what reference
material you can consult.

[https://www.computer.org/web/swebok](https://www.computer.org/web/swebok)

~~~
partycoder
I strongly encourage you to take a look at this book. It is a tour around
software engineering including budgeting, planning, implementation,
releasing... everything that you can think of. Always useful to take a look at
it to find out where the gaps or weaknesses are in your knowledge.

Now, some people will try to tell you that project management is all about
going to 3M with a forklift and getting multiple crates of stupid post-its.
It's not. There's much more to it than just sticking post-its.

An engineering manager represents the ENGINEERING interests of a project, not
only pushing features and saying "yes". Being a good manager is not about
saying "yes", it's also about saying "no"... understanding tradeoffs and
balancing them.

Saying yes to features all the time and discouraging quality will only create
a culture of checked-out paycheck zombies.

------
p333347
Project managers and programmers are blood rivals. So firstly, never seek
appreciation from your team. If you get some, always be skeptical of these
possible sycophants. Secondly, never try to be their buddy - it will never
work, and if it seems to, it just means that they are tolerating you. Thirdly,
you should use the phrase "good job xyz" ad nauseum (Programmers know that it
is BS most of the time but still expect it most of the time). Lastly, learn
Excel, especially merging cells and bordering and coloring them..

