SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for August 12th, 2010

The Bootstrappin’ Team: All Starters

Posted by Bob Warfield on August 12, 2010

This is my third post on Bootstrapping a Company in the Internet Age.  We started with Bootstrappa’s Paradise where I explained why whether you plan to raise VC or bootstrap your idea all the way, both roads are bootstrapping.  The world will no longer give you a pile of money for an idea, a slide show, and a team. 

This installment is all about what kind of team it takes to Bootstrap an Idea into a Business.  Putting together the right team is a problem you’re going to face right up front, and if you don’t get the right team, your idea is going nowhere.

The Bootstrap team will consist of from 1 to 4 people.   The number, in and of itself, tells us a lot about the Team.   Let’s say we have a cool enough idea and enough motivated friends that we get 4.  Why not 5 or 6 or even 10? 

Remember, the goal of the Bootstrap is to get to cash flow breakeven as soon as possible.  The more overhead, the harder that’s going to be.  But there is an even more pragmatic goal than cash flow breakeven.  Cash flow breakeven sounds wonderful, but let’s be brutally honest.  The Bootstrap Team starves while the company is trying to get onto its feet.  They starve either financially, because they don’t have a Day Job to pay the bills, or emotionally, because they’re trying to do it all while still holding down a Day Job.  They aren’t paying themselves much of anything, so Cash Flow Breakeven can be a bit of a gray area.  Make sure you’re thinking Cash Flow Breakeven after the team quits their Day Jobs and needs a real paycheck.  It need not be a lucrative check, but it has to be enough to keep them going indefinitely.  That’s my definition of Cash Flow Breakeven because until you get there, you haven’t really completed the Bootstrap.  In the end, it isn’t clear that an extra 4 to 6 people on the team, more mouths to feed, will really get you there enough faster to be worth it.

This brings me to my second observation about the team.  They really have to want to do it.  They have to believe in the product and market and have the passion.  It’s not just a Job, it’s an Adventure.  Why else would they starve?  Figure its going to take up to 2 years to get to the ideal of being able to quit your Day Job.  That’s not a short haul.  Maybe you get there sooner, but plan for 2 years.  Some of the more famous bootstrappers talk about spending the first year building product and the second year building momentum.  Yeah, I know, everyone is yacking about slamming together a product in less than 6 months.  That’s cool if you can do it.  But I’m not talking about a free demo.  I’m talking about getting to the point of revenue.  Where someone will actually pay you for what you’ve built.  Yeah, that matters for a Bootstrapper.  Gettin’ paid is important!

Okay, what’s the last thing about the Bootstrap team to think about?  You need a critical mass of starters.  I’ve written about the idea of starters before, and much of my thinking was crystallized after reading 37Signals latest book, Rework.  Starters are people who do something other than manage other people.  They write code, create marketing programs, talk to customers to help them or sell them, and all the rest of the myriad tasks any business needs to get done.  You can hire it out to consultants, but that’s raising your burn rate again and making people starve more.  Some of it you’ll have to hire out.  With a team of 4, you’re not likely to have a bookkeeper or a lawyer to set up the corporation.  But keep it tight.  Ask who will do the key jobs:

–  Product Development:  Who will write the code, test it, and write any documentation you’re providing.  Who is your product visionary?  Who is the UI expert?  Who does the backend scalable server piece?

–  Marketing:  I’m talking about your demand generation and web presence.  Lots to do here.  Who will create your website?  Who will administer your marketing programs?  Who is coming up with the marketing content?  Who is doing graphical design work? 

–  Operations:  Who will deliver the service?  Who will set up and run your data center (trick question: you are wasting your time crawling around cages at a colo.  Put your service in the Cloud!).  Who will do Tech Support for your customers?  How are you fulfilling orders? Who manages the raft of software to do payment processing, order taking, manage customer lists, and whatever else associated with tracking and administering your customers cradle to grave?  You don’t have time to write all that software, it isn’t differentiated, so you have to buy it.  Nobody makes a one-stop suite to do it all, so you’ll be pasting together a patchwork and trying to make it seamless.

