No matter what path you choose, you need to build a startup team that will allow you to develop and deliver key features with increased stability while keeping this team flexible.

Before the market fit is found, your product needs to quickly adapt to users’ feedback, and be able to change its direction or pivot completely. At the same time, your solution needs to be stable and scalable because user churn in the early years can be painful.

While being a consultancy firm that works with startups on the one hand, and creates Railsware products on the other, our team knows a lot about startups’ growth and success. In this post, we’ll highlight the most crucial startup hiring mistakes and offer you some tried-and-true tips on how to avoid or mitigate them. 

Hiring unnecessary specialists

Startups reaching outsourcing agencies frequently get a team that can be overcrowded. Project manager, business analyst, separate backend and frontend developers, DevOps, graphic and UX designers, QA engineers, and manual QAs are claimed to be essential team members. Such teams can only operate with strict separation of responsibilities, where delivery of a single feature requires the involvement of 3-5 distinct experts.

While this approach seems to be stable at first glance, in reality, it leads to several issues:

• No one is fully responsible and accountable for the whole feature. A frontend engineer may be blocked on backend incompleteness, backend API can become unstable because QA missed some edge cases, etc. 
• Decision-making is often blurred and delayed as it involves many people and requires the approval of all the team members.
• There is no single person who knows all the details and aspects of a specific feature.

One may say that a project manager is responsible for connecting the dots in such teams. However, project managers in such distributed teams often don’t question feature edge cases or the whole necessity of a change. They act as mediators, translating requirements and questions from one side to another.

Communication in such groups becomes a real hurdle for the team’s productivity. Engineers are blocked until a project manager passes all the detailed requirements to them; QAs are looking for written detailed acceptance criteria before they approve a change; the project manager is expecting a product owner to answer all the questions. Such lack of autonomy leads to delivery delays, lost information, and miscommunications.

In setups where roles are already distributed in a small team from the beginning, every team member will mostly care about their part of the job, but not the product as a whole. For example, this is often visible in between design and engineering collaboration.

When there is a broad distribution of roles on a project, designers don’t have to be T-shaped. They don’t constantly communicate and synchronize their activities with engineers. As a result, designs are disconnected from the engineering – they don’t match the actual frontend UI library, and don’t reason on implementation complexity for new designs. This brings additional communication overhead and development complexity.

How to mitigate these problems

We recommend starting with a smaller team of T-shaped experts. Engineers should understand UX and take responsibility for automated testing, designers should communicate regularly with engineering, and product managers should challenge the whole necessity of a proposed feature as well as contribute to strategic roadmap planning.

Needless to say, expertise requirements for the core team should be quite high – this will allow you to move fast with a smaller team and stay flexible at the same time.

The wrong economy of a core team 

It is hard to overvalue an understanding of a perfect initial team size. Both under and over-hire can be equally ineffective and costly for your project.

Understaffed teams will have a hard time keeping codebase quality without sacrificing business needs, while over-hired teams may have issues organizing work processes.

Some typical signs of over-hired teams are:

• Engineers are spending too much time on low-priority features. They may lack product and tech stack knowledge, while more senior colleagues don’t have time to assure proper onboarding. When a team grows too fast, there’s no time for onboarding processes to be adapted.
• Product team doesn’t have enough time to work on new features and collaborate with engineering on scoping them out. As a result, development teams may either step on each other’s toes working on the same context or start endless loops of refactorings on refactorings.
• Bigger teams require more time to coordinate efforts. This can go smoothly when the team is growing gradually but can become a mess with big management overhead when a lot of new folks join the team at the same time.

Some think that an economically justified balance is to have several junior engineers per 1 senior. It may seem logical with an argument that a senior team member should boost up and mentor several junior ones, especially in a bigger team where communication, planning, and decision-making seem to be covered by other roles. Although, from what we’ve observed, the reality differs.

Such a team setup brings several problems. For instance, a senior engineer doesn’t have a qualified enough colleague to challenge their decisions or get advice from. There’s no one to learn from on a team and developers start losing motivation. Delivery also suffers. Senior engineers spend too much time reviewing the work of others instead of pushing new features themselves. And all that leads to a lack of automated tests, low quality, non-extendable codebase, and regular overworks. In the end, the team’s productivity boils down to the least productive individuals.

