The Saturday Checkout

#6

Setting up a reliable and effective offshore Shopify development team

Read time - 15 minutes

13/01/2024

So, your Shopify store is big enough to warrant hiring an agency, or hiring some devs to help you out. You've done your research, and you've decided to go offshore.

On paper, it's a great idea. You can get a team of devs for a fraction of the price of a local team. They're eager to work, and you can get a lot done in a short amount of time.

But, as you've probably heard, it's not all sunshine and rainbows.

I got a decent pedigree on the subject matter. I've not only hired and managed hundreds of offshore staff, I've personally set up and managed a 100+ person BPO in the Philippines (Berthaphil, Clark) while also run teams of offshore developers for my own businesses, and other's businesses.

There are a bunch of gotchas and pitfalls you need to steer clear of, otherwise I can personally testify you'll end up with an unreliable & ineffective team costing more than you bargained for.

With that said, setup and managed properly, an offshore team can be a huge asset to your business. And today, I'm going to show you how to do it.

Let's get into it!

TLDR; Quick & Dirty

• Realistically, you're going to need a project manager to manage your offshore team. If you don't have the time & technical expertise in-house to manage your team, you're probably better off going with an agency, or hiring locally.
• You're going to need to spend a lot of time upfront to get your process watertight. This includes things like:
  • Setting up a project management tool like Jira or Asana, communication tools like Slack or MS Teams, and a code repository like Github.
  • Setting up a development environment that's easy to use, and easy to get up and running.
  • Having explicit coding conventions, including a QA & code review process that's easy to follow, and easy to manage.
  • Having a clear and easy to follow deployment process, including rollback procedures in the case where things go sideways.
  • You'll also need to set up and follow process for managing your team, including daily standups, weekly sprints, and monthly retrospectives.
• In short, to be successful with an offshore team you need to dedicate significant time & resources into hiring a team while also building out a watertight process that's easy to follow & manage.

Ready to dive into the details? Keep reading...

So first, let's define what an offshore team is, why you'd want to use one, and the potential benefits.

What is an offshore team?

An offshore team is a team of developers that are based in a different country to you. They're usually based in a country where the cost of living is lower, and the cost of labour is cheaper.

For example, if you're based in the US, you might hire a team of developers based in India, or the Philippines.

Why would you want to use an offshore team?

So, just let's start off by being totally honest here.

There's a clear an obvious benefit to using an offshore team: it's cheaper. And often, finances dictate that some businesses have no choice but to go offshore.

And to continue with brutal transparency, apart from costs, I'm not really sure there are any other benefits.

Maybe, at a stretch I could add access to a larger pool of talent, but I'm not really sold on that either.

Anyway, before we get stuck into getting an offshore team set up, let's talk about some of the pitfalls.

The pitfalls of using an offshore development team

1. Infrastucture

There's a reason offshoring is cheaper. You're buying the time of a developer who is based in a country where things aren't quite as developed as they are in the US, Australia, UK, or any other "first world" country.

And like it or not, that means your team probably won't have access to decent facilities, utilities, or be able to afford the latest and greatest hardware.

At first blush this might not seem like a big deal, but it can be a huge problem.

I've had devs lose entire days of work because of power outages, or internet outages ("brown outs" anyone?). I've had devs lose entire weeks of work because their laptop died, and they couldn't afford to replace it.

That's maybe fine if you're running a small store, but if you're running a store that's doing $100k+ per month, where your professional reputation is on line, it's worth factoring in.

2. Communication, Timezones, Language, and Culture

Communicating your specific requirements to a developer sitting in the same office as you is hard enough. Communicating your requirements to a developer sitting on the other side of the world, who's sitting in their loungeroom, completely and 100% divorced from your reality... well that's a whole other ball game.

And that's not even taking into account the fact that you're probably going to be working in different timezones, and speaking different languages.

There is an implicit expectation that offshore team members will be able to completely "westernise" themselves when working for your brand. But the reality is that's very very difficult to do, and probably just won't happen.

So you're going to have to tread very carefully, and be very explicit in your communication, including expectations and requirements.

3. Quality

