Has your project come to a state where it seems like the only way to move forward and meet deadlines is to hire new employees?
If you are absolutely positive that increasing manpower will solve the problem of the project’s delay, I recommend familiarizing yourself with The Mythical Man-Month: Essays on Software Engineering. However, if the decision has already been made, new staff will be hired anyway. Sadly, if you ignore Brooks’s law, the actual project delay might be catastrophic to your company.
How, then, can you get the most value from new hires? Roll up your sleeves and onboard them.
Make them feel safe
You need someone totally immersed in the task at hand — the work that is essential and profitable to the project. However, many new team members don’t have any contract of employment — they work as free interns or part-time workers without any social benefits (e.g. health care). They are often expected to prove that they are worthy enough to be treated like regular employees. Are you sure that somebody who is constantly worried about an unclear employment contract, long working hours, health insurance issues and vague assessment criteria is capable of doing miracles to your project?
You obviously need to evaluate every new person — just make sure to establish your formal partnership on fair terms, like a contract for a short trial period (the most common one is 90 days long).
Make it easy to join your project
You can directly benefit from arranging several things before a new hire starts their job. You can prepare all assets required by a new employee once, and later take advantage of them.
Software issues
Operating System
Setting up a project environment can take a lot of time, time that could be spent on implementing new features. If your team is required to work on a particular OS, make sure it is already installed on all workstations. However, if the team has freedom of choice, inform the freshly employed person that they can work on the OS of their choosing — prepare all required prerequisites: e.g. an installation key for Windows, a USB drive with a Linux OS, a newborn child for others, etc. — and set up the system. You will save a good few hours from their first day of work.
Dockerize the environment
To make sure that the development environment is compatible with the one on the production server, you can use Docker to set up a complete, well functioning ecosystem. A well prepared and maintained docker-compose.yml file can save your current and fresh employees a lot of headache. In case of a need for setting up a fresh workstation (when the old one is broken or you’ve just hired someone) it will take just a few minutes to install and warm up a fully prepared environment— and all requirements are listed in one file so there is no need to interrupt a senior developer to verify the settings.
Provide all credentials
Prepare all accounts and access keys that are needed to work in your company beforehand. You can hand the new employees everything they need to authenticate themselves in one package. Make sure to obligate them to change their passwords on the first time they log in. You can also create a LastPass account for them.
Look after readme.md files
For projects that are not publicly available on GitHub there is a tendency to overlook the importance of readme files. This is serious negligence, since a well-maintained introductory documentation for a project is invaluable when a new developer joins the team.
Build readme files in your company using a standard template and update them as projects evolve. Consider including the following sections:
- Description,
- Requirements,
- Running the application locally,
- Usage,
- Running the tests,
- Contributing,
- License.
Do not hesitate to tailor readme files to the specific requirements of your projects. It will significantly shorten the time needed by a new employee to contribute to your projects.
Prevent information overload
New employees have a lot to remember during the first days and they can feel a little bit overwhelmed. A simple welcoming tour is essential but not sufficient. Identify issues that are common for every new employee and find a routine for dealing with them.
Welcome guide
Your new hires will appreciate an easily accessible source of all vital info — who can be addressed in particular cases, a summary of the usual workflow, where the leave of absence form can be found, etc. Keeping the instructions up to date will save time during future onboardings. Ask your new staff about issues they encountered but couldn’t find in the guide and update it accordingly.
Mentor
Appointing a tutor is also a great idea, but remember, your team has regular duties to maintain as well, so automate as much as you can and do not overload the tutor with too many tasks during the onboarding.
| By doing so, you can shorten the time before a developer can start writing code by hours and often even days. Furthermore, the rest of the team can be much more productive when they don’t need to constantly lean over the shoulder of the newbie to help them. |
Keep your eyes on the prize
Thanks to all these efforts, you can significantly increase the chances of a commit on the first day. After all, you hired developers to deliver new features — the sooner they start doing so, the better.
Now you can focus on making sure that the quality of code in your company is still compliant with the highest standards, even though you expanded the team.
Clean code
Agree on the rules
Oblige your team to adhere to software development best practices — keep a list of common values and principles shared among the developers and maintain the code in compliance with it, without any exceptions.
If an application was written before these coding principles were known to the company, it is harder to maintain it with every passing month — to the point where its development is simply bug-driven and extremely costly. As such, don’t underestimate the importance of best practices for creating software. After all, they were agreed upon among the most experienced developers.
This will also help you hire only those programmers who are capable of following them. Avoid candidates who describe these practices as unattainable, impractical or unrealistic — their incompetence brings nothing but poor architecture, hidden bugs and dreadfully high maintenance costs.
Collective code ownership
One of the many advantages of code reviews is opportunity to enforce craftsmanship on new employees. The code they produce is code that the rest of the team has to understand and deal with. Every pull request should be as small as possible to speed up a code review and an integration with the codebase.
Do not hesitate to use pair programming as it ensures a better understanding of the system, reduces bugs, and optimizes the usage of the skills of the team members. A new employee will grasp the application context much faster and the team will be able to form a justifiable opinion about their skills.
Shared understanding
The anticipated outcome of every task should be well described — a laconic and ambiguous goal description is effortless to scribble down but it doesn’t take into account all scenarios needed to fulfill a user story. It avoids meeting actual requirements and opens a wide door for miscommunication. Concisely written acceptance criteria ensure that all the needs of the client are met and introduce a shared understanding of the task among the team. To increase the benefit, make sure that the criteria are prepared in a fixed format and can be easily used for writing tests.
To ascertain that every developer in a team knows when their task can be submitted for a pull request, double-check that the Definition of Done is precisely composed and easily accessible.
Encourage asking for help
Many developers tend to sit with a problem in solitude working towards enlightenment and, finally, a solution. Even in a team of the “full-stack” developers there are people more familiar with particular technologies. Make sure that everyone knows who to call for help in case of a javascript issue, and who is the best in solving database concerns. Organize your office space so that frequently cooperating employees are sitting nearby.
Adjust the workload of the developers responsible for assisting a new team member. If they are as loaded as usual, they may tend to disregard calls for help or answer in slapdash fashion.
| Collective code ownership will protect an application from crashing after merging new code. The codebase will be easy to read and understand, code reviews will be fast and projects will be less expensive to maintain in the long run. |
Measure performance
If you already utilize the Gitflow workflow, code reviews, pair programming and Scrum on a daily basis, you won’t encounter any trouble when you try to assess the value added to projects by the new staff. If you always scrimped resources for those good practices, the time has come to implement them and enjoy the benefits.
Evaluate new code frequently
The easiest way to evaluate the quality of new code is to use code reviews for every merge request. By assigning different team members to reviewing distinct tasks, you will gather more diverse feedback and your new hire will have the opportunity to learn from many experts in a short period of time. Use the Gitflow workflow to maintain every task on a separate branch. Update tests when new code arrives — this will give you the assurance that fresh code won’t break in production.
Estimate tasks in points
Abstract points allow your team to have an insight into the pace of work on a project even though developers perform at different speeds. If you convert points into hours you are losing the accuracy of that insight. Imagine a task estimated at two points. It can take one developer 5 hours to finish, another may need 10 hours and a new hire even more.
Do not expect the velocity chart to immediately grow by the number of points delivered by a developer who is more familiar with the project. Remember that the new hire is not intimate with your application yet, and the rest of the team will spend some time helping them. Therefore, you can even end up with the velocity chart dropping for the first few weeks of onboarding.
Eliminate known obstacles
Be mindful of the work conditions in your office. There are several issues that, when ignored, tend to lead to occupational diseases or even sick leaves.
Poor ergonomics
Make sure the workstations are safe and ergonomic. Get rid of short, narrow desks without height regulation, avoid placing more than one person at a single desk, do not put workspaces too close to each other just to save on rented office space. Invest in ergonomic keyboards, forearm pads, monitors with adjustable height. Your team spends most of the day pinned to the desks you provide and recovering from posture defects takes months.
Staff overloaded with work
Do not overwork your employees. You should even think about reducing the number of working hours. Thanks to using Scrum properly (that is Scrum, not Scrum-but), you will be able to measure the value added to the project by the team working 30-35 hours a week. You may be surprised that the results are still satisfying. Programming is much different from the assembly line, a higher number of man hours does not translate to a bigger impact so nicely.
Obviously, overtime will produce more code, but the success of your projects does not rely on the number of lines of code. Paying attention to quality is more profitable.
Programmers tied to their desks
Let them know, that they are allowed short breaks from staring into the screen, like taking a stroll every hour. Solving a complex problem requires the ability to look at it from many angles. The time when developers are making themselves tea is also the time when their minds are occupied by looking for the best solution for the current software issue. Even a chat with another programmer in the corridor can tremendously help. Do not force them to stare blindly into a monitor and constantly hit keyboard keys.
| Once again, software development is not an assembly line – focus on quality, not quantity. |
Inadequate light and ventilation
Check whether the lighting is suitable for prolonged computer work. Remember that an office that is too dim or cold-lit can lead to many eyesight defects. Temperature also plays a role in productivity — let your employees control the air conditioning settings.
In a job description, the assets listed above don’t look as impressive as a billiard table, darts, regular alcohol parties or free cookies, but they will definitely attract the experienced and thoughtful candidates.
The aforementioned bonuses can lure many applicants but be aware that they may not be as focused on the job as you would wish. Furthermore, if you use the cool-looking facade to cover the lack of basic amenities, every valuable employee will move to another company as soon as they have the opportunity to.
The gain
Shorter onboarding
- Dockerized application environment,
- a welcome guide,
- prearranged workstation,
- all permissions and accounts required to start the work set up earlier,
- encouraging asking for help.
Ability to measure the value added to a project
- Scrum,
- Gitflow Workflow,
- estimating in abstract points.
Lower maintenance cost, faster implementation of new features
- Clean code,
- unit tests,
- code reviews,
- simplified workflow,
- pair programming.
The pain
Hiring new staff won’t speed up development right away. Every boost from a new employee will be charged with communication overhead — you can use some of those tips to make it significantly smaller — but it will still be present.
Regardless of the methods described in this post you won’t see new features faster the next day or the next week a new person joins the team. But using those practices will make the road less bumpy for the company and may reduce the need of hiring more people in the future.
The alternative
Just push new people to the office and be very amazed that your project missed the deadline anyway.
Photo by Aral Tasher on StockSnap