Ask HN: Switching from developer to project manager. What to keep in mind?
What is the most important thing to think about when you’re switching from a development to a (project) management position?
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.
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.
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...) often a robust and quick way to get started navigating a new project setup.
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.
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.
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).
ie. "What should the team be working on now"
But equally there are a class of decisions in which developers ought to have the final say:
"how should we implement this" and sometimes "which technology should we use"
I think peer is about right. With an important caveat, that PMs are often ALSO people managers. But that role is separate.
People are going to come to you with unrealistic requirements. This can't be a discussion- you have to say “No, there's no way my team can pull that off, we need to fix this”, and you have to have the relationship and credibility for them to believe you, trust you, and know they can work with you to come up with a solution. That's ambiguously like being a peer that also has the authority or respect to have the final say.
At the same time, you'll find out that every new project starts with the same response from your best developers: “No, I don't think we can do that”. 99% of the time, there's some ambiguous requirement making them apprehensive at a totally reasonable request. You have to have the relationship to firmly say “I'm willing to put in the hard work to figure this out with you”. You should have the credibility that they will have some kind of faith that you can better scope requirements in a way that alleviates their concerns.
If this is how you work today, ask yourself how many devs you work with already feel the way I do? If the devs can't tell you 'no', they have no control, no creative freedom. Put me in that situation, I'll find work elsewhere.
PM's normally do their job via persuasion. They may get push back from the team on certain issues. Their job is report on this push back and the reason for it.
Agree. Accountability is the key here (this is not about authority). If things do not pan out as expected, the PM must be answerable, and to be in that position, [s]he must have the ability to make the final call in most situations.
It's one thing to keep your coding skills sharp, but there is so much to do as a PM other than writing code that will more than make up for the 40 hours a week you gave up by switching jobs. In theory your role as a PM at your company exists because the developers and designers are no longer able to sustain the managerial/organizational overhead coming from team and scope growth.
This really depends on the needs of the organization, but my rule of thumb is to only write code if (1) it's to get data you need or (2) you're bored and can't find anything to do.
As mentioned up the comments, I try to pick up some of the small and boring tasks. Or, as my test engineer is usually overbooked, I pick up test tasks.
- 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.
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."
One basic tool here is to have an explicitly listed agenda for the meeting, with a first cut arrived at before the meeting. New topics ("walk-ons") can be added to the agenda in a discussion at the start of the meeting, or at the end if time permits. It's surprising how many 60 or 90 minute meetings are run without an agenda.
If you run out of time (which is undesirable and should be corrected if it happens often) you can push items at the tail of the agenda to the next meeting.
One job of the manager is to be sure all topics (not just pet topics) get their fair share of attention, and to move the meeting onward when needed.
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]
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.
Years ago I put into practice David Allen's Getting Things Done methodology. While I've significantly customized my own process since then, I still use techniques like immediate capture. When a todo / idea / concern comes up, I quickly capture it in a holding area and get back to what I was doing. Then I intentionally revisit that list at regular intervals to pick off items with my full attention.
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.
It doesn't work as a developer either :)
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.
Dev productivity killers:
* Notifications
* Meetings
* Emails
* Interruptions
Great managers block these. Bad managers cause them.
[0]: https://twitter.com/_ericelliott/status/814082788378804224
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!
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.
"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.
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.
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.
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!
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.
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!
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.
- 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.
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.
- 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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
Communication seems to be key. Ensure you understand and that you are understood.
2) Rightfully Estimating Time Overestimate keeping in mind shipping a feature is usually making it + testing it out a bit.
3) Know what features can be chopped off when push comes to shove.
4) communicate clearly and with as much supporting documentation as possible. We still can't vulcan mind meld. So as a PM you need to convey your prioritised vision to your devs. motivation, how a feature fits on the roadmap, dependent features, Screenshots/ mocks, process flows, test cases to check against, all this will make sure features shipped don't need reiteration.
4) Architect for longevity If you are working with an architect, he will probably be responsible for this. But remember, its ok to delay the initial stages of your product if you are spending time building up the core. Think build systems, continuous integration and deployment cycles, just the API layers and business logic, UI work happening totally independent as functional mocks etc etc.
5) Trying to stay away from the temptation of coding. Code when you need to, assign tasks to yourself as and when required but not as a norm. It takes a lot to see the bigger picture and keep track of so many moving parts of a project. Doesn't help overloading your system with dev tasks too. These two worlds are pretty different beasts.
PS: One tool which I relied heavily on over the last year was Omniplan. We not just tracked dev items, but also things like deployment timelines, adoption rate within the org, training schedules for employees and how all this tied up into the features which needed to be rolled at and at what time. A sample of dev wise sprint plan which helps people plan their workload , keeps meetings to the point, and lets people take vacations when they are relatively less occupied :) http://imgur.com/a/1b2mH
I'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.
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.
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
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.
My advice is to not underestimate the toll that can take on you. Trying to convey the importance of a specific item for a client to a developer is difficult, too, particularly if the dev is already pretty busy.
He also has a book "talking with techleads" which reflects on the question that you have asked!
Don't overcommit.
Address the biggest technical risks early.
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.
* Peopleware
* The Mythical Man-Month
I can't think of better books on managing software projects and software developers.
Be nice if you didn't pull that shit.