Managing by Milestone
I wanted to let everyone (well…all 1 or 2 of you) in on a little secret a learned recently: there are two ways in which you can be accountable.
You can be accountable for work, or you can be accountable for communication. And yes, there is a pretty big difference.
Now, of course, in the fast-paced “hectic” start-up world where everyone has to be good enough to a) wear multiple hats and b) want to contribute and wear multiple hats and be excited, there are many (if not all) the folks in the company that are both accountable for some work, and some communication. However, I just wanted to post about this because what else are blogs for if not to ramble on until you get something in your own mind?
So, what to do with this revelation. Well, being a product-centric/happy guy, I float towards wanting to be accountable for communication on projects that are not directly product related. This means I favor a setup where you manage by milestone and not detail. Why is that? To me, it’s a boatload more effective to sit down for 30 minutes each week with a team lead, go over key milestones identified at the outset of the project and log the issues as opposed to sitting down for 1+ hours with everyone on the entire team and going through the plan point-by-point.
Why do I care what Suzy is doing on Tuesday of next week? If you do, you might be slipping into a trap of micro-management.
Now, of course, anything I say should be taken with a grain of salt. I know nothing from nothing and am simply a geeky pleeb trying to work all this out and how it can work the best in the scenario I’m currently in.
With that being said, development project management has to be done differently in a small environment in order to work. It HAS to be agile. I’m 100% - no, 1,000% - convinced of this. There is NO other way to go.
My first step? Tearing up any spreadsheet that I had related to tracking dev schedules. What goes in its place? I’m pulling out some flip charts and writing the following:
Product Name - Release Number / Date / Sundial Location / Whatever
- What’s in the backlog?
- What’s been planned?
- What’s in development?
- What’s ready to ship?
I then track the overall status of the release itself. Smiley face / sad face, thumbs up thumbs down, whatever. It needs to be clear, it needs to be somewhat interactive, and developers have to be able to walk over to this thing and scratch their names off, or move a sticky note with a requirement on it to the next grouping (for example, development to ship / qa, whatever) when it’s ready to go.
People love to check their own names / tasks off of lists. I love to see people checking their own names and tasks they have ownership of off lists.
So, let’s throw another kooky wrench into the mix? What if you want everyone to see this schedule so they know what is being worked on when it comes to the life blood of the company (i.e., the products themselves). Well, that’s easy if everyone is ass in seat, in the office. However, that’s not always the case.
I’m thinking a Web cam.
Will this invade privacy? That’s the initial concern. How can you avoid that? Get 1 camera, point it at the dev schedule that’s on a wall in a grid taped together or on flip chart paper taped to the wall.
Oh wow — didn’t I just recommend to violate a cardinal rule of product management? Never, ever give sales specific dates / info on the dev schedule! Blasphemy!
Ehhhh…I’m starting to think it’s not going to matter so much — especially now that I’m dealing in more of a consumer-based mindset. Which, I’m loving by the way (whole other blog post on that bad boy topic).
I doubt any of that made sense. Which is fine. It’s working for me, and in my head it all makes sense. The litmus test will be to see if it makes sense for everyone else that it needs to make sense for. And if I can keep it clear enough in my head that when I start to tape big pieces of flip chart paper to the wall behind my desk.
God, I love my job.
