Point 0. Do you really need an in-house team?

It’s nice to have your own development team. You can create features, brainstorm, and discuss your future. You can give your team equity in the company to motivate them, but this practice is pricey.

Point 1. You don’t have to start with looking for a developer

If you are good at tech and you’re able to give a task and then approve the final code — then sure, hire your future developer ASAP. But if you need to focus on business and management, better be sure you have somebody to lead a team, like a tech director or project manager. You can rely on him for the tech part, and be able to focus on the product.

Point 2. Define all the roles and describe the job

Define the volume and specificity of the project-supporting work. If there are many new functions to develop ahead, you’ll probably need a few different full-time developers. If it’s enough to just keep servers alive, then all you need is a part-time admin. 

Describe your expectations about required technologies and the developers’ experience level, write about your product, and explain possible tasks. Now, you should have something you can upload to career web-sites.

Here is an example of how to describe the role:

  • Job title
  • Description of tasks
  • Who you are looking for
  • Qualifications and skills
  • Project and team information

It doesn't have to be long. You can summarize everything you need in one page.

Here is how we do it: the page for designer job description has the name, the definition, tech list, and terms. Below that, there is more info about us.

Point 3. Pick your possible team members

Take a look at the applications and exclude developers who don't meet your needs in specialty or experience. Take the rest to the interview stage. Here are things you should check while interviewing.

Soft skills. Is a developer interested in business goals, or does he just wanna code? Is he independent, or does he need to be guided to complete certain tasks? Does he match your project personally?

There are no right or wrong answers. One project needs an independent contributor, while the other does not. Look at every skill through your goals and needs.

Tech skills. Make sure you won’t need to redo everything your new developer does, and that he is really able to do all the things he said he could. The easiest way to prove this is with a test task.

Point 4. Give a test day or probationary period

Assess your possible candidate in the field: connect him to the team and watch how he manages real tasks. It depends on the project, but you can observe just for a day or for a two-week sprint.

At the beginning of the probationary period, organize a kick-off meeting. Introduce the developer to the team. Tell him about the product and its future. Give him access to your repositorium, messenger, and CRM. Introduce him to work processes; explain your prioritization and evaluation policy.

Like any other employee, a new developer will need time to adapt — to understand the code and realize your expectations. Don’t think that he’ll be ready to develop new features immediately, but pay attention to his work methods and values.

Point 5. Build your team processes

Assembling the team is just the first step. If your product is not a one-day issue, but a long-term business, the work needs to be systematized. Here are things that will help you do so.

Regular management system. You can try working in sprints. At the beginning of each sprint, you will set and dissect tasks. You should have meetings everyday, and at the end of them, you should look at the project retrospectively and discuss the work you’ve just done, taking feedback and analyzing problems.

This will help you know that the team is on the same page and moving in the right direction, and that all the developers understand business priorities.

‍Tech process organization. The tech lead of the team has to ensure that development is always progressing. This requires test processes and auto-updating systems. 

Also, the code should be understandable to any new team members. This requires code standardization.

Different teams’ synchronization. Over time, the project will grow, and experts will start working independently. Developers, designers, and analysts will manage their tasks in their detached teams. But their efforts will still need to meet in key points. For example, designers are always 1–2 sprints ahead of developers to make sure they already have mock-ups by the time they get the task.

And, of course, you don’t have to make everything with just your own employees. You can use the magic of outsourcing any time you want.

Skipp helps both with new projects and existing ones. Tell us more about yours, and we will assemble the perfect team for you.