What's Your Start-up's "Bus Count"? 7 Myths of Entrepreneurship and Programming

(Photo: Stuck in Customs)

For the last two years, one name has come up again and again when talking with A-class start-up investors: Pivotal Labs.

See, Pivotal Labs quietly helps dozens of the fastest-growing tech companies in the world, including freight trains like Groupon and Twitter. If your start-up needs to get good coding done quickly, as in lightning fast — or if new hires need to get good at coding quickly — top venture capitalists are likely to look over their shoulder and confide: “Call Pivotal Labs.”

I first met the Founder of Pivotal Labs, Rob Mee, when one of the start-ups I advise, TaskRabbit, began working with them.

One thing is immediately clear: Rob is obsessed with how to get obscenely high output. But that’s nothing new. Here’s the differentiator: he’s obsessed with how to get obscenely high output with sustainable effort. One of his first remarks to me was “3am with Jolt and pizza can be fun, but it’s a myth that it’s the fuel behind scalable success…”

My kinda guy.

I then posed a few questions:

How do you create a scalable, bullet-proof business? In this case, “bullet-proof” meaning that there’s no single point of failure — it won’t nose dive if any single player (like you) is taken out… or opts out.

What are the myths of tech product creation (software specifically, and entrepreneurship more broadly) that he’d like to expose?

This post contains his answers.

Think software doesn’t apply to you? If you’re in business, rest assured that at least a few principles of good software development most definitely apply to you. Translate them into your world and prosper.

Enter Rob Mee

Software development is a rapidly evolving field that got off to a very rocky start.

Conventional wisdom for many years was that software engineering should be like other types of engineering: design carefully, specify precisely, and then just build it – exactly to spec. Just like building a bridge, right? The problem with this approach is that software is just that. Soft. It’s endlessly malleable. You can change software pretty much any time you want, and people do. Also, since software can be used to model just about anything, the possibilities for what you can ask software developers to do are pretty much infinite. Want to simulate a circuit in software? Go ahead. Run a bank? No problem. Connect half a billion people to their friends? Why not, piece of cake. Not only that, but what we ask programmers to produce changes in the middle of the development, often in unpredictable ways.

This is not bridge-building.

Denying the reality of constant change doomed many software projects, for many decades, to either abject failure or huge budget overruns. So why did an entire industry hew to this conventional wisdom that flew in the face of all evidence? Hard to say. Finally, however, there has begun to emerge a new consensus: software development needs to respond well to change. In fact, it needs to be optimized for change. Nowhere is this embraced more than in today’s web start-up development community. So-called agile methods have gained currency, and the “lean start-up” movement calls for exceedingly rapid change, often automated and based on experimentation with the live system.

So we’re all good, right? Not so fast. In spite of the acceptance of more agile methods, there’s plenty of received wisdom hanging around… and most of it ought to be thrown out the window.

1. Myth: You have to hire “ninjas”.

The myth of the hero hacker is one of the most pervasive pathologies to be found in Silicon Valley start-ups: the idea that a lone programmer, fueled by pizza and caffeine, swaddled in headphones, works all hours of the night to build a complex system, all by himself. Time out. Software development, it turns out, is a team sport. All start-ups grow, if they experience any meaningful success. What works for a lone programmer will not work in a company of 10. And what’s worse, encouraging the hero mentality leads to corrosive dysfunction in software teams. Invariably the developers who do a yeoman’s 9-to-5, week after week, cranking out solid features that the business is built on, lose out to the grasping egomaniacs who stay up all night (usually just one night) looking to garner lavish praise. Rather than reward the hero, it’s better to cultivate a true esprit de corps.

2. Myth: Programmers need to work in quiet, without interruption.

This makes sense … if people are working on their own. Every interruption does indeed break concentration, and it takes a while to get back “in the zone”. Some well-known software companies even insist that each programmer have their own private office. That way they’ll never be interrupted, right? Except that modern-day interruptions have little to do with an actual person tapping you on the shoulder, and everything to do with instant messaging, mobile phones, Facebook and Twitter, email, and the music coming in through headphones that programmers swear helps them concentrate. The reality is that most programmers working on their own only spend a small fraction of their day actually programming: the interruptions are legion, and dropping in and out of a state of concentrated focus takes most of their day. There is a solution, however: pair program. Two programmers, one computer. No email, no Twitter, no phone calls (at least not unscheduled; you can take breaks at regular intervals to handle these things). If you do this, what you get is a full day of pure programming. And “getting in the zone” with someone else actually takes almost no time at all. It’s a completely different way of working, and I maintain that it is far more efficient than working alone ever can be. And in fact, with the current level of device-driven distraction in the workplace, I’d suggest it is the only way that software teams can operate at peak efficiency.

3. Myth: Start-ups run hot, so we’re just gonna have to burn everyone out.

