10 takeaways from building an offshore development team
How we built it and how can you do it too as the CEO of a startup
Maybe you are thinking about building your own startup. Startups offer a great opportunity to become an independent person, and having your own business is always cool (if it works). I can tell you a story about how we, as developers, built an offshore startup for the owner.
I have liked computer and software programming since I was 12. Much later, after I finished university, I worked for the government and big corporations on a lot of projects: usually big enterprise systems for banking, insurance, and financial analysis. But all those projects had one thing in common: huge inflexibility. For me, as a software architect, this was not what I wanted, and I dreamed of working for a very flexible startup. One day, I got the opportunity to become a software architect for a Boston-based startup.
1. Have a good business plan
My colleague and I were hired by a CEO who had spent over 30 years trading stock and had become, let’s say, a wealthy enough man. He decided to build a startup for stock market analysis almost as a hobby. Sounds like a nearly perfect job, working for a man like him, right?
He had a business plan and an excellent knowledge of the core domain. Furthermore, he wanted to expand. The only thing holding him back was software development. It was hard for him to keep his development team stable. Unfortunately, his original engineers kept getting lured away by companies like Google, Facebook, and Tesla who suck up everyone in software engineering like a vacuum cleaner.
Takeaway: You really need to understand your business.
2. Take advantage of an offshore
He decided to set up a remote offshore development team, and we were asked to build that team in Prague, Czech Republic, where we are from. It was good for him. Czech salaries are much lower than those in the United States, but the efficiency, reliability, and culture are similar.
We had to spend the first couple of weeks in Boston to get familiar with the core business. Who (from Central Europe) wouldn’t appreciate that?
Takeaway: If you are thinking about setting up an offshore dev team, try Central and Eastern European countries like the Czech Republic, Slovakia, Poland, Hungary, Romania, or Ukraine. You’ll find some very professional developers.
3. Get a local person
Maybe you are wondering how we met the boss, am I right? It was quite a coincidence in our case. I was asked by my former boss who was recommended by his former colleague who was in touch with the owner of the startup.
My former boss became the local manager and CTO of the whole company. The CEO of the startup fully relied on the CTO, and the CTO relied on us regarding development questions. He was responsible for all local management, HR, accounting, legal issues, and leading development across the stormy sea to the bright future.
You may find it quite disappointing that we didn’t discover a bullet-proof solution for “how to meet your new CTO”. But I believe there are plenty of ways to meet your future CTO: websites, conferences, headhunting on LinkedIn, asking friends (it is a small world). Of course, finding a trustworthy and reputable person who can be a tech lead is a difficult task. Everyone who is really good certainly has work somewhere else.
Takeaway: You need a local manager, preferably a CTO or tech lead cofounder, and you should meet him in person. Find someone who has already built some offshore teams.
4. Open a local branch
We opened a branch of the US company in the Czech Republic, and all the developers were direct employees of the local branch. The CEO wanted to have full control of the development team. But that wasn’t the only thing. He really wanted some details to remain business secrets. Also, we were happy to work on a product (as company employees) not a project (as agency employees) because it’s hard to develop a relationship with a project as an agency employee. And, most importantly, you can think about a product over the long term.
Takeaway: It is easier to motivate people who work as employees to get on board with your startup work ethic.
5. Create a virtual office
In Prague, there are plenty of fancy office buildings, even close to the historical center, within a 10-minute walk of the famous astrological clock. Even though we opened an office, we wanted the whole team to be virtual. Every tool we wanted, we used as an online service. For office communication we used Microsoft Mail and Skype, for conferencing Zoom, for the development process Atlassian Suite (Jira, Confluence), and for code versioning GitHub. We sent money via Transferwise, we signed documents with DocuSign, Dropbox was our shared drive, and all our servers were on the AWS cloud. (Since then, I’ve tried GSuite, Google Meet, BitBucket, and a lot of other tools which are suitable too.) Basically, the only hardware we had in the office was a notebook, two monitors, and an internet connection. We were totally flexible. We could work from home. We even tried digital nomading. This setup was hugely advantageous during the COVID-19 pandemic.
Takeaway: If you set up a purely virtual office, you can open it or move it very easily. Limit all possible paperwork.
6. Hire and motivate people
On the other hand, a more time-consuming issue was the staffing process. We spend almost a month interviewing candidates every day. Of course, we knew how many people we needed and what kind of expertise they should have. It was worth the effort, and we built an excellent team, not just regarding tech skills but also regarding interpersonal relationships. We understood each other well.
Motivation was key. There are a lot of big companies full of burnt-out people who are trying to find more satisfying jobs. The ideal situation is if the developers strongly believe in the startup’s mission, its core business, and therefore, their joint success. Our boss was very convincing in this way. We really identified with the company. OK, we also knew the boss was a wealthy man. You know, it is better to work for a stable company that regularly pays you than to live in constant fear of not being able to make your next mortgage payment.
Speaking of motivation, two other things helped a lot: visiting the headquarters in the United States as a business trip and stock options. Those things motivated us a lot. I remember one of my colleagues calculating his gains from stock options the whole day and making a huge mistake. He almost booked a house in Florida before he realized he was two decimal places off. Regardless of his mistake, he was just as satisfied.
Takeaway: Engage developers, offer them stock options, and bring them to the HQ.
7. Establish remote communication
US <-> CZ communication was pretty smooth. We wanted to update each other often. We had standups every day (4 pm CEST, 10 am EST), where we discussed our progress, and a lot of ad-hoc calls with the Vice-President of products in Boston. Remote calling, in most cases, naturally limits calls to just what you really want to discuss and resolve. And many times, the message was short enough to use chat.
The feature specifications needed to be written more formally and were written in the common space in Confluence (a wiki-like tool). We could discuss and comment directly in the document till it was clear to everyone involved. We used that document for code and creating tests and later for acceptance testing. Then the CEO could be sure that he would get what he wanted.
Takeaway: Communicate with the team regularly. Talk face-to-face once a quarter. Write a report about processes, gains, and losses every month. Listen to employee feedback.
8. Get the team to work
We were supposed to take over a classical brownfield project, but it had been abandoned by all the programmers and, sadly, there were just a little comments or documentation. Plus, we immediately had to keep all the systems working and servicing customers. We worked on the operations side first. We successfully acquired all the servers under our management (it ended up doing some nice hacking, which I hadn’t enjoyed for ages). After that, we started working on high-priority and critical bugs that customers had been complaining about for a long time.
After the initial resuscitation and stabilization, we decided to collect the original and future requirements, write tests (originally covering about 2–3%), and try documenting as much as we could before we were able to write new features and start removing technical debts.
Finally, we could start developing our shiny new features in the software. For the boss, just a high-level feature plan was important as well as when we would be able to deliver them. We prepared a plan for him, and he was able to observe tickets in Jira and watch the progress. The development goals were frequently changed, therefore we adopted agile style of development.
We set up a relatively standard delivery process and developed a very very nice continuous integration system based on Jenkins. Since we used Git, we had every piece of code under control and were able to deploy several times a day.
Our main language was Java with Spring Boot framework. In the beginning, we had to deal with a lot of technical debt, but after solving that, we delivered new features very regularly.
Takeaway: Only focus on high-level features. Don’t micromanage. Work with the team on requirements, but let the team estimate them and check the progress.
9. Move operations into a cloud
We had a great DevOps team. Those guys could make miracles happen. Every server we had was on the AWS cloud. The advantage of this was that we could choose the geographical locations. So, some servers were in Virginia, some in Canada, and some in Europe, close to Frankfurt, Germany.
As a result, we didn’t need to operate with any physical servers at all. Everything was virtual. Sure, it was a little bit more expensive, but it unlocked fully-remote operations from any place in the world. And we reduced costs by renting servers for only a particular time.
Takeaway: Have all your servers on the cloud, including those for dev support.
10. Listen to the experts
Despite the fact there was a time to move on it was one of the best working experience I have. My last lesson learned I want to mention is that architecture design is good to discuss well by the team before everyone is satisfied. The design of the architecture often determines the success or failure of a product.
For best results, often take your expert advice. And if you let the team come up with their own solution to your problem after an internal discussion, the result could be excellent. Some may have a tendency, even based on their experience, to promote a specific solution or specific technology. Don’t do that it’s generally considered as a bad practise and it is not well received by developers.
As a boss, you don’t need to be a tech expert. That’s what you pay other people for. It is most advantageous for you to know everything about the domain. It is most advantageous for your developers to be able to bring a new perspective to the domain. They can express their point of view, unspoiled by “we always do like that” opinions, and find a better way how to automate your business process. Take advantage of that synergy. Let them do their job.
Takeaway: Tell your developers WHAT to build not HOW to build.
