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.
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. :(
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.
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.
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.
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.
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'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.
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.
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.
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.
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 !
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.
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.
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.
Readit News
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.
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.
- 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]
[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.
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 :)
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.
[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.