Understanding 1.0

In your career as a software developer, you’re going to be screwed at some point. My advice is keep thinking, don’t yell, treat those you work with decently, and you’ll be fine. It’s valuable experience, but it’s nothing compared to 1.0.

1.0 is developing the first version of a new product. It’s what all those startups are busily doing right now. They’re working on some 1.0 idea that’s good enough that a handful of bright people will forgo their lives in support of the chance of being right. See, we had a great idea. We’re bazillionaires and we were right.

Most of those startups fail.

Before the Web site Fucked Company, failing was a quiet, somber thing. The dot-com explosion made colossal flameouts front-page news, and everyone discovered what most of us already knew.

Really. Most startups fail.

Why?

To understand the difficulty of 1.0, I need to give you a model for understanding how a 1.0 software product actually shows up. I’ve designed just such a model by heavily borrowing from a theory known as Maslow’s Hierarchy of Needs , which is worth talking about all by its lonesome.

Maslow’s theory contends that as humans meet their basic needs, they seek to satisfy successively higher needs that occupy a set hierarchy, as shown in Figure 22-1.

Figure 22-1. Maslow’s Hierarchy of Needs

At the bottom of the pyramid is the biggest area of need: physiological needs. These are the basics: food, drink, air, sleep, etc. The idea is that you won’t be able to focus on anything else in the hierarchy if these needs aren’t met. Think of it like this: who cares about falling in love if you can’t breathe?

Moving up the hierarchy, you have safety needs, love/belonging, esteem, and finally, the oddly named “self-actualization” tip of the pyramid, which is our instinctual need to make the most of our unique abilities. Translation: Writers write, singers sing.

