After the seed round funding, many startups are ready to hire their first software development team. In a study, 23% of small businesses fail because they don't have the right team. So, how to build the right team for the early stage startup?
This is a series of 3 articles where I describe setting up a team at different stages of an early stage startup, growth stage, and mature company.
In this article, I show you the key concepts of setting up a team for an early stage startup.
Early stage startups should treat the team as the means of delivery and software development as a process.
Team as the means of delivery
Hire the top software engineers in the town!
As a founder, you are excited about hiring some good engineers to be part of your very first team. I agree with you that hiring a good engineer does speed up the delivery in the early stage. However, I've seen the case of the best engineer in the team struggling when the team grows big.
Google conducted research about what makes a team effective. The conclusion is how the team members interact, structure their work, and view their contributions matter more than who is on a team.
If your startup doesn't promote the team-first mindset, your best engineer who is used to working as an individual will find it hard to share responsibilities with the new team members.
Also, a team of product-minded engineers who understand the product makes an effective team.
Team-first mindset
In Team Topologies, the author expressed that the team members should put the needs of the team above their own. They should:
- Arrive for stand-ups and meetings on time
- Keep discussions and investigations on track
- Encourage a focus on team goals
- Help unblock other team members before starting on new work
- Mentor new or less experienced team members
- Avoid "winning" arguments and, instead, agree to explore options
You can count on the team to do high-quality work on time and align with the company mission.
Product minded
Product-minded engineers want to understand why decisions are made, how people use the product, and love to be involved in making product decisions.
When making engineering tradeoffs, they consider from the user perspective and suggest a suitable solution without sacrificing product impact.
Dunbar's number
Dunbar's number suggests the limit to the number of people you can maintain stable social relationships.
By referencing Dunbar's number, Team Topologies recommends:
- A single team: around 5 to 8 people (based on industry experience)
- Families ("tribes"): grouping of teams of no more than 50 people
- Divisions/streams/profile & loss (P&L) lines: groupings of no more than 150 or 500 people
Software development as a process
Last year, Michael Sibel, CEO of Y Combinator, shared that slow product development is 1 of 5 things that kill startups after their seed rounds. No process deciding what to build is one of the key problems.
Agile software development is a set of practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.
Agile software development advocates early delivery and flexible responses to change, which perfectly fits startups.
As starters, Scrum and Kanban are beginner-friendly.
Team
Team and process are the keys to building the right team. Early stage startups should start with a relatively small team and expand as needed.
Team of three
Team of three is a relatively small team that is capable to design, develop, and operate the product.
For starters, you should start with three people as a team. In this team, two software engineers and one designer would be ideal. The two software engineers should have the knowledge of turning the design into a product and releasing the product to the users.
Kanban
At this stage, Kanban is the ideal framework to manage the software development process.
Kanban is a lightweight workflow management framework.
On the simple side, you have three columns named To Do, Doing, and Done on your Kanban board. You start by adding a new card to the To Do column. You move the card to the Doing column when you start the work, then move it to the Done column when you are done.
On the complex side, the different stages of the development process are shown as columns on your Kanban board. Examples like Backlog, Ready, To Do, Doing, Review, Testing, Shipping, and Done.
One of the Kanban principles is to start with what you do now. To begin, you create columns based on your current process (if you have one now) and add new columns as needed. Otherwise, I highly recommend starting with the Kanban template (remove the Code Review and Testing columns if you don't need them now) or any of the Trello board template.
Team of eight
When your startup starts attracting more customers and receiving more feature requests. The team of three needs to be expanded to keep up the pace.
At this stage, you consider hiring more specialists, like ops, web, or mobile developers. The goals of hiring are filling up the technical gap and increasing development throughputs.
While adding more members to the team, don't forget about the suggestion from the Team Topologies. Based on the industry experience, the recommended maximum team size is 8. Any number higher than 8 is recommended to split into two teams. I will write about splitting the team in the next article.
Kanban or Scrum
Communication becomes harder when the team becomes bigger. You'll realise the communication cost is higher with a team of eight than a team of three. However, your early investment in the software development process starts to pay off.
If you are doing good with Kanban, I recommend you to continue practicing it.
If you find Kanban is too flexible, you can consider Scrum.
Scrum is another agile framework and it is more suitable for people who like a more structural way of working.
Unlike Kanban, Scrum time-boxes the development cycle within 2 to 4 weeks, which is called Sprint. In each sprint, there are few events are necessary to help you develop software:
- Sprint Planning - At the beginning of the sprint, the team plan the works to be done within a sprint
- Daily Scrum - Every day in the sprint, team members show up at the same time to communicate their plan of the day
- Sprint Review - At the end of the sprint, the team review what they have developed with the stakeholders
- Sprint Retrospective - Before ending the sprint, the team sits together to identify what can they change to improve their effectiveness
In my past startup life, Scrum gave my team a structured process of delivering software. Sprint Planning and Daily Scrum aligned my team towards the company goals. Sprint Review and Sprint Retrospective gave my team the space for improvement.
Summary
To build the right team for your early stage startup, you should treat the team as the means of delivery and software development as a process.
To begin, you start with a relatively small team of three and adopt Kanban as a software development process.
Then, you expand to the team of eight when necessary and either continue mastering Kanban or change to Scrum for a more structured software development process.
