Pitfalls of staff augmentation services

In the previous article, we explained why we loved outstaffing even before it became mainstream. This year has shown how much the demand for the outstaffing model outstrips the supply. With the current shortage of personnel, product development companies that want to grow are using all available tools to scale up quickly, get ahead of a competitor with a release and win another battle for their consumer.

We offer a comprehensive guidance on how to address the most common concerns and provide both clients and contractors with highly useful strategies for successful cooperation within the outstaffing model. This article is a must read for resource managers, recruiters, team leaders, product developers and for everyone who interacts with third-party contractors.

Peace (and profit) to everyone!


Ready → Building a Team → Go!

Concern: what if I hire a bunch of guys who are not fit for the project? You need more candidates to choose from!

When you start looking for an IT-outstaff team for your project, make sure you spend enough time explaining the details. A laconic request similar to "Looking for Frontend Developer (React)" is probably a good start when you need someone to do the job, but it some client would not say much more than that.

Some of the customers say, "I will gladly brief you (with a detailed description of the project, deadlines, technological stack) Tuesday for a hamburger (CV, test task, technical interview) today". Unfortunately, this approach does not allow the contractor's team to get a better idea your requirements and select suitable candidates. A developer who has a clear picture of his role on the project will be able to brush up the necessary topics in his memory before the start of the project, read the documentation, etc. In fact, that makes him a more welcome member of your team.

If you don't encourage your prospective contractors to check your requirements at the start, you may end up lumbered with dozens of irrelevant CV's Or, even worse, you may choose a developer that you liked, and get rejected — because the demand for good specialists is very high. The choice has to be mutual.


How to prevent failure?

Before requesting a CV and conducting an interview, make sure you have a Project Management & Information Checklist

Feel free to use our template..

We recommend including the following items there:

  • A list of requirements for a specialist (mandatory and "will be a plus"). The easiest way is to use your job description.
  • Your team composition — who is already working on the project. It will be useful, if an outstaffer is going to join a team of 5-10 or more members. In this case, the contractor will understand that it is not worth offering solo players.
  • Project deadlines, so that the contractor has the opportunity to check his plans and vacation schedule in advance to avoid delays.
  • Description: area, project goals, how the processes are organized. The more detailed your list is, the higher your chances of getting developers with relevant experience are.
  • A list of tasks to be solved. Developing from scratch or working with legacy code? Architecture design, code review, bugfix, refactoring, implementation of new functions? What will you need to focus on, what type of tasks prevails on the project?

We always do our best to carefully check a potential project, especially if it requires a one-time allocation of at least 5 people. After the interviews are completed and the client has chosen the talents, we offer to hold a discovery call between the teams. Team leaders, project managers and other active participants of the project from the client's side answer questions from our specialists, discuss roles on the project and organizational issues. After the call, we discuss the project internally to get feedback from our team members. If all the participants are satisfied with the prospects for their participation in the project, then we are ready to start. This call also helps the client to make sure that the choice is correct and synchronize with us on some of the key issues. This is especially important if we have a long project ahead of us.

Concern: what if I'm not careful enough about the selection? Let's conduct two more stages of the interview. Plus live coding!

Most often, customers approach interviews with candidates very responsibly — perhaps even more thoroughly than with their in-house staff. Case study: two stages of interviews for an hour each, testing of theoretical knowledge, and a live coding session for dessert. A developer is requested to solve problems in real time under the supervision of 3-5 people led by the vice president of the company (okay, we exaggerate a bit, but that is probably not far from the truth.).

Tension of the mind

