I've gotten the gist of these lessons from a software engineering class, HN articles, and from my internship (at the same company), but I'm still not very confident about becoming a great PM. Can you recommend any books or resources that covers more of this kind of stuff?
When your boss asks a question: Be able to answer it. If you can't, figure out how to answer it. Figure out what you need to track to be able to answer it in the future without being asked.
This is where Agility comes in. Not in throwing out Planning. But in being able to respond to Bad Planning by incrementally improving your process and understanding until you've got Good Planning.
You're not going to walk in the door on day one and toss out a plan that lines up actual to estimated hours at 93%. But with that tenacious follow up and follow through you can get there.
And it's not just for the boss. It's awesome as a Developer to know that I'm 50% done. That the requirements have been met for the 50% I've delivered so far and I won't be constantly going back and reworking code because someone didn't put in any effort ahead of time to think this damn thing through.
Rework is the death of budgets, team happiness, and will bring about the zombie apocalypse.
Also, meetings are an important, efficient way to dig through tough problems or keep stakeholders up to date and involved. If you feel like your meeting are wasting time, then maybe you're just not managing your meetings well enough. Or maybe it's because it's not all about you. Maybe it's a little bit about Bob the Developer transitioning off another project that just wrapped up and onto this one, or Trisha the Account Executive who has her weekly status update with the client tomorrow. Or discussing the great success or disappointing failure of spiking this new library.
I think of Development Team meetings like Pool Maintenance. Sure it'd be nice not to pay the Pool Guy to come out and check the water. If you could only pay him for "real work" that'd be great. But that's not reality. And if you're not daily spending 15 to 30 minutes testing the water with a: "What did you plan to do yesterday? What did you actually end up doing? What do you plan to do today?" then you're likely blowing a lot more than the 15-30 minutes * N Developers with people floundering, getting tunnel vision, people who need a helping hand, maybe just need a break, making sure Bob is aware of the utility classes Tammy just developed so he doesn't go off duplicating effort, etc.
It's about fostering communication. It doesn't happen by accident. If you find it's happening and effective without the meeting then by all means re-evaluate. But don't do that before you actually have the data to prove that. Because the risk is much greater than the cost.
And managing risk is what it's all about. You do that right, and your odds of success go up ten fold. That doesn't mean don't try anything new either. It means weigh your options. Timebox. Reinvest in your product and your team, but don't get so distracted you forget why you're here.
That said, I highly recommend The Innovator's Dilemma[0] and Inspired: How to Create Products Customers Love[1]
[0]: http://www.amazon.com/The-Innovators-Dilemma-Technologies-Ma... [1]: http://www.amazon.com/Inspired-Create-Products-Customers-Lov...
Good luck!
0: http://scottberkun.com/ 1: Now called "MAKING THINGS HAPPEN: MASTERING PROJECT MANAGEMENT" http://scottberkun.com/books/#post-52