Another common issue is the desire to save money. Some startups tend to look for cheaper outsourcing agencies in order to cut expenses. Why pay more if you can get 3-4 engineers for the price of one from a more expensive agency, right?

Well, by hiring cheap specialists you usually get less experienced people and mainly task doers. Such teams are focused on moving tasks in Jira but not on a product as a whole. They won’t question feature priorities, won’t think much about edge cases, and will do exactly what is written in a Jira card. And many things will be missed.

Inexperienced specialists can easily get blocked on simple questions. Lack of experience and autonomy won’t allow them to resolve problems by themselves. We’ve seen codebase becoming unmaintainable in 6 months of development: all the business logic split between a couple of classes, long running SQL queries without proper indexes, and no unit testing at all. In some cases, the result of such a development process is a half-done product that is impossible to develop further, so one would need to go into an expensive rewrite.

At the end of the day, you always get what you pay for.

How to mitigate these problems

Over the years, we’ve found that small teams with enough expertise work more efficiently for new startups. They need less management, don’t require overcommunication, or a communication middleman, and are better involved in the whole decision-making process.

Experienced teams know how to get the job done. They build software version by version, focusing on a working product and happy users instead of a number of Jira tasks in the “Done” column. They will care about the scalability of a product when a user base grows, and ensure codebase extendability when a team gets bigger.

We believe that the best size of the initial product development teams is 2-3 experienced product engineers who work in pairs. They can move fast, challenge and review each other in decision-making, split work during iteration to develop several features in parallel, or combine efforts for pair or group programming sessions. A pair forms a unit that has good knowledge of a product and its users, can set up a development process, manage feature and tech debt priorities, scope out tasks, and communicate efficiently.

Obviously, when a product grows, the engineering team should grow as well. The initial pair of engineers can define an effective development process to scale and onboard new team members.

Implementing efficient onboarding processes, including clear documentation of responsibilities and providing essential resources, becomes crucial in maintaining organizational cohesion and minimizing disruptions during periods of rapid team expansion.

It is way more effective to hire newcomers when there is a strong core team already present. That way, you can ensure a smooth onboarding, knowledge transfer, and productive work on high-priority tasks from the first week. A strong core team has better chances of being well-balanced.

Unbalanced team staffing

For outsourcing agencies, it’s not uncommon to hire people specifically for new projects when they lack some specialists. 

Instead of bringing a well-functioning squad that has worked together for several years, they staff new teams with recently hired engineers with different prior experiences, approaches, and understanding of what work ethics is. There are no guarantees that such a newborn team will work efficiently, even short term. As a result, the development process may become quite unorganized and will require additional management overhead, or a separate team lead role who would spend most of their time coordinating work, instead of focusing on technical problems and actual engineering.

Furthermore, staffing new projects with newcomers doesn’t take into account the strong and to-improve skills and traits of each separate team member and doesn’t allow well-balancing of the whole team.

Regardless of prior experience and skill sets, all team members should be able to work as a single unit, make key decisions together, review the solutions of each other, and lead any debates to an agreement and effective outcome.

It’s hard to imagine a worse scenario than several senior engineers not being able to agree with each other and working completely isolated. Many times we saw a situation where technical decisions made by a single engineer were unchallenged by others, also with a lack of rational judgment or research. For instance, moving too early to microservices, using unscalable data storage solutions, preemptive database optimisations done without numbers, and selecting technologies based on recent hype. It all can lead to expensive reworks in several years, which can become especially complicated if an original solution author is not a part of the team anymore.

How to mitigate the problem

Over the years, we’ve found that newcomers can smoothly supplement the team only when it already consists of tenured engineers who have already set up a well-organized product development process. A so-called “core team” is a small group of engineers who have prior experience working together, share a similar development culture, and can organize and bootstrap the initial development process.

Well-functioning teams can deliver an effective project with less management needed. A pair of tenure engineers can:

