Extending the team with freelancers
Two freelance engineers joined the Careship Engineering team from January to March 2021. Here is how it went and what we learned. #thankyouteam
Introduction
It was my first opportunity to grow the team in my role as Head of Engineering at Careship. We were four engineers and myself when two freelancers joined us. Such a big change could go either way, in our case, it resulted in a pleasant time full of learning.
How to onboard freelancers quickly and efficiently? I don’t have any correct answers and every team can deal with it differently. Here is what I think helped us.
The experience and feedback
Our backend is built mostly with PHP; it was relatively simple to express what we require. George Graham has, with his years-long experience, fit the position perfectly. He oriented himself in our codebase very quickly and was able to contribute in almost no time. Our backend uses CQRS and he confidently developed many query parts of the system, getting closer to the core every sprint.
Jonathan Mullins had a bit of a tough start. The project manager and I were not exactly clear about the scope of his projects until the last minute. He kept his calm, adapted, learned, and delivered. Over time we came to understand how his strong knowledge of WordPress could help the team. He upgraded our content management system, implemented changes suggested by designers and set up the regular release time with our content team.
It was great to see how they both fit into the team, and receive feedback and ideas from them during their stay.
(Both George and Jonathan granted permission to publish the feedback and scope of their work.)
Here is why I think it went well
Our development and delivery process is not perfect, but it’s solid enough to allow us to onboard new engineers quickly and efficiently.
Simple enough continuous integration. We don’t use fancy git-flow, manual testing scenarios or a complex release process. Instead, we cover our code with a sufficient amount of unit tests, create small code increments which are easy to code review by splitting user stories into small subtasks, and use feature switches to allow us to merge code directly to the main branch. With that, we know that we can deploy to production any time and a simple one-click pipeline in Jenkins does the work for us.
Both freelancers submitted their first pull request, the in-house team reviewed it and the code made it to production on their second day at Careship.
Capable senior engineers in the team. I’m very grateful to have senior engineers in the team, they shone during the onboarding time. Their good knowledge of our projects, their vision, a solid code base and small sprint stories made it a smooth ride. All questions seemed to be answered just before they were asked. And any obstacles were resolved very quickly by the team.
Great team culture. Everyone in the team is very open to giving and receiving feedback. And it may be contagious. Both freelancer engineers very quickly picked up the pace. It was great to hear how the collaboration evolved and how everyone exchanged and learned.
I noticed that there is a difference in reporting between a scrum team and freelancers. A scrum team runs in regular sprints and reports at the end of the delivery cycle. Both freelancers liked to report their progress directly to me at first. It took little effort for them to adopt the scrum processes.
What may we do differently next time?
Both freelancers were attending scrum events, Careship’s company reviews and other meetings at the beginning (we tuned that later in the quarter). It may have not been the most efficient way to use their time. But I believe that it paid off in the quality of deliverables and their strong commitment. They knew what Careship stands for, what we do and what our vision is.
If I were to hire engineers for a project not so closely connected to the core of our business, I’d consider keeping them in another rhythm. Maybe individual sprint cycles and reporting, skipping regular standups and all-hands meetings. It would require a project to be well decoupled from the rest of our business logic, with clearly defined requirements and connection points. And also more focus from the responsible project manager.
We experienced what I knew already — onboarding is expensive. It takes time. With freelancers, I would focus on technical project requirements a little bit more than with permanent hires to reduce the technical onboarding to a minimum.
Closing thought
Hiring freelancers isn’t just about finding a nice profile and handing over the project documentation. It won’t work by itself. They should collaborate with the in-house team, integrate their work and share knowledge about the project to make the most of their contribution.
I’d be happy to hear about your experience in the comments.
