31–40 of 109 posts
- 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.
- Avoid scheduling meaningless meetings. Make sure your meetings serve a purpose and are not just status updates. - Encourage communication between different roles. - Trust the developers. I like it when a project manager can talk code but in the end it's the people who are doing the work who should make decisions. - Protect your team from upper management. Don't let senior managers assign work to your team members f…
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...
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 n…
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.
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 proje…
> 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.
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.
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.