So, you decided to give the world a new software product or service. You have a thoughtful idea, a vision, clear positioning, some first potential customers and even a budget. In general, things are easy - to assemble a team of developers and make a product.

In this article we will consider the right and wrong decisions in the selection of people, their motivation and the preservation of the team - your new asset. It is not about how to recruit the best people and build a perfect development machine, but about what gross mistakes in the selection of people and the organization of their work can ruin your undertaking.

Part I. Risks

In an ideal situation, the development of a new product looks like this: you recruit people, describe your product with it as you see it, and name the term. The team goes to work and at the right time brings a ready-made quality product, which then gradually (but also quickly and efficiently) refines.

In life, of course, this happens infrequently. In each case, there is a set of problems, but in general they are quite typical. Therefore, even at the start of the project, it is possible to describe a set of the most common risks, some of which are implemented in the course of work into common problems. Let's see the most frequently implemented ones:
')

1. Fatal delays. The product is being developed and even turns out to be of high quality, only now either the window of opportunity has closed, or the budget has ended.
2. Stable substandard product. The product is ready and released, customers have come, but they constantly encounter problems when using your product. A team week after week, month after month can not ensure their normal work. Customers do not stand up and go - either to competitors or to nowhere.
3. Laborious implementation of new requirements. Customers stand in line (some even with a bundle of money) with requests to add new features, but for some reason, refinement is very, very slow. Or on serious amounts of user data a year after the start, everything suddenly began to work very, very slowly, and no one knows how quickly to solve the problem (and customers scold you with the last words and leave). In general, we are talking about a low “internal quality” of your product: an unsuccessful architecture, lack of tests for critical code blocks, complex internal dependencies — all of this does not allow developing a product at a reasonable rate and fighting for customers.
4. Loss of a workable team. At some point, key specialists (especially if such a specialist is one) may suddenly decide that it is more interesting for them to work in another company, or even fall under the tram. It happens that the remaining team is not able to not only develop, but even maintain the product with an acceptable quality. And the candidates at the interview look into the full angst of the eyes of potential colleagues, then into the code, and no longer get in touch.

The trouble does not come alone, and often several risks are realized at once. For example, there is at the same time a fatal delay in terms, and consistently low-quality product, and time-consuming implementation of new requirements. The risk of losing a workable team in this case is unlikely to be realized, because it was not there.

Or another situation where the product is made quickly and efficiently, well solves a specific task of customers. But there was a desire to add additional functionality, but the initial decision was based on the fact that there would never be such requirements. New features are realized by a slim system of crutches, long and difficult. And then the key specialists get tired of all this, and they leave.

Realizing any of these risks and even combining several is not a sentence for a product and a business. As a rule, you can make an effort and get your product back on track of sustainable development. Especially if the company already earns decently. But the time and money spent will not be spent on development, customers will wait for all this time to solve their problems, and competitors will have a head start. Prevention is much cheaper than treatment. Here about her and talk.

Part II. Qualifications and motivation

Any developer (however, this also applies to other professionals involved in the development) has two slightly conditional, but very important parameters. This is a qualification and motivation .

A qualification describes how well a person can do his job. And motivation determines how much he really realizes this ability.

We describe four extreme cases:

1. Highest qualification, wide motivation. This is the unstoppable Creator. It is effective and concise. He always knows what he is doing, because he has already done all this. It works all day because it is inserted.
2. The highest qualification, the motivation went into the negative. Almighty too, only he needs nothing. Somehow solves urgent tasks, but it is necessary to force and control.
3. No qualifications and no motivation. A stereotypical student with a profile education, who at the entrance to the profession wants a big salary, but only two months a year work for it.
4. No qualification, but over-motivation. A person is insanely energetic, learns new things and learns. But at your expense. He makes all sorts of mistakes, some of which manifest immediately, and some will shoot later. Time is consumed by more experienced colleagues (if they have any) with questions, control and correction of their mistakes.

Both of these parameters are not constant in time.

Qualification (if you manage to measure it with some tricky number) as a rule grows occasionally and abruptly - during periods of gaining valuable experience, mastering new approaches and technologies. But it can be said that she sometimes falls. For example, when switching to a new technology, which is still unknown to the developer, his qualifications in your team will drop slightly. And then the opposite will grow.

Motivation, however, jumps up and down like an abnormal one. It is influenced by a huge number of factors. Belief in the product, feedback from users and management, the ratio of interesting and routine tasks, several days of full stress before the problematic release, the news that a new colleague in the same position receives one and a half times more, praise from colleagues - all this motivates vary widely. In practice, it is very difficult to stay at the peak of productivity for more than a few days or to maintain a very high average motivation for more than a few months. But at the peak of motivation, a cool developer can do the work that will lay the foundation for your future product, or carry out such deep processing that will open up new possibilities for your product.

