Archive for September, 2012

“Good, fast, cheap” – all 3?

[tweetmeme source=”chenelaine” only_single=”false” service=””]


Years ago when I inherited my first truly complex, multi-disciplinary program, a beast with 1.5 million lines of code among other things, a wise mentor told me about managing to three things: content, schedule, budget.  Namely, one gets to pick two out of three, and the third item has to float.  

I didn’t realize it at the time but most other people refer to this triad of parameters as “good, fast, cheap – pick two”.   

This is great as long as we are doing armchair product development.  However, in real life, for better or for worse, these three parameters almost always look overconstrained. 

  • GOOD: For any new product or service, intensive customer development will tell us the absolute minimum set of features/functionality we need to provide.  Once you truly grok the buyers and users and have invested in coming up with the short list of stuff they need, it is really, really hard to cut anything off of this list.
  • FAST: To keep pace with today’s fast moving markets and customer needs, everything that needs to be done needs to have been done yesterday, or we risk becoming irrelevant.  One can never release products or services quickly enough to meet the needs and expectations of the business and its stakeholders.
  • CHEAP: There are very few startups (or any other businesses for that matter) where the product organization isn’t short staffed and/or watching the run rate like a hawk. Even if budget is unlimited, there is the mythical man month issue to contend with. The current headcount almost always defines the budget for any internal projects to be done within the next few weeks.

How do we run projects when all three parameters appear fixed? Asking people to do more faster on a going basis isn’t awe-inspiring or effective (at least not if you care about burnout prevention).  

What I find is that while all three look equal, if we take a few moments and think about the situation critically and rationally, we can usually find the one that is less equal than the others. The one that is a nice-to-have disguised as a must-have. With the grace of some corporate will, there is often maneuvering room on this one.

In some cases, it might be that the headcount is fixed (a true budget constraint), and a specific delivery date that are set by external circumstances outside of our control (a true schedule constraint). For instance, if you are in consumer electronics and you want your product to be in physical Best Buy stores for the holiday season, you are going to be showing the buyers a looks-like, works-like product in final-looking packaging in April, together with every other CE product that is competing for shelf space during the same holiday season.  In that case one might have to make some hard choices and cut beyond the MVP feature set in order to meet that date, with a plan to augment the product with additional features and functionality later on (e.g. with software updates delivered over time).  

In other cases, it might be that your headcount is fixed (a true budget constraint), and you need to get enough work done to facilitate a specific workflow for a specific customer or set of customers: your product or service is useless until you achieve critical mass on this workflow (a true content constraint). In that event, whatever the business pressures might look like, you simply will have to negotiate enough elapsed time to get the job done.

At the end of the day, overconstrained projects are self-inflicted problems for an organization.  If we are willing to ask the hard questions, and make difficult tradeoffs with eyes wide open, we can usually find a sensible solution that optimizes the outcome for what truly matters.


Burnout – real or not real?

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I happened upon an Inc. magazine article yesterday, where Marissa Mayer (CEO of Yahoo) is reported to believe that burnout is a myth.

There are some interesting points made in this article, some of which I do agree with and some of which are head scratchers:

  • Burnout has nothing to do with long hours
  • Lots of people work long hours continuously for decades
  • Burnout is more about resentment when work takes people away from things they truly care about – e.g. children
  • To avoid burnout ensure people make time for the things they do care about

The bit about resentment is certainly true. But I disagree with the part about burnout having nothing to do with long hours. Ms. Mayer has superhuman stamina. Most people probably can’t survive a 130h work week on a sustained basis. While I am in awe of her dedication, I rather think this datapoint is six sigmas out of the norm.

The fact remains that if someone is working that much, they don’t have time left to take good care of themselves. They aren’t exercising or eating properly or spending quality time with their family. This is fine when you are 25 and your body can take any amount of abuse and show no bad effects. For those of us who haven’t been 25 for a while… not so much. People get physically sick after a while, either with garden variety colds or with stress related illnesses.

The other thing I find, which seems counter-intuitive, is that when people have things other than work to think about, they think better and perform more effectively at work. This is certainly true for me: I volunteer at MIT and work with students to mentor them on entrepreneurship, and I always find that talking to students helps me refresh my perspective on my work and helps me arrive at new insights that I might not have arrived at without some external stimulation. If I can spend some time kayaking or riding my bike over the weekend, I come back to work balanced and refreshed and able to think more clearly on strategic matters than if I worked both days over the weekend.

So, in short, I think the article is fine and provocative, but I try to be vigilant and take what steps I can to prevent burnout in my team. I try to make people take comp time right after a big crunch, and to the extent possible, I try to regulate the big crunches so they don’t come too close together. It’d be nice if we can plan our work better to head off these big crunches altogether… but that’s a topic for another day.

Twitter Updates


%d bloggers like this: