COVID-19 has turned our world upside down. There is hardly an industry that has not been affected by it. Nowhere has this become more obvious than in the way we work. For many months, entire sectors were entirely occupied by remote work. Well, not entirely…
One small sector has been working remotely all along. What was new to most has been the norm in the blockchain space. Although remote work can be pleasant, asynchronous work creates its own dynamic. The strategy, plan, execution, and communication need to be more structured than in an office environment.
Nothing to worry about, you think, armed with your months of remote work experience. However, remote work in the blockchain space comes with its own set of issues:
- A lack of professionalism: while people in the blockchain space are talented and hard-working, the entire industry still is a bit “rough around the edges.” Move fast and break things is the industry’s M.O., but that comes at the expense of a good user experience.
- Overcomplicating things: hash rates, consensus mechanisms, and token economics aren’t concepts you bring up during water cooler talk. Explaining things in an easy-to-grasp manner is a challenge for blockchain natives.
Well, that sounds like even if you structure the work process and talk to your blockchain people, you might not understand them. Let’s consult Google for help about working with a remote developer team. Going through a couple of articles, you’ll find they all recommend…
…setting clear goals & expectations.
…having clear responsibilities.
…structuring the process.
…communication, communication, and more communication.
Sounds quite general, doesn’t it? Maybe we should specify this a bit for working with developers.
This is precisely what we did. As veteran blockchain developers and remote workers, we know what works and what doesn’t. We distilled our years of experience in 5 Do’s and 5 Don’ts of working with a remote developer team.
What to do when working with a remote developer team
Bring developers in early
Before any project, there is an idea. This is exactly when you should bring in developers into the picture. Quiz them about how feasible the idea is and how you can realize it. They will also have a good understanding of what architecture to use. You should leave questions like which technologies to use and which design interfaces work well. Their insights will save you a ton of time and energy that is better invested elsewhere.
Just like how you cannot ask an engineer early enough how to build a house, you cannot be too early when asking a developer for their input.
Be specific with your demands
The more precise your requirements, the better the outcome will be. If you tell your engineer just to build a house and you’ll check back with him when it’s ready…you might not like the result. The same is true for working with developers.
Communicate what you want your product to do and what problem it solves. Your developers need to know all the different scenarios of how your customers might use it and why. By giving precise guidelines, you prevent misunderstandings and make their job easier.
Bring interesting problems
Do not despair if you aren’t asking them to build the next software behemoth. Your developers will still give it their all. But just like in any other profession, unusual problems are the most exciting to solve. The more interesting your project, the more engaged your developers will be when writing the code. This can make a surprisingly big difference in team morale, so don’t hesitate to bring forward an ambitious idea.
Use tools to maintain communication
At Rapid Innovation, we use:
- Google Meet for video chat
- HelloSign for digital contracts
- Gmail for external communications
- Slack for internal communications
- Figma for UI/UX wireframes/mockups
- Loom for explainer videos
- Google Suite for documents/spreadsheets
And that’s not even a complete list. If that sounds like a lot, remember that you’re better off talking too often than not enough. Communicate early, often and get straight to the point. Your developers will appreciate the feedback you give them and incorporate it into their work process. Long periods of silence are a recipe for misunderstandings when working remotely. This applies to everything including payments, and your project will stay on scope, on time, and on budget.
Respect your developers
Yes, we know how non-developers imagine developers: And yes, there is some truth to that. Developers can sometimes be introverted, technical in their speech, and maybe a bit “geeky.” But remember, they take an idea you have in your head and turn it into a functional product someone uses and appreciates. That is pretty amazing, so be polite and respectful when communicating with your developers. They’re masters of their craft and be warned that not all of them correspond to the image you might have in your mind.
What not to do when working with a remote developer team
Don’t come unprepared
The better you understand your developers’ process and the language they are using, the better the outcome is going to be. You don’t need to learn a programming language to be prepared, but you should have a precise understanding of your idea, the problem you are trying to solve, and who is going to use your product. The more preparation you put in, the better your project brief will be. This will set up your project for success right from the beginning.
Don’t assume anything
If you think it’s easy to do, maybe it is, and maybe it is not. Don’t take your developers for granted because their work will only be as good as the guidance you give them. Even if it’s beating a dead horse, don’t hesitate to get in touch with them via one of the remote communication tools. Even a quick email or a short voice message is enough to make sure the project is on track, and your developers are working towards your desired outcome.
Don’t skimp on the resources (time and money)
Just like with investing, it never hurts to have a bit of spare cash and spare time up your sleeve. Your developers can get anything done for you, but it might take a bit longer or be a bit more expensive than you initially anticipated. Maybe they need another pair of hands because you assigned them a particularly challenging project. Whatever the problem, estimates are just that, and complications can always arise. As long as you keep the communication intact, it will get resolved.
Don’t be too finicky about the details
You should come prepared but don’t overshoot into the other extreme and try to micromanage. Luckily, most clients understand that the tech is best left to the developers themselves. After all, you wouldn’t tell your engineer how to construct your house either. Developers know what technology is the best fit for solving a problem and why, so leave that part to them.
Don’t expect perfection right away
Nothing comes out perfect right from the start. If your app or website is a bit rough when it sees the light of the day, that is perfectly fine. Your developers will refine the code and remove the bugs. At the end of the day, they are working towards your final product being excellent. If the road to that is a bit bumpy, that is part of the process and no reason to panic.
The world is new to remote work, but we are not. We’ve been doing this for a long time. Many different projects, stakeholders, time zones, and countries later, we precisely understand the ins and outs of remote work. We practice what we preach and follow all of the guidelines you just read ourselves. This is our contribution to making the blockchain space a bit easier to understand and a bit more professional.