The Hitchhiker’s Guide to Software Development

(and other ways to fail upwards…)

The great thing about failing a lot is that you can re-position it as “deep experience” and move from sad sack to industry expert overnight. And boy do we here at TurnKey have a ton of experience and expertise.

We’ve failed so much that each time it happened it was like welcoming an old friend to dinner (where they stick you with the bill). Though failure came in all shapes and sizes, one particular area of misfire was how to build and optimize our software development team.

First the boring backstory: prior to starting TurnKey, we spent 12 years building a venture-backed company called Tonic that became the leading patient intake software for large health systems. In layman’s terms, it replaced that boring wooden clipboard in the doctor’s office that you always wondered about with an easy-to-use mobile application that was integrated with the provider’s backend systems, such as the electronic health record. I just fell asleep writing that paragraph so I am sympathetic to your plight.

Anyway, as you might imagine we needed to build and scale a software development team that could create an enterprise-grade platform within the complexity of the U.S. healthcare system (oh wait, I just did it again). We strived to craft a dream team in a cost-effective way, which was a goal that took us on a journey traversing a wide range of approaches, each of which held promise but ultimately proved unsuccessful until we landed on the right one.

Of course, every situation is different and an approach that is ideal for one type or life stage of a company may not be best for another. But despite this caveat, here is our Hitchhiker’s Guide (since that’s what it felt like) to creating and scaling high performing software development teams, and ultimately why we decided to codify all this “experience and expertise” into TurnKey so we could help others avoid the same devastating pitfalls we had to live through (did you catch that sly product placement?).

Let’s go!

Our First Failed Approach: Hire All Local Talent

When we raised our seed round, our initial thought was disbelief that anyone would actually give us money for anything. But our attention then quickly turned to how to spend our limited capital in order to get the most bang for our buck.

So we set off to hire all these amazing developers, who of course would want to trade stock options for a reduced salary given that we were going to change the world in new and wondrous ways. As it turns out, A-level engineers like to get paid a market rate in addition to options, work in a plush office (at least pre-Covid), have amazing benefits and enjoy half-day Fridays. The cliché that there is no free lunch in life isn’t true when it comes to American tech talent — most literally get a free lunch every day.

Thus, we quickly realized we had no chance to successfully scale this approach since we weren’t a bright enough object to attract the brightest people, and we didn’t have the resources to compete effectively with the big sexy global tech brands. The lesson here is that if you are able to hire who you want, where you want, and at any price, then yes hiring local talent is the best approach. But if even the FAANG’s of the world have a problem doing this, then it’s safe to assume that most of us mere mortals will too.

Our Second Failed Approach: Outsourcing

So after we recovered from the sticker shock of building and scaling our own team locally, we did what any self-respecting entrepreneur would do — make it someone else’s problem.

We needed to craft a prototype and began working with an outsourcing company based in Ukraine. The cost was right, and the prototype (mostly) worked. But once we moved from building a prototype into creating a company that required a scalable product and scalable processes, things broke down faster than a dockerized container with a few bad lines of code. [Editor’s note: DevOps humor never ever works.]

The first challenge we faced with outsourcing was very high turnover amongst the staff. When we dug deeper into the problem, we realized the people who were assigned to our account were inexperienced in building a scalable product and were underpaid. If you are a top engineer, you don’t want to work for an outsourcing company because you hold yourself to a high standard for quality and are turned off by churn-and-burn, project-based work that is designed primarily to generate an invoice. And because no one at the outsourcing firm was coming to us directly with these staffing problems, we had no visibility into how these challenges were being handled. This made us incredibly vulnerable.

More importantly, our incentives were fundamentally misaligned. We were motivated by building an MVP that could get us to the next milestone (raising a Series A and picking up initial customers) but our outsourcer was motivated by maximizing its profit goals, which roughly translated into “charge a lot, pay out as little as possible and quickly move on to the next project.” This is when we realized that if we didn’t control people’s pay, we couldn’t control what they produced.

The astute reader can probably guess the outcome of this approach: our prototype was enough for a slick demo but had to be completely rebuilt from scratch in order to actually work when installed at a customer. We wasted a lot of time and money, though it did drive us to develop a taste for a stiff bourbon.

To be fair, outsourcing is one of the most ubiquitous approaches out there, and it has its haters and its fans. The camp where you land usually depends on if you used outsourcing for the right reasons. I’d hate on a fork too if what I needed was a knife. Just to show that we aren’t completely biased (not true), here is when outsourcing actually can be a good approach:

• For legacy projects.
• For rapid prototyping to validate a concept (with the assumption that you will need to rewrite the code if you will continue with a project).
• For specialized needs, like automated test coverage.

But if you want to build IP for your core product, outsourcing will either fail outright, or end up costing way more than it would using any of the other options listed in this overly verbose blog post.

Our Third Failed Approach: Hire Offshore Talent Directly

Whoever said the third time’s the charm can kiss my grits.

Ok back to our story. So now we’ve failed with outsourcing too and we were left to decide what potentially fatal move we should make next. Shockingly our Board had not fired any of us yet, though it likely crossed their minds. It was clear that we were on a path to becoming a unicorn — minus the horn, the wings, the thick mane and the powerful legs. So basically just a torso that can’t move.

