
Ask HN: Switching from developer to project manager. What to keep in mind? - alaaf
What is the most important thing to think about when you’re switching from a development to a (project) management position?
======
orbz
Have spent about 5 years in Program/Project Management, and 10 in Developer
Lead roles, and the big thing I'd have to say about the PM world is that just
because it has Management in the title doesn't mean you're a people manager.

You're the developers' peer, and will have to do a good chunk of work
convincing them that the work you think is important, is in fact important.
Everyone has gut feelings on what the project should be and where it's going.
Your job is to provide hard evidence and tracking of that on behalf of the end
user.

Also you're not a full time dev anymore. Don't take dev tasks on unless
they're menial and no one else wants to do them. Nothing undercuts trust like
doing someone's job for them.

~~~
mabbo
> the title doesn't mean you're a people manager. You're the developers' peer

This, 1000 times. The Project Manager role is one of convincing others,
helping organize them, and smoothing out relationships with other
teams/organizations. If you try to act like an authority figure, the devs
working with you wind up in an "Office Space" style "I have 8 bosses" problem.

~~~
heisenbit
Some PMs wear at times the peer hat. However I believe it is not a good idea
to consider yourself a peer. Confusion about roles can lead to conflicts. By
design the PM has to have to last word in most critical decisions, especially
with outside contacts and that makes one stand out. An important part of the
PM role is to say "NO" to all sides - while a peer may say only "no" \- and
this requires power. How to achieve a power position and how to maintain (wrt.
to team but also other parties) it is also part of the PMs work.

