Brief Notes on Scheduling
Dev scheduling, and scheduling in general, plays quite a big part in my day-to-day work. Everyone comes to me for dates, estimates, status, release details, etc…
So, how does one go about it in a startup without going totally crazy? Well, by avoiding getting sucked in to the details, of course.
I’m really all about macro-level views. I like to keep things fairly hands-off, but know enough about what’s going on that I can provide guidance / assistance when required. The other benefit to doing things this way is, you can handle a lot more because you aren’t trying to manage all of the sub-tasks that sit below a milestone, but you can start to drive communication / efficiencies cross-functionally, which is also a big part of being a successful PM.
There’s an underlying theme with this that I’ve been told a few times by people way smarter than I’ll ever be: if you control the information, you have some degree of influence. I still have to think about everyone creating and sync’ing schedules and how to manage that in the sense of getting folks the right information in a timely manner - helping them execute where I can, and actually executing on your own stuff.
Part of the fun in all this is that no one group in an organization will handle schedules the same way. But of course, a PM needs to get team leads / project leads that are working on release-specifics, on the same page so it can all come together.
It’s a lot of fun, to be sure.
