Our bizdev guy jockeying for the top spot. FAIL! 
I’ve been involved in no less than two dozen software or Internet-related launches in my career. Having just finished the initial launch of StarPound, I thought I’d drop a few notes here about launching. This post will ramble a bit, as I am still really decompressing from the launch.
I will preface this by saying that no matter how many times you’ve launched stuff, you will learn something new each time. Embrace it!
The Launch Date
Putting a flag in the ground and declaring the date to the whole team is a big motivator, but it can be risky. But just do it. You can’t hit a date unless you first have a date to hit. And your team has to have input and buy-off on that date. It should be a stretch goal, otherwise, it is meaningless.
“You can’t hit a date unless you first have a date to hit.”
If your engineers are telling you it will take 60 days, set an internal date of 45 days. Get everyone motivated to hit that date. If you are excited about things, they will, in turn, get excited about those things and will become superhuman during the last two weeks leading up to the launch.
But be careful about publishing your engineering date to the market … :) You really need to know your engineering capabilities and what pitfalls might crop up ahead of the launch - otherwise, you could be setting yourself up for embarrassment.
And of course, don’t commit the whole team to a date and be “that guy” (or gal) that does’t do anything to help them get there. Which leads me into …
Don’t be Afraid to Get your Hands Dirty
If your the type of leader that likes to sit back and delegate, you shouldn’t have left your nice job at Bellsouth (unless you had no choice, of course). Funny thing about people - they respond very well by being lead from the front, and not the rear.
Back when I was in the Army (under Reagan - sheesh I’m getting old) there was this one Lieutenant that all the guys wanted to serve under. Young guy - green as hell - but he got his hands dirty. He wasn’t above pitching in to get the job done. Whatever it took.
When I arrived in Germany to my line unit in 1987, my new platoon sergeant has to break me in, so he dogged me and made me serve motor pool duty for a week - in the cold rain - scrubbing a whole fleet of original 105MM M1 tanks that were covered in mud (they had just come back from a big field exercise). While the more veteran guys walked by me hazing me for being a new recruit, this Lieutenant walks up and asked me what I was doing. I told him. He took his parka off, rolled up his sleeves and helped me wash every single tank on the line. Most of the other officers were lame in comparison. This guy gave a sh*t about his team, and we responded in kind. We would have walked through the fire for that guy - and some of us did.
In any startup, people are expected to wear multiple hats, each and every day.
Delegation is a fine skill to have, but you have to earn the right to use it, and you earn that right by leading from the front, not the rear.
If someone has a problem with that, you need to get rid of them - period - because they will kill you in the end, one way or another. I recall one day a few weeks ago where my schedule roughly consisted of the following tasks:
- Morning status meeting with the whole team
- Writing PHP code for our new web site
- Biz Dev: meeting with a new Fortune 500 customer
- Meeting with potential investor
- Using Photoshop to create new buttons for our app
- Market research - then working on marketing packets
- Interview new sales guy
And this was just my schedule. Other people had it much worse. If you cannot willingly wear multiple hats, or you don’t have the skills needed to wear multiple hats, you have already made your journey that much more difficult. If you really don’t have the skills to help out in other areas, make an effort to learn. It’ll make you a better leader in so many ways.
In short - delegation is a fine skill to have, but you have to earn the right to use it, and you earn that right by leading from the front, not the rear.
Sales and Business Development
Don’t ignore the sales effort while you are prepping for the launch. You don’t want to wake up with a nice launch, and no one to show it to. If you aren’t balancing sales and business development calls with launch-related stuff, you are heading down a very slippery slope. The technology dead pool is full of companies that blew their wad on great launches, but they ended up mostly being “all hat and no cattle.”
At the same time, don’t distract your engineers with too much sales support - they need to stay focused on the task at hand, which is getting product to market. if you do need to tap your engineers for sales support, try to streamline their involvement as much as possible. Do you really need to drag your whole development team into a pre-sales meeting? How about just the CTO? Another approach is to set aside a certain block of time each week that they can be available for sales support, rather than ad hoc’ing everything.
Patience.
People will miss things, so accept it now - certain tasks, even critical ones, can get lost in the noise. You’ve gotta stay on top of everything and everyone. And guess what, you will miss things, too. Get over it.
Your team’s level of motivation and attention to detail is going to have a fairly direct correlation to your ability to keep things moving forward, despite the cyclone spinning around you.
The 90% Solution
This is something I’ve espoused for a long time, and it is rarely more fitting than when you are trying to launch something new. The 100% solution is never attainable - so forget about. Strive for 90% and try to get that part right. The rest will come in time.
If you had a splitting migraine, would you pay someone for a pill that solved 90% of your pain, or are you willing to suffer in misery while they work on the pill that solves it all?
Cheers.