To put it simply, one can consider the result of the work of both the individual employee and the whole team as the product of the qualification for motivation. The near zero value of one of the parameters will give a very mediocre result, and the product of large quantities allows you to create breakthrough products.

A little more about qualifications

Qualification can be decomposed into several components:

1. Technical qualifications are knowledge of their tools (algorithms, languages, platforms and development environments, heaps of frameworks and libraries, applications for the work of a designer or tester, and so on), as well as skills for their effective use.
2. Experience is the knowledge of how to act in certain situations. It can be obtained from its mistakes (for example, when the developer himself wrote several multi-threaded applications and stepped on all the main rakes) or on others (for example, work in a team of high-loaded solutions and see how others make these errors near). The value of experience lies in the possibility of avoiding mistakes on the way to the goal that can be costly for your product and business.
3. Interaction skills are the ability to effectively build interaction with others: colleagues, users, clients. This includes the ability to articulate thoughts, and the atmosphere of mutual assistance in a team, and responsibility for the quality of their work, and caring for end users, and the ability to insist on their own, if necessary. This qualification is perhaps the hardest to acquire. Perhaps that is why it is often called culture.

A little more about motivation

Motivation is also not so simple. It can be said that she has a certain basic level, which is determined by whether a person believes in a product he is working on, he sees prospects for himself, he feels that, in general, everything goes as it should.

Motivation around this basic level varies widely every day. But if the baseline is too low, there will not be any peak in productivity that allows you to make a breakthrough product. And the fall "to zero", when the whole day passes in the struggle with oneself and in imitation of activity, there will be much more.

Conversely, when the base level of motivation is high, the overall effectiveness of the staff (especially in terms of interaction) will be much higher. Falling "to zero" will still not be avoided (at least due to the accumulation of fatigue), but this will not be an everyday routine.

So, we have a basic level of motivation, which is determined by long-term parameters, and “current”, which you need to follow every day.

So what do we want from employees and teams?

Everything is very simple. If you want your project to fail not because of development problems, but at a later stage (and even more so if you want it to shoot), you need:

1. At all positions recruit only people of sufficient qualification;
2. Provide them with a high base motivation;
3. Every day, monitor your current motivation.

Part III. Choice of people. Right and wrong

And so, we need skilled people. That is, people who are not only technically savvy and experienced, but also will be ready to work productively together. Where do you get them?

How to

Recruit people with experience and vaccination with the right culture. Usually these are people with experience of 5+ years who have worked for large and medium-sized companies for an appreciable amount of time, about which you know that everything is fine with culture. Culture in our case is when it is not customary to do shit under any circumstances (accept the fact that this is actually the generally accepted wording in our field), there is a cooperative atmosphere within teams, the company and employees are open to modern approaches to organizing effective work, and so on. In general, the honorable role of large and medium-sized IT companies is to train your employees. And since they are quite large, good developers who are stuck in professional, career or salary growth, they will definitely be there. Here you need them.

The reward for making the right choice will be a team that knows what it does, is involved in the process, is transparent to business and does one thing with it - a good product.

How wrong

To hire a team of people with no experience (yesterday's students, today's interns), people from in-house development and from small companies engaged in customized development (unless, of course, they have no experience described above).

They will not have either experience or outlook to make the right decisions (for example, in terms of forecasting data volumes, workload, organization of modularity and separation of concerns), or work culture in an effective team (responsibility, planning skills and all agile, design and code review, test and write tests, and so on).

And an inexperienced developer will learn at your expense and bring little benefit, but at the same time take the place of a person who could already move your business. It will devour the time of experienced developers (here is an excellent article on Habré , illustrating the problem), who will have to answer questions, carefully check the beginner code, and then redo it. And if you do not redo it, then a bad decision will fire much later, and an alteration that would cost a maximum of a few hours may then cost several days, or even weeks.

Of course, there are not so rare happy exceptions. But if your goal is to get the product within the time frame and the budget, then first of all you need to take care of the risks that we have discussed in such detail in the first part of the article, and not rely on luck.

What happens for the wrong choice

If you choose people without a suitable technical qualification, you can find yourself in a situation where yesterday's student at the very beginning chose an exotic DBMS instead of the good old SQL, and the costs of serializing in JSON were so huge that the application rose tightly. And now, for three weeks, the team has been struggling with the problem of obsolescence of information in the cache, because it is still faster than changing storage. And the problems snowball continues to be carried downhill.

