fundamental lessons I have learned from working in informational technology

  1. If you aren’t happy with what you are doing, nothing else matters.  All your successes will lack value. 
  2. requirements are not final until the DRD (ui design) is final
    • requirements are only truly final when ops finishes installing the code to prod
  3. what you will get for HTML is not necessarily what you can use (or expect)
  4. 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)
  5. 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”)
  6. First draft schedules always have you performing full code reviews and addressing issues prior to the drop to QA
  7. Second draft schedules always have you performing full code reviews and addressing issues in parallel to QA testing
  8. a good product manager knows how to tell their business owners no
  9. schedule padding isn’t extra time in a schedule, it is time assigned to tasks you haven’t thought of yet
  10. never let them see you pad your schedule
  11. there is nothing worth saying electronically that wouldn’t be better said in person or on the phone (audience size permitting)
  12. meetings without planned agendas aren’t worth having
  13. it’s never too early to start communicating day-for-day schedule slips (re: PRD/DRD deadlines) - share the joy!
  14. say what you are going to do, make sure everyone heard it and then do it
  15. tell people you did what you said you were going to do when done (follow-up)
  16. too many status reports become noise that drowned out the message
  17. every new client/browser release is going to expose a “bug in your product”
  18. everyone wants to release meaningful, quality products in a timely manner
  19. billing and registration projects always take longer
  20. don’t try to build the perfect system - make it stable, maintainable (operations) and flexible enough to update later
  21. engineering, QA should not be involved in the day to day support of a product after it releases - if they are, you screwed up
  22. 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)
  23. when you have stopped making it worse… ship it
  24. 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.
  25. 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.
  26. 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.

  • Tags