I recently got asked for book recs for new project managers, and I had some trouble coming up with any. It’s a shame, really– most of the books on management I’ve read really haven’t impressed me. And books on project management often are focused on PMP certification, not real-world wrangling of technical people and projects.
There is one that I think is good– Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp. I liked because it was bitter, and true, and realistic. The author also has a blog which I like quite a bit, Rands in Repose, and the book sounds like a collection of blog posts– insightful explorations of particular things– rather then an overview of how to manage humans. I would love, love, love a Rands books that’s an overview of project management.
The particular Rands post I linked to above, The Taste of the Day, has the best description I’ve ever read of how it feels to go from doing technical stuff to managing technical people.
Think of this. You have a job where, whenever you need to, you can find the absolute truth. When someone asks you, “Phil, why is this happening?” you are 100% confident that you can figure out the precise answer.
This is the idyllic situation many engineers on the planet Earth live in, and, well, it’s just a great gig…
Now you have a new job. You have an office and you have a door. On your desk, there’s a timer that tracks the number of seconds that it’s just you alone in your office. Whenever someone else walks into your office, the timer magically resets to zero.
Today’s record for consecutive uninterrupted seconds is 47.
This is not a world an engineer is used to, this interrupt-driven day full of people and political calculus. This is where the reputation that your manager does nothing begins. It’s your manager who thinks it. It’s the close of the day and your manager wonders, “Did I actually do anything today except contend with a constant stream of people coming into my office?”
Minus the office with the door, that’s pretty much what it felt like for me.
There’s a funny thing about the type of advice that people give to you when you’re a new project manager. They give you lots of advice on what task-tracking system you should be using. Getting Things Done is popular, but there are still Carnegie fanatics. Rand segues from the passage I’ve been quoting right into the task-tracking system he uses.
When I was a newbie PM, this struck me as weird and a little insulting. I’m a manager, here. Why are you talking to me about tracking tasks? Talk to me about managing people and projects– that’s what I’m here to do.
I get it now. People give newbie project managers advice on task-tracking systems because:
- They’re trying to communicate how different your new gig is– you are no longer paid to do stuff. You are now paid to organize and track other people as they do stuff.
- You’re going to need to do a lot more tracking now then you did when you were doing stuff, and a good system is an absolute prerequisite for survival.
- Task-tracking is the easiest part of project management to teach somebody else. It’s really hard to explain how to go into a room of angry people, figure out what the solvable problems are, what the necessary actions are to solve them, identify the people to take the actions, and persuade them to do it. It’s comparatively much, much easier to explain how to make a cool task-tracking spreadsheet.
- Talking to people: this includes translating between different folks on your project, calming people down when they’re angry, and getting your team members to explain what they’re trying to do and why it’s not working so that you can understand it and pass it on.
- Keeping your superiors aware of what’s going on: part of talking to people, but crucial and delicate enough to be worth mentioning separately, you need to not waste your bosses’ time, but keep them informed of any crucial problems, without creating unnecessary angst and melodrama and while still reassuring them that you’re on top of things.
- Identifying what’s going wrong: figuring out why something isn’t working, figuring out if it’s fixable, identifying who can fix it, and getting them in a room together to hash it out.
- Making decisions: deciding what needs to be done to solve problems and keep things on track, and deciding which decisions you can make on your own, which you can make but need to notify your higher-ups about, and which you need to escalate up the food chain for somebody else to make.
- Keeping your people going: keeping your team focused, motivated, and on-track, while maintaining the necessary facade of cynicism that is absolutely crucial to keeping the respect of most technical people.
- Tracking information: keeping track of all the bits and bobs of your project, who needs to do what and when, what was agreed to vs what’s being done, bugs and enhancement requests, budget and people and issues and risks that could keep your project from succeeding.
