Hiring Strategies for scaling start-ups

I used to be in a position where I took over a position as a CTO with a team of 6 people. The vision for the company was clear: Growth and build a Platform.

I had a look at our current staffing which was based on a feature team with dedicated specialists, a DevOps engineer, two backend engineers and three frontend engineers with different specialities (web & mobile). Our stack consisted of a simple Kubernetes hosted Java Spring Backend, a react based web app and a react-native consumer app.

The vision was clear, the base was clear but the Question was:

How do we scale and what kind of people do we need?

We went for the path of hiring dedicated specialists to build a strong foundation for each component within the stack. I truly believe that this is the right approach if you need to build a Platform as generalists like full-stack engineers will only particularly have the necessary deep knowledge to build a generalized and abstract platform. Of course, there are pearls out there with full-stack people who have plenty of knowledge in this field, but those people you need to find and attract as a start-up.

We put out our positions for desired people on our web page and on job seeking platforms and the first applications arrived. We slowly hired people which did not only fulfill the knowledge criteria but also had good cultural as we wanted to persist our diverse and open start-up culture.

The first hires in your first scaling phase matter a lot, as they will be your knowledge and culture multiplicators for future scaling phases.

At a certain point we grew to 14 people still working within a single team. We accomplished a lot but there was also a rise in chaos. People with a tendency to silence will become more silent within a team of that size. That wasn’t what we wanted as we missed valuable contributions due to that team size and we made the decision to split up the teams into smaller feature teams.

This made a huge difference in terms of individual vocal contributions but came with the price, that each team had to find itself as a group again. During that time the velocity declined but that was foreseeable and increased again after 2–3 sprints. The new issue which arised, was more difficult to solve.

We saw increasing velocity and happiness within each team but we started to see that the teams didn’t talk as frequently anymore to the other team members and created frictions between feature implementation. Also cross-team dependencies became harder to handle. At that stage we reminded each team member, that all members of the engineering team are still one team and the respective feature teams are only a vehicle to enable focus and manageability to deliver product related features.

Open and frequent communication, both within the feature teams and the full engineering team, was the key to come over the issues we’ve seen.

At this point, we made a transition from a small single focus team to multiple feature teams which were able to deliver features in parallel. I believe that hiring specialists for feature team staffing was a really good experience in our scenario. If our strategy would have been, build multiple products, I would have gone for smaller teams staffed with full-stack engineers as they offer a more dynamic skill-feature allocation and require less communication overhead as everyone has the necessary skills to do each feature.

Another consideration would be to staff a core team consisting of specialists developing an architectural strong who own that core primarily and small full-stack feature teams building solutions upon it.

I strongly believe that this was the right strategy but we missed some later to be manifesting problems due to architectural misconceptions and strategy implementation which I will cover in one of my upcoming stories.