There's a myth that offshore devs are just the same as onshore devs, but cheaper.

Truth is, that's 100% not the case.

Even with the best of offshore developers you're going to be dealing with cultural differences, language barriers, and timezone issues.

That said, there are some great devs offshore, and if you're lucky enough to find one, you'll be able to get a lot done for a fraction of the price.

(At least until they get offered more money and bugger off elsewhere - happens a lot!)

For the majority though, you'll need to set up really clear and tightly defined processes to ensure you're getting the quality you need. That takes serious time and effort to set up, and just as much time and effort to manage.

Chances are you'll also need to give every developer in your team a tonne of training to get them up to speed. In many cases offshore devs are informally trained, meaning lots of bad habits that'll need to be worked out.

4. Overall costs

There's a truism out there that says "the more you pay, the less you have to manage and train"... and to a certain extent that's very true here.

The market has gone a touch crazy with COVID sending Shopify dev rates through the roof and with the recent crash and mass Shopify redundancies, prices are a bit all over the place.

The point here is: You'll save money specifically on developer labour costs... but you'll significantly add to those costs by having to devote your own time building out internal systems & procedures, as well as managing your team.

At the end of the day, you really only save money at scale. A large team of devs, fully trained up, following a well defined process, being managed by a project manager or tech lead, will probably be cheaper than a local team.

And I've been stuck hiring devs from the Philippines at up to $80k per year, and still had to spend a tonne of time managing them, and training them up.

That's not exactly cheap!!

So while maybe in the past you could get a team of devs for $20k per year, those days are long gone.

Okay.. so you've been hit with all the pitfalls, and you're still keen to go offshore. Let's talk about how to get it done.

How to set up an efficient, top quality, and cost effective offshore Shopify development team

First things first... it's doable. I've done it, and I've seen it done.

1. Hire an onshore tech lead or project manager who knows their stuff.

Before you hire any offshore devs, you'll want to set up all the systems & processes your team will be following.

Shopify is a complex beast... there's no true "local" development environment, and as a result different companies build and compile their themes in different ways.

The most recent Github integrations, while a step in the right direction, are still a bit clunky, and it's super easy for a dev to accidentally push up a change straight into production that breaks your store.

So you'll need a tech lead or technical consultant to come in an get this set up.

2. Set up your development environment

Okay, so you've got your tech lead onboarded, and now they need to setup your development environment.

The number one rule we're after here is: Make it hard for someone to fuck up your store.

Seriously, that should be a permenant banner on your desktop.

Once we've figured that out we can start talking about enhancing the developer experience... although in my experience the two go hand in hand.

The new Github integration is pretty good, although commits to the main branch go straight into your live theme, which I'm not thrilled about.

If you have the cash you can hire a technical QA to integrate Cypress or other testing library and Github Actions to run pre-merge testing and make sure nothing is going to explode.

Also, make sure you do Post Verification Testing (PVT) to ensure nothing is broken in the live storem, and solid rollback procedures just in case something is.

3. Project Management, Requirements, & Writing Tickets

Over the years, whether onshore or off, I truly believe a tightly defined and enforced design & ticket creation process is the key to an effective project team.

Seriously, it's the first thing I look at when working with a new team.

Shitty tickets = shitty work.

Always.

So with that in mind, the first thing you'll want to set up is your project management tool. I've used Jira, Asana, Clickup, Trello, Monday, some random open sourced french one, and a whole bunch of others, and on the whole, they all get the job done.

For software development teams I personally prefer JIRA, but acknowledge it can be a bit of a beast, and I'm hearing lots of good things about Clickup.

Ticket need to be clear, concise, and have all the information a developer needs to get the job done. That includes:

• A concise & understandable title
• A clear description of the problem, and the desired outcome.
• Definition of Done (DoD) in list format - what exact outcomes does the developer need to deliver to get the ticket over the line?

I have a strict rule... if a developer does the job according to the ticket specs, and it's not what I wanted, it's my fault for writing a shitty ticket.

When it comes to language and cultural differences, this is even more important. A good ticket is core to getting the job done right.

I promise you, large team or small... if you get your ticketing process right, your dev team will love you, and they'll be able to get a lot more done, better.