–  Leadership:  Who will be CEO, Product Manager, Office Manager, and Den Mother all rolled into one?  Who sets the priorities and directions?  It can’t all be run by committee, though there can and should be a lot of consensus.

Are you starting to get a sense of just how unique a Bootstrap Team is, what they have to accomplish, and how hard they must work?  Think very carefully before you add someone to the team.  The more hats they can wear, the better.  It’s all about rolling up sleeves and getting it done.  You’re sharing a foxhole that’s way forward in the battlefield.  Who’s got your back?

What about Stars?  Why didn’t I call for a Boostrappin’ All Star team? 

Stars aren’t always Starters.  When they are, hire them, by all means.  In my book, the real Stars are also Starters.  But, many Stars are those who are particularly good at managing people as opposed to producing any particular content of their own.  They are tall, charismatic, and went to the right schools.  Guess what?  That stuff doesn’t help you an awful lot to Bootstrap.  You can’t afford the overhead of that tall, good looking, sweet talking CEO if that’s all he can do.  You can’t afford the overhead of the brilliant developer geek who has graduated from coder to architect.  If he doesn’t want to get his hands dirty writing code, he’s not for you.  Send him to a bigger company.  Starters are often much more ordinary seeming people.  It isn’t because they’re less smart or talented, it’s just that they didn’t get there through the skill of impressing and manipulating people.  They got there by doing it themselves.

Beware the other end of the spectrum too.  Bootstrap teams are no place for interns, beginners, junior players, bad programmers, or anyone else that can’t pull a full load.  Nobody will have time to train them, check their work, or fix their mistakes.  You’re looking for the business equivalent of a tiny elite combat team that can be dropped behind enemy lines without money, weapons, or identification and they will make it back alive, well, and ready to do it again.

I’ll be talking next about coming up with the Idea.  Get your team together first, if you can.  I know it helps to have the Idea to sell them, but getting even one other person in the boat will help you to shape the Idea.  Plus, having a keen awareness of the Team’s capabilities will help you know what you can or cannot really deliver.

Bootstrappa’s Resources

Links to the Bootstrappa’s Paradise blog series as well as other useful resources for Bootstrappers.

Posted in bootstrapping | 4 Comments »

Once You Have Bad Programmers, You’re Doomed!

Posted by Bob Warfield on August 12, 2010

I love that line from Paul Graham’s post about what went wrong with Yahoo:

In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

That observation is so true, as is this one:

Theirs was not to reason why; theirs was to build what product managers spec’d.

That’s in reference to Yahoo’s totally Product Managment-driven decision process.  It has seemed to me at times like Microsoft errs dangerously on this side too.  Product Managers are essential, and can be great, but if you place in a role where their job is to hand down stone tablets for the developers to slavishly implement, it doesn’t work.  It is not empowering to the developers who have tons of great ideas, insights, and vision themselves.  But ultimately, it’s just not a good idea to have guys in Ivory Towers thinking great thoughts they have no responsibility or accountability to deliver on.  It’s certainly not much of a team effort when things work that way.  I see great Product Managers as being the ultimate Customer Advocates.  Who else can say that they spend 100% of their time understanding the company’s customers and translating that into product requirements?  The trick is to balance those requirements against other sources of requirements, for example the need to innovate and differentiate, which far more often comes with vision rather than customer feedback.  It takes both as even the brilliant Steve Jobs discovers when his visions get too much at odds with what customers want.

The final great point from the post for me was:

In the software business, you can’t afford not to have a hacker-centric culture.  So which companies need to have a hacker-centric culture? Which companies are “in the software business” in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

Hacker culture often seems kind of irresponsible. That’s why people proposing to destroy it use phrases like “adult supervision.” That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.

Yes indeed, there are worse things than seeming irresponsible.  Though I think the appearance of irresponsibility is only an appearance and comes from suits not being able to understand the hackers.

So let’s say you’re running a company that has Bad Programmers.  Are you really doomed? 

