Software Project Mgmt Reading and Blogs…

As I learned in a sink vs. swim situation, I wanted to share some books and blogs that helped me. UP FRONT LET ME STATE: I am still learning and screw-up ALL the time. I by no means have this figured out and would love to hear what works for you guys. We are all students of the human mind and can learn together on how this works.

Books you need to read from Amazon.com I compiled a list there so you can just purchase in whole or pick what is interesting. If you only pick one book be sure it is the Mythical Man Month. It brought home for me the resource vs. task view of the world. Being able to defend your position and schedules is just as important as being able to create them. Highly Recommend

http://www.amazon.com/wishlist/KFGNUDC6KD6C/ref=reg_hu-wl_goto-registry?_encoding=UTF8&sort=date-added

From blogs you should monitor via Google Reader or various other RSS reader…

http://www.google.com/reader/bundle/user/08571077781259521426/bundle/project%20mgmt

Specific posts that made me take pause and wonder what I was doing:

http://37signals.com/svn/posts/902-fire-the-workaholics <– I hate to post this because I find myself being the workaholic. Reading this post again reminds me of why I need to step back
http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html
http://www.joelonsoftware.com/articles/fog0000000052.html <– This one made my jaw drop and TOTALLY change course on how I pitched my projects. It became more about knowing my customer and possible customers lingo before pitching the idea
http://en.wikipedia.org/wiki/Earned_value_management <– Black magic till I started getting smart on it. Better or worse, DoD loves it and if you embrace the data it can set you free
http://www.computerworld.com/s/article/print/9137708/Opinion_The_unspoken_truth_about_managing_geeks?taxonomyName=Management+and+Careers&taxonomyId=14

Tips for Managing Geeks is a big topic in my world. The models you will read in books apply to MBA and more traditional engineering models. Geeks have nuances, this is my mix of all the sites I have read on the topic and many you guys have heard me say:

  • Whoever is right most, is the lead. Period.
  • Know your people! Birthdays, anniversarerys, important events in their lives. Add it to your Blackberry or Google Calendar and setup a reminder. Calling them the day before their 10th Wedding Anniversary does two things: 1 – Lets them know that you see them as more as a FTE/EP and 2 – Reminds them to take time off and buy a card or do something special. Head down during OT periods makes doing that rough.
  • Share credit. When I started giving my teams entire credit they became more willing to charge the next hill with me. Don’t worry about calling yourself out as having done well. Organic recognition, IE your folks see it will last longer.
  • Define vision and expectations. Do not settle for less, do not become mushy on your values and DEMAND compliance. Anything less is unacceptable and will be dealt with. Now with that said your expectations are almost always going to be higher than your team can obtain, so let them shoot for the stars and if they get to the moon than you did alright
  • Lead from the front. Geeks need to know you are a set of useful hands and not a set of beating hands
  • Do not report out on Monday or call an all hands with geeks. Chances are the weekend will provide a set of fresh eyes and geeks need that to tackle a problem. My advice, push customer and leadership meetings to Tuesday
  • If you have never programmed or specifically in the language or technology your teams use, then you will have very little credibility. Likewise your teams have never managed schedule or cost and deserve the same lack of credibility. As a manager and leader you provide the overall vision and will gain credibility by showcasing top coverage for them. Not going to meetings, covering scheduling and reporting…geeks hate that crap and will appreciate that they are not able to do the tasks. What you can’t produce in code you can produce in framework and structure. Just be sure you pickout the head person and develop a relationship of trust to augment
  • Geeks are passionate as evident by their selection of careers. As such there is a challenge to not release as quickly as they report. Chances are the walls will not hold the “my hair is on fire” approach and leaks will occur to your customer or leadership. Let them leak. Because I established a chain of command and RAA (Responsibility, Accountability, and Authority) I always told people “You can take what my staff is telling you and run with it. Until the report leaves my lips or inbox it is all simply hearsay. They have no authority to report and as such your choice to act on their data puts you both in a bad position” That usually woke people up…it puts a LOT of responsibility on you though.
  • Process and beuracracy exist in any company. Geeks hate it, shelter them as much as possible. There might be 10 steps to get something done, but only show them the 2 you need their input for.
  • Management speak should be avoided like the plague. There is no socializing, synergy, energizing, leveraging, or “long poles in the tent” in their worlds. Save it for above blog posts where I mention knowing your customer lingo. Geeks don’t care
  • Train your folks. Every person is usually hand selected, but if you want to grow them then you must feed them. In a bell curve we discipline the bottom 10%, train the 80%, and expect the top 10% to be amazing. When you train the bottom 90% you are reinforcing that it doesn’t pay to be the top dog

Updated: