We had the opportunity to sit down with Zayn Blore and Matthew Mottola prior to their talk on how they drive distributed teams and how leading organizations both large and small embrace distributed teams.
Event: https://www.meetup.com/Remote-Product/events/269969502/?isFromReg=true
About the Speakers
Zayn began his career competing with Microsoft & Netscape to create a web browser. Sadly Microsoft won, but it spurred him on to learn about coding, team leading and product development. In the intervening decades in the IT industry, he built and launched products handling billions of pounds for FTSE 100 giants to highly confidential ones with medical & legal data for small private companies which need to be ultrasecure. In the process learning and expanding his skillset from being a developer, team leader and project manager. Recently his focus has turned to the more complex problem of business change and engagement in product development, through the formation of Simplify Change (https://www.simplifychange.co.uk/) and his role in it as COO, heading their product development of BEE Insights and other products.
https://www.linkedin.com/in/zaynblore/
Matthew is the author of The Human Cloud and Cofounder of Venture L (https://venturel.io/) — the all in one collaboration tool helping remote freelance teams work seamlessly at scale — on how to drive virtual distributed teams. Remote talent has been Matthew’s secret weapon to drive product. In parallel, Matthew led 15 remote freelancers to build his book The Human Cloud with co-author Matt Coatney, while building and leading the Microsoft 365 Freelance Toolkit with hybrid teams on campus and globally distributed. According to Matthew: “Thinking distributed unlocks the best talent in the world, and enables exponential returns in speed and quality. As product leaders, we’re only as good as the teams we lead, so why constrain ourselves to one physical location?”
https://www.linkedin.com/in/matthewmottola/
Why do you lean into remote freelance teams?
Zayn:
Remote Teams have grown on me over time, as they offer numerous benefits over traditional full-time on-site teams. They do however come with their own gremlins which need to be addressed to truly get the best out of remote teams.
Over the years I’ve used numerous freelance teams from on-shore teams in UK, to teams in India, Eastern Europe or South Africa. They each have cultural differences which you need to be aware of, but the benefits of being in a timezone which is suitable to support your product or project, having a teams who know a particular culture as well as in many cases cheaper rates depending on where the they are based makes for a compelling case.
One key benefit is a reduction in time people spend ‘on the bench’ so to speak. Waiting for the next project to come in. With work outsourced to freelancers this is no longer your concern, and the freelancer is then given the freedom to work on other projects. Resulting in a higher utilisation rate, so everyone wins.
It’s really important to stress that by moving to a remote freelance team model you get access to experts across the globe, so you can pick and choose from subject matter experts as suit you, rather than being restricted to a limited pool of talent (which may already be tied up in other projects). This can’t be over emphasised.
Matthew:
It just makes sense. I never intentionally planned to hire remote freelancers. Instead, I always looked at how to get the work done based off my own situation. Being young, generally this meant having little to no resources.
For example one of my favorite projects was designing a University textbook in an Ebook format. I had written the content, knew I needed design, but had no idea the technologies required. I was living in San Francisco, and when I asked around, there was no way I could afford the local talent. I saved up for a couple months to have $2,000, then turned to a freelance platform, posted a general description of what I was looking for with a comparable Ebook, and within 48 hours a freelancer out of Nashville Tennessee got back to me with comparable projects and said he could do it within 3 weeks.
I’ve carried this over to every team or company I’ve led. For example, while building the Microsoft 365 freelance toolkit I didn’t have any headcount. Many employees helped, but it wasn’t a traditional 5–10 person with a developer, some designers, and a product manager. Instead, I had a budget to hire Freelancers. Everything from designers, writers, researchers, project managers. To be honest, I actually had no idea how to use Microsoft products. So instead of reading manual after manual, I hired a Microsoft expert by the name of Russ Crowley to basically teach me Microsoft products.
Now I’m not that extreme where I only hire remote Freelancers. In fact I think there are situations where full-time employment is essential. And I definitely don’t believe we should only be remote or only be freelance. Instead, I think there’s a shifting of the balance between full-time employees and Freelancers. While commonly contingent talent (freelancers are contingent talent) might be between 30 and 50% (tech has skewed this to be over 50%), I believe contingent talent should be around 80% while full-time employees should be around 20%.
What challenges have been most pressing with distributed teams?
Zayn:
One of the biggest challenges in my experience is those cultural issues that come up, and along with those different ways of working.
The key to addressing these are being open and transparent on how you expect teams to work. From when weekly or daily stand-ups occur, which documents or processes or sign-offs are needed for each activity.
For example, when working with a team in UK one of the issues that came to light was their willingness to be independent and make decisions on their own. This resulted in changes to the delivery timeline which were communicated back to our client resulting in cost and quality issues.
The converse is also true, where I’ve worked with a team from Eastern Europe which needed all detail up front for each and every feature. If working ways had been agreed up front, along with level of detail required for specification definition the delay and to-and-fro process which resulted could have been avoided.
Bringing the team together, ideally physically, at the beginning of a project is a fantastic way to pre-empt these issues, and create the foundations for a solid, long term productive team without the downsides of a full-time on-site team.
Matthew:
Transparency, and controlling the context for varying levels of it.
For example, one time a teammate sent a draft copy to me for an onboarding email. Honestly, the email needed a lot of work. Let me rephrase that, it was really bad. Now to me, this draft should’ve been public, meaning anyone on the working team could provide feedback. Except the employee sent the draft to me individually through email. So what should I have done? Should I reply via email just to her? Should I reply and include the whole working team? The employee was probably embarrassed by the email. And honestly, the corporate culture on this team was pretty terrible. Even though there was growth mindset posters on the wall, this company is infamous for being intellectually cut throat.
I chose to create a shared document where everyone could see, and pointed her and the team to that document.
Now what was the right call? Should that be private? No matter what, what should be the right channel to respond?
Going forward, my teams now are very explicit around transparency as related to certain scenarios. With feedback, there are two types — personal feedback and working feedback. Personal feedback is things that are behavioral or personal development related, or anything you expect to talk with your boss about during a one-on-one. Working feedback is the actual work itself. When it comes to working feedback, we are radically transparent. No work should be sitting on someone’s hard drive. It should all be open. To the point that as a CEO, everyone from the leadership team down to the intern should know exactly what I’m working on and be able to provide feedback.
How can a leader get started working with remote freelancers?
Zayn:
In my experience the biggest obstacle to this is simply a failure to start, as is often the case with a change it is seen as high risk, with potential consequences being high.
This is in fact the area Simplify Change concentrate on, as we see the failure to adapt to business change appropriately as the biggest cause of project failure that occurs today.
To mitigate this we encourage the use of the BEE Methodology when implementing projects, where this touches on remote freelancers its fundamental to build in processes where communication across the wider team are put in place at the earliest stage, allowing planning, processes and adjustments to be made, and minimising the disruption to people and other processes.
Furthermore this decreases the fear people have in a new change, be that working with a remote team, or with freelancers and should cover all aspects of these with the relevant people in an organisation, from Legal to Security and compliance.
Obviously this can be a complicated process so the first step is choosing a low-risk project which touches on as few people internally as possible. This ‘restricted scope’ project can then be tuned to resolve any potential issues that arise, serving as a benchmark for other projects.
Lastly, as with anything, it’s important to understand the true change of using remote freelancers. If you’re hiring a development team, why aren’t you also hiring freelancers to fill the gaps or solve other problems you have? Why not bring in appropriate experts as and when you need them to harness the power of the modern age.
Matthew:
Three steps.
First, pick the smallest and least risky work. Ideally, work that if it goes wrong doesn’t hurt. For example, I always default to market research. Research my industry, find who you think are my top 10 competitors, then find and synthesize public sentiment.
Second, in regards to remote, I call it the coffee shop challenge. Go to the coffee shop, and sit there for at least 2 hours. Can you get your work done? If so, is it important work? If the answer is no to either of these questions, time to evaluate why. Obviously not all work can be done in a remote manner. But, and I know Covid has probably shown you this already, most work can be done remote.
Third, after you’ve completed these first two steps, throw away all tools and instead ask yourself what processes are best for your organization in regards to both remote and working with real answers. For example what processes will you put in place for working hours? Will you require at least two hours of overlap between the different time zones and expectation for a teammate to respond within 2 hours? In my experience, we’ve used all different types of tools that quite frankly do the same thing. Trello, Asana, G-Suite and G-Drive, Microsoft Teams, Notion, Jira. But with every single tool, it has always come down to the processes, not the tool itself.
