(Reading time: approx. 3 minutes)
On paper, startup development teams appear to be at a huge disadvantage when compared to the development teams of bigger companies. Smaller operating budgets, fewer people, spartan office amenities, greater project scope and tighter time lines are some of these challenges. Having worked at 5 startups and a couple of Fortune 500 companies, I’ve learned that startup development teams have certain key advantages that can be leveraged to overcome these challenges.
Freedom to question everything
Startup teams have the freedom to question everything. By everything I mean everything.
When engineering teams are allowed to question why they are building something, incorrect or unnecessary features can be changed or scrapped early in the development process. This saves time and results in a better product. In addition, when engineers are allowed to question the processes and tools used to build the product – something even more special happens – it improves the competitiveness of the company in perpetuity.
Innovation at Netflix and Hubba are examples of what is possible if you allow your teams to question the status quo.
Netflix’s engineers questioned the popular notion to “never test in production”. Netflix’s development team built a tool called Chaos Monkey to randomly cause system failures in PRODUCTION SYSTEMS. By purposely causing and recovering from system outages in the middle of a business day (in a carefully monitored production environment with engineers at the ready to recover), Netflix’s team learned more about their system’s vulnerabilities and how to automate recoveries from failures than they could have in non-production environments. All this was done with no impact to customer service. The result? During the massive Amazon Web Service failure in April of 2011 which took down sites like Quora, Foursquare, Reddit and Scvngr – Netflix customers were unaffected.
At Hubba, one of our biggest challenge is integrating data pools containing inconsistent and conflicting data structures into a single cohesive data model. Conventional wisdom says that labor-intensive human intervention is required to scrub and transform the data from these diverse sources (ie. an ETL). Instead, we are building a data integration module that uses introspection and intelligence to discover and correct data faults without human intervention.
Letting your team question everything means that decisions are made with the fewest possible assumptions. This gives you the best chance at a good outcome. Question EVERYTHING.
Access to decision makers
When questions arise during development, how fast does your team get answers? And how often do the answers come directly from the decision maker – in person?
In a startup, questions can be posed directly to the decision maker, whether it is the tech lead or the CEO, in person. No emails, no documents, no human intermediaries. These questions can be as small as “… which directory should I create the security module in?” and as big as “… is feature-x aligned with the CEO’s vision of the product?”. Fewer assumptions are made when you have direct access to the decision maker. This provides the fastest path to building correct software.
Our CEO constantly reminds us that the best part of his day is fielding the important product questions and the subsequent discussions that follow.
A side effect of smaller teams and smaller budgets at a startup is self-sufficient engineers. Each engineer, by necessity, is a subject matter expert on a wider array of subjects. For example, few startups have the budget to hire an engineer dedicated to server administration (or any other supporting role that does not directly contribute to product development). As a result everyone on the team has server administration skills. When someone on the team solves a shared problem or learns a new skill they are shared with the team with the knowledge that everyone needs to be as self-sufficient as possible for the team to succeed. This becomes part of the team culture and gets passed on to new members as the team grows.
Forms, sign-off processes and most documentation generally don’t exist in early stage startups. All effort is focused on building the product. This is not to say that there is no need for formalization at startups, there is. But for startups formalization should only exist where it is absolutely needed. Generally, this takes the form of best-practices related to development topics, such as, naming conventions, test automation, build environments and code repository.
Less formalization improves productivity and team morale. There is nothing more demoralizing than filling out forms.
Smaller teams tend to be closer teams. It’s purely a function of team size divided by time. As a member of a small team, I simply spend more time with each of my team mates than I could with a big team. I can tell you from experience that engineers on close knit teams collaborate more, are more helpful to each other and are more productive. When I am debugging a production issue at 3a.m. I’d personally prefer to be working with a small closely knit team than a large corporate team.
Startup development teams have innate advantages over their counterparts in bigger companies. Successful startups understand and leverage these advantages.
What distinct characteristics does your team have that gives it an advantage over bigger companies? I’d love to hear from you.