How to hire the team of developers for your IT-startup, that really makes the product

Now, you’ve decided to give the world a new product or service. You have a thoughtful idea, vision, clear understanding of the goal, a few first potential investors, and even a budget. For now to complete the team remains a subject.

This article is devoted to right and wrong decision to hire web developers, their motivation and creating the team. It’s not about recruiting and building a perfect development machine, but about blunders in searching of programmers and organizing their work, that leads to damage of your project.

Part 1. Risks.

Just imagine the ideal way of new product development. You hire people, describe them your idea, and set up estimates. The team goes to work and makes a release at the right time. It’s a high- quality product with further modernisation.

Nevertheless, in real life, such story doesn’t happen often. Every project has a lot of issues, however, they are typical. That’s why, at the beginning of the project, we can describe a set of the most common risks, because some of them turn into common problems during the work. Let’s consider the most common:

• Irritative delaying of deadlines. The product is being developed and even it’s turning out qualitative, except the budget comes to the end or the source of inspiration has run low.

• Poor-quality product all the time. The project is developed and released, customers have come, but they continue to face problems using your product. Week after week, day after day team doesn’t provide them useful solutions. You lose your customers and they go to your competitors.

• Labour - intensive of new requirements implementation. Customers come with requests to add new features, but for some reason, it’s slowly. Or you have a huge stream of users’ data a year after the start, and… everything suddenly began working very, very slowly, and no one knows how to quickly solve the problem. Other words, we are talking about the low “internal quality” of a product: unsuccessful architecture, lack of tests for critical code blocks and so on. All these points block further development stage and compete for the customers.

• When you lose a hard-working team. At some time, key team members can suddenly decide to work in another company. It happens. And your present team is not able to develop and support the product with acceptable quality. You looking for candidates, give them code preview. They are looking into your eyes and never get in touch.

When it rains, it pours and often a couple of risks are realized once. For example, there can be both a fatal delay of terms, a poor quality product and hard implementation of new requirements. The risk of losing a hard-working team isn’t be realized in this case because there isn’t such team.

Let’s look into another way of development, when the product is built quickly and efficiently, it solves a specific customer’s’ tasks. But the client has a desire to add additional functionality. However, managers came to terms that there will never be such requirements. New functions are implemented with a lot of pitfalls, long and difficult. And then key experts get bored with all this staff, and they go.

The risk existence and even a combination of risks are not a verdict for the product and business. As a rule, you can make efforts and set up a sustainable development for your product. Especially, if the company has a great income. Otherwise, preventive measures are much cheaper than treatment. Let’s talk about them.

Part II. Qualification and motivation

Every team member (we are talking about developers) has two special feature, but very important. These are qualification and motivation. Qualification means how well a person can do his job. A motivation means how much developer realizes his ability.

Qualification usually grows from time to time and spasmodically. Such grows depends on acquiring valuable experience, mastering new approaches and technologies. But sometimes workers lose their qualification. For example, when you implement a new technology, that developers don’t know, his level of qualification decreases according to this team. And if they cope with it, then qualification will grow back.

Motivation is jumping up and down. A huge number of factors affects it. Belief in the product, feedback from users and managers, the ratio of interesting and routine tasks, a few days the hardest work before problematic release, the news a new colleague in the same position receives more payments. All of this factors impact on motivation. In fact, it’s very difficult to survive at the peak of productivity for more than a few days or to maintain a very high average of motivation for more than a few months. Nevertheless, at the peak of motivation, a dedicated developer can do the work that will be the foundation for your future product. Also, he carries out a deep processing that will open new opportunities for your product.

II.1 Qualification

The Qualification consists of 3 main components:

1. Technical qualification is the knowledge of the tools (algorithms, languages, platforms and development environments, heaps of frameworks and libraries, applications for designers or testers, etc.), as well as their implementation of skills.

2. Experience is the knowledge of how to act in certain situations. You can get it by means of your own mistakes or others (for example, to work in a team of a highly loaded solution and see how others make these mistakes). The value of experience is the possibility to avoid mistakes that can damage your product and business.

3. Interaction skills are the ability to build interaction with others: colleagues, users, customers. This includes the ability to explain thoughts clearly, create the atmosphere of mutual assistance in the team, responsibility for the quality of their work, the ability to insist on the proposal if required. It’s hard to gain this qualification. Probably, that’s why it is often called culture.

II.2 Motivation

We can say motivation has some basic level. This level is determined by whether a person believes in the product he is working on, whether he detects the prospects for himself, whether he feels that everything is going on as it should.

Every day motivation varies around this basic level. But if this level is too low, there won’t be the productivity peaks influencing on technical gaps.

Otherwise, when the basic level of motivation is high, the overall performance of employees (especially in terms of interaction) will be higher. Anyway, we cannot avoid the decrease of the motivation level (at least because of the accumulation of tiredness), but it won’t be a daily habit.

