Friday, May 1, 2009

On Starting Up: Part time soldiers in a full time fight

PTSD (Post traumatic stress disorder) is a syndrome which afflicts soldiers after they have been in a particularly intense war. PTSS (Part time soldier syndrome) afflicts chumps like me who choose to fight part time in a full time fight in the battlefield.

Too much self glorification? Perhaps. But no one's ever alleged I have a deficiency of vanity!

Unfortunately, PTSS is all too real. Today we shall analyze its causes, symptoms and potential cures.

An analysis of PTSS

Summary:

PTSS happens to startup (co)founders who try to start / run a startup while maintaining another full time gig.

Causes:

1) You are too poor to leave your current gig

2) You are too much of a pussy to leave your current gig

3) You are barred by law (and a desire to stay in the same country) from leaving your current gig

Symptoms:

1) An inability to prevent a grisly murder-rape of every single schedule / estimate you construct:

Software estimation is hard. Fred Brooks wrote "The Mythical Man-Month" over 33 years ago. Too bad: to date, a large number of software firms count effort in man-years. Just last month laughed in my head as I heard someone say some functionality that I planned to replicate that week had taken them 20 man-years to build. Three weeks later I am still one week away from replicating it. But don't blame me, software estimation is hard!

Brooks says the reason software estimation is that communication is hard. You can't speed things up by adding members to a development team because the increased communication overheard could eat up all of the advantage of the new pair of hands (or eyes, or brain).

When you're working part time, communication is much, much harder. For one, I meet with three of my engineers two days a week for 10 hours or so. (My decision to co-work on weekends might have been the smartest decision of my career.) My CEO, CCO (chief customer advocate) and I meet once a week. When we are not meeting we multi-task and talk by phone or email. This sucks. Let's consider today. I demoed our system working fully on the Dash today and I screwed up majorly. The how of this screwup is a long story (and another post) but the why of it is - we had agreed upon nothing but that there would be a demo. Had we been working together 5 days a week for 8 (more like 16) hours, I would have gone over to D or S's office with my very first thoughts about the demo and fixed the bug in the design process. Instead I did a horrible demo which affected all of our morale and threatened the very existence of RC on Dash. (Yeah, it went that horribly). I think we've managed to do some damage control owing to the awesomeness of D and S as understanding human beings. But residual low morale will still simmer on low heat till I redo the demo next week. The issue is minor as far as effort goes, all about form not function, but in startups morale is vital.

So this was something as simple as a demo. In an early stage startup, every decision is a strategic one and it all matters. Trying to do this part time is sort of like trying to win a war where co-ordinating units that are part of a strategic assault can communicate only once every day (or worse).

2) A starving second quadrant

Second quadrant tasks means tasks that are important but not urgent. The name comes from Stephen R. Covey's time management quadrant published in his 7 habits book. In any startup, there tend to be significant, potentially destiny altering events every week. A customer demo this week, an investor demo next and so on. If you meet once or twice a week, these things can very very very easily dominate discussion on that day and the direction of your efforts on all other day. But success rate for these meetings is very low for startups, because, well, they are startups. So, if you focus all your efforts on what the customer meeting you next week wants, you'll have made no progress on what the much bigger sized customer who's going to meet you next month but who you know nothing about yet will want. You can't let events in the immediate future drive your overall strategy and direction and you can't change direction every week.

I think we are handling this problem well right now. All 3 of us have been aware of its existence since the beginning and I think have done a good job at avoiding this mistake.

3) The Renegade

The Renegade is that member of your unit who is really good at his job but has a mind of his own. People join startups because they are independent. But like all war situations, only one person can lead. So startup leaders have to be really good at the difficult job of herding cats. Ever try herding a cat remotely? It's next to impossible.

The only way to reign in the renegade (if he's worth keep in on the team) is to listen to him explain to you why you should be going entirely in a tangential direction, then getting his buy in that the direction you want to go in is more important. You'll need to do this at least on a weekly basis. Even then, there'll be times when he won't buy your argument. The test of whether a renegade is worth keeping or not, is what he does when that happens. Does he listen to you and do what you say despite his desire to do otherwise. Or does he do what he wants. If it's the latter, find a replacement.

There are several other problems with fighting part time. Clearly, the fact that this *is* a full time war - that your competitors are writing code while you go to school or write code for someone else - is a big issue, but I'll write about that in a separate post about competition. I'll add more things here if I can think of any.

Meanwhile, what are *your* experiences fighting part time?

No comments:

Post a Comment