A product development team made up entirely of new hires starts with no shared habits, no knowledge of your business and no code to learn from. To build a strong one, hire the person who will lead it first, keep the first team small and mixed in experience, give it one clear goal, and settle a handful of working rules before the second person starts. Even done well, it takes some months before such a team works at full pace, so plan for that.
Decide what the team is for before you hire
A team needs a goal it can reach. “Build our platform” is not one. “Let customers place and track orders online by the spring” is. Write down the first release you want real people to use, and keep it small enough to reach in a few months. A list of later goals in rough order is enough of a roadmap at this stage. Detailed dates for features a year away will be wrong.
The team also needs one person who decides what gets built next. That person usually exists in the business already: someone who knows the customers and has the authority to say no. Scrum, a widely used way of organising development work, calls this the Product Owner. Our article on the difference between a product manager and a product owner explains the role. Without it, the developers end up choosing priorities themselves, or taking them from whoever asked most recently.
It is worth checking at this point that employing a team is the right answer. A team is a fixed cost every month, busy or quiet. If the work is one defined project, or an existing system that needs a few days of attention a month, a supplier may cost less. Our comparison of a software company and an in-house developer sets out when each fits, including the cases where hiring is clearly better.
Hire the lead first, then build around them
The first technical hire shapes everything after it. They choose the technology, set the standard of work and interview the people who follow. Take longer over this appointment than over any other.
If nobody in the business can judge a technical candidate, borrow someone who can. A technical adviser you trust, sitting in on the interviews, is worth paying for. Our guide to hiring a CTO for a start-up covers how to assess a senior technical person when you are not technical yourself.
After the lead, most new product teams need:
- Two or three developers. On a small team, people who can work across the whole system are more useful than narrow specialists.
- Design. A part-time or contract designer is usually enough at first, unless the product will be chosen mainly for how it looks and feels.
- Testing. On a small team the developers write automated tests and check each other’s work. A dedicated tester earns their place once the product has users who depend on it.
Resist filling every role on the organisation chart before there is a product. The Scrum Guide, last revised in November 2020, describes a team as typically ten or fewer people, and most new teams should start well below that. Every person added is another set of conversations to keep going.
Mix experience deliberately
A team of new hires has nobody who knows how things are done here, so the mix matters more than it does when adding to an established team.
One or two experienced people, with the rest at a middle level, is a sound starting point. A team made up only of senior developers costs more than the work needs, and strong opinions with no agreed way of settling them slow everything down. The opposite mistake is more common in our experience: a group of junior developers reporting to a manager who cannot review their work. The software appears to progress, and the problems surface a year later. Take on a junior only when someone has the time to teach them.
When interviewing, prefer evidence to puzzles:
- Ask the candidate to talk through something they built: what they decided, what went wrong and what they would change.
- Set a small practical exercise close to the real work, short enough to be respectful of their time.
- Speak to people who have worked with them.
- Ask how they use AI coding tools and how they check the output. The Stack Overflow Developer Survey 2025 found that 84% of respondents were using or planning to use AI tools in development, and that more of them distrusted the accuracy of the output (46%) than trusted it (33%). A good candidate will describe how they review what the tool produces.
For a brand-new team, look for people who have started something from nothing before. Setting up a project, a release process and a set of conventions is a different skill from working within ones that already exist.
Where to find people
Referrals from people who have worked with a candidate remain the most reliable source. Beyond that, the usual routes are LinkedIn, specialist technical recruiters, who charge a fee, and local meetups and user groups for the technology you have chosen.
Write the advertisement for a developer to read. Describe the product, the technology, the size of the team, the salary range and whether the work is in the office, remote or a mixture. Vague advertisements attract vague applications.
Hiring remotely widens the pool considerably, and our article on tools for remote development teams covers what such a team needs. Employing someone who lives in another country raises tax and employment questions, so take advice before making that offer.
Settle the working rules before the second hire
An established team absorbs a new person into its habits. A new team has none, so decide a few things early and write them down:
- The code lives in a repository the company owns. The same goes for hosting, domain names and every other account. None of them should be in an individual’s name.
- A second person reviews every change. This spreads knowledge as well as catching mistakes.
- The software is built and tested automatically, and released in small steps. A first release in weeks, however modest, teaches the team more than months of preparation.
- Work is planned in short cycles. Scrum calls these sprints and limits them to a month or less. Many teams choose two weeks.
- Decisions are recorded. A short note of what was decided and why saves the next hire from reopening it.
- Each new starter releases a small real change in their first week. It proves their access and equipment work, and shows them the whole route from code to live system.
Guard against the team coming to depend on one person. Make sure at least two people understand each part of the system. Our page on what to do when a developer has left shows what that dependence costs when it goes wrong.
Employment points to check
These need proper advice, and the rules are changing.
- Ownership of the work. Code written by an employee as part of their job normally belongs to the employer, but the contract should say so plainly. Contractors are a different case, and need a written assignment.
- Probation. Under the Employment Rights Act 2025, the qualifying period for protection against unfair dismissal falls to six months for dismissals from 1 January 2027, according to the government’s published timetable. Probation reviews will need to be held on time and recorded.
- Notice periods. Experienced developers usually have notice to serve, so allow for a gap between an accepted offer and a first day.
Before advertising the first role, put four things on one page: the first goal, who decides priorities, who will interview technical candidates, and a budget that covers at least the first year. If any of the four is blank, settle it before you hire.