Bootstrapping And Growing Your Tech Team

So you’re a technical founder of a young exciting startup. You’re expected to take technical role and build a team to build the product. So how we’d start?

The founding team

When you build a team, there’s one common pattern on founding team: they are focusing on speed and time to market. As a tech founder, you might find this at odd with code quality, and that is right. We always strive on confidence on every build. In ideal world every build should have unit tests, integration tests, stress tests and then delivered to customer, but in a lot of cases, it’s mutually exclusive with time to market. So how to tackle this issue?

Step 1: Define Your Product Team

The good thing about startups is team is usually small and communication is easy. During this good time, it’s important to define the role of the product team to cover every facet of product development lifecycle. I usually divide the team to 4 big chunks.

Every person needs to take or assume one of the role. Every product team that I’ve built or I helped to build usually consists of those four roles with different titles. Every single person on the startup that consider themselves as the product team needs to take one of the role. The roles are divided this way to give a clear ownership of every step and facet on product development. Let’s take a look:

1. Product Owner is usually assumed by the guy that know the business process and rules on the product. In early stage, often this role usually taken by the CEO. This role owns the product features and the priority.
2. Project Manager is the guy that focuses on getting things down. This role owns the timeline and resources.
3. Developer is self explanatory. They code the product, they make dream comes true. This role owns the code and infrastructure.
4. Quality Assurance is the gatekeeper. They must be the fiercest defender of the product quality.

This role division also serves as a guide for future career path. All four of them need to be equal, and nobody should serves in two roles in the same time, because the nature of division is to provide balance.

The reason I draw line over them is to illustrate the tug of war or tension that needs to be maintained. The team breaks apart if one party too push in or to push out. We need to maintain the strain just enough to make the team works.

Step 2 : Lay out process and tools

A product success chance can be increased by adhering process. A popular framework is agile processes such as scrum or kanban. Choose one and stick to it, if one does not work, switch and try. Attend a training or learn the video together with the team. Talk with other companies who do similar process. Although many people start to declare the demise of the agile. At the moment, it’s the only available process framework that have and still works.

As a technical founder, we’re also expected to lay out the engineering process because it’s your domain. You’re expected to know and do things like code review and automated build. If you lucky enough you may be able to create a continuous delivery/integration/deployment process.

The tools I usually use are as follows:

1. JIRA Software — I use it to organise user stories and to know the visibility on the project.
2. Test Rail — I use it for QA team to create test suites and test cases for our products.
3. GitHub — Everybody knows it, it’s hands down the best place to place the code.
4. Travis CI — it’s tied with GitHub, it provides easy automated build tools for your CI and CD needs.
5. Fabric.io — as majority of the team I’m involved with is mobile team, fabric gives us flexible platform for distributing beta and getting crash logs.
6. Instabug — for instant bug report, it also reports crashes. I use it for the beta testers.
7. Amazon Web Services — a very popular cloud. I’ve tried many others too, but mostly I’m working with AWS.

Step 3 : plan the roadmap and educate your team

I’ve seen a startup that take the quote “move fast and break things” to the extreme. They deliver bad product that constantly breaks down. To avoid that, plan your product roadmap. Discuss with the whole team about it. The most important roadmap items for early stage startup is the first 3–6 months. For each milestone put a theme or common goal. For example in the first 3 months is MVP, the 3–9 months is the user acquisition, and so on. So people on your team aligned.

If you have sizeable team, focus on a high leverage activities such as mentoring and building a solid onboarding process for new hires. This will save a lot of time for building products. Aside of the technical materials needed to build the product such as iOS or Android training, spend some time and money to buy books like Clean Code.

The MVP Phase

Getting the product out of the door is hands down, the goal of an early stage startup, and speed is important. We may not have a luxury of writing unit and integration test in this stage. On early stage, most of the burden is usually shifted towards QA as the gatekeeper. Here, QA team need to be resilient and tough as more manual tests need to be done. Crashes and major bugs is pretty detrimental for an MVP. Minor bugs are somewhat okay because it can be fixed quickly. You may as well implement a continuous delivery system in this phase. Not doing so is anti pattern because CD is a high leverage activity on this phase regarding to speed and fast feedback. I somehow puzzled with contradicting excuse of not doing CD early on: because they have no time due to the speed requirement. You have no time to save time. Haha!

The User Acquisition Phase

This where the things shifted from speed to robustness. Pressure is in the dev team. Implement things that you had no chance to implement in the first three months. Write unit tests, write the tests that you haven’t written in the first 3 months, implement code review, refactor ruthlessly. We still deal with speed but robustness takes priority on user acquisition. Improve the QA test cases and automate what can be automated. We want to make sure we have high confidence on features delivered to the users on this phase. In this phase, there is usually business shift, changes here and there, new hires coming in and we still want to have high confidence on our build.

The “Next” Phase

Writing software product is never ending. The first two phases are usually the hardest. When you pass those phases, you usually already build a somewhat complete team. So the focus is shifted to scale. Scaling the product, scaling the team. The first 4 roles will expand. So in this phase, what you need is a leader of the pack or manager. Hire or promote managers, build a career path and training plan. But one thing to note, keep the organisation as flat as possible.

For the developers, it’s time to learn distributed system and architecture. You may start with a simple CRUD backend in the start, but overtime it’s going to be large. In this phase, think about the architecture, decide the parts we need to be refactored first and so on.

Conclusion

This is only one way of building a startup tech team. People mileage can vary. One thing about technical founder is to keep in mind that you need to strive for perfection. In many cases, I see tech team is neglected. So find a good founder that realise that tech team is as important as “the business guy”.

- This article has been republished with editing and permission from Didiet Noor. Original source is from Medium.

Didiet is a software engineer and tech advocate. He can be contacted via Twitter @lynxluna.