Sunday
Jun072009
IdeaLab: Risky performance, kill your Netflix, and don't be so certain
Sunday, June 7, 2009 at 10:46PM
These last few weeks have been nutty as I implement my workship plans (see Testing The Classics: A Time Management Experiment: Time Blocking), so I'm going to cheat and share some quick bits I've been collecting on Twitter. Comments?
- Should every performance be an experiment? It depends. If you are beta-testing new ideas, then yes, experimentation is important. It's also risky. However, for mature performances, less experimentation makes sense. But with minimal experimentation comes complacency.
- Want more time, more money, & less stress? Cancel Netflix. Why less stress? Mostly it's the burden of "I've bought it I have to use it." (Question: What's the economic term for this?) I also found myself frequently searching for instant selections that looked appealing. I ended up lowering my standards a lot to match what I found.
- Time management tips from 2nd grade girls softball: a) 2x2: Swings hard vs. Connects. Depends on success rate. Either wasteful or amazing. b) Waits until last minute then swings fast: No planning, pure reaction. OK if intentional and tactical. Terrible if strategic and avoidable.
- Twitter navel-gazing: More than anything else, Twitter's value is as an excuse to make conversations.
- Good Enough is hard to swallow. Good Enough is medicine for perfectionism. It's a reverse application of Parkinson's law. But man it's tough to let go of wanting it just right.
- Uncertainty is a function of experience.
- The unknowns always happen at the end of projects, not at the start. To protect against this, constantly test, and keep your iterations tight. (Credit to my TTL collaborator Liza.)
- Honest but bad: Actual response from submitting a request to a city library: "Our response may be fairly rapid or it may take us many weeks or months to respond." While they're trying to help, this isn't specific enough to matter. Basically it means "Don't depend on anything from us," i.e., they might be a black hole. I'll phone them instead.
- Divergent and convergent phases have their own energy. Continuing the diverge/converge cycles idea, divergence courts discovery, while convergence witnesses birth. Where are you in your projects now?
- Every warning sign has an interesting story. Don't feed the animals. Bridges freeze before roads. Patient loading and unloading zone.
- Before jumping into a response, ask yourself, "How big a deal do I want to make of this?" Some things simply aren't worth it.
- Did you work two days straight on one project? Why was that necessary?
- Amount of time I spend in my outliner: 45%? In browser: 45%? You?
- How do you know what you did actually WORKED? Or didn't. Did you measure it?
- Certainty is dangerous. (Ask Robert Burton). However, does faith = certainty?
- The more audacious your goal, the more painful the process. You buy it?
- Resist the urge to start over completely from scratch (2nd system syndrome). Most often it's better to evolve current version. Agree?
- A reader asks if it's possible to eliminate keeping a master projects list. Well, yes, but it's essentially cheating: Keep a single actions list, but group them under projects (or "None"). This is merging the two, but it's a list trick - you're still maintaining two levels. (See Extreme GTD: How low can you go).
- Don't be discouraged if you wind up at the same place again. You are not the same person as before; you know something new.
- Relationships are projects. Not all, though.
- Relationships are experiments. ""
Reader Comments (7)
>Want more time, more money, & less stress? Cancel Netflix.
I put my Netflix subscription ON HOLD three months ago, and what I’ve noticed is that I’m beginning to miss it more and more. I accumulate movie recommendations, and at a certain point I really get hungry for this kind of input (to put it drily). But the experience of watching video on Hulu and YouTube has, incredibly and unexpectedly, changed the way I think of Netflix: ordering discs is aggravatingly slow. I’m beginning to get the idea that there’s a Kindle in my future for this reason.
> Good Enough is hard to swallow.
Perfectionism is a dodge. When I can’t meet the requirements of a task, I find myself saying, “I want to get this perfect.” I’m lying to myself. If that’s the last excuse in my excuse box, then I never had a prayer to begin with. Time to go back to basics, figure out what I need to learn or practice to execute better the next time, and go about putting a new plan into place.
>Uncertainty is a function of experience
Amen, brother.
>The unknowns always happen at the end of projects, not at the start.
It’s a good aphorism, but as a student of decision-making under conditions of uncertainty, I’m going to quibble: there is a tendency for project managers to enthusiastically seek out the unknowns at the start of the project, then stop paying attention to the unknowns that don’t turn up. And reagrding the unknowns that happen at the end of the project: I guarantee they have their origin in conditions present at the start of the project. Nonetheless: the ends of projects are definitely a time for heightened attention, caution, and care.
>Honest but bad
I love it. In customer service, there are dual precepts: manage your customer’s expectations, and be sure to exceed them. This is a good example of managing your customer’s expectations so far downward that it’s not even worth trying. Try that in a for-profit environment and watch your livelihood evaporate.
>How do you know what you did actually WORKED?
After every mission in the military: the after-action report; periodically: the lessons-learned study. Here’s a corollary question: If it didn’t work, how important to you was it, really, whether it worked or not?
>The more audacious your goal, the more painful the process.
Why join these two concepts? Why not: the more audacious your goal, the more satisfying the achievement? The greater the lessons learned on the journey? The harder to find a single point to start?
>Don't be discouraged if you wind up at the same place again. You are not the same person as before; you know something new.
Real wisdom here. You may also have found the explanation for that other truism: “You can’t go home again.”
The unknowns always happen at the end of projects, not at the start
Agreed, Greenman, better to plan as best you can and hopefully unearth the unknowns at the outset rather than midstream. But even with the best laid plans I continue to find projects grow because of the unknowns. In my business this is largely because we are developing as we go, so we can't know everything. And, that's probably a good thing because we want to get a prototype running quickly so we can learn from it and improve it. Rather than try to solve every problem we think we might have, the theory is that its better to get into the field quickly (Agile development), solving only the core critical problems, and allow enough time for unknowns where we can learn. But who wants to say: "I don't know...", or "We should expect unknowns..."
Since I haven't heard others talk about this, I suspect many consultants or contractors like myself often budget for the "knowns". And then invariably something happens that throws the budget and timeline; a browser bug, more rounds of revisions than expected; some other bug we couldn't possibly expect. But by the time that happens the project is so deep in its hard to explain that we have encountered an "unknown". I am curious, maybe projects need a built-in "unknown" phase? Or perhaps projects a made into mini-projects which are more manageable to control?
Liza, I agree. I'm a building contractor, and what I say to my clients is this: there are some unexpected things that we can anticipate -- here are some of them -- and there are some unexpected things we can't anticipate. Here's how we handle the unexpected when it happens, and here's what your part in that process will be. Here's how we address this in our specifications and in our contract. Here are some stories from our recent experience.
I don't know how software developers normally approach this, but to the extent you're committing to delivering a product with certain performance criteria and are working on fixed price contract, the stakes are high for you. I think you've got to talk explicitly about this with your clients. Some clients obviously won't care, but everyone's better off if this subject gets broached directly.
Having said that, there's no doubt that the unexpected tends to manifest itself at the end of the process. It's rather Darwinian, isn't it? The unknowns you have time to handle don't survive, but when the deadline is near, by virtue of your product having become more robust, only the most wily, sneaky, and unexpected unknowns -- the strongest -- are left. They were probably likely all along, but lurked under the surface of the more obvious, and weaker, unknowns.
(from reader James Ledoux)
Perfectionism is a dodge. When I can’t meet the requirements of a task, I find myself saying, “I want to get this perfect.” I’m lying to myself. If that’s the last excuse in my excuse box, then I never had a prayer to begin with. Time to go back to basics, figure out what I need to learn or practice to execute better the next time, and go about putting a new plan into place.
Nice thinking, Greenman.
the ends of projects are definitely a time for heightened attention, caution, and care.
I'm stealing that one.
a good example of managing your customer’s expectations so far downward that it’s not even worth trying. Try that in a for-profit environment and watch your livelihood evaporate.
That gave me a nice chuckle. A Greenman-style perfect summary.
After every mission in the military: the after-action report; periodically: the lessons-learned study. Here’s a corollary question: If it didn’t work, how important to you was it, really, whether it worked or not?
More goodness; thanks!
Why join these two concepts? Why not: the more audacious your goal, the more satisfying the achievement? The greater the lessons learned on the journey? The harder to find a single point to start?
I buy it.
>Don't be discouraged if you wind up at the same place again. You are not the same person as before; you know something new.
Real wisdom here. You may also have found the explanation for that other truism: “You can’t go home again.”
How about "You can't go home again, and you probably shouldn't anyway." :-)
Great comment, Liza. Thanks.
The stuff we can plan for clearly goes into the plan. The known unknowns (a contradiction? no) are variables we know about from experience. "We may have septic problems. Here's the possible impact if we do..." So how to handle the true unknowns? Beyond padding the budget (in a good way) and using our experience (the previous case), the only thing that comes to mind is a TTL-style rapid cycle of try, test, and learn. Thoughts?