And if you choose people without a suitable culture, then one day you will find out that the developers do not check the newly written code themselves at all, but immediately give them to testing, from where it returns to them three times. And the duration of each release is shifted by a week. And then, when you once again realize that the release dates have gone somewhere again, and your business is already under threat, you suddenly find out that there is a task that everyone is waiting to complete to move on. But nobody does it. And everyone says that the task is not his. Against this background, the situation where a few clients have already received a two-time corrected error after updating for the third time appears to be a trifle.

Special case - development outsourcing

Outsourcing development is a great solution if your startup fails.

You do not need to search and hire people, all competencies have already been selected, the contractor has been tested. But his interest is to make money, and not to make a quality product for you as efficiently as possible, and every mistake that leads to alterations in the future is not a problem for the contractor, but additional money (after all, the main thing is to close the current stage, right? ). But if the product is still doomed, it's not scary. But if a product suddenly suddenly becomes profitable, then the contractor may be asked: is it not too cheap for its services, and indeed, whose product it really is.

About the fact that you are not able to influence the effectiveness of the work of the contractor’s team, and you cannot change the team so easily, if something goes wrong, we will not even speak further.

Part IV. Team motivation. Right and wrong

So, a team of qualified people 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.

Simply put, the developer (tester, designer, interfaceologist, layout designer, team leader) works in one of three modes: “self-realization”, “work for a salary”, “wait for me to be fired”. And absolutely all people switch between these modes of basic motivation at different periods of their lives.

In the self-realization mode, a person works on your project as his own. He is a fan of the project, glances ahead, and not just at his feet, helps his comrades. Well, what a sin to conceal, wants to drag in a new technology, try out a new approach or redo everything from scratch. But in general, in this state, any member of the team is several times more productive than in the other two (here we offer the reader to get acquainted with the classic work of Frederick Brooks "Mythical Man-Month" , if he suddenly does not know him). And the team as a whole can also work in this turbo mode. In this case, the team even pulls up the “drop-down” participants to the overall level. Within certain limits, of course.

In the "work for a salary" mode, there is also nothing really bad, if you have a sense of responsibility. The man does not burn, but his productivity is stable. He does only “from and to”, but he does “from and to” well. And with a clear conscience goes home at six. In this mode, a person can do a good job, but he no longer has the motivation to look into the future, think through potential problems that lead to a particular decision, and most importantly - seriously struggle to ensure that the decisions are correct, the quality of the product is high, and the pace of development met the needs of the business.

And finally, the last mode. Usually, a person falls into a pit, “waiting for me to finally be fired”, when he is running out of strength and hope that everything will change for the better. Probably, every reader was in this state, and there is no need to describe the level of productivity of such an employee.

It is important that the team spent as much time as possible in a state of maximum productivity and in no case did not go into a minus, from where you will not be able to pull it out. The price of the issue is the chance of getting into a window of business opportunities with a competitive product.

Let's understand how to achieve this.

How to

Our goal is to gather experienced developers (testers, designers, layout designers, analysts) from large and medium-sized IT companies with experience and a high level of “production culture”. And then keep them as efficient as possible.

The right people go to your office to “talk”, as a rule, because at the current job you are in a professional, career, salary deadlock. That is, they lack confidence in the product, interesting tasks, a greater sphere of authority and wage growth. And everyone wants to be appreciated, respected and not thrown.

If you need these people, offer them what they lack.

Of course, everyone has their own little special request. And it concerns not only the moment of employment, but also each next day of work in this project. Therefore, consider the conditions for the team better long before the first person comes to get to know you better. And not only think over, but also impose on the budget and business plan.

So, what can you offer your future team:

Product Involvement

Start with product perspectives. 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. Nobody enthusiastically makes the notorious UG.

But selling your product once is not enough. The value, significance, success and prospects of the product, its successes and failures must be in plain sight. If the team does not see progress, success and failure, it will never associate itself with this product, and you can forget about the “self-realization” mode. Everyone will be busy only in order not to substitute his personal ass in the next emergency.

Money

After the product is sold to the future team member, offer good monetary and social and labor conditions.

You take experienced professionals to yourself, so the salary (including premiums) should be higher than the market .

First, you take away people from such companies that are above their average employees do not want to pay or can not.

Secondly, you say to your employee: “We understand the value of employees, you are our key asset, we want and are ready to pay our employees above the market (this is important for maintaining the“ self-actualization regime ”) and at the same time we expect them to work appropriately in a way. We are not ready to pay less to employees who work worse - we cannot afford such employees. And we cannot pay more, because such expenses will not allow the business to soar. ”

Personally, it seems to the author that it is better to play openly with the right people: mark the salary-premium-chocolate conditions for all positions, the number of these positions, how long the budget lasts, and how you plan to earn (earn or invest) money. This removes unnecessary expectations about the growth of salaries as they grow in position, the size of bonuses, the revision of salaries before the product starts making money, and so on.

