Our Make team recently set out to create a platform where freelancers can grow and find great jobs, while minimising the other hard things that come with freelance life. For more information on how Make became our freelance team, check this article out.
On Thursday 28th March, we hosted an AMA on the ZATech Slack Community, and the OfferZen freelance team answered questions on how elastic dev teams can be used to scale dev capacity quickly. The aim was to help developers learn more about how hiring freelancers can help fix their burning backlog.
Meet the team:
Here’s some more information on the members of our team who worked on responding to the questions that we received:
Ben: As the head of Make’s freelance community, Ben has experience coaching freelancers to, not only find the right missions, but to thrive in them too. He’s passionate about building relationships with developers who want to use Make as a platform to help them level-up through solving problems with software.
Naomi: As the freelance mission manager, Naomi is focused on matching company members with great freelancers as well as ensuring that missions are successfully executed. Using her experiences and learnings from working in cross-functional teams, she aims to make a difference in the lives of developers and companies who want to build awesome tech products.
Dan: As someone who has worked as both a freelancer and permanent employee, Dan has a host of personal experiences to draw from when thinking about the freelancing space. As Make’s technical team lead, he is currently focused on using freelancers to scale his own team, so that he can level-up productivity and team agility.
Having touched on why freelancing is critical for agility, how to onboard freelancers and learnings from our own experiences, here are some of the highlights from the AMA.
Top questions from the AMA:
If I built a system that I know I won't be maintaining, aside from commenting the code, what can I do to make it as easy as possible for the person who will be doing this work?
Dan:
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. The most critical aspect is a test suite - it doesn't have to be full unit tests, but at least high-level smoke tests that can capture the system's intended behavior better than comments. This will help the new dev be way less scared of introducing regressions. If it's a complex system, it helps to include a decent read-me document. I also like to include an up-to-date system model, just a whiteboard drawing of how the high-level components interact.
Here’s a cool article on this topic: “Software Documentation: For The Good Of The Maintenance Engineer”.
Does Make plan to assemble mercenary teams for projects? For example, 1 ops, 1 back-end, 1 UX designer etc.
Naomi:
That's definitely in the pipeline. We've started by focussing on software engineering roles only, to ensure that:
- We've figured the value prop and service offering for freelancers and companies, and
- We get the basics right.
We've already had some missions where we get an experienced dev to help the customer scope a project and then we match another dev to work on that subsequent mission. Exactly how the offering of teams will evolve, will be determined and figured out after we've done proper customer development. But we plan to be adding PMs and UX/UI designers very soon!
Do you treat new freelancers like staff; onboarding them and doing code reviews for the first few projects?
Dan:
The first step, when we work with freelancers, is to give them a decent onboarding doc which explains our team heuristics. Here’s an example of our freelancer onboarding doc. Daily recaps are a great way to stay connected with what they're up to and what decisions they're making. To help others with difficult questions like this, I’ve started releasing videos with tips on winning with freelancers, you can check them out here.
When working with freelancers, a big concern is code quality - beyond just linting stuff - more on how you do things, and how you structure projects etc. What’s the best way to ensure this quality?
Dan:
We do PRs and reviews for each deliverable feature - I like to stay involved throughout the process. But sometimes the freelancer will be working on something I can't really give input on - that's why we hired them as a specialist. Although, for the freelancer's sake, feedback is always useful for learning, so I try to stay involved and share as much knowledge as possible. Tight feedback loops prevent misalignment as soon as possible.
As freelancers come and go, do you phase them into the team’s usual rhythms, like daily stand ups, or do you work with them in a different way?
Dan:
This largely depends on whether the freelancer is remote or on-site, and how core their work is to the product.
For remote, non-core freelancers, we ask them to post daily screencasts which show their work so that we can give feedback. We find that this is more asynchronous. On-site devs join our normal daily standups immediately, often they enjoy interacting with the team. Freelancers working on core systems will also have frequent check-ins with our stakeholders - like any full-time employee would.
How do you ensure your freelancer developers aren't inflating their hourly numbers or deliberately working slower than necessary?
Ben:
Generally, we find that it’s the manager’s job to prevent freelancers from deliberately working slower as well as to ensure that the freelancer delivers on time and according to the spec.
This requires careful thought and communication around what needs to be done, which means having well-structured project initiation meetings and clearly set outcomes. Then, we try to track those outcomes diligently. One way to do this is to use a time-tracker like Harvest. One of our freelancers, Luke, wrote up his methods for this here. As Dan mentioned, another great way to do this is to get the freelancer to do a daily screencast of what they’ve built that day.
If you use Make, then you’ll have the added benefit of our support. We check in with the freelancer and the company on a regular basis to:
- Find out if the project is running smoothly, and
- Provide feedback either way if things are not up to scratch.
Ultimately, it’s up to the manager to decide:
- The level of granularity at which the mission should be tracked and reported on, and
- Whether or not the value is being delivered.
We actually work on a daily, not hourly, rate since we believe that people should be given more freedom and responsibility to deliver. If you micro-manage someone too much, then it can kill motivation, creativity and trust.
Dan, what challenges did you face while working as a freelancer, and do you enjoy permanent or freelancing more?
Dan:
They both have their own advantages and I feel that it depends on the stage of life that you're in. When I was freelancing, I loved having the freedom to travel and work in my spare time; it was all about shipping code efficiently to enable my lifestyle. Some folks really enjoy taking on completely new projects every few months, and freelancing is ideal for that.
I really love my permanent work at the moment, because I'm working really closely with a smart team and I get to invest in a product over many years.
My biggest challenges while freelancing were all the parts that weren't actually writing code. But my biggest fail was that I didn't pay my income tax for two years because I was used to PAYE.
Are there any best practices on freelancer contract clauses that can help set the company and the freelancer up well?
Naomi:
When it comes to contracting, the number 1 principle to remember is fairness. But you should also keep in mind why a contract is required in the first place. For a freelancer, a contract is super important because it gives them surety in the job - especially since the scariest thing about freelancing is the lack of job security. For a company, contracts protect their commercial and IP assets. So it's very important for them to ensure that they have clauses which protect their confidential data and information, as well as intellectual property rights.
Using these WHYs as a foundation, write up the contract, but keep it as simple as possible and use plain language. It really isn't necessary to be overly verbose on the very basics.
The most important terms to list in the contract are:
- The names of the contracting parties (in most cases this will be the registered company name)
- A description of the service that is being contracted
- Obligations of the freelancer and company
- The project’s starting date
- The hourly/daily/monthly rate
- Where the job will take place (onsite/semi-remote or remote)
- Whether the payment is dependant on the output or the actual days and hours that are worked
- If there are any conditions, the contract must be very clear about what those conditions are
As a general rule in contract law, it is best to ensure that all terms are clear so that they are not open to different interpretations. Badly written contracts increase the probability of contractual disputes arising.
How do you vet, monitor and manage companies?
Naomi:
Firstly, we make sure that companies who want to work with our freelancers understand what's expected of them at every step. Then we make it clear that we expect both parties to take the venture seriously and move fast. By making sure that all of the necessary clearance and decision-makers are available upfront, we can be sure that this is properly communicated to all relevant parties.
Does Make use freelancers to build Make? If not, why not?
Dan:
I love this question! We've recently changed our system architecture to make it super easy to scale our dev team. Firstly, hiring takes ages, so it makes sense to use freelancers to be agile. Secondly, we have varied tech requirements that change over time, so it doesn't make sense right now to hire a full-time infosec or devops person.
Right now, we are working with 3 freelancers on our own platform, and we’ve worked with a total of 5 this year. I'm super impressed with how productive we've been able to be thanks to freelancers.
I’ve learnt that the ideal missions for freelancers are things that don't require a full systems view. Some recent missions have been to: