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 900 million 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.

Leave a Reply

Comment Rules: Remember what Fonzie was like? Cool. That’s how we’re gonna be — cool. Critical is fine, but if you’re rude, we’ll delete your stuff. Please do not put your URL in the comment text and please use your PERSONAL name or initials and not your business name, as the latter comes off like spam. Have fun and thanks for adding to the conversation! (Thanks to Brian Oberkirch for the inspiration.)

162 Replies to “What's Your Start-up's "Bus Count"? 7 Myths of Entrepreneurship and Programming”

  1. I agree. The NDA issue is significant. There is so much information piracy going on that we must be able to protect our intellectual property. Perhaps Pivital Labs will reconsider (?)

  2. I work people i have known for a long time, or locals, where reputation matters, i would never trust some great big corporation with my ideas, in this instance, go for agile launch launch launch and go global global global fast fast fast

  3. Tim,

    I cannot be more thrilled that you have touched so heavily on programming. It was my goal to develop an app for android software this summer and release it before fall. I HAD the motivation and was mentally prepared until it was plagued by the frustration of finding a good starting point. From people I have networked with, they said that programmers do not like to give out helpful hints in hopes of keeping the number of programmers to a minimum. What are your thoughts, because I can safely say with my intentions I won’t be running any programmers out of business. Thanks for resparking the interest.


  4. To the author and crew and the followers that have caught my interest in the 4HB and 4HWW. Thought you might enjoy and inspirational video that gets me up every time. (I did not create this video and own no properties of it)

    Hope you like it.

  5. Thank you for this excellent post from Rob. I’m glad that folks beyond the immediate Pivotal neighborhood can also benefit from the mind behind the company that so many of us take advantage of frequently. I am a happy past Pivotal client and can attest to how well Rob’s advice works in practice. The principles described here translate into happy and solid teams, excellent code, automatic knowledge transfer, frequent releases, and more.

  6. Good thing you busted the ninja myth. For years I have seen all these companies looking for programming ninjas. They want one person to perform the duties of 5.

    Unrealistic is what it is. Besides if you were a ninja, wouldn’t you have your own company up and running? I would think so.

  7. How and where I should search to find a company or person who would like to buy my company (cosmetic branch) or invest in my father company ( fashion, clothes industry)? We have a lot of possibilities (we have our own premises, machines, and well educated staff. I would like to sell my company and focus on father’s company as it is impossible to have a few irons in the fire. The only thing we need is helping hand. After world crisis we lost almost everything. Now, we start again. We rebuild. I wrote to polish Business Angels Club. But any respond. So maybe I will find someone from abroad who would like to make investment in Poland? I really hope I do.

  8. Great post Tim, made my day!

    I am a jack-of-all-trades when it comes to programming and always thought being a master-of-none was a bad thing until i read this post.

    On larger projects when i have to get other developers to help out (project management i guess!), i find it’s invaluable to know all kinds of technologies, 1) because you know which the best technology is to use 2) you know what skills to look for in other developers 3) you don’t get ripped off by developers and know how long projects should take.

    Regarding myth 2 and distractions, I generally work alone (i’m self employed), but find when other people are around i get a lot more done – if i’m in a local coffee shop and i don’t know anyone there, i get into the zone pretty quick for some reason. I am living in paradise (Mexico), and have pretty much given up working when the sun is out during the day – too much fun to be had, so when i do work it tends to be in the evenings when there are less distractions.

  9. Great insights, these ideas can be applied any role within your organization too, example: you can replace programmer with sales.

  10. Hey Tim,

    As a senior software developer I can attest to all points in this post…good stuff!

    Your answer to myth #2 is especially relevant in this day & age. Our team of 4 developers are co-located with no walls between our desks; when we really need to work through a design issue we put at least two heads together and bang out a solution on the spot. No formal meetings or creation of design documentation can get things done any more efficiently than that.



  11. nice, pair programming is cool and works, but engineers who know how to throw ninja stars do help a lot as well.

  12. many, many good advice known from ouselves experience put in one book and one bloog. excellent. like wikipedia : )

  13. If employees can’t stay off Facebook on their own and need pair programming to prevent them from goofing off, I think you have bigger problems.

  14. Very good article, especially the “full stack” developer part, which makes any company ready for rapid market change and adaptation.

  15. I have just come across this site, and finding it interesting and informative

  16. love the article.. the author is awesome… i really enjoyed the myth and also well written.. made the bookmark for more articles

  17. In Agile development it’s a good practice to limit the number of features the team is developing at one time. Let’s say the team can have only 2 features in process at one time. For the team to be effective developers should know how to work on all the tasks and layers of the design. Agile teams consist of cross-functional people with cross-functional skills.

  18. I’m trying to set up my tennis consultant business online here in kobe japan and put it on automation, I some of the things apply for me too, thats. Great blog.

    Happy Holidays.


  19. Really Knowledge post for me. Sometime after reading this type of knowledge post we feel that only professional can write this. Overall thanks for your info

  20. I’ve hired on oDesk for my app and was very disappointed.. Worst piece of code I’d ever read. Had to redo everything on my own. So my advice would be keep the feedback loop as short as possible. Check progress all the time. If you can code or prototype visually (Xcode) that’s definitely a plus.

    [Moderator: link removed]

  21. I really do thing specialization is important at least because it does allow the boss to be good at one thing, and then outsource the rest of the activities of a business.

    Although, on a certain level, they don’t have to be specialized to the point of being a super-power in their field, since that would inhibit them from doing a good job managing the business.

    And yes, I love hiring programmers and then training them in a similar field so that they can grow with the business.

  22. Go away. Calling some of these things “myths” are what is killing my profession and my productivity. I have had enough of you self proclaimed gurus in how to make actual gurus obsolete and replaced by cogs in a purportedly better machine.

  23. As a software engineer, pair programming is great when you need to pull someone in to help solve a very narrow, difficult problem otherwise it feels like you are giving me a nanny to make sure I don’t go on Reddit. Pair programming creates feelings of resentment or insecurity within a team because one half of the pair will always feel like he’s doing more or doing less than the other person. Pairing 2 lazy, mediocre programmers together does not a good programmer make. Most projects don’t consist of difficult problem, after difficult problem to solve.

    The superior programming environment is where any one who is doing engineering sit within speaking distance of one another but not strictly forced to work together. Then people can think out loud with whoever is available to listen, can break off into a pair to solve a problem if need be, or continue to stay focused on a problem they have already figure out. You don’t need two people to set up Postgres for the 1000th time in your life, or wait while that EC2 instance boots up, or any other problem that for a good programmer should be a little bit of mental down time while they regurgitate a solution to a problem they first pair programmed the solution to 10 years ago.

    It sounds to me like Pivotal Labs has forsaken the HR process of finding an actual good, competent engineer and solved it by duct taping two mediocre engineers to one keyboard. Pivotal labs doesn’t sound like a place I would ever want to work, or ever contract out work I had to.