There’s a fine entry in Wikipedia regarding Maslow’s hierarchy if I’ve piqued your interest (see http://en.wikipedia.org/wiki/Maslow’s_hierarchy_of_needs ). Personally, as a manager of humans, I stare at the hierarchy when dealing with folks on the edge. The hierarchy gives me insight into where exactly a person is stressing out. Are they in need of career advice? (Easy.) Or do they need marriage advice? (Harder.)

Rands 1.0 Hierarchy

In thinking about the difficulties of 1.0, I realized that Maslow’s model applied to shipping the first version of a product. There’s a hierarchy that defines what you need to build in order to ship 1.0, and it looks like Figure 22-2.

Figure 22-2. Rands 1.0 Hierarchy

Note regarding charts and graphs: Phillippe Kahn, the founder of Borland, told a great story about statistics that I think equally applies to charts and graphs. The story is, “Did you know it’s a statistical fact that people with larger feet tend to be better spellers? [Insert awe.] It’s because people with bigger feet are older.”

Charts ‘n’ graphs paint the world in a clean, linear fashion that serves one purpose: supporting the message of the author. Do not trust charts ‘n’ graphs, but don’t let that lack of trust blind you to the intent of the story.

Pitch

At the top of the hierarchy, there’s Your Great Idea. I’m calling it “pitch” because I’ve got this alliteration thing going on. You can’t get anywhere in building a product or a company without a phenomenal pitch. It doesn’t matter if you’re Mr. Charisma; you’ve got to have the idea because it defines the structure and constraints of everything below it. If you don’t have the idea, you don’t know who to hire, which is the second layer—people.

Before we talk about this second layer, let me first congratulate you. I’m tripping over myself happy that you’ve discovered the Next Big Thing, but there are some basic facts to pay attention to. The first is:

Fact #1: You’re in a hurry. Don’t forget it.

You’re a fool if you think you have exclusive rights to your pitch. There are too many bright people staring at exactly the same infinite pile of evolving information to assume your innovation is original. The only thing that gives you this right is delivering 1.0, and first, you’re going to need some people.

People

With your pitch in hand, you’re going to find the people to build your idea. These are your founders. These are the folks who will not only build your 1.0, but more importantly, your engineering culture . Their arrival presents a challenge and a twist to the pyramid.

Your first few hires walk into a blank slate. Yes, they’re believers in the pitch—otherwise they wouldn’t be in the building—but now it’s their pitch, which means they’re going to ask the hard questions because they’ve got some skin in the game. These hard questions are going to help them start making decisions about the eventual products.

As the keeper of the pitch , you’re going to try to stay involved, but you simply can’t be there for every decision. Your job is to listen and watch incessantly so that you can detect how the decisions and actions of your people are slowly changing your pitch. This leads us to our twist. The Rands 1.0 Hierarchy is much scarier than Maslow’s, because it really looks like Figure 22-3.

Figure 22-3. The Real Rands 1.0 Hierarchy

There’s a good reason why folks don’t build their pyramids like this—they fall over. The only way to keep them from falling over is to constantly push one side or the other. This is your startup. It’s an impractical concept with your pitch sitting at the bottom defining everything above it. What will kill you about 1.0 will be how much time you’re going to spend trying to keep this pyramid balanced, which brings us back to the topic at hand: people. Another basic fact:

Fact #2: No one is indispensable.

Now, I’m a people person. This entire book is devoted to figuring out how to make sure folks get along and get stuff done, but we’re not talking about an established company here. We’re talking about 1.0 and the rules are different because you are an unknown quantity and everyone is expecting you to fail.

Ever built a fire? What do you need? A match, some paper, and some kindling wood that catches fire easily. Your first three hires are your kindling. Their job is not to define the product roadmap, their job is to get things moving, and if things aren’t moving, you need to get some more wood.

At my startup, I was brought in as the first engineering manager. The founders had brought on two free electrons with totally different temperaments (see Chapter 43 for more on free electrons). One was burning the midnight oil on getting a working prototype done. He was fully aware we’d throw the whole thing away, but he knew that the ability to see the idea in code would change everyone’s opinion of what we were doing. It would make the pitch real.

The other electron also loved the pitch, but he was working on infrastructure for future products. He was what? Yes, we had no product and one of our key hires was already investing in the future. When is investing in the future a bad idea? How about when the now is not defined? The second free electron was working under the assumption that 1.0 would be successful, and while I appreciated his enthusiasm, let’s remember Fact #0: Startups almost always fail.

I spent some time with the second free electron and, as it often goes with very bright people on a mission, it was clear he wasn’t going to be swayed, so I let him go. That day. One quick meeting with our VP and it was done.

As you’ll learn in Chapter 43, you don’t run into these types of stunning engineers often. Firing a free electron is pretty stupid for most companies because they have so much potential, but here’s the deal: you aren’t a company until 1.0 is done. A great way to topple your fledging pyramid is to hire folks who are not getting the product done with a sense of urgency. Get 1.0 done and then worry what’s next.

Process

There is no word that irks engineers more than process. Try it right now. Get everyone in your office and say something like, “I’ve defined a new process to assist our bug triage.” Watch their faces sag. They hear “busywork.” They think, “management is trying to justify itself.”

This is not the word that defines the third level of the hierarchy. That word is communication.

Fact #3: Process defines communication.

Process is the means by which your team communicates. Whether this is via a wiki, e-mail, or the hallway, any team larger than one needs to define a means to share information. This is not an argument for specifications, documentation, or a whiteboard filled with dos and don’ts. You just need to agree how you’re going to share information.

When your second engineer decides, “Yes, I’m going to capture my design decisions in a wiki,” that’s process. When your third engineer starts tracking bugs on that huge whiteboard in the meeting room, that’s process. It doesn’t have to be good, it doesn’t even have to be universally agreed upon on, it just has to be stuck in a place where everyone can see it.

Microsoft’s SourceSafe was the repository of choice when I landed at my first startup. Stop laughing. It did a fine job with a team of six engineers who had zero time to worry about source control. Sure, it was slow as hell and lost a day’s work here and there because of various hiccups, but we were working on 1.0, and who had time to think about something more reliable?

Roland did.

Roland was a junior engineer and he was a Perforce fan. Roland did what any good employee of a startup would do. Over the course of a weekend, he set up a Perforce server, rewrote all of our build tools, and scheduled a 10 a.m. meeting on the following Monday, promising Krispy Kreme doughnuts. His message: “This is the way it is. Everything works better. Thank you and have a doughnut.”

In a weekend, Roland fixed a major flaw in our process (crappy tools) and also demonstrated another fact of the hierarchy

Fact #4: Each layer shapes and moves those near it.

A sure sign of a healthy pyramid is that one layer invades another. Think of each change to people, process, and pitch as a shove in one direction. This movement requires compensation in the other layers, otherwise the whole thing falls over. Roland’s decision to change the engineering process pissed off some folks. We lost some time to some source management edge cases that Roland hadn’t thought of, but, within a week, we’d adjusted. Even the most vocal opponent of the change ended up in Roland’s office arguing about how we could make it better.

If, in your organization, your pyramid is not constantly adjusting to keep itself upright, something’s wrong. If the new folks aren’t testing the pitch, they either don’t buy it or they don’t get it. If your engineers aren’t arguing about the way they develop software all the time, they’re becoming stagnant, and that trickles down to your pitch and trickles up to your product.

A great stagnation warning sign during 1.0 is when someone decides to create an organization chart defining “This is who does what.” Now, investors and outside parties need this org chart to get a sense of whether you’re real or not, but your 1.0 team does not. The whiteboard in the corner of the room, which lists who is doing what, is your org chart. The definition and hierarchy an org chart portrays is the first step in creating a culture of secrecy in your org. That might work for Apple, but you’re not Apple, yet. You’re hope and hard work.

Product

At some point, you’re going to need to fake being done. You’re going to need to release something that barely looks like your pitch because you don’t have product until a neutral party stares at something.

Fact #5: You don’t have a company until you have a product.

Product is not pitch. Pitch is the three-sentence idea that gave you the credibility to hire the people. The people argued about the pitch, they created process to refine and develop the pitch, and that changed it. The pyramid wobbled hither and fro during all of this. Maybe it fell completely over and you scrambled to stack those layers up again. Good job, there. You still don’t have product.

The neutral parties, your customers, need to see what you’ve been building because all your people are completely insane. All that healthy shifting of the pyramid has been taxing them. Each shove forced them to adjust their perspective of the pitch, their relation to it, and adapting to change is fucking exhausting. Folks who say “I like change” are not currently working at a startup. Folks at a startup don’t say much because they’re busy adapting to the latest pyramid shift.

This state of constant change is the leading cause of startup burnout, and it’s also the reason you’ve got to get that product out. The perspective of the neutral party is essential validation because you’re nuts. Your pitch has been dissected and redefined so many times that it may no longer be something that is useful. A neutral party doesn’t care about the pitch, your people, or any of the pyramid shoving you’ve been up to; they just care whether the product is useful.

Using the Pyramid

At no point will you ever draw this hierarchy on a whiteboard during an organizational crisis and say, “Folks, pay attention to the pyramid—so says the Rands.” The idea is to give you a tool that reminds you, “Hey, it’s all connected!” The pitch guides the people. The people refine the pitch. People and pitch create process and product, and, yeah, it’s all a big mess and that’s why startups fail.

The pyramid gives you a hazy map to think about the problems your company might face. People will yell in the hallway and it might sound like they’re arguing about product, but keep listening, maybe it’s process. Even worse (better?), maybe it’s pitch. Your one job as keeper of the pitch is figuring out which layer of the pyramid is being tested, and then figure out which way to shove the pyramid. This leads us to our last fact:

Fact #6: The lower the failure, the higher the cost.

A year into my startup, the founders were at a crossroads. We were doing an enterprise web application that was built for onsite deployment. Problem was, everyone was going loopy about hosted services. The pitch there was: “Look how much time and energy I’ll save you by hosting this application in my data center, not yours.” This idea flew in the face of years of Oracle, PeopleSoft, and IBM domination of that huge pile of business software and hardware sitting in your data center, but it was the Internet and the Internet was going to save the world.

The founders changed their pitch. “We’ll just create copies of the software in our data center! We’ll save money keeping our bits close to home!” No huge difference there? Wrong. This adjustment to our pitch changed the fundamental architecture of our product. Rather than have hundreds of customized versions of our software sitting in various data centers, we had to have one copy of our software that was configurable to each of our customers’ needs, and that wasn’t the product we designed.

It wasn’t an instant disaster. We had piles of money to throw at this transformation, but the transition cost became so great that we stopped working on anything except getting the hosted application working and, right about then, the bubble burst.

Let’s call “failure” a really bad decision. It’s when you choose to change something and that change percolates up through the pyramid. If you make a bad decision regarding version control, well, you can probably adjust to that. You can fire a free electron and probably find another bright person who can channel the pitch better, but you’re probably going to rattle more than you think. A failure of pitch is a structural failure that affects your entire company Everything in your company depends on the vision that you’ve presented and screwing that up can be fatal.

Building Culture

If you’ve actually got a pitch ready to go, again, that’s terrific. This totally conceptual model I’ve thrown together doesn’t cover some major topics that you need to understand. How are you going to fund this thing? Where do you find VCs? Where do you find great people? Your life will become an endless list of questions and decisions and you’ll probably forget everything I just wrote in your frenetic sprint to keep your pitch alive, so I’ll simplify. The hierarchy I describe is not a model for how to build a great product; it’s a picture that describes the construction of the culture of your company. That’s what you’re really building in 1.0. A lasting, interesting culture that, if you’re lucky, continues to produce great products.

Think of your five favorite companies and think about what made them successful. Yes, they probably had a great 1.0. Think about when you first saw a Mac. Think of the first time you saw Netscape. How about your first useful search on Google? Those products are the end result of people killing themselves to get the damned thing out the door, but these people weren’t just creating that product. Their work defined the culture of the company, and that is what modeled their future success.

And that’s why 1.0 is trying to kill you. 1.0 is expecting you to underestimate it. 1.0 wants you to think all you are building is a product, but the product is merely the outcome. A successful 1.0 is measured by the success of the product that ships, but it is built by a seemingly endless amount of decisions, arguments, failures, and successes that you can’t plan for that will teach you everything you need to know, but are, inconveniently, trying to kill you.