So, we have a basic level of motivation, and it’is determined by long-term parameters. Also, we have “current” level, that you need to monitor every day.

What do we expect from the team?

If you want your project works, I recommend following this rules:

• You should hire developers with needed level of experience

• Provide them with a high level of motivation

• Monitor the current motivation every day

Part III. The searching of developers. Right and wrong ways

As we’ve determined we need skilled developers. People who are not only tech - savvy and experienced, but also they will be ready to work productively together. Where can I get them?

Right way

Recruit people with experience and the right culture. Usually, these are people with experience of 5+ years who have worked in medium-sized companies. Culture in our case is not doing shit under any circumstances, there is the atmosphere of cooperation inside the teams, the company and employees are open to modern tech approaches and so on. In general, the honorable role of IT companies is to prepare employees for you.

The reward for the right choice will be a team that knows what it does, the team involved in the process doing a good product.

Wrong Way

To hire people without experience (yesterday’s students, today’s trainees), people from in-house development (unless, of course, they have the experience described above).

They will have neither the experience nor the outlook to make the right decisions (for example, forecasting data volumes, load, organization of modularity and separation of concerns), or the culture of work in an effective team (responsibility, planning skills and agile, design and code review, testing and writing tests, and so on).

And an inexperienced developer will learn at your expense and do little good. At the same time, he takes the place of a person who already could move forward your business. He will steal the time of experienced developers because they will have to answer the questions, check the code carefully inside of the beginner, and as usual rewrite it.

Of course, there are some happy exceptions. But if your goal is to get the product within the time frame and budget, first of all, you need to take care of the risks that we considered. Don’t count on luck!

Outsourcing as the way of solution … well, and Remote - Insourcing

You don’t need to seek and hire people, all responsibilities have already been selected, the contractor is experienced. But his goal is to make money, not to develop a quality product for you. Every mistake leads to earning of extra money (because the main thing is to close the current stage, right? ). More productive and profitable way is Remote - Insourcing or Dedicated Team (detailed information see hereInsourcing, Remote - Insourcing, Outstaffing: what makes business sense

Part IV. Team Motivation. Right and wrong

So, the team of qualified people is recruited. Now we need to solve the second part of the task: to ensure that all these people work well. So, we will talk about maintaining motivation.

What’s right way?

Our goal is to gather dedicated developers (testers, designers, coder, analysts) from IT companies, with experience and a high level of “production culture”. And then we should maintain their maximum effective mode of operation.

The right people go to your office to “talks”, as a rule, they faced with a professional, career, salary deadlock at the present work. That is why, they don’t have enough faith in the product, interesting tasks, greater scope of authority and wage growth. And still everyone wants to be appreciated, respected and not thrown.

Of course, everyone has their own aspirations. Therefore, to think of the conditions and requirements for the team is better before the first person comes to get an interview with you.

So, what can you offer your future team:

• Involvement in the product. Describe product prospects. We assume that you already have a thoughtful idea, a vision and all that. If you want your team to work in the “self-realization” mode, “sell” your product to it. The value, significance, success and prospects of the product should be in sight. If the team does not see progress, successes and failures, it will never associate itself with this product, and you can forget “self-realisation”.

• Money. When you sold the product to the future team, offer them a good salary and social-labor conditions. You hire experienced professionals, so the salary (including bonuses) should be higher than the market price. High salaries allow, as noted above, to require from the employee a certain level of efficiency. This will be important when it is required to change the existing working conditions, to change business processes.

• Responsibility. The key issue in the development process is responsibility. If reasonable estimates are a week of working time, and the manager demands to solve the task in two days and does not listen to any arguments, in 99% of cases the result will be the failure to carry out the requirements. That’s why it’s critically important the evaluation of labor costs will be calculated by the team members. Because the estimation of the task is an assuming of responsibility for the timing and quality solution of this task. The correctness of estimation requires experience, and taking responsibility requires culture.

What’s wrong way?

The team hasn’t to see you hopeless. Keep the new features discussed with the customers in the secret from the team. At the same time, always tells about estimates of new features.

Accept the ideology of “die, but do it” according to estimation. Delegate the monitoring of teamwork and maintaining the motivation for Team Lead, this is his job. Do not keep promises, do not apologize for the delay in salary and do not fire the “bad” employees.

Of course, the development process will work, and the product will appear. But at the same, the user experience can be critically bad. In addition, at the moment when the product suddenly takes off, it turns out that the team cannot maintain this rate.

Conclusion.

Set up a high level of the development process. Hire experienced professionals who work as team players. Calculate your financial and time possibilities. Sell ​​your product to the team. Provide good work conditions. Remember that responsibility is not a certificate, you own it yourself. Use the team’s high motivation to get a competitive product. And remember you have a very valuable asset, that is important as the confidence of customers and investors’ interest.