Particularly at the beginning I would think carefully - possibly with the help
of an experienced peer aka senior project manager - how to divide
responsibility in the project. I found RACI
([https://en.wikipedia.org/wiki/Responsibility_assignment_matr...](https://en.wikipedia.org/wiki/Responsibility_assignment_matrix))
often a robust and quick way to get started navigating a new project setup.

~~~
dpark
> _However I believe it is not a good idea to consider yourself a peer._

But PMs _are_ peers. PM is not a position of authority. If you are acting as a
PM and try to present yourself as if you have the authority to override dev
decisions or demand that they do certain things, it might work, or you might
breed resentment and hurt your interactions as well as the general team
dynamic.

A PM should treat devs as peers and work to reach compromise and get buy-in
from key stakeholders. A PM should not attempt to force their vision or plans
onto the team. If you can't do the job without being in a position of
authority, then you're not a good PM.

~~~
erikb
I think the difference here is between having responsibility vs acting like
the guy with the crown. A manager should respect his engineers and shouldn't
tell everybody that the engineers are "his guys" like he owns some slaves.

But in the end he's the one who should be allowed to override an engineer's
decision on whether to work on task A or task B, when to pull extra hours and
when it's okay to slack a little.

And if he's good he will be able to keep all the annoying meetings away from
the engineers, which as well gives him more power over them but also allows
them the freedom to focus on the code.

In a good relationship between PM and engineer it doesn't feel like one is on
top of the other. But that doesn't mean there is no hierarchy in the company
decision making perspective.

~~~
dpark
> _But in the end he 's the one who should be allowed to override an
> engineer's decision on ... when to pull extra hours_

No way. I can agree that _often_ the PM has the ability to set task priorities
(not always, devs can push back and the devs' people managers will have the
final say), but no way does a PM have the authority to decide that a dev
should be working extra hours. Absolutely not. That is a pure people
management decision (and one that should almost always be decided no).

~~~
op00to
This is a great point. If there's a resourcing issue, it should be brought up
on the project calls way before it's an actual problem.

------
rubidium
The answer depends a lot on the industry/ product. But in general:

\- Communicate, communicate, communicate. Give status updates. Ask for status
updates. Get information from customers to your development team. Give updates
from your dev. team to your customer.

-Be the voice of the customer. Know if it's more important to be really good or just get the dang thing finished. Let the development team know "we need to cut corners on this one because that's what the customer wants" if that's what needs to happen (of course, don't compromise safety).

-Take care of external roadblocks. Get API info, product specs, pricing, timelines, deadlines, etc... and find a way to effectively give it to the development team.

-Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?"

-Do project retrospectives.

-Learn the art of minimizing meeting length but maximizing their effectiveness. Communicate, communicate, communicate.

~~~
orblivion
> -Assume your dev team knows best how to build, test, and ship the product,
> but ask them questions to find out why. Don't be authoritative, but rather
> put on the attitude of a student. E.g. "I hear you saying we won't be able
> to ship next week. Why is that? What caused that? Is there anything I could
> for our next project that would help prevent this from happening?"

As a dev (never been a PM), the PMs who impress me are ones who ask enough
questions to figure out exactly why something will take a long time to
implement, and then negotiate the right surgical change in spec to
significantly reduce complexity with a minimal cost in hitting requirements.
The customers know their requirements, the devs know how complex they are to
implement. The PM can learn both, which puts them in the position to say "What
if you just did it this way? It won't hit requirement X, but it will hit
requirement Y, which is much more important for this iteration."

~~~
nicoburns
The PM's who have impressed me (as a dev) are the ones who have allowed me to
talk to customers directly, so that I can have that exact same conversation.

------
jives
Many developers try to keep track of everything in their head. That won't work
as a PM.

Your time will usually be much more fractured than it was a dev, as you track
multiple ongoing projects at various levels of detail. If you try to keep
everything in your head, you will most likely start dropping balls, and if
there's anyone who shouldn't drop balls, it's a PM.

So, my advice: make lists and track the status of everything you can.

"A large percentage of my time as a PM (project manager) was spent making
ordered lists." \- Scott Berkun [1]

[1] [http://scottberkun.com/2012/how-to-make-things-
happen/](http://scottberkun.com/2012/how-to-make-things-happen/)

~~~
rodolphoarruda
I've spent 2016 with an average of 10 to 15 active projects I had to manage.
Each one of them had an average of 5 stakeholders performing around 2 or 3
tasks per week I had to manage. That alone, using simple math, gave me 150
active tasks per week that I should track. You can easily double or triple
that number if you had tasks created to yourself before (preparation) and
after (follow-ups) each task due date. On top of those, you still have to
manage admin/desk work to the company you work for (timesheets, expense
reports review and approvals, contract reviews etc.).

More than task lists you need a method to support them. And that is something
you can build based on corporate policy and culture (not following any
particular order). Inbox Zero combined with a task oriented PMS like Basecamp
has worked for me so far.

~~~
DougWebb
For a 40 hour week and 150 tasks per week to track, you have just 16 minutes
per week per task. 16 minutes, to understand what's going on with a task that
requires 13-20 hours to complete. How can you possibly develop an
understanding of any of these tasks? I'm guessing that you can't, and that
your 'tracking' must be limited to updating Basecamp with whether or not the
task is on-track or blocked.

~~~
rodolphoarruda
It doesn't go that way because of the variety of projects/tasks you are
handling. For some projects I check the entire Gantt chart in seconds, send 2
or 3 notifications and that's it, 5 minutes max. Other times it would take me
1 full hour to write a single email with 4 or 5 statements and send it to
company executives. I have to choose my words, be careful and rewrite. So it
depends.

You are not taking overtime into consideration. In 2015 alone I worked a full
month worth of overtime. Working 40h a week for me was far from reality. On
peak periods I was pushing from 12 to 16h a day.

Edit: tried to improve grammar. Added more details to improve context.

------
LoSboccacc
I did the switch. The hard part is leaving your previous shoes behind. While
not mandatory you have to choose how to partition your time and set your
priorities straight.

Chances are if getting promoted you are good at it, whatever that is, probably
better than most your manages. Find someone that thinks in your same patterns
and delegate as much technical issues to his guidance, so you will have no
surprise if you need to turn your back at the technical aspects while solving
budgeting/timing/serivces issues.

Be prepared to say no to improvements, that's a hard thing to do for
programmers turned managers. If you have a chance, get a 10% contingency on
tasks so you can gift good devs with time to branch out their ideas.

Be sure to rotate menial tasks to prevent burnout, it's easy to pin them
always to the less skilled but that does nobody any favor.

Depending on your org structure it may be impossible to be autonomous on
budget/spending/allocation, use that to negotiate timing. "I need x to finish
in this timeline or need the timeline shifted by y" works most of the time if
you're not happy with a given objective, especially if x is controlled from
above.

~~~
Bahamut
More on rotating tasks, it's important to give all developers, even junior
ones, appropriate challenges. It is important to keep people engaged &
learning, but not burn them out.

------
codebeaker
Interestingly topical I shared this tweet [0] a day or two ago, repeated here
to save you a click. Having switched from dev to CTO (which is like PM for
every product in your company, when you're small) it resonated with me. I
personally think it's my job to "shield" the team from any/all external
distractions.

    
    
        Dev productivity killers:
         * Notifications
         * Meetings
         * Emails
         * Interruptions
         Great managers block these. Bad managers cause them.
    

Otherwise, I can only agree with the advice about structure, and discipline.
I'm currently shopping around for something like
[https://github.com/danger/danger](https://github.com/danger/danger) to help
me do my job better by policing Trello automatically - we've had great
experiences using this for Capistrano's pull requests and I'd love to try this
approach on Trello to police the rules we agreed to, but don't necessarily
always follow. That'd probably save me double digit hours each week.

[0]:
[https://twitter.com/_ericelliott/status/814082788378804224](https://twitter.com/_ericelliott/status/814082788378804224)

------
Sharma
Most Important: Be humble.

You know how to program and do the technical design, but do not do that
anymore.

Delegate the development/technical tasks to your tech lead/Sr Developer.
Help/Suggest them if they are overloaded or lagging behind but don't impose
your technical strategies. Delegate and delegate!

Keep everyone involved. Do not hide any information from team. Invite Sr
Dev/QA/Tech leads to the meetings with clients(selectively).

Give importance to every team member. Involve them in decision making.

Finally, do all of the above based on the situations. Do not do everything all
the time.

So...Manage all of this to become a good Manager!

------
Arcanum-XIII
Don't forget where you came from : you're there to help grease the path
forward, not to be a new cog for higher management. I've witness the change
multiple time, and it lead to very bad pm... and don't forget that you will
fail sometimes one or the other parties involved - some dev will be
disgruntled, management will be behind you with misunderstanding of the
situation. Last thing : learn to communicate, you're more than probably moved
because of that !

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

~~~
jurgenwerk
Excelent list. Can you describe the "Never use the word should" a bit more in
depth and give some examples?

~~~
ryanmarsh
Normative speech (often using the word "should") means "I have reason to
believe". "Reason" usually being based on some a priori[0] knowledge.

"we should be able to do x with y"

"y should just work"

"users should be able to k"

In a problem space such as software, where extreme complexity bordering on
chaos is the norm, we we see little evidence supporting common claims of an
expected outcome given reason from some fashion of first principles.

"Rails should work just fine for this", given some principles about Rails.

The problem with the above statement is that you cannot possibly take into
account the entire complexity of the final implementation of the appropriate
solution beyond the most trivial example.

Marsh's first law of software: The complete behavior of any sufficiently
useful computer program cannot be reasoned about by a human in polynomial
time.[1]

Should is a smell. The only should I trust is a passing test.

Sorry if that's clear as mud. I've been working to come up with a good
explanation for my "normative speech has no place in software" axiom and I'm
not sure I've nailed it quite yet.

0: From Wikipedia: A priori knowledge is independent of experience, as with
mathematics (3,000 + 2,000 = 5,000), tautologies ("All bachelors are
unmarried"), and deduction from pure reason (e.g., ontological proofs).

1: Yes I'm referencing my own made up law. Prove it wrong.

------
cjcenizal
I've never made that switch so I can't give advice on how to PM effectively
(that probably is also very team- and project-dependent). But I imagine it
might be a challenge to completely leave the engineer mindset behind. So I'd
be careful to avoid talking with engineers as if you're still one of them,
e.g. discussing technical challenges in depth, suggesting solutions, reviewing
code. Stay focused on your new role as PM to avoid any confusion and keep the
team humming along. Good luck!

------
cpeterso
“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).

Scott Berkun’s “Making Things Happen: Mastering Project Management (Theory in
Practice)” details some of the less process-oriented, more “in the trenches”
aspects to managing a project.

Steve McConnell’s “Rapid Development: Taming Wild Software Schedules” is more
of an encyclopedia of software project management. Published in 1996, it’s now
a bit dated, pre-dating Scrum and Agile but all those ideas have been known
for a long time.

------
erikb
Tip: Find a real PM platform and ask them what they hate about engineers
turning PMs. Here you get a lot of advice from engineers who basically say "be
nicer to engineers than the other PMs I know". But there are reasons for these
misunderstandings that go beyond PMs being arrogant pricks. If you can figure
that out you'll certianly have an easier life.

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

------
amorphid
As you probably know, estimating how long software takes to develop is at best
challenging, and at worse impossible. Part of estimating how long something
will take comes from some domain expertise. I encourage you to continue
dabbling in the technologies you're team uses, so what you know doesn't drift
too far from what your team knows.

Another reasons to keep dabbling is that you may decide you don't like project
management. If you work as a PM for two years without writing any code, trying
to get back into development is gonna be much harder.

Lastly, as a code dabbler, don't try being a developer yourself. That's no
longer your role. The occasional git commit to fix a typo or something is
fine, but you don't wanna be that guy who is a control freak, always
refactoring the code your team delivers. If you wanna write code, stay in
development.

------
giis
If there is one thing I say "Don't _act_ like being nice to fellow team-
members & Don't make fake urgency for specific task."

Most annoying thing : I can handle with some straight forward guys but not
someone who fake like caring about you and your career, while actually fooling
you. And remember those 'urgent' task needs to completed in late nights or
weekends and no one cares about it for months, stop pushing people just
because you possess some-kind of authority. Be transparent.

All the best!

------
JimmyL
Remember that you're not a developer anymore, and that the way you contribute
to the team isn't coding. You're moving from a role that focuses on concrete
contributions, to a role that focuses on creating leverage so that others can
contribute better.

Your job now is to manage the state of the projects you're working on, and
enable the developers on your teams. If you're coding, you're almost certainly
not doing that to the degree you could be. The new job will be difficult.
Change is hard, new skills are hard, and there are days you'll want to just go
code something because it's easier to do and more fun.

Don't do it.

Your priorities are enabling your team and making sure that everyone knows and
is on board with the state of your projects. In your new job, the way you
succeed isn't by putting out code - it's by your projects and teams
succeeding.

Make sure you like the sound of these priorities; if you don't, you should
probably reconsider the change of roles.

Lastly, make sure that you understand what you're accountable and responsible
for. Project managers don't (by default) have people responsibility, but at
your company they might. Same question about doing product ownership, agile
coaching, tactical team leadership, reporting, etc.

------
cerrelio
These are based off my current experience in transitioning to a management
role. I'm still a dev, but my manager is "testing me out" for a management
role.

\- Keep current on technologies, what your team uses and wants to use, and
also technologies that might be useful.

\- Know your developers' strengths and weakness, both technical and
interpersonal.

\- Time management. (Can't stress this enough).

\- Ask lots of thoughtful questions (informed by the first item in the list).

\- Develop relationships with other managers, teams and executives. If you
want to manager bigger things, those guys need to see you and know you can do
it.

\- Don't hold grudges. At the end of the day, go home and forget about any
bullshit that occurred.

\- Trust your developers.

\- Don't be afraid to say no.

\- Take risks. Accept responsibility when those risks turn into failures.

\- Give genuine praise.

One sort of cultural thing to keep in mind. It may not apply to you though.
After moving to the Bay Area several years ago I noticed that behavior with
organizations often defaults to passive-aggressive, especially when there's
disagreement. Avoid being passive-aggressive and correct others (in a
professional manner) when they're being passive-aggressive. I used to deal
with more aggressive people when I worked on the East Coast. You know where
you stand at least. PA behavior allows bad sentiment to stew and kills
progress of any sort. Being assertive most of the time will solve this.

~~~
cpeterso
A corollary of managing passive-aggressive team members is to not hide bad
project news from upset management. A project in trouble is unlikely to get
back on track on its own. Management wants to help but needs to be able to
trust your status reports.

Likewise, your job is to ship the project and you need your dev team's trust
to do that, so you should look for new solutions and risk mitigations when
raising project problems to management, not pointing blame or throwing people
under the bus.

------
maxxxxx
\- Avoid scheduling meaningless meetings. Make sure your meetings serve a
purpose and are not just status updates.

\- Encourage communication between different roles.

\- Trust the developers. I like it when a project manager can talk code but in
the end it's the people who are doing the work who should make decisions.

\- Protect your team from upper management. Don't let senior managers assign
work to your team members for their pet projects.

~~~
codebeaker
Further to your first point, with which I absolutely agree. My team recently
asked me to introduce ROTI [0] (return on time invested) as part of all our
meetings, and it has helped us gauge the mood of meetings, and work out which
kinds of meetings don't work well.

Between these and retrospectives it's been possible for us to eliminate most
all contra-productive meetings.

[0]: [http://www.agile-ux.com/2009/01/09/return-on-time-
invested-a...](http://www.agile-ux.com/2009/01/09/return-on-time-invested-a-
roti-for-your-meetings/)

------
binarymax
Above all else, remember the Iron Triangle.

[https://www.mindtools.com/pages/article/newPPM_54.htm](https://www.mindtools.com/pages/article/newPPM_54.htm)

[https://www.atlassian.com/agile/agile-iron-
triangle](https://www.atlassian.com/agile/agile-iron-triangle)

------
dmourati
Prepare to be largely ignored and avoided. I know the PMs I work with mean
well but I find it hard to take them seriously or give them much credit when
their work product is mostly spreadsheets, gant charts, and scheduling
meetings.

Product managers, on the other hand, deal with what gets in front of the
customer, why, and when. I have more inclination to work with them.

------
moron4hire
You may find yourself naturally gravitating towards thinking in terms of you
doing particular tasks, and if you are still maintaining a part-time developer
role on the project, the danger exists that you will make yourself a bottle-
neck on tasks.

You will have to learn how to delegate. Give people the opportunity to fail.
Even if someone doesn't seem like they can do a particular task, give them the
chance to learn, and give them the resources to learn.

This goes into always remembering to protect the future of the project. You'll
receive tons of pressure to do "quick fixes" and "just brute force it" and
other bullshit management lines, a lot more than when you were just a
developer. It's your job to be a shield against upper management for the sake
of the project. Don't short-change the long-term viability of the project and
your team for short-term gains.

------
bigethan
Without shipped features or a trail of closed tickets to point at, what will
be your measure of career success?

In my experience making a similar move, I initially made my gauge of success
too dependent on others. I had to sit and think to create new metrics and
measurements outside of what was currently done in order to show my success.

~~~
cpeterso
That is a great point. A project manager's quarterly goals, for examples, will
be rather meta compared top a developer's. A project manager's success
shouldn't be a byproduct of the dev team's work. At the end of the day, you
don't have the authority to make developers do anything and you can't take
credit for their work. But you should still be able to succeed in _your_
project management job even if the developers don't ship on time.

------
dbcurtis
1\. Have clear goals. Be able to articulate them. 2\. Communicate the goals to
your team. 3\. Understand what barriers your team faces in completing the
goals. Eliminate the barriers, or adjust the goals. 4\. Clarify your goals.
5\. Care about your team as people. 6\. Communicate your goals clearly.

The best boss I ever had was an ex-Israeli commando officer. Most people look
shocked when I say that. Here is why he was great:

1\. There was never, ever, any doubt whatsoever what he wanted done, and when.
2\. When you told him what it would take to do that, he actually listened, and
did what he could to smooth the path. 3\. He never left basic humanity behind
for any reason in his treatment of team members.

------
minipci1321
1\. Instantly stop being a developer. Trust your team -- if they cannot figure
it out, most probably you won't be able either. (Saying that because for some
time at the beginning it will feel like you can.) Remember, they are at least
as smart as you are, and have been thinking about the problem for much more
time than you can dedicate to it. If they fail, you alone won't save it
single-handedly.

2\. Managing open-source-based codebase is vastly different from managing the
closed-source one. Mixing both (a reality) will require special thinking and
measures. It will require two very different sorts of developers and
activities.

------
zippergz
Make sure you have a very clear understanding of the difference between a
Project Manager and a Product Manager. I've found that lots of developers
think they're the same thing....

~~~
djcapelis
You'll find those things can mean very different things in very different
companies.

------
op00to
The job of a project or program manager is 100% influence based. In other
words, you need to employ influence skills to get people to work on your
priorities. There's a great book, Influencer, that spells out a procedure for
determining how and when to apply a subset of skills that will help nudge your
team in the best direction.

------
cpeterso
I moved from dev to technical program/project management at Mozilla. Given the
organization's open source projects and bottom-up hacker culture, we have no
unified project management process or tools. We have Bugzilla, GitHub, wikis
(public and private for security sensitive work), Etherpad, Trello, Jira,
Confluence (Atlassian's wiki product), Google Docs and Spreadsheets,
Smartsheet, and other tools. Every team users different subsets of tools.
Choice is good but can make collaboration between teams or at a higher program
level more challenging.

I'm curious whether Google or Facebook have standard project manager processes
and tools internally. I know Facebook users Phabricator, but they also user
GitHub.

------
fma
I'm not a PM, but I have a PM that I greatly respect.

My take away from him is be organized. If you have to oversee a lot of
projects, lots of schedules, lots of people, you can't keep track of it all.
Outlook, Onenote...find some good tools and use it well. Follow up promptly -
you may need to deal with other teams a lot, and other teams won't put you on
a top priority.

As a follow up as 'other teams won't put you on a top priority'...don't put
other teams on a top priority :). Learn to say no when you have to. But also
learn to say yes when you can. Your team may need assistance down the road and
you want to cash in those chips.

------
schnevets
Not a PM, but beginning to take on a few duties for an internal project, and
I'm quickly realizing how much of the job involves measuring and forecasting
things that are immeasurable/prone to entropy.

I always assumed PMs would ballpark things like Red/Amber/Green color codes
and projections, but that "winging it" will only take you so far.

The big lesson learned from a somewhat chaotic first foray into management was
record everything, and leverage that evidence in every decision post kick-off.
This requires more disk space than my brain has, so my note taking and
organization skills were forced to go through an overhaul.

------
tehlike
be an enabler.

make your eng peers do uninterrupted work, reduce meetings, cut the crap out
of the corporate process.

This is not to say keep them in the dark about what is going on, but don't try
to schedule a "sync" meetings, ever :)

Another thing that me and my PM peer did was, we had direct communication
line. he could ping me anytime, and i could ping him anytime. We came up with
ideas at odd hours that ended up making a good amount of revenue increase, but
we also respected each other's time. I used him to get myself pure work time
when people were asking for updates, and he used me to prototype many of these
ideas.

it worked out really well for both of us.

------
arsenide
I'm "only" a developer, but clear, concise communication from PMs is the most
important thing for me in my current position. Think about yourself as a
developer: what do you want from PMs? Personally, I like clear communication
and quick resolution regarding the issues I have (that can be solved by PM) in
my day-to-day workflow. When I am working on something and hit a road block
requiring PM input, the most important thing for me is to get feedback as soon
as possible so I can continue on what I am doing.

Communication seems to be key. Ensure you understand and that you are
understood.

------
wiresurfer
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](http://imgur.com/a/1b2mH)

------
unclebucknasty
Make sure the expectations of the role in your environment are clear and that
the position adds value vs. being just a thin veneer over other roles.

I've seen many environments which have project managers that aren't needed.
Very capable people are then relegated to noting status updates and pressuring
the team to meet deadlines. That way lies misery for all.

Agile has done away with a lot of these positions, however, environments that
are highly complex with long term activity and/or many stakeholders to
coordinate may still warrant the role.

------
bdcravens
All the development will seem to be moving way too slow, and everyone will be
doing things that seem unneeded. (Hint: you did the same thing as a developer,
but you'll really notice it now)

------
rb808
You have to concentrate on keeping resources - keep you good people, get
budget for more people, keep close with customers and/or the people who pay
for your software. Manage up and down.

------
shandor
This probably depends on your exact role, but usually there's enough technical
role left for devs-come-PMs that keeping your technical skills top-notch is
really important. In the end, you are the one to make a lot of decisions that
have impact in the future, so better make those decisions as informed as you
can. It's easy to get lost in all the new things with new role, so keeping up
technology-wise will need work.

------
dchuk
You have to delegate planning/architecture/development always. You can't
afford to take deep dives into specific things anymore because you will be in
charge of many more disparate tasks.

Every once in a while you can participate in some technical discussions but
ultimately now you are responsible for them happening, not necessarily
happening with you.

~~~
bhassfurt
So true about delegating. I initially found it difficult to let go of control,
but delegating effectively is a very liberating feeling.

------
smoyer
That you can go back ... I've been forced into management several times and
pushed myself back into development when I got bored. Smart companies will
create a technical track that allows advancement roughly equal to the
management track (though it never seems to equal the sales track).

------
usgroup
Out of interest, why are you switching to project management if you wouldn't
mind me asking?

~~~
dylanha
I'm not the OP but I'm thinking of switching too. My reasons:

Often writing the code for microcontrollers can be overwhelming especially
when it's full of bad style or I have to understand a new library. There is
often a difficulty mismatch. I find myself hating my programming job for
hours, only thinking about money.

I have never tried program management and honestly it sounds easier. I watch
my bosses just ask me for time estimates then take credit when I succeed and
blame me/fire me if I fail to deliver by that date. I want to put myself in
such a favorable position. (Although if I own the company, I'm probably
financially responsible for losses too)

Even if I get rejected 9/10 phone calls, is it worse than dealing with
compiler errors and run time errors all day? How hard is it to talk to
customers and relay it to developers?

It seems the only real hard part with management is 1) estimating the
difficulty of tasks, 2) knowing if your programmers are really struggling or
if they are just slacking off. 3) trying to extract ideas from customers who
don't know what they want

~~~
_betty_
While I'd never recommend staying a career that you hate, I'm not sure
switching to a position you think is cruisy is a great idea either. That's a
recipe for under performance and bad management.

It does sound like you've never worked with a good PM, I'm not sure if I have
either as I do struggle a lot with what value they actually add to projects.

99% of the time its better for people to speak directly and not relay
information through other (probably non technical) people.

Of course you do need to limit distractions but I think you can set
expectations with people about what distractions do and how often they should
distract you.

Also find that a lot of PMs try play power games, I really think they need a
new job title like Project Coordinator or something that sounds a little less
in charge.

Interesting to see this thread has a very mixed idea of what a PM is, a number
of people mention things I'd expect as part of a sales or BA role. I wonder if
this is part of the reason people find PMs useless is that no one really knows
what they should be doing.

------
Clubber
When you are looking for something to do, don't make work for your developers
(meetings).

------
edoceo
Remember the most valuable resource to give your dev team: TIME to do their
job well.

------
BickNowstrom
[http://a16z.com/2012/06/15/good-product-managerbad-
product-m...](http://a16z.com/2012/06/15/good-product-managerbad-product-
manager/)

------
codefreq
There is a great talk from Patric Kua.

[https://vimeo.com/172341374](https://vimeo.com/172341374)

He also has a book "talking with techleads" which reflects on the question
that you have asked!

------
PaulHoule
I would suggest getting involved with the project management institute,
possibly getting a certification. The training for pcap or PMP certification
is actually really good as to helping you do your job.

------
facorreia
Communication above all. Make sure all stakeholders agree and understand
goals, scope and trade-offs, and that progress is communicated often.

Don't overcommit.

Address the biggest technical risks early.

------
polskibus
Don't forget where you came from! You'll be better at your job if you
understand what your subordinates have to deal with on a daily basis.

------
futhey
Did this myself. Remember: You know too much. Make this an advantage, but
don't become a part-time dev manager.

You know the nitty-gritty and every detail of how a piece of software is made.
Use this to your advantage to make developers you work with feel safe. You've
been in their shoes before, you aren't going to change requirements last
minute. You aren't going to come to them with an incomplete spec and demand
unrealistic outcomes. When your bosses are setting the stage for disaster,
you're going to fix it at their level before your dev team even hears about
it.

However, don't fall into the trap of discrediting what the developers you work
with are saying or doing, because you have the experience or know more than
them. Be humble, and believe in your team. Gain their trust, and make sure
they know they can come to you with their problems, mistakes, and questions
early. They'll warn you when something is going wrong before anyone else even
notices it (instead of keeping quiet and going along with a bad idea). They'll
tell you the real reasons why they're pushing back, while they give other PMs
excuses they think are more likely to get them what they need to succeed.

Your primary job is no longer product or productivity or even shipping. Your
job is to get the best work out of the people you work with (even the people
you work for, not just those you manage). Most of the time, the problems you
fix are communication problems. Most of the time, everyone means well but
doesn't realize when and how they're shooting themselves in the foot.

Momentum is everything. Don't let anyone place anything above your team's
momentum. Become a firewall between criticism and productivity. Internalize
critical feedback, but be careful about when and how you bring it to your
developers. Sure, there may be rough edges on your product, but every time you
tell your guys they're screwing up, you're sacrificing project momentum.
Finish a rough draft of your product, celebrate the victory you've earned (now
it's 80% complete), and motivate everyone to polish off the rough edges after
thanking them for their hard work.

It's your job to celebrate every minor victory and be “that guy” (or gal) that
emails the entire company to show off something a member of your team did. Not
to make yourself look good, but to motivate that person to give a damn the
next time doing the right thing means working hard (when nobody is going to
notice).

Also, don't write any code and don't do code reviews. Keep your skills sharp
by building MVPs, doing technical research, exploring APIs while the spec is
being written, etc. Don't step on your team's toes by micromanaging &
nitpicking with their code.

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

------
JensRantil
I'm currently reading the book "Team geek". It's a small book and I would
highly recommend you read it!

~~~
op00to
Why? What's it about? How does it pertain to the discussion?

------
aryehof
Continually report and contrast the original schedule and scope, versus
changes due to requirement changes and additions.

------
ffggvv
Don't sit around doing nothing, take care of the team's personal problems,
make people feel part of something.

------
ilaksh
Is there such a thing as a project management internship?

------
tboyd47
Stop coding and start managing.

------
pryelluw
Empathy.

------
abramN
learn to recognize when a project is going south, and act immediately!

------
cryptozeus
Post this question on quora

------
draw_down
Pretty much every PM I'm ever worked with kept a short-staffed team, picked
ship dates the team was unlikely to hit, then as the date neared, started
scrounging around for developers outside the team to fix all their shitty bugs
and MacGyver their product/feature into a shippable state. Then after they
ship, of course all credit and promotions went to the original team.

Be nice if you didn't pull that shit.

------
yarou
Nag people (seriously). Be as proactive as possible.

~~~
ZenoArrow
That's terrible advice. Micromanagement is a time drain and reduces morale. If
you want the best out of a team, set clear goals and protect them from office
politics.

------
kyberias
Run.