It’s an interesting problem to think about fixing it.  How did you get there to start with?  Here are some thoughts:

–  Like Yahoo, you had a culture that didn’t value Technology.  Great programmers can smell that a mile away and will general avoid it.  I have seen cases where most of a company didn’t value the developers much, but there was an elite core group where great developers could flourish.  It’s often hard for overly sales-driven cultures to value developers as much as they should.  As one friend put it, sales-driven cultures see the Customer as God and Sales as the Church.  There were certainly elements of this at work for Yahoo.

–  You outsourced or isolated your Developers.  This is not a guarantee you have Bad Programmers, but it is a virtual guarantee they’re not really plugged into your corporate culture the way they should be.  Developers can smell this too.  Sometimes they like being off by themselves, but its too easy for it to turn into a Stone Tablet scenario at which point they’re unhappy.  The opposite extreme is the Dev Group that has no customer contact and is just implementing whatever they feel like.  Also bad!

–  The fish rotted from the head.  Bad Leadership is a problem for Developers.  They have little patience for a lot of politics or a weak leader that’s easily snowed.  Dilbert is not a recipe for a great Hacker Culture.

–  Lazy hiring.  You started out with some great developers, but you did a poor job hiring and building an organization.

–  Lousy process.  Smart people abound, but the processes in use are not productive, or worse are destructive.  This is usually a function of poor change control.  If left to fester, you can get spaghetti code from the brightest of teams.

So back to the question of fixing it, and while we’re at it, let’s also look at avoiding it in the first place.  Consider these proactive steps:

–  Make sure your corporate culture values what Developers do.  They don’t call them Software Companies for nothing.  They’re not Sales Companies, Marketing Companies, or Finance Companies.  Make sure you act like it, while also recognizing the huge value these other groups bring. 

–  Keep the Developers well plugged into your corporate culture.  If they’re remote, work overtime looking for ways to make sure they’re still plugged in.  Rotate them through corporate.  Send the right people out to the remote locations frequently.  Never let it turn into a case of micromanagement from afar (Stone Tablets) or no management at all.  Make sure there is strong leadership in the remote locations and make sure the leaders there most of all are plugged back into corporate.  Let me tell you, this will be a lot of work.  You outsourced and offshored to save money.  Welcome to the first of many hidden costs that will make it seem less attractive, though not fatally so.

–  Get great Engineering Leadership.  You need leaders who are inspired, visionary, extroverted, technical, and downright fun to hang around.  They need to be great not just with the developers, but with their peers in the other functional areas.  The leadership, more than anything, has to move the cultural values both ways across the blood brain barrier that often separates Developers from the rest of the culture.  They’d better speak both languages (Geek and Business) to do that well.

–  Realize that Hiring is critical from day one, and it never stops.  I could write many posts on hiring, but I will leave it to one simple observation.   99% of the time people seem to regard hiring as a temporary distraction from what’s really important, such as delivering a product.  But hiring the wrong people will cause you to deal with more kinds of Hell for longer than any architectural mistake you can possibly make.

–  Keep tuning the process.   Start out with the obvious Best Practices, but don’t rest on your laurels from there.  Development organizations have two responsibilities: delivering Great Products and building a superior Software Factory.  They spend most of their time focused on the Products, but like Hiring, the Software Factory is not to be overlooked.  Any given product release is just a battle in the war.  If your Software Factory releases faster than the competition, if it builds better product every cycle, and if it does this more cheaply than the competition, it’s a huge advantage.

One last piece of advice.  If you already have a lot of Bad Programmers runnning around, find a way to isolate them.  Don’t just beg Good Programmers to come in and drop them piecemeal into a pit of Bad Programmers.  They won’t be effective and they won’t hang around.  Start out making sure you have great leadership, and build new groups with Good Programmers.  Preferably do this product by product, and through acquisition of Teams that are known good entities who know how to work together to accomplish great thinks.  Don’t hire Good Programmers and term them into Bad Programmers inadvertently, or drive them away altogether.

Posted in software development | 8 Comments »

%d bloggers like this: