10 ms·

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

164 points by alaaf 10y ago

What is the most important thing to think about when you’re switching from a development to a (project) management position?

cjcenizal 10y ago
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!
ffggvv 10y ago
Don't sit around doing nothing, take care of the team's personal problems, make people feel part of something.
LoSboccacc 10y ago
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 10y ago
  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.
- inopinatus 10y ago
  Top tip, don't even think of it as a promotion. You're not anyone's boss.
bigethan 10y ago
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 10y ago
  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.
rubidium 10y ago
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 10y ago
  > -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."
  - tkxxx7 10y ago
    Agreed. PMs at my last job excelled at this. As a result, our "sprints" felt smooth and natural, and we always had time to eliminate technical debt.
PaulHoule 10y ago
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.
dchuk 10y ago
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 10y ago
  So true about delegating. I initially found it difficult to let go of control, but delegating effectively is a very liberating feeling.
dbcurtis 10y ago
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.
Arcanum-XIII 10y ago
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 !
Clubber 10y ago
When you are looking for something to do, don't make work for your developers (meetings).
usgroup 10y ago
Out of interest, why are you switching to project management if you wouldn't mind me asking?
- dylanha 10y ago
  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
  - sbov 10y ago
    I find this reply interesting, because as a developer I feel like #3 is pretty much the only hard thing I have to deal with: translating human intention, which is sometimes paradoxical, into code. It can be hard enough when it's your intention, it's even harder when it's someone else's, and can be a huge time sink when it's multiple someone else's. Corner cases especially, where there is no answer that can completely satisfy all the stakeholders, becomes a balancing act.
  - _betty_ 10y ago
    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.
jives 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
shandor 10y ago
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.
moron4hire 10y ago
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.
tboyd47 10y ago
Stop coding and start managing.
polskibus 10y ago
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.
orbz 10y ago
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 10y ago
  > 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 10y ago
    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_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.
    - dpark 10y ago
unclebucknasty 10y ago
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.
pryelluw 10y ago
Empathy.
Sharma 10y ago
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!
dmourati 10y ago
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.
giis 10y ago
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!
yarou 10y ago
Nag people (seriously). Be as proactive as possible.
- ZenoArrow 10y ago
  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.
fma 10y ago
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.
codebeaker 10y ago
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
maxxxxx 10y ago
- 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 10y ago
  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-roti-for-your-meetings/ http://www.agile-ux.com/2009/01/09/return-on-time-invested-a...
deleted 10y ago
[deleted]
cpeterso 10y ago
“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.
rb808 10y ago
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.
edoceo 10y ago
Remember the most valuable resource to give your dev team: TIME to do their job well.
deleted 10y ago
[deleted]
schnevets 10y ago
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.
cpeterso 10y ago
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.
amorphid 10y ago
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.
zippergz 10y ago
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....
- we3k 10y ago
  Interested to know your version of difference between Project Manager vs Product Manager.
- zippergz 10y ago
  And also that project management (or product management) are not "management" in the normal sense of the word.
- djcapelis 10y ago
  You'll find those things can mean very different things in very different companies.
cryptozeus 10y ago
Post this question on quora
bdcravens 10y ago
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)
abramN 10y ago
learn to recognize when a project is going south, and act immediately!
erikb 10y ago
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.
minipci1321 10y ago
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.
smoyer 10y ago
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).
kyberias 10y ago
Run.
aryehof 10y ago
Continually report and contrast the original schedule and scope, versus changes due to requirement changes and additions.
futhey 10y ago
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.
tehlike 10y ago
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.
cerrelio 10y ago
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 10y ago
  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.
JimmyL 10y ago
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.
binarymax 10y ago
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
yblu 10y ago
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.
facorreia 10y ago
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.
wiresurfer 10y ago
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
BickNowstrom 10y ago
http://a16z.com/2012/06/15/good-product-managerbad-product-manager/ http://a16z.com/2012/06/15/good-product-managerbad-product-m...
wai1234 10y ago
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!
ryanmarsh 10y ago
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 10y ago
  Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?
  - ab1243 10y ago
    Sometimes it's appropriate to use "should," such as "We should implement some kind of user authentication." Other times, you'll hear someone say that their idea is the way it "should" (when they mean "must") be done, without regard to drawbacks, benefits, long term costs, or the need to treat their coworkers with respect. "This should be done this way! Your way is just wrong." That kind of thing happens on some teams. Sometimes, they're right. The other way is just wrong. Some other times, it's jerk driven development.
  - ryanmarsh 10y ago
    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.
