1. If you aren’t happy with what you are doing, nothing else matters.  All your successes will lack value. 
  2. communicate aggressively; stop by/call, IM/Skype, email – out of sight is definitely out of mind. It’s up to you to get your point across and ensure people understand it.
  3. requirements are not final until the DRD (Design Requirements Document – ui design) is final
    • requirements are only truly final when ops finishes installing the code to prod
  4. what you will get for HTML is not necessarily what you can use (or expect)
  5. no matter how long it takes to define the project, dev has 1-2 months to build it (QA/QE has a couple of weeks to test)
  6. When not in meetings, 50% of your time is spent modifying (fixing) code you inherited (asking yourself why someone did it that way) and the other 50% is building something that will eventually get handed off to someone else to modify in some future release (luckily they will benefit from your insight into “doing things right”)
  7. First draft schedules always have you performing full code reviews and addressing issues prior to the drop to QA
  8. Second draft schedules always have you performing full code reviews and addressing issues in parallel to QA testing
  9. a good product manager knows how to tell their business owners/stake holders no
  10. schedule padding isn’t extra time in a schedule, it is time assigned to tasks you haven’t thought of yet
  11. never let them see you pad your schedule
  12. there is nothing worth saying electronically that wouldn’t be better said in person or on the phone (audience size permitting)
  13. meetings without planned agendas aren’t worth having
  14. it’s never too early to start communicating day-for-day schedule slips (re: PRD [product requirements doc]/DRD deadlines) – share the joy!
  15. say what you are going to do, make sure everyone heard it and then do it
  16. tell people you did what you said you were going to do when you are done (follow-up)
  17. too many status reports become noise that drowned out the message
  18. every new client/browser release is going to expose a “bug in your product”
  19. everyone wants to release meaningful, quality products in a timely manner
  20. billing and registration projects always take longer
    • ANY project that requires integrating with anyone else will take longer
  21. don’t try to build the perfect system – make it stable, maintainable (operations) and flexible enough to update later
  22. engineering, QA should not be involved in the day to day support of a product after it releases – if they are, you screwed up
  23. build tools into your design/estimates from the beginning (it’s easy to remove them if push comes to shove, but hard to add them in)
  24. when you have stopped making it worse… ship it
  25. enumerate all the options based on facts.  If the choice isn’t obvious, let emotion or strategy be the deciding factor.  The politics is in knowing the difference.
    • Don’t forget option 0 – do nothing
  26. every company is the same.  They all think they are complex beasts doing high-end work and their processes are more backwards/complicated than anyone else’s.
  27. when asked, worker bees will complain about bureaucracy.  The powers-that-be will swing the pendulum and reduce the required artifacts.  Generally, the artifacts are good.  It’s the process to get milestones approved that is bad.  Process improvement should be about improving the transition of phases, but it never is.
  28. the best process describes what people are doing well that you want to repeat
  29. people defining processes don’t generally work on projects that follow their processes – these processes suck
  30. On delegation: You will reach true success when you have nothing to do, but accomplish more than others.
  31. be selfish – make sure you get done what you need to for your commitments before helping others. The ideal is that you can slightly modify what you are doing to help others
    • if it’s obvious the other priorities are more important, make that case and change expectations. There will always be ‘hills to take’ or stretch assignments. Don’t let others make that the norm.
  32. Initiative is not given, it’s taken; Do not wait around for others to tell you to put out a fire or be handed a baton. Stomp on the fire! Take the baton!
  33. Projects don’t go wrong, they start wrong
  34. Stewardship vs Command and Control; Stewardship where you focus on growing, shepherding, evolving something delivers the highest value; Command and control is a tactical reaction to not knowing what to do
  35. Line of Sight Empowerment; Delegate authority to people with the clearest line of sight. They have the best vision to see what to do. They are different people  in a valley or on top of a hill.