• Dive into the project context fast.
• Communicate and manage priorities directly with product people without a middleman in communication.
• Make technical decisions. Pick architecture and tools based on what will work best for a product.
• Make product suggestions and provide constant feedback. 
• Collaborate with designers directly instead of being blocked on finished designs or design components that don’t fit into current implementation.
• Deliver roadmap on time and with transparent progress updates.

Only having a strong “core team” will allow you to scale in quantity without sacrificing quality.

Early CTO hire

In order to gain the most outcome and value from a person holding a CTO position, a company founder should have a clear understanding of the typical CTO responsibilities.

Judging from the title itself, the main responsibility of a CTO is the technology research, selection, and integration. CTOs often define technical architecture in startups. They pick a combination of languages, frameworks, and tools, think about integration and support, and plan out future technical scaling.

While it’s hard to overestimate the importance of these responsibilities, the technical architectures of SaaS companies rarely include anything exotic during the first couple of years of their existence. Pick a popular and mature web development framework (e.g. Ruby on Rails), outline your data schema for the MVP features, select frontend tools and cloud hosting provider, and you’re good to go!

What’s more important is to move fast with new product features: the right definition of product priorities, fast and stable technical implementation, product scalability for fast customer acquisition, efficient support, maintenance, and alerting – all that with a limited development team.

For this reason, a CTO is often hired with the main responsibility of building an engineering team. Although many miss an important risk – you rarely find a CTO who can be responsible for both technical decisions and team building at the same time. We often notice that CTOs are taking over only one of the aforementioned responsibilities. Bigger companies prefer to split between two separate roles – CTO and Head of Engineering, where the Head of Engineering is responsible for team hiring and growth. So you should be very specific about the reason behind hiring a CTO.

When it comes to building an engineering team, a CTO can be a good choice only if they had similar successful experiences in the past. And context matters a lot. Have these CTOs worked in a big FAANG-like company before, or did they build an engineering team in a greenfield startup? What decisions did they make in the past? Which of them weren’t successful and which lessons were learned? People with a CTO title have a very broad range of past experience and managing an engineering team in a big company is very different from building a team in a young startup.

At the very same time, C-level managers often tend to bring a lot of changes during their first months of work. It increases the risk of turning the whole company in the wrong direction if a CTO had a totally different past experience than the one the company currently needs.

In the end, even if hiring a CTO will work out well, it still doesn’t mean that the just-formed team would work in synergy.

How to mitigate the problem

We noticed that at the beginning, it’s often far more important to organize efficient team hiring and development processes than to have a separate person responsible for the technical decisions. Why? Because with a strong development team, you’ll get mature tech choices as well.

Don’t hire a CTO until it’s a critical necessity. With the saved money, you can hire a professional and experienced engineering team that can successfully take up the CTO role for at least several years.

Hiring complete strangers 

When it’s time to grow your team, a well-built and time-tested hiring process is a game changer. A good hiring process can dramatically increase the chances for a new hire to fit the team, be productive and motivated from day one. Whereas the ill-chosen specialist can significantly slow down the development process and never bring value to the team.

How to mitigate the problem

The best option is to build a smooth hiring process to cherry-pick the most prominent candidates who will fit into your team. At Railsware, our hiring process is based on making technical interviews as close to real work as possible. Candidates for engineering positions join us for a full workday, where they work on backlog tasks from real projects in pairs with Railsware engineers. Pair programming is an essential approach for knowledge transfer and decision-making that we use frequently during regular work, as well as the hiring process.

Pair programming helps us achieve two main goals of the hiring process:
1. Challenge candidates’ skillset, see how they think and make decisions in real-life scenarios – how they navigate a codebase, make implementation decisions, test the code, what questions they ask, and when they decide to refactor. All these aspects give our team a clear picture of how a new person will later work in an actual team.

2. Allow a candidate to work with future colleagues and see the actual project they will be working on. This way, job seekers can build clear expectations of the position they are applying for, and get much more information for a weighted decision about joining the team.

Spending more time with candidates on hiring steps will give confidence in long-term productive cooperation.

Hiring without onboarding & development processes 

Even when a hiring process is well-setup, structured, and battle-tested, it will never give you a 100% guarantee. False positives will happen from time to time. This is why newcomers’ onboarding is crucial too. And efficient onboarding needs well set up development processes.