4. Coding Conventions, QA, & Code Reviews

Okay, so you've got your project management tool set up, and you've got your tickets written. Now it's time to get coding.

Now it's time to set up your coding conventions, your Quality Assurance (QA) procedures, and code review process.

I'm not going to go into too much detail here, coz you hired a tech lead, yeah? 🙂

Coding Conventions & Reviews

Your tech lead will deal with code conventions, but for the most part I want to see clear and concise code, with comments where necessary, and a clear and easy to follow file structure.

The rule is: How easy is this code going to be to maintain if a different developer has to come in and make changes?

Code review is just an addition to this, so not going to go into too much detail here either. But the rule is: Every single line of code that goes into your store needs to be reviewed by a second developer, or your tech lead.

Quality Assurance (QA)

Quality Assurance (QA) is a bit more tricky, and I've seen a lot of different approaches. Ideally you'll hire a technical QA to set up a testing environment, and write a bunch of tests to ensure your code is working as expected.

You can then feed that into your Github Actions, and have it run every time a developer pushes up a change. That'll give you an automated layer of safety to ensure nothing is going to break when you push to production.

Chances are though you'll just be doing manual testing, and that's fine too. Just make sure you have a clear and easy to follow process for testing, and that you're testing every single ticket before it goes live.

Also, in all scenarios, do PVT on the live store for the main functions of the store. You don't want to be pushing up a change that breaks your checkout, or your add to cart button.

5. Hiring, Training, & Managing your team

Okay, so you've got your tech lead, you've got your project management tool, you've got your development environment, and you've got your QA & code review process set up.

It kinda feels like you're setting up a whole IT department, right?

Well, you kinda are. 🙂

And just like running a real IT department setting up all your systems is just the start. Now you need to hire, train, and manage your team.

I won't go into all this too much, that's a whole newsletter of its own, but here's a few tips:

• There are a lot of bull-shitters out there. Get your tech lead to do 5 minutes of code pairing with every candidate before you hire them. They'll know instantly if they're any good.

• No matter how experience they are, you'll need to train them up on your specific systems & processes. That's going to take time, and it's going to take effort, just just take that into account when measuring their initial productivity.

• You'll need to task manage your team. That means daily standups, weekly sprints, and monthly retrospectives. You'll also need to manage your team's workload, and make sure they're not getting overloaded. For this I recommend a team like DailyChecklist and getting each team member to outline the work they expect to get done that day (no more than 6 hours of tasks per day)

• You'll need to manage your team's performance. That means regular 1:1s, and regular performance reviews. You'll also need to manage your team's career progression, and make sure they're getting the training they need to progress.

• Don't forget to manage your team's culture. That means regular team building activities, and regularly checking your team is happy and engaged.

And I reckon that'll do it for now... if you want more info on running an offshore team, drop me a line and if I get enough interest I'll write a newsletter on it.

Parting Thoughts On Offshore Development Teams

So, there you have it. A quick and dirty guide to setting up an offshore development team. Just like most things that sound too good to be true, the reality is you'll get out of offshoring what you put into it.

I want to be clear, I've worked with and built some amazing offshore teams, and I've seen them work really well. But I've also seen them fail miserably, and I've seen them cost a lot more than they should have.

So, if you're going to go offshore, make sure you're prepared to put in the time and effort to get it right.

That said, if you're not prepared to put in the time and effort, you're probably better off going with an agency, or hiring locally.

And if that's you... drop me a line and let's chat. 👍

Need more tailored advice?

Here at JohnDetlefs.com we specialise in making Shopify stores nice and accessible, and have even saved some clients from expensive lawsuits.

If you need any help, reach out, and let's chat about how we can convert your store from an accessibility wasteland into a fully WCAG compliant utopia where happy customers leave glowing reviews.

Either way, best of luck, hope you're crushing it, and have a great week!

Cheers,

P.S. Found this useful? Share it with your friends. They'll thank you for it. Also, consider subscribing to my newsletter. I send out a weekly email with tips and tricks for Shopify store owners. You can unsubscribe at any time, and I promise not to spam you.