Working crazy hours doesn’t get you there faster. In fact, it slows you down. Sure, you can do it for a week. But most start-ups plan to be around for a little longer than that, and developers will going to have to keep programming for months, if not years, to build a successful product. Many start-ups operate as if the pot of gold is just around the corner; if we only work a little harder, we’ll get there. Pretty soon developers burn out, and simply go through the motions of working long hours without any corresponding productivity. Working intensely, for shorter periods of time, is far more effective. Pivotal has helped hundreds of start-ups build systems, and has done it on a strict 40-hour week.

4. Myth: Looming deadlines necessitate shortcuts.

Many software teams use the excuse of a high-pressure market and the need to ship product right now as an excuse to do shoddy work. Writing tests goes by the wayside; careful design is forgotten in the rush of frenzied hacking. But software teams are no different than other teams we’re all familiar with, and the way high-performing teams succeed is not to lose their cool: on the contrary, when the pressure’s on, you stay frosty, and let your training carry you through. How many times have we heard stories of remarkable performance under unimaginable pressure – whether it be military, professional sports, or a pilot landing a plane on a river – and the explanation almost invariably involves the heroes saying, “We trained for this situation.”

5. Myth: Developers should take ownership of their code.

Ownership sounds good. As American as apple pie. Personal responsibility, right? But “ownership” in a software team implies that only one developer writes – and understands – each module of code. This leads to defensiveness on the part of the developer. It also creates risk for the business owner, since the loss of one person could slow the team, or potentially cripple the business if they were responsible for a particularly crucial part of the system. A much healthier process allows any developer to work on any code in the system. Pair programming facilitates this, because knowledge is passed from person to person. The so-called “bus count” (how many people in your team have to get hit by a bus before you’re all dead in the water) is a critical indicator of risk for the software start-up. And it’s not really a bus we’re talking about here – it’s your competitors, who would love to hire your best developers. The more people who understand the whole system, the stronger and more resilient your organization.

6. Myth: You need a quirky hiring process.

Would you hire an actor without an audition? You wouldn’t last long as a director if you did. But this is exactly what almost all companies who hire software developers do today. Usually the process involves talking through an applicant’s experience with them. And that’s all. Imagine asking an aspiring actor if they enjoyed their role as Hamlet. Did you play him well? Good. You’re hired! Many famous software companies propose brainteasers for their applicants. Some top companies even give candidates an IQ test. The best of them run candidates through a simulated software problem on a whiteboard. This is a sorry state of affairs. I’m going to state (what should be) the obvious: the only way to hire good programmers reliably is to program with them. I run programmers though a one-hour, rapid-fire, pair programming interview – and that’s just the start. Having done it over a thousand times, I can score developers relative to each other on a 100-point scale. What do I look for? Mental quickness, ability to think abstractly, algorithmic facility, problem-solving ability. And most importantly, empathy. Because collaboration is the most important thing we do, and it doesn’t matter how smart you are if you can’t relate to how other people think.

7. Myth: Specialization is essential.

Managers, quite naturally, want to attack problems by dividing and conquering. In software teams, this often manifests as an urge to force specialization. Front-end vs. back-end, database administrators, and so on. Brad Feld suggests in his blog that every team should have one “full-stack programmer”, someone who’s a true generalist. He’s right, but he’s not going far enough. Everyone, in every team, should know the full stack [Tim: read Carlos Bueno’s piece here]. Why? Because specialization makes a team fragile. Remember that bus count? Every specialist is a liability; if they leave, and you can’t replace them, you’re sunk. Not only that, but it makes a team sluggish. Specialists need to make their disparate parts of the system communicate through defined interfaces. In effect, they end up writing informal contracts with each other about how to do it. This leads to a lot of overhead, and often defensiveness or finger-pointing. At Pivotal, every developer works on every level of the system, from HTML and JavaScript, to Ruby, and down to the database. And the argument that specialists will be better at a particular layer of the system if they’re allowed to focus on it doesn’t really hold water. The state of software technology today is simply not that difficult. Programmers are better off knowing all layers and how they interoperate. By the way, another important implication of all this: you don’t need to hire for a particular technology. Ruby programmers in short supply? Fine, hire a Java programmer and train them in Ruby (pair programming works great for this). Someone defines themselves as a “server-side” programmer? No problem, make them do JavaScript, they’ll pick it up.

If they’re any good, that is.

###

Read more about Pivotal Labs and find their collection of tech talks here. If you’re in SF or Boston, try TaskRabbit while you’re at it 🙂

Click here to browse this blog’s other Entrepreneurship posts (covering everything from Twitter and FUBU to selling companies and angel investing).

The Tim Ferriss Show is one of the most popular podcasts in the world with more than one billion downloads. It has been selected for "Best of Apple Podcasts" three times, it is often the #1 interview podcast across all of Apple Podcasts, and it's been ranked #1 out of 400,000+ podcasts on many occasions. To listen to any of the past episodes for free, check out this page.