Moving on from Time Inc.

In January of 2010, we sold StyleFeeder, the startup I founded, to Time Inc. (additional coverage at WSJ, Xconomy, TechCrunch) and, since then, I’ve spent a truly enjoyable time at the company.  However, I recently decided that I wanted to take some time off to relax and consider the future, so I resigned a few weeks ago and finished up at the end of last week.

Whenever I told people that we sold to Time Inc., I could usually detect that they were somehow reminded of AOL and TimeWarner (worst merger ever).  Sure enough, “And how’s that working out for you?,” they would smirk.  The reality is that it was going great.  In the past year, we built and launched StyleFind using StyleFeeder technology and business relationships.  StyleFind is off to a great start and will no doubt become a major player in the women’s fashion e-commerce space.

The people we sold the company to knew we had created a high-output, super-functional organization… and they weren’t about to screw that up. Mostly, they kept the corporate stuff out of my way and strongly encouraged us to keep doing the things we were good at.  We were in NYC frequently, presenting both to the company’s top management and to the technology leadership.  I know we contributed a lot to Time Inc. and we were treated very well in return.  If you ever have a chance to work for Time Inc., I would recommend it.  And if you are ever lucky enough to sell a company to them, you’ll find that nearly everyone is both intelligent and nice to work with.

I will have a lot to say about StyleFeeder and e-commerce in the coming days, so come back soon.

Some thoughts about Scrum

I was involved in a wee little exchange on ye olde Twitter social medium over the weekend with @dcancel and @pt in which I said I didn’t like certain aspects of Scrum (which, by the way, is a software development methodology).  I was asked to elaborate.

I think Scrum has a lot of good aspects.  I’ll go a step further and say that for most startups and probably most software projects, Scrum should be your default.  You should be required to make a case for not using it before moving to something else.  However, there are two effects of Scrum that I don’t like.

Most importantly, I think Scrum does have a chilling effect on innovation.  Common symptoms of this are people saying things like “Stick to what is in the sprint” or “That’s a super idea – put it in the backlog and let’s consider it during our next planning meeting.”  Innovation and creativity don’t respond well to statements like this.  They appear suddenly and without warning and are opportunities that you must seize and run with.  Damn your plans.  Scrum is part of a family called “agile methods,” and, by comparison, it absolutely is.  Well, maybe sometimes it just isn’t agile enough.  But I guess it depends on what you are optimizing for.

The second thing that I don’t like about Scrum is that if you have a highly functional team that is cranking, applying Scrum to the chemistry of your team will absolutely slow things down.  As lightweight as it is, there most certainly is overhead involved.  Perhaps there are other benefits of having Scrum in place, but speed isn’t one of them.  That being said, Scrum can be fairly lightweight and is probably the most responsible choice you can make in the face of actual methodologies that you can, say, buy books about.

Now, what do I like if it’s not Scrum?

I like goals.  The objective of a sprint (using Scrum parlance) is to complete the specified work.  Hopefully that maps to your overall strategy.  Hopefully that makes your goals a few steps closer than before.  The reality is that reaching your goals are the most important thing, not necessarily how they are achieved.  If you want to boost conversions, increase registrations, reduce latency, etc., it’s way better to stick with a few key numbers that you can measure against and simply chase those until you’ve moved whatever needle you are measuring.  It is very frequently the case that you will have no idea what will end up working for you in terms of actual tactics.  But the ability to make guesses, learn, retry and iterate is going to get you there.  Sticking to a plan and realizing halfway through a sprint that things are Not Going Well is not going to lead to the desired outcome.  And constantly changing the composition of a sprint makes the whole process seem very flimsy.

But Scrum is just a hammer in your toolkit.  Choose it for the right job and it can be very valuable (yes, really!).  If you adopt it during a phase in your company’s lifecycle when you are trying to focus on innovation, consider yourself warned.

Do you have techniques to make Scrum work better in an environment that requires innovative thinking put into practice?