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!
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.
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.
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.
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.
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.
> -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."
The PM's who have impressed me (as a dev) are the ones who have allowed me to talk to customers directly, so that I can have that exact same conversation.
"Learn the art of minimizing meeting length but maximizing their effectiveness."
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.
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.
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.
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.
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 !
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
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.
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.
It might be that you're better at the management side of things. But don't be tempted just by "grass is greener" thinking: Try to imagine that every job could be hard, that you jump in, discover you don't know what you're doing and you're under a lot of pressure to find a solution, to take action and write documents and schedule meetings and send emails. Will you be motivated to struggle and prevail? More motivated than your worst days in previous jobs? If your response to that is "bring it on," then the shift will be good.
Don't forget that any position that deals directly with clients also takes the brunt of their wrath if they're unhappy. As a non-dev in a SaaS company, I was the primary point of contact for a number of clients and if anything went wrong, I was the first person to hear about it. Clients are not usually pleasant when something is broken or if their project is running late.
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.
I had always been interested in the software development lifecycle. I eventually made the switch from dev to program/project management, in part, because I had worked on too many projects at different companies that failed to ship. I wanted to be part of the solution.
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]
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.
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.
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.
Agreed. Your personal process is incredibly important, and lists or more advanced productivity tools are there to support that process.
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.
It's also harder to proof that you are doing your job if you are in the middle between a few teams. Therefore tracking activity in tools instead of your head is also an advantage. Best is not hand written lists, but official tools that are accepted as serious. E.g. the CRM or the issue tracker.
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.
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.
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.
> 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.
Some PMs wear at times the peer hat. However I believe it is not a good idea to consider yourself a peer. Confusion about roles can lead to conflicts. By design the PM has to have to last word in most critical decisions, especially with outside contacts and that makes one stand out. An important part of the PM role is to say "NO" to all sides - while a peer may say only "no" - and this requires power. How to achieve a power position and how to maintain (wrt. to team but also other parties) it is also part of the PMs work.
Particularly at the beginning I would think carefully - possibly with the help of an experienced peer aka senior project manager - how to divide responsibility in the project. I found RACI (https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.
> However I believe it is not a good idea to consider yourself a peer.
But PMs are peers. PM is not a position of authority. If you are acting as a PM and try to present yourself as if you have the authority to override dev decisions or demand that they do certain things, it might work, or you might breed resentment and hurt your interactions as well as the general team dynamic.
A PM should treat devs as peers and work to reach compromise and get buy-in from key stakeholders. A PM should not attempt to force their vision or plans onto the team. If you can't do the job without being in a position of authority, then you're not a good PM.
I think the difference here is between having responsibility vs acting like the guy with the crown. A manager should respect his engineers and shouldn't tell everybody that the engineers are "his guys" like he owns some slaves.
But in the end he's the one who should be allowed to override an engineer's decision on whether to work on task A or task B, when to pull extra hours and when it's okay to slack a little.
And if he's good he will be able to keep all the annoying meetings away from the engineers, which as well gives him more power over them but also allows them the freedom to focus on the code.
In a good relationship between PM and engineer it doesn't feel like one is on top of the other. But that doesn't mean there is no hierarchy in the company decision making perspective.
> But in the end he's the one who should be allowed to override an engineer's decision on ... when to pull extra hours
No way. I can agree that often the PM has the ability to set task priorities (not always, devs can push back and the devs' people managers will have the final say), but no way does a PM have the authority to decide that a dev should be working extra hours. Absolutely not. That is a pure people management decision (and one that should almost always be decided no).
Simply put, if you are a PM and don't consider yourself a peer, I don't want to be a dev in your organization for exactly the reasons I listed above.
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.
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.
I'm conflicted, because both of these statements are true.
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.
Having worked at some large corporations then have pmos and such. Yes, pm's are normally clased as peers. Devs normally report to a people manager. Pm's dont manage people.
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.
I'd qualify the "convince people that work is important" should be made conditional on it being actually important. Like, I think it's important to facilitate the other direction of information flow by listening to developers, figuring out why they think certain things are more important than others, and advocating for the things you end up agreeing on.
When I made the switch from developer to product/program/project management, the biggest mistake I made was still trying to write code.
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.
And if you're bored and can't find anything to do, please don't take the fun research task that I'm hoping to get to once I finish the important/boring tickets in my sprint. :(
That's one of the hardest thing I do - leaving "fun and interesting, but not critical" stuff in the backlog for my developers.
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.
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.
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.
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.
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.
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.
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.
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 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.
108 comments
[ 3.1 ms ] story [ 167 ms ] threadChances 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.
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.
- 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.
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.
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.
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.
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/
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.
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.
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.
It doesn't work as a developer either :)
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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!
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.
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!
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.
[0]: https://twitter.com/_ericelliott/status/814082788378804224