At the same time we immediately close the question of whether to offer a share in the business. It so happened that the situation in Russia differs from the situation in the United States in this matter very much. There, startups cannot compete in terms of money with the largest companies in the industry, but they offer a dream - options in case of take-off. Everything is exactly the opposite for us - startups with a budget and a well-thought-out development plan can afford to pay a little more than the market due to a small effective team. And the promises of a share in the bright future will not buy anyone: too sad statistics. At the same time, offering a stake in business to people with whom porridge has not yet been cooked is in elementary danger in Russia: a corporate conflict at any stage can bury the whole undertaking. Options do not really work with us.

Thirdly, rather high salaries allow, as noted above, to reasonably require a certain level of efficiency from an employee. It will become important when it is necessary (and this moment is sure to come, and more than once) to change the existing working conditions, to change business processes. For all those affected by the changes, this will be a way out of the comfort zone, so business will not do without pressure from the head or from outside the team. If the changes have benefited, smart people will eventually agree with them, but without interim conflict anyway. And in this case, the right material motivation is an important insurance against the loss of valuable employees.

A responsibility

Responsibility is a key issue in software development for both teams and businesses. If objectively the task requires a week of working time, and the manager requires to solve it in two days and does not listen to any arguments, then in 99% of cases the result will be poorly fulfilled requirements and a pile of problems noticed under the carpet. The developer will be forced to do shit (we remember that we specially recruited people who are physically unpleasant to do shit), and the problems noticed under the carpet will cost in hours or weeks of delays in the future. Motivation fell, problems appeared. That is why it is critically important that the assessment of labor costs comes from team members. You can bargain for it, formulate the task in more detail, adjust the requirements (hello, agile), but the final assessment should be given by the person who will fulfill it. Because the assessment of a task is an act of assuming responsibility for the timing and quality of the solution of this task. Accuracy requires experience, and taking responsibility requires culture. It is these requirements for team members that we formulated in the second part of the article.

Expectations and reality

Frustration is a gap between expectations and reality. Always keep abreast of the expectations of your professionals and see how things are in reality.

For example, delaying a salary without warning is only a day - minus to “motivational” karma. A sudden change in requirements at the middle of an iteration without clear, compelling reasons? Minus in karma. A colleague gets the same amount as you, but works at half strength, and no one has done anything for two months? Minus in karma. New employee of the same level take on the same position with a salary of one and a half times higher? Anyway, it will become known - minus in karma. Always forgive deadlines on the day of the deadline, but this time strictly in accordance with the agreement reduced the premium? Anyway, minus in karma. Promised a premium on clear terms, and then “objectively, no money to pay so much”? You will not be forgotten.

Cons in karma can not be avoided. Some of them will be intentional and absolutely necessary. But at some point the accumulation of frustration will lead to an abrupt drop in the productivity of team members. And then, at some critical point, the motivation of the team as such will fall, and the team will pull the motivation of its “misguided” members no longer up, but down. Therefore, it is very important to monitor the size of the gap between expectations and reality.

How wrong

Just do not treat the development team as one of the most valuable assets.

But it can always turn out so that the original idea and the very first product and its customers can not bring money, and you need to quickly change shoes on the fly. At this point, of all the assets you will have only money, the will of the founders and the development team.

Do not "report" to the team. After all, if you think about it, how do developers care about sales? Keep new features discussed with customers secret from team to last. At the same time, always halve for the team the terms of appearance of the functions that you have agreed with customers.

Accept the “die but do” ideology in terms of timing. Put the question of monitoring and maintaining motivation on the team leader, this is his job. Do not fulfill promises, do not apologize for the delay in salary and do not dismiss "rotten" employees. And of course, take it for granted that the employees have only one interest - to earn more (yours, by the way) money, doing less work.

Of course, the development will work with all this, and the product will gradually appear. But at one and the same time much less functionality will be done, the user experience can be critically bad, and at the moment when the product suddenly takes off, it turns out that the team cannot run at the right pace, including due to rake code.

The most important thing in one paragraph

Set the bar high. Recruit experienced professionals who can work in a team. Know your financial and time opportunities. Sell ​​your product to the team. Provide good conditions. Give people the opportunity to consider your product as common. Remember that responsibility is not a certificate, it is not issued, but taken with your own hands. Keep track of expectations and reality. Use the high motivation of the team to get a competitive product. And remember that now you have a very valuable asset that is no less important and not less fragile than the trust of customers and the interest of investors.

In the next part

In the next article we will look at the organization of the work of the team - also from the position of minimizing risks. Do not switch.