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

157 Comments


(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).

Posted on: June 7, 2011.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

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)

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

  1. What you’re talking about is closer to moder Agile development. This is a very mature space in the software industry – mix in some Lean practices such as Kanban – and, you’ll take this to the next level ;-)

    Like

  2. I agree with the author on a few points. Generalists are important but good luck finding someone with all those skills you mentioned (HTML and JavaScript, to Ruby, and down to the database).

    As a developer, I prefer to be skilled in certain areas and prefer my experts to take over the milestones that are important.

    BTW, I like the taskrabbit interface (except for the buttons at the top – hard to follow).

    Like

    • Hey Steve, hiring specialists isn’t an agile approach, you want to internally train people to have a T shape skill set where the developer is a specialty in one but can help out in other areas.

      Like

  3. Very timely Tim, thanks :-) Haven’t been able to afford the ninjas (yet) anyway & thankfully have learned a lot from mistakes at my (killed) job so sustainability & diversification have been top-of-mind…but this really solidifies a lot for me. Thanks Rob!

    Like

  4. I especially like this one myth: “Specialization is essential”. I’m an all-round web developer and designer but unfortunately there are a lot of old fashioned web businesses out there that are looking for specialized people. Of course, you gotta be good at at least something, but there’s more to life than front-end developing. Front-end developing in a team of 10 people. “Don’t touch the PHP”… argghhh.

    Like

    • Yeah so true and great writeup. I’ve been applying for jobs lately and some of the descriptions can be lengthy when one considers what the job may actually entail. Besides all the communications fluff like “ability to work alone or in team”, “good communications skills”, “self-starter” and that jazz, they’d like it if you had 2-4+ years experience in each technology they’ve been using forever because a guy they hired x years ago got them started on something they’re afraid to get off of.

      THIS was actually in an ad I looked at today:
      • Application Development (C#, C, C+, C++, VB, VB.Net, PHP, Java, SQL, mysql, Oracle, PL/SQL)
      • Web Development (PHP, HTML, CSS, AJAX, JavaScript)
      • Database Architecture
      Seriously? So they have no idea what they’re looking for, and they will never find them.

      An interview last week I had for a job was to recreate an existing windows application, which is basically just a big form – onto a website, and they want to use PHP/mysql (my specialty). Turns out, they’d like the application to be able to work on multiple mobile devices (blackberry/iPhone, no biggy), is available offline (outside of cellphone area), and syncs automagically when re-connected or re-entering cell service areas. I didn’t even bother telling him PHP/mysql would be my last choice for such an application. Then he told me I was asking $15,000/year too much.
      And in another interview, “So 4 years direct experience with Drupal, jQuery, and PHP? But zero with script.aculo.us? [Don’t call us, we’ll call you.]”

      Like

  5. MYTH: Startups run hot, so burn everyone out…

    Thank you for saying this Rob. It goes without saying that the mentality of “work till you drop” at startups is pretty pervasive. Sustainable output is key. I personally have had to learn this lesson the hard way. Perhaps others have gone through this model of production….

    1. BIG Idea – Everyone is excited and rallies behind the big idea / product / project. (This is the stage where you and your friends high five each other for being so awesome to think of such a great idea)

    2. Power Sessions – You know the first few steps towards making your product a reality so you pull a few all nighters doing research and placing a few phone calls. (This is the stage when the unsustainable effort is put in)

    3. Stumbling Blocks – The power sessions slowly lose their steam as you hit stumbling blocks. This is when the true magnitude of the project becomes real to you. (This is the stage where your friends start dropping out)

    4. Fizzle and Guilt – Suddenly its a few months down the road, the project is half completed, and no one feels like working anymore. (This is the stage where you are back to being alone with a half-baked idea and no more energy left to push forward)

    Moral of the story? Don’t be like younger me where all my projects were half baked and never completed due to unsustainable output. Pace yourself and set goals. My personal advice? Set ONE objective / feature / task per day and complete it. Most importantly just remember… you can’t fail. (Literally… you made the product / idea/ project up so you can’t fail at something that previously didn’t exist!)

    Like

  6. Timely advice Tim. I’m currently in the midst of building an exciting new start-up that’s already attracting a lot of attention here (in Australia) but the biggest frustration is actually getting it to market quickly and efficiently. I believe in build, test, iterate, launch, iterate etc. We’re getting close to launch but I’m certainly worried about the “bus count”.

    Like

  7. Great post. Makes me wonder what kind of software project your working on. 4HB App?

    I’ve become obsessed with leaning about software development lately and would be interested in hearing your thoughts Tim on non technical involvement in the software process.

    Like

      • Hi Tim, when you launch the apps im interested in learning more about the earning business model behind it.

        Im currently talking to programmers and developers to work out my first muse, which is based on a mobile app as well, would be interesting to talk about this subject.

        my application will source a lot of consumer data and with some back-end metrics and analytics its seriously interesting for certain companies. i believe a lot in social data and next to this it will help people being more mobile :)

        when you find it interesting to talk about and have the time, it would be a pleasure to talk about it, when you dont have the time but do have some expert friends ;) same goes out for them ofcourse.

        many thanks, Pascal

        Like

      • Tim, you’re a genius! Of course, you knew that….

        Man, I have to echo Guillermo when he says, “Tim, please dont leave BlackBerry users out!”

        Can’t wait!

        Like

      • Aloha Tim,

        Thank you for your post about Pivotal Labs. I am in the beginning stages of having CRM software and a corresponding mobile app developed. I contacted Pivotal Labs and quickly realized that I do not have the budget to work with them. Would you be able to recommend any other developers that are less pricey? Please advise.

        Thank you for your time and help, Tim. I look forward to hearing from you!

        Like

  8. I love the interview “audition” very few companies know how to interview in a way that actually assesses skills and whether a person would be a good fit at their company. If you can make them do what they are going to do, you see their skills as well as how they act about what they are supposed to be passionate and successful at.

    Like

  9. The best part of this terrific piece is the fine line Rob Mee draws between useful automation and irresponsible outsourcing of a key responsibility (hiring).

    It would be easy for someone to think that the IQ tests or roadside riddles big software companies use to grab ninja talent are great examples of 4HWW-style automation. But as Rob Mee points out, this is irresponsible when you are expecting to work with the programmer in teams after they are hired.

    Like

  10. Good points Rob and thanks for posting this Tim!

    I’ve been working in a Fortune 500 company for my entire career and the funny thing is – you see folks inside think they are working in a “startup environment”. They almost take this list of myths as the way they operate. A very strange beast to observe, the dysfunction that ensues is hilarious at times. I’ve moved up from programming into management only because the corporate borg has offshored those parts of the business as they are deemed “non-strategic” roles.

    I sit here laughing at myself as I’m now part of the corporate machine, yet in my spare time from family and other interests I dream about and then struggle trying to start-up a side project/product. Other elements are wife, kids, mortgage, etc. I am a generalist: CompSci degree, Oracle/MySQL, Java, html/css/js, and playing with stuff like Ruby, Objective-C/Cocoa.

    Do you have any advice for someone in my shoes?

    Like

    • hey matt,

      I do not know if i can help u from where i am.
      but i think the same thing as u and i do not have all the computer skills u have. i am working in a european french leading bank (trying to help greece and then getting poor S&P grade)

      in other hand, i could be seen as very “creative” or any other words that pop up when u think about people who are not afraid to ask question and make “not common” idea. my wife says that she likes my way of thinking for linking materials engineering and shoes design (for example).

      i really think that guys like us should exchange (like a big brainstorming) to see what we can do in order to pursue our dreaming lines or dreaming way of life.

      we are about buying a small mechanic(al?) company (which is not very well now) i wonder what funny things i can do with a turning machine :) maybe it is not the good way for a muse !

      and u, what are u dreaming line and business projects?

      (by the way i am kind of rugby union and plan to do something about it)

      Like

  11. Great post. I too have found lots of these same situations. Programming doesn’t have to be as complicated as some make it out to be and smaller apps can actually be done very easily and cheaply its actually quite surprising!

    I’d say if anyone hasnt take the time to investigate getting a program done because they believe its too hard or expensive, dont assume, put in some time, get some quotes, you might be surprised at the result!

    Like

  12. Well I am not a programmer. Thanks for these myths. Good points to remember for future reference.

    Thanks
    Leonard

    Like

  13. Tim, and Rob, do you think it’s perhaps worth mentioning that what you’re calling myths do partly depend on the kind of product/project being worked on?

    If you move to more “mission critical” type of software development, like medical, financial, agricultural, etc then you can work through a lot of these “myths” and change them to “depends”. For example lets say you’re working with GIS systems then specialization actually IS pretty essential. Also perhaps don’t ignore that the specialized knowledge required may be more about the product/project itself than the programming.

    Having said that I, and probably every other devhead, look forward to seeing if you, Tim, can 4 hour software development!

    Like

  14. I fully agree with the 40ish hour work week. Ppl need to refuel on their own lifes to feel energetic about work again.

    I disagree about specializing. While one should be well rounded, it takes dedication and focus to be truly good developer even in one area. The front end changes fast and if you are going beyond the drag and drop tools out there and building your own frameworks, you better know exactly what your doing. If you are always leveraging others full frameworks…then sure… know everything so you can glue them together. But even then, most won’t have in depth knowledge and ability to build these systems themselves

    Like

  15. As always your posts are informative and inspiring. Thanks for this one, as for all your others. I am not much of a techy or coder, but I have many friends that will love this article and hear what you have to say.

    Like

  16. Thanks for the great post by Rob. I’ve been fortunate to work at Pivotal Labs (not programming) and it’s really a unique place. The core of understanding everything and working together as a team is great. Withstand that bus! Everybody behind you has your back.

    Like