“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.”~ Steve Jobs

Jan 25 Five Rules for Building Effective Software Development Teams

The technology startup model in the United States has proven itself a very effective tool for creating disruptive software companies. Despite their relatively unlimited development teams and financial resources large corporations often struggle to match the innovation regularly found in high growth startups. I would argue that the fact that startups are small and nimble, primarily as a result of being underfunded and understaffed, is largely responsible for their success.

That being said, pre-revenue startups, still in the product ideation and creation phase, can be stymied by too many resources. For example, you may remember Color Labs, a company co-founded by Bill Nguyen and Peter Pham. The pair raised more than $40M from Sequoia, Bain, and SVB. Flush with venture capital the team hired more than 30 developers and purchased the domain name “color.com” for $350,000. They spent the next year building a mobile app that no one seemed to want or need. I would argue that Color failed BECAUSE they had too much money, too many stakeholders, and too many decision makers. In my opinion the company was doomed from the start. Color had an amazing software development team capable of building almost anything but they ceded their biggest advantage — the ability to experiment and fail quickly — by building their company BEFORE they built their product. Ironically Google failed to realize their failure offering $200M for the company just weeks before their launch — unfortunately Peter and Bill turned their offer down and the board voted to shut the company down shortly after they launched their mobile app.

In my experience, very early stage startups with more than five members almost always fail. Startups teams progress in ‘fits and starts’ when they’re in the product development phase. Lots of software code ends up on the cutting room floor — the larger the team the more wasted code. But this waste isn’t the real problem — the real problem is a lack of trust.

Small teams develop trust very quickly — trust that is necessary in order to make the sort of product decisions startups must make on a daily basis. In larger organizations trust takes longer to develop and is never universal. This dearth of trust often results in lengthy and torturous decision making processes and results in missed or delayed pivots that are the lifeblood of startups.

Developers, like all humans, have egos and the more of them you have the harder it is to convince them they are headed in the wrong direction and that their code should be scuttled in favor of a new approach. Large development teams, regardless of whether they’re in a Fortune 500 company or startup find it very difficult to pivot and when they do pivot they do so very slowly. For example, the team from Odeo threw away three years of code to pivot from podcasting to messaging — fewer than three developers were involved in the decision. This would have been impossible in a larger organization with a committed software development staff — the pivot resulted in the creation of Twitter and the rest is history.

- Works from the same location allowing for multiple stand-ups throughout the day (especially during the earliest stages)

- Ships an MVP in no more than 90 days and subsequent releases every 30 days (no exceptions)

- Freezes hiring (including interviews) until there is evidence that the MVP has achieved product/market fit based on customer validation

- Leverages third-party APIs/SDKs/Tools (never building anything in-house that can be acquired elsewhere)

There are always exceptions, but in general, if a startup sticks to these five principles during their product development phase they have a chance to build something great. Remember, developers (especially lead developers) always want more developers just as I always want more pizza — the problem is too much of either can kill you. Each additional developer will almost always stymy your efforts and make it more likely that your team will become demoralized, frustrated, and generally miserable.

Finally, I can’t stress enough the value of having an experienced product manager on board from the start — you can outsource QA, design, and perhaps some development work — but you should never attempt to go without an in-house product manager — someone who is not writing code or creating user interfaces. The product manager’s role is to help the team discover and develop the right product for their customers — period. Amit Ashwini from Cognitive Clouds explains it rather succinctly,

Better product managers lead to better products, and with better products in our lives, we all ultimately win. Unlike most other roles in an organization, when a PM stops coming to work, your team might not feel the effects right away. Nevertheless, over time the lack of PM’s expertise will shine through in the products delivered to market. Honestly, almost anybody with a decent technical and business sense can be a Product Manager. However very few can become great Product Managers.

Once you’ve figured out what to build and have product market fit you can start growing your team — slowly. Hopefully, you’ll need to start scaling quickly, but you should realize that you aren’t out of the woods yet. More pivots are coming and with each additional headcount they will become more expensive and more difficult to execute. Always push back when the development team suggests building your own [insert thing] when there is an off-the-shelf substitute that will work for now. Wait until you’re a big company before building your own analytics solution or ad serving solution — the savings or performance boost isn’t a big deal when you’re in the early stages. Focus the team on your core competency and you’ll be able to keep the size of the team manageable.

Remember, the smallest teams can have largest effects and in the case of software development size really does matter.