draw_down 10y ago
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.
ilaksh 10y ago
Is there such a thing as a project management internship?
arsenide 10y ago
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.
JensRantil 10y ago
I'm currently reading the book "Team geek". It's a small book and I would highly recommend you read it!
- op00to 10y ago
  Why? What's it about? How does it pertain to the discussion?
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
op00to 10y ago
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.
codefreq 10y ago
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!

164 points by alaaf 10y ago

What is the most important thing to think about when you’re switching from a development to a (project) management position?

cjcenizal 10y ago

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!

ffggvv 10y ago

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

LoSboccacc 10y ago

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 10y ago
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.
inopinatus 10y ago
Top tip, don't even think of it as a promotion. You're not anyone's boss.

bigethan 10y ago

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 10y ago
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.

rubidium 10y ago

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 10y ago
> -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."
- tkxxx7 10y ago
  Agreed. PMs at my last job excelled at this. As a result, our "sprints" felt smooth and natural, and we always had time to eliminate technical debt.

PaulHoule 10y ago

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.

dchuk 10y ago

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 10y ago
So true about delegating. I initially found it difficult to let go of control, but delegating effectively is a very liberating feeling.

dbcurtis 10y ago

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.

Arcanum-XIII 10y ago

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 !

Clubber 10y ago

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

usgroup 10y ago

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

dylanha 10y ago
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
- sbov 10y ago
  I find this reply interesting, because as a developer I feel like #3 is pretty much the only hard thing I have to deal with: translating human intention, which is sometimes paradoxical, into code. It can be hard enough when it's your intention, it's even harder when it's someone else's, and can be a huge time sink when it's multiple someone else's. Corner cases especially, where there is no answer that can completely satisfy all the stakeholders, becomes a balancing act.
- _betty_ 10y ago
  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.

jives 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.

shandor 10y ago

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.

moron4hire 10y ago

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.

tboyd47 10y ago

Stop coding and start managing.

polskibus 10y ago

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.

orbz 10y ago

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 10y ago
> 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 10y ago
  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_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.
  - dpark 10y ago

unclebucknasty 10y ago

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.

pryelluw 10y ago

Empathy.

Sharma 10y ago

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!

dmourati 10y ago

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.

giis 10y ago

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!

yarou 10y ago

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

ZenoArrow 10y ago
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.

fma 10y ago

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.

codebeaker 10y ago

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

maxxxxx 10y ago

- 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 10y ago
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-roti-for-your-meetings/ http://www.agile-ux.com/2009/01/09/return-on-time-invested-a...

deleted 10y ago

[deleted]

cpeterso 10y ago

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

rb808 10y ago

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.

edoceo 10y ago

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

deleted 10y ago

[deleted]

schnevets 10y ago

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.

cpeterso 10y ago

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.

amorphid 10y ago

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.

zippergz 10y ago

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

we3k 10y ago
Interested to know your version of difference between Project Manager vs Product Manager.
zippergz 10y ago
And also that project management (or product management) are not "management" in the normal sense of the word.
djcapelis 10y ago
You'll find those things can mean very different things in very different companies.

cryptozeus 10y ago

Post this question on quora

bdcravens 10y ago

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)

abramN 10y ago

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

erikb 10y ago

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.

minipci1321 10y ago

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.

smoyer 10y ago

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

kyberias 10y ago

Run.

aryehof 10y ago

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

futhey 10y ago

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.

tehlike 10y ago

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.

cerrelio 10y ago

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 10y ago
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.

JimmyL 10y ago

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.

binarymax 10y ago

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

yblu 10y ago

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.

facorreia 10y ago

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.

wiresurfer 10y ago

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

BickNowstrom 10y ago

http://a16z.com/2012/06/15/good-product-managerbad-product-manager/ http://a16z.com/2012/06/15/good-product-managerbad-product-m...

wai1234 10y ago

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!

ryanmarsh 10y ago

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 10y ago
Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?
- ab1243 10y ago
  Sometimes it's appropriate to use "should," such as "We should implement some kind of user authentication." Other times, you'll hear someone say that their idea is the way it "should" (when they mean "must") be done, without regard to drawbacks, benefits, long term costs, or the need to treat their coworkers with respect. "This should be done this way! Your way is just wrong." That kind of thing happens on some teams. Sometimes, they're right. The other way is just wrong. Some other times, it's jerk driven development.
- ryanmarsh 10y ago
  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.

draw_down 10y ago

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.

ilaksh 10y ago

Is there such a thing as a project management internship?

arsenide 10y ago

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.

JensRantil 10y ago

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

op00to 10y ago
Why? What's it about? How does it pertain to the discussion?
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

op00to 10y ago

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.

codefreq 10y ago

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!