To remedy our development problem, we decided to learn our lessons from the first two approaches and hire individuals directly in Ukraine since despite our problems with the outsourcer we could tell that there was a ton of world-class development talent there. Plus Ukrainian developers are culturally Western and speak English, which means nothing gets lost in translation and productivity is just as high as developers stateside.

Our first step was to try to recruit people directly. This is really difficult when you live in San Francisco and you have to manage job boards in Kiev. We looked at using outside recruiters in the local market, but the commissions were equal in expense to their U.S. counterparts. We were ultimately successful in finding a few good folks, but it took a ton of time and energy and proved distracting.

And since all of the team members were set up as contractors, we had to send out individual international wires to each person in order to pay them. This was a manageable process at 10 programmers, but by 20, it was a royal pain in the arse. I still think Bank of America should at least send us a toaster for all the exorbitant fees we paid.

The other challenge that emerged is that because our team members were independent contractors, they were responsible for getting their own computer equipment, paying their own taxes, finding their own healthcare benefits, and more. This meant that while this approach proved great for us (ie the company), it severely limited the pool of people you can hire since most folks don’t want to deal with these headaches, and they don’t like the perceived instability of a contract relationship.

And you can also quickly run afoul of local labor laws. Yes, that too…

All of this compelled us to migrate to Approach #3.5. This is a hybrid where we opened up a legal entity inside of Ukraine, which allowed us to hire people directly. It definitely had its advantages: we now controlled people’s pay, could dictate the processes, and it seemed more stable to prospective employees. And we only had to make one monthly international transfer, which is perhaps why Bank of America never sent me that toaster.

A legal entity inside Ukraine also allowed us to sponsor immigration for the best developers using a K1 visa, which can only be done with a subsidiary in the foreign country.

But like most things in life (such as gluten-free Wheat Thins), this was also too good to be true, and ultimately the administrative costs of maintaining the entity were way too high. In other words, opening your own subsidiary sounds like a great idea until you get completely mired down by red tape and bureaucracy. Often times we found ourselves spending more time managing our Ukrainian subsidiary then running the parent company in the U.S. That’s a recipe for disaster (as is the recipe for gluten-free Wheat Thins).

Our Fourth (and Best!!) Approach: Use An Offshore Management Firm

As we became increasingly overwhelmed by the administrative burden of sustaining an offshore subsidiary — all while trying to both raise additional capital and beg, borrow and not steal our way to more ARR — we decided to close down our legal entity and instead use an “employer of record” company based in Ukraine.

This solved some of our problems though not as many as we had hoped. The job of the employer of record is to stay compliant with all local laws and manage payroll. But that’s about it — the rest is up to you (remember that part above about no free lunch?).

We were fine with this arrangement at the time as it reduced the administrative work we didn’t care much about, but still left us free to build the kind of culture and team we wanted. We were in full control over the people we hired, the pay we gave them, and the processes we expected everyone to follow.

But then as we continued to scale our team, we had to also manage all our own custom recruiting, and had to bring on additional HR staff to help manage what had become more than 100 full time staff in Kiev. Employer of record companies (of which there are many) can’t solve for these types of critical challenges — think of them mainly as a utility.

What we wanted — and what we ultimately had to build for ourselves at Tonic due to a lack of viable alternatives — was an offshore management firm that could do everything an employer of record could do (ie simple accounting and payroll), but also perform higher value activities for dedicated development teams like:

· Handle all the recruiting and replace team members if needed.

· Actively reduce churn through regular mentorship of development staff.

· Respond quickly to problems as they arise.

· Deliver proactive team and culture management.

· Offer regular professional development and training opportunities.

Or said another way, an offshore management firm can be the best-of-all-worlds approach that allows you to scale your development team effectively while minimizing any potential downsides of managing an offshore team.

In (Merciful) Conclusion…

Despite our voluminous failures along the way — and I’ve only told you about the ones related to scaling our dev team (there were plenty of others) — Tonic eventually became the most widely deployed patient intake platform among large health systems and was ultimately acquired by a leading revenue cycle management company called R1 (NASDAQ: RCM).

(WARNING: here comes the shameless sales pitch for TurnKey…Try not to roll your eyes until the end.)

We decided to launch TurnKey to help companies large and small battle the same development challenges we did but with none of the pain and suffering. TurnKey takes the Offshore Management model we built for ourselves and deploys it on your behalf. For example, we have our own in-house staff of all-star recruiters that custom recruit your dedicated development team so you don’t have to, and then we also have our own HR staff that provides ongoing mentoring, training and perks so that team retention remains high. All of this is included when you work with TurnKey.

One more cool thing: unlike the vast majority of our competitors, we are based in the United States — Silicon Valley to be exact — so you have a trusted local resource to call at any time and for any reason. And you’ll always get an understanding ear since everyone at TurnKey has been there, done that.

We hope this Hitchhiker’s Guide can help steer you along your own product development journey. But if not, at least you can always call TurnKey (info@turnkey-labs.com, 310–699–6884).