Back to the actual case. Our developer shared that the initial interview had been conducted by a telegram bot. The timer started, the bot gave an academic-level task (and you know how I don't like academic tasks) and expected a solution code. Then he clarified in five different formulations how the code works and what can be improved in it. As a result, he rated my soft skills level as low (really?!) and offered to have another interview, but with a real person."

Our experience shows that the rigidity and inaccessibility of the selection criteria very rarely correlates with the complexity and prestige of the project. Stringent requirements can be a proof of the fact that the customer hardly misses one candidate out of 20 suitable CVs.

How to prevent failure?

The interview should be relevant to the project tasks. If few developers proceed to the next stage of your selection funnel, perhaps it's not about the developers. To get more relevant CVs, make sure you clarify the input requirements, or loosen the selection criteria to a wider range of skills. That may help to increase the conversion rate and save your resources when you really want to pick candidates with sufficient and relevant expertise.

If you have had a joint project with a contractor for several years and have been through fire and water together, you are probably ready to take into account his views. It's often hard for a quiet personality to cope with the nerves and to stand out in the live interview. The contractor knows the qualities and abilities of his employees better than a recruiter does after a couple of hour-long interviews. Even if a candidate has not formally passed your selection, but the contractor insists on giving him a chance, you may benefit from saying yes.

A view from the client's side

A useful tip we can share is to find an account manager from the contractor's side to work in the client's premises, to do sprint planning, grooming, retrospectives, etc. This person would understand how the product lives, what kind of culture the company has, what kind of people work there. Due to this deep immersion, it is quite easy for the account to pick some new members for the team or make replacements. He may have a good idea of what's best for the project.

There were several cases when we insisted on giving a developer who was rejected after an interview a 1-2 weeks test run. If he had not passed the trial period, the customer would have paid 50% of the cost — we shared the risks. But that has never happened — the developers justified the trust placed in them and stayed on the project.

Another tip is to be sure to give feedback after the interview. This will allow you to review your requirements, and make sure everything works out with your next candidates when the contractors know what is especially important for you.

There is an addition to the team. Let's get started!

Concern: How will I pick 10 people to the project at once? Everything will break down. Help!

Onboarding of outstaff specialists is very similar to hiring full-time employees. Both need to get familiar with the existing approaches, regulations, work requirements, task tracker, etc.

When you need multiple new hires, or a team, this can be an extra load on team leaders, architects, and managers from the client side. At this point it is important to prevent chaos (when access is given manually, documents are sent to multiple people, developers knock doors and get the information they seek).

Ass pain

How to prevent failure?

Prepare a checklist for onboarding in advance (or use our ready-made template) — include the information about who is responsible for what, where to get access, links to the necessary documents, and so on. Here is a sample list:

  • Accesses (VPN, API, Repositories, Postman, Swagger, etc.)
  • Description of the team structure. Who should I contact for any questions?
  • Instructions for configuring the dev environment of the project.
  • A backlog of tasks for new developers, with designated priorities, if known.
  • Technical specifications for development (including the UI kit, layouts and links to Figma, browser support requirements, etc).
  • Documentation for the existing functionality.
  • Communication rules (Telegram chat, mail, Google calendar, task tracker, report form, accepted control points — for example, weekly calls). The developer should understand where and in what way to request clarifications on the tasks, how to resolve controversial issues and in what form to report the results.
  • Deadline and project stages with an approximate description of the results for each stage to adjust the deadlines.

If you have your own metrics, methods of evaluating efficiency, project management systems, be sure to explain them to the contractor at the start. To be in line with each other's expectations, both sides need to know the rules of the game. Then the reports will be filled out exactly as needed, and the effectiveness of the specialist will meet the client expectations.

Fact: Our internal research shows how competent onboarding increases the level of a project developer satisfaction by up to 20%, which has a positive effect on his involvement.

Concern: What if outstaffers work too slowly? What should I do then?

At the start of the project, the productivity is only gaining momentum — this applies to both in-house and outstaff teams. Do not rush to form your opinion while the processes are being configured. Experienced contractors know that all potential problems usually manifest themselves in the first weeks, so they are especially attentive to the project at the beginning.

A view from the client's side

The period by which it is possible to draw conclusions about an employee strongly depends on the role. For example, a designer or a tester may show the result faster -- usually after two sprints. In fact, we are ready to give an employee for up to three months before we draw our conclusions. If we don't get what we want, we ask for a replacement. This does not happen very often though.

But what if the adaptation period is left behind, and the developer fails to show the expected results?


How to prevent failure?

Immediate feedback is a key to success. Discuss with the contractor what went wrong and why the desired result is not being achieved. The right actions on his part would be to conduct an audit, talk to his employee and identify the weaknesses. After that, you will decide together what to do - replace the employee or eliminate those weak points.

We had a case when a client came and said that he was removing one developer from the project. The client didn't want to give it another thought — "no, that's all". When we found out the reason, it turned out that there was a conflict between our developer and another team member, which interfered with the common project. We offered to transfer the developer to another team within the same project and give him a two-week trial period. As a result, the developer worked another four months on the project, until its completion. If there is no motivation and involvement issues, and the staff technical skills are at a sufficient level, look for other reasons for inefficiency — they may not be apparent at first glance. There are few good developers on the market, but there are even fewer good managers and communicators, especially in conditions when everyone works remotely. As practice shows, there are almost no unsolvable problems. If you react in time, there will definitely be a positive effect.

Below are some more recommendations that will help you maintain a good pace and quality of work:

  • Share your project time estimates with your manager and he will have a clear picture of the project and the risks implied.
  • The developer's qualification should correspond to the tasks. Do not give the Middle a task of the Technical Leader level. The best way is to gradually increase the complexity of tasks and let your employees grow.
  • Have you added a manager from the contractor's side to the work chats yet? Do it right now!
  • To avoid the risk of adding too many extra hours, check whether the specialist works only on your project or distributes his time between several projects? At Holyweb, we adhere to the "one developer — one project" rule so as not to reduce efficiency due to constant switching of contexts.

Concern: What if outstaff employees are not as motivated as our beloved in-house staff?

Our experience shows that outstaff employees are usually even more motivated than the in-house team members, as they are determined to achieve a specific result in a relatively short time (for example, to successfully complete a project in 3-4 months).

But if you leave the most interesting tasks to your employees, and call outstaffers only when everything is burning or broken, there may be a decrease in motivation, and even burnout. You are not the one who does that, aren't you?


How to prevent failure?

Keep the promises that you made to the developers — treat them in this matter the same as you treat your employees. Everything you say in an interview should be true. For example, if you need to work with large volumes of legacy code from three years ago, do not hesitate to say it directly — they may be used to similar tasks, but they have the right to know what they face.

Don't be afraid to give outstaffers more freedom and higher-level tasks. Maintain a balance between refactoring and developing features that will allow the developer to get to a higher level. One more think that does not motivate anyone is coding for nothing — if you worked on a feature that never gets used, it's discouraging and demotivating, even if the work was paid for.

Do not encourage overwork, even if the employee himself takes the initiative and he is very passionate about the project. It is better to have a long and steady workflow with more or less uniform productivity than bursts of productivity alternating with pockets of wayward procrastination.

Concern: What if specialists don't do my project, but play Dota all day long? I can't see what they're doing there

Managing your in-house team gives a nice feeling of complete control over the situation — these are the people who sit in the office in front of the boss and work every day for the benefit of the enterprise.

Outstaffing assumes that the client takes responsibility for giving tasks to a developer who is sitting in someone else's office, or even in another city. At the same time, each of his working hours is paid. There is nothing weird about the desire to have full control over the process and spend funds rationally.

Some contracts include the downtime payment terms, that is, the payment for all the team's working hours over a given period of time.

Once we worked in one team with a specialist from another contractor and witnessed an interesting situation. For some reason, the client's management forgot about this developer and were not giving him any tasks for two weeks. Then the contractor decided to remain silent and ask for payment in full. This situation made the client to reconsider his practice of downtime payments. It is difficult to comment today on those events, but we would consider checking the contractor's internal regulations to make sure that won't happen at all. Anyway, stranger things happen at sea.


How to prevent failure?

The year 2020 has shown all of us that working from home is something we all can do. Big companies that have been using this model for a long time and have all the regulations and procedures in place to control the staff productivity, from Moscow to Syzran or Bali. Here is the standard work procedure for an outstaffing model - the team performs tasks according to the backlog generated by the customer. The developer tracks the time spent on each task. At the end of the month a report is submitted the client for approval and the hours are paid. The amount depends on the labour costs, that is, the customer can see how many hours were spent on what task, and compare this with the history of commits (portions) of the code. It's a fairly transparent model. You can trace where the time is spent, and the developer doesn't mind the Big Brother who is watching him all the time.

It is important to understand that the backlog is formed on the customer's side. Therefore, if you have difficulties with setting tasks or you do not have time to provide a workload the outstaffing team, do not hesitate to contact the contractor's account manager-discuss and decide what to do.

If your workload estimates fail to come true and the full volume of hours has not been worked, there are several options:

  1. Prevention. The developers (team) estimate their workload and inform your manager about it in advance. Proactivity rules!
  2. Pay for idle hours at a discount to split the load in half. This way, the team is still booked for you, and the contractor covers his costs to stay in the black.
  3. Reduce the team and buy the volume equal to the current need. With new requests signed and issued every month, you have an opportunity to regularly review your plans and adjust your volume of obligations accordingly.

Concern: What if my confidential data gets stolen and sold to competitors?

There is a feeling that it is always easier to maintain confidentiality within the team. However, with the right approach to the organization of the outstaffing process, you can easily achieve the same results.


How to prevent failure?

All the control mechanisms adopted in the team should apply to the outstaff. Bureaucratize the process of transferring, storing and disposing of confidential data. Your staff can use specialized software (for example, Citrix) for secure internet access.

To access the customer's services, a VPN is usually used, which provides a secure connection to the corporate network and allows you to use the customer's services (Jira, Gitlab, Bitbucket and other internal services). In some cases, only a username and password are used to connect to the VPN, in others — two-factor identification using a special device (token).

In large organizations where data privacy is especially important (for example, in banks), there is usually a security service and its own software that provides the possibility of remote connection. This part usually flows smoothly as contractors have good reasons to meet your requirements and observe your safety regulations. Optionally, hire an outstaff developer in a less than part-time position to give him access to your internal information systems.

Companies work under a signed NDA to ensure confidentiality. Many customers go for individual NDAs with each of the employees who have access to sensitive data. Add the penalty for breach of confidentiality to the Agreement.

Are we together until the end? What to do to be happy together

The release went to production, the cycle is completed. Now you have a new achievement - you successfully implemented outstaffing model. Now you have a proven resource provider who knows your requirements and features. Expand your interaction and achieve great results. But what if…

broken heart

Concern: What if the contractor leaves me? He may leave the project or take half of the team!

The may be number of reasons:

  • It is not clear how long-term your cooperation will be. There is a good reason why contractors prefer long-term contracts, where both parties have agreed on the terms and duration, to those where the prospects are vague. An ability to schedule their workloads helps contractors deliver predictable performance. That is why it is useful to talk about joint plans and future projects.
  • The developer is leaving the agency. Well, that happens. Make sure you have a process in place to pass all the necessary information along to the new employee. You can allocate a time period for the previous developer to instruct the new team member.
  • You are poaching the contractor's talents. Don't do that. Web Production companies lose a lot of staff anyway. It's natural for employees to seek new prospects with some of the clients or other companies. Will it be profitable for you onboard one developer and lose five more who will stay with the contractor?
  • You never indexate the wages. In case of very long projects, the pay rates may grow as wages increase (autumn of 2020 showed how quickly this can happen). Therefore, outstaffing should be viewed as an HR process, and not as mere purchase of workforce. The chain reaction works in a simple way: you don't indexate, the supplier is not able to increase his employee's wage, the employee quits and you lose him/her. If you plan a long-distance run, make sure you include the pay indexation in the agreement.

The outstaffing culture is currently in the growth stage. Customers and contractors are working together on the new rules to make their work more efficient. With the demand for the outstaff growing at an incredible rate, a viable interaction model is something we all need to develop quickly to meet this demand and thrive. This article summarized our experiences in order to identify and address some of the clients' concerns. We aimed to provide support to employers to move beyond stereotypes and have some tools against the most common risks.

We wish you good luck in building a win-win interaction!