winfred.nadeau

Great software speaks for itself.

Avoiding Rabbit Holes With a Time-box of Focus

originally written April 15, 2015

We recently spent several weeks researching what Hired could gain by disrupting the market for CSS frameworks.

The logic was pretty reasonable, as most rabbit holes appear innocuous on the surface.

If we can supplant twitter bootstrap, we’ll have a really interesting opportunity to generate a virtuous cycle of growth for our company.

Developers would be exposed to our brand in warmer value-driven context than that of “hey do you want to change jobs?”. Further out, we could even have a really firm grip on the entire hiring market for frontend UX. These are the makings of a monopolist’s wet dreams.

Are we ready for such a moonshot?

Together with our senior frontend engineer and true wizard of CSS, we set out to validate or invalidate this possibility that had been plaguing our minds for much of 2014.

The default time-box is your review cycle

Reviews happen quarterly for us at Hired, and we were lucky we got started mid-quarter because I’m honestly not sure if I’d have thought to pull my head up for air without the review cycle reminding me to do just that.

An unfocused time-box is not a time-box.

As time and space are inexorably linked, a time-box without space to focus collapses under its own weight. Truly, a black-hole of product development can form if left unchecked.

We made the mistake of trying to juggle other feature requests at the same time. Switching contexts is expensive and it definitely made it harder for us to be scope-cutting ninjas on a quest for a strong MVP. We can’t even really say how much time we spent focused on a primary objective because we were so scattered.

Be ready for a tough decision at the end of the time-box.

At the end of our time-box, it became clear that the technology to meet our vision simply wasn’t there yet. (Well, without going deeper down the rabbit hole and potentially re-writing lib-sass.)

As a business, this moonshot proved a little too out of reach for the risk involved, so we made the decision to stop development on the open source project.

The best X divorce their ego from Y.

You might be tempted to think: “But what if this demoralizes everyone?” In my experience, teams that transparently confront the sunk-cost fallacy head on actually have a boost in morale.

How much worse would it have been if we hadn’t had a line tethering us to the surface or had a manager pushing us even deeper despite growing doubt?

What do you think?

Did we make the wrong decision from your perspective? Are you personally facing a tough situation like this?

I’d love to hear your thoughts or questions! Hit me up and let’s chat.