Not everyone understands that after the start of work, interaction with the team cannot be interrupted. If the client has a built-in architecture, code requirements, then connect the developer (give access to accounts and layouts) and leave him to figure it out, nothing good will come of it.
The client must be willing to extend their onboarding system to outside professionals as well as to the in-house team. Discuss your vision, requirements for approaches, expectations for results. Giving regular feedback is the minimum without which a high-quality result will not work.
Keep the promises you made to the developers - treat them in this matter the same way you treat your employees. Everything you say in an interview should not be at odds with reality. For example, if you need to work with large amounts of legacy code, written three years ago. Do not hesitate to say it directly - developers also work with such tasks, but they should understand what awaits them.
Don't be afraid to give outstaffers more freedom and more serious tasks. Maintain a balance between refactoring and feature development, which will allow the developer to get better. Work that will be shelved also does not motivate anyone. If you worked on a feature that did not go into production, it is offensive and demotivating - even if the job has been paid.
Do not encourage overtime work, even if the employee is very proactive and very passionate about the project. Long and consistent work with flat performance is better than bursts of productivity interspersed with failures in performance, motivation and code quality.
It is important to talk to the developer, and not slip into the bureaucracy. Otherwise, the employee may get the impression that he was caught in a hostile environment. All this applies to outstaffers, because they are the same team members.
The reality is that today's outstaffer can become your full-time employee in a year or two (even if you don't expect it at all), and you should immediately treat him as your employee. It is also important to understand that an outstaffer who has left the company with a negative feeling talks about it everywhere, forming the customer's company reputation. How will you then prove that it was precisely because it was an outstaffer? And, most likely, it will only get worse.
- Accessories (VPN, API, Repositories, Postman, Swagger, etc.)
- Description of the command structure. What questions and who should you contact.
- Instructions for setting up the dev environment of the project.
- Backlog of tasks for new developers, with indicated priorities, if known.
- Terms of reference for development (including UI kit, layouts and links to Figma, requirements for browser support).
- Documentation for the existing functionality.
Communication rules (Slack, Telegram chat, mail, Google calendar, task tracker, report form, accepted control points - for example, weekly calls). The developer must understand where and in what way to request clarifications on the task, how disputable issues are resolved, in what form he should report on the work done.
Deadline and stages of the project with an approximate description of the results for each stage to adjust the timing. If you have your own metrics, methods for assessing efficiency, project management systems - be sure to convey them to the contractor at the start. Both parties need to know the rules of the game in order to sync up in expectations. Then the reporting will be filled out exactly as needed, and the specialist's efficiency will meet your expectations.
Competent onboarding increases the developer's level of satisfaction with a project up to 20%, which has a positive effect on his involvement.