With several people on a project, it’s easy to progress thanks to face-to-face communication and thorough discussion of every detail. However, when the team grows, the development will eventually become chaotic and spontaneous rather than predicted and planned without proper work processes in place.

How to mitigate the problem

It’s important to spend the first months with newcomers in a controlled environment where they can get acquainted with a current team, work processes, and approaches, and have expectations defined. When building an engineering team on such principles as focus on quality, work ethics, transparency, and feedback – it requires much more time and effort to onboard new members. Newcomers will have various past experiences, so if your team values attention to detail or has a defined approach to working with the scope – that should be shown in practice.

It’s a good idea to ensure there is an efficient development process present already in a current engineering team before new people come on board.

• Project documentation and setup instructions should be up to date in order to avoid spending time on setup during the first week.
• Branching, pushing, and merging processes should be clearly explained from the very beginning. You wouldn’t want newcomers to wait on merging the code when they don’t know who should review it or how to react to reviews.
• Access management can become a bottleneck if it depends on a separate IT department or isn’t managed properly. Ensuring the process is smooth and all involved people are notified in advance will help avoid newcomers being blocked on access.

One part of the onboarding process is to get acquainted with the product and its codebase. Various approaches can make this process productive. We recommend starting with either context-light small scope or a feature that is somehow isolated from the rest of the product. This way, we help newcomers to learn new contexts and deliver tasks at a good speed at the same time, not sacrificing much to the onboarding overhead.

Needless to say, a scope of work for the newcomer should be prepared before the first work day. First tasks should be clear and well-defined. The roadmap should be planned ahead of time considering the team increase. Adding new engineers to the team with no scope of work prepared for them is a big source of ineffective expense.

Ensure that PdM or product owner responsibilities are well covered before the engineering team starts growing. Tenured engineers managing the initial workload for newcomers can also help new team members quickly learn missing bits of the project’s technical stack. This is done through pair programming, code review, and regular feedback sessions.

Another vital aspect to pay attention to during the onboarding process is the individual traits of each new team member. For instance, some engineers may deliver code changes very quickly, sacrificing quality. Such specialists may forget to add an extra test, address some of the feature edge cases, or keep code duplications. On the contrary, others may be spending too much time overthinking the code from every angle, asking irrelevant questions, or planning out premature refactorings. It would be quite time-saving to detect and give feedback on such disturbances from the very beginning.

For a growing team, a lack of attention and feedback to newcomers will quickly lead to decreased quality of the codebase. A lack of patterns and standards defined in a team will make it more time-consuming to implement new changes, and code will become harder to understand and maintain. In reality, many startups start to deliver fewer features with more engineers.

Your team’s engineering culture takes time to grasp, which is why new team members need to spend some time inside a well-built team. If you isolate newcomers from the rest of their mates, their state of knowledge and experience will stay at the same level as it was during the hire – they won’t learn from tenure team members and they won’t have a chance to bring new practices and knowledge to the existing team.

Split your team into squads if it’s growing fast, plan out allocations ahead of time, and make sure each newcomer has a more experienced colleague nearby.

In summary: 

• Be specific about the scope of work you are hiring for.
• Build your hiring plans based on the roadmap and business plans, don’t hire for the sake of bigger numbers. We often hear plans to “hire 50+ engineers by the end of the year.” Yet smaller teams are often more productive and focused. Hiring for startups should be methodical and aligned with your strategic goals.
• Ensure onboarding and development processes are in place. Collect feedback from newcomers to assess your processes and improve them.
• Involve senior team members in mentoring and onboarding newcomers. That way, engineering practices and coding standards will be kept and enhanced in the increasing team.

Wrapping up

Despite the common belief that startup building has to be super fast, team building for your startup must take time. Fine-tuned processes, battle-tested approaches, clear work ethics, well-weighed hiring decisions, and a smooth onboarding process are the things that make the whole difference and can either make or break your company. Investments in hiring, onboarding, branding, and team retention will pay off in the long term, as they allow you to build a strong, scalable, and sustainable team.