Category Archives: Constraints

Unplugging (sort of)

This week, we’re on vacation in Cape Cod with my wife’s family.  They’ve been renting the same tiny cabin by the beach for the past 35 years, and coming here is pretty much the highlight of our summer each year.  Last summer, we brought Theo here when he was just three weeks old.  This morning, he and I took a walk along the harbor in Provincetown at low tide — he thinks of each beached boat as a giant bucket, just waiting to be filled with sand.

The problem is, whenever we’re on vacation, I have a hard time finding the right balance between “unplugging” and staying engaged with the real world.  One the one hand, I want to remain connected with work and friends, on the other, I just want to tune out, relax, and be with the people I’m with.  Inevitably, I end up fighting the struggle each day, carving out some time for the important stuff at work, and forcing myself (with limited success) not to stress about it too much the rest of the time.  It’s tough, and to some extent I feel like I achieve the worst of both worlds: neither able to fully enjoy my break, nor be fully present for important happenings at the office.

This has become more of an issue as technology has evolved.  Here at the cabin there’s never been any phone or TV.  Then there were cell phones.  Next, internet down the road at the town library. Then, iPhone and blackberries.  Now, this year we have a mobile broadband connection for our laptops, so we’re as connected as we can be.  For certain things, it’s great: we watched the World Cup final online last weekend, and yesterday my father-in-law did an interview via Skype, which saved him a day-long trip up to Maine.  But, work email and things to do are now within arms reach at all times.

I suppose the vacation case is just a microcosm of the larger question of how to balance real-world face time with online time.  Fred Wilson, one of my favorite bloggers, covers this topic frequently, and I’m really amazed the extent to which he’s able to stay engaged with the networked world without driving his family crazy.  In our case, the family is only semi-digitally integrated; it’s just not part of our culture to always be connected.  Maybe getting an iPad would push that culture change in a good way.

Lastly, I think it also comes back to information fitness — using online (all?) time to do the most important and productive things, and not just consume endlessly as you might in a less online constrained environment.  And of course, one of these days I’ll be able to plan ahead enough so that everything is under control at the office and I don’t have to worry about anything.  But I’m sure if I did that, I’d find reasons to plug back in…

July 14th, 2010

View Comments

Constraints, LifeHacking

Silenced!

Today, I got my first dose of Twitter smack down, as my account was suspended along with a bunch of others following yesterday’s Gov 2.0 Expo.  Ouch!  Well, at least I’m in good company.

As one of the commenters on the Tech Crunch article noted, a situation like this is definitely a bit of a wake-up call about relying on one service for your communications.  I felt eerily powerless this morning when I couldn’t tweet about not being able to tweet…

September 9th, 2009

View Comments

Constraints, Platforms

Chandler and Constraints

I spent most of this morning looking back through old posts about the Chandler Project and OSAF.  I’ve thought about this a lot, due to the many parallels with my work at The Open Planning Project.  For newcomers, those parallels are:

  • Massive funding from a visionary with a dream (in OSAF’s case, Mitch Kapor, in TOPP’s, Mark Gorton), where that dream may not always be perfectly articulated;
  • Rapid staffing around an open source project attempting to satisfy that dream (OSAF’s Chandler to TOPP’s OpenCore /  OpenPlans CoActivate);
  • Due to both of the above, a propensity to expand scope and broaden the potential market(s).

Since Dreaming in Code (the book chronicling the story of Chandler and OSAF) was published in 2007, Kapor has stepped away from the project and pulled his funding.  Through 2008, OSAF operated under his funding, but with a scaled down staff (10 down from ~25).  Long story short, the project failed to get enough traction and was just too expensive. There has been lots of commentary about why this happened, so I’m not really attempting to describe anything new here.

For my own understanding, though, I want to jot down the takeways that seem most relevant to my work at TOPP.  Here’s what it seems that OSAF couldn’t do, and what I’m hoping to do at TOPP Labs:

Choose one market to start with, and satisfy it fully. In Crossing the Chasm, Geoffrey Moore describes a (high tech) market as the following:

  • a set of actual or potential customers
  • for a given set of products or services
  • who have a common set of needs or wants, and
  • who reference each other when making a buying decision

According to Moore, it’s the last one that tends to hang people up — it’s not a market unless the members reference each other.  In other words, you need to focus.  In his “beachhead” (aka D-Day) strategy, he advises putting your full effort into your initial market segment, generalization be damned, and satisfying other users with what’s left over.

If there aren’t any real constraints, create some. If embrace change was the mantra of the XP movement, and embrace constraints is the mantra for web 2.0 startups, then perhaps introduce constraints to create change should be the mantra for over-funded tech non-profits.  Some constraints that are particularly relevant in this case are:  target market (see above), team size, project scope and timelines, and if all else fails, funding.  Granted, it is difficult (but not impossible, IMO) to introduce other constraints when funding is plentiful and reliable.

Don’t get too academic, OR, let the market drive your decisionmaking. This is perhaps just an extension of “constraints”, above, but I think it’s worth mentioning separately.  Looking at the way Things (team of 2 devs) and OmniFocus (experienced sofware entrepreneurs) ate Chandler’s lunch, it’s clear that there was a failure in the product development process.  While the Chandler team was debating database infrastructures and making endless product spec notes in their wiki, Things brought a simple, usable product to 1.0 in just over a year.  They didn’t have the luxury of lengthy debates; they needed to get something out there, get people using it, and get feedback.  Since their 1.0 release in January 2009, they’ve steadily released relevant updates based on real feedback.

Can you be market-based and constrained in an open source environment?  I think so; it just required leadership and understanding of these factors.   It could be argued that Chandler wasn’t able to implement these kinds of changes because of its open source nature and collaborative process, but I believe that it’s possible (and this has been clearly demonstrated) to maintain market focus and constraints in an open source project.

So, now that we’ve got that straightened out, it should be smooth sailing, right?

May 21st, 2009

View Comments

Constraints, Open Source, Planning