Forbes: An Insider’s Guide To Outsourcing And Outstaffing Software Development

John Sung Kim 4 min read

Originally posted on Forbes.com

As many say costs for software developers have soared across the U.S. and Western Europe, outsourcing to arbitrage labor costs has not just become popular but also increasingly necessary.

To build two SaaS companies in the Bay Area, I’ve leveraged offshore development teams to a degree of success. I also had a chance to be a marketing consultant for a leading online marketplace for developers and am the CEO of an outsourcing company, so I’ve become intimately familiar with this industry over my career.

There are many talented, ethical agencies and developers across the world; however, just like in any market, extensive due diligence by the client is a must. Before hiring outsourcers to build your app or hiring recruiters to source offshore labor, here are three insider observations you might consider:

1. Outsourcers, outstaffers and recruiters commonly portray interns as juniors, juniors as mid-levels and mid-levels as seniors. Because this practice has become so widespread, I’ve found there is market pressure on many good vendors to sell their staff this way. So clients should manage their projects intensely on a daily basis to ensure consistency and quality.

2. Failure rates for apps built by outsourcers can be incredibly high. While there is no published data yet, I’ve seen very few examples of outsourcers who have built and launched a commercially successful product on behalf of a client as a turnkey service.

3. I’ve seen some recruiters start to offer research and development (R&D) center services to clients to compete with outsourcers. This new trend of not only sourcing the developers but operating the office and administrative functions on behalf of the client have additional fees. Over time, this could reduce labor costs for the clients, but clients need to make a bigger upfront commitment.

Given the state of the current market, I suggest implementing these best practices before engaging any outsourcing, outstaffing or recruiter firm:

1. For outsourcers building the entire turnkey app for you, ask for the references of at least two software applications they have launched successfully. Code is only one part of what makes a software application successful, so if the response is “we have none” but you still like the firm, you can engage your product or project manager to manage the outsourced staff directly.

Also, ask the references how the outsourcer accommodated change requests. Your app’s scope or project is likely to change multiple times. You want a partner who is adaptive, but being adaptive in IT can be as much about the outsourcer’s culture as it is about their process.

2. If you’re looking to outstaff to add to your existing product and team through recruiters or R&D centers, you may want to intensely focus on the interview questions and test tasks assigned to the candidates. For example, when I ask a candidate, “Why do you want to work for us?” and the answer is something akin to “for more money” and not “I want to work for a ‘product’ company,” that developer never lasts with us for more than a year.

I’ve also learned to ask what local conferences or Meetups the candidates belong to. Voluntary self-education is one of the leading indicators I’ve seen in how much value a developer will bring to our projects over the long run.

But by far, the “marquee” question I ask every developer is, “Have you contributed to any open-source projects?” While not every top developer contributes to open-source projects, I’ve noticed that many open-source contributors are top developers.

It may be harder to find developers who contribute to open-source projects in emerging economies, according to a GitHub open-source contribution map, but we’ve found this is the single biggest determinant (other than cultural fit) of whether a developer will produce at an elite level.

3. Go through a trial period without firm commitments, and if the developers are to your liking, prepare to offer a term commitment of a year or more to the vendor. In my experience, outsourcers and outstaffers often have their developers sitting “on the bench” some of the time, so term commitments mean they don’t have to suffer a margin loss — and you could negotiate some of this savings in reduced fees.

As a negotiating tactic, you can also offer to prepay their wages quarterly or every six months.

4. Look for providers that focus on both a vertical and a software language. I believe the vendors that are efficient with your time and money are so because they focus on a specific vertical — like fintech or mobile games — and have expertise in one or two languages.

I recommend avoiding shops that claim to be experts in “Java, Python, C++, and AI/ML” and that spam you with faces of attractive females representing their agency’s expertise. These are often bottom-of-the-barrel operators. I’ve found that most of the good shops specialize in a vertical and specialize in a language, and they have plenty of work from referrals — so they don’t need to spam anyone.

5. Negotiate the monthly wages and the buyout fee if you decide to make the developers a part of your permanent team. Outsourcers and outstaffers need to charge more than what they pay the developers to make reasonable net margins.

Sales costs, office space, recruiting and bench-time contribute to overhead. In my experience, average buyout fees range from one month of wages to one year, so negotiate — as the market prices range drastically.

As Bloomberg suggests, the demand for talented and experienced tech talent in the U.S. continues to rise, and the BLS reports that unemployment for the professional, scientific, and technical services sector was at just 2.5% in December 2018 — so sourcing labor from other countries may become a necessity, even for Series B- and C-funded startups. Understanding nuances of the regions where you hire and following some best practices should save you a lot of time and money — and maybe some midnight migraines as well.

8 Simple Ways to Improve Your Client Communication

Anna Medvedeva 6 min read

Talking with clients involves many variables like business, money, strategy, and of course the project itself. But no matter how good your code quality or analysis, the client will always remember how well you communicated.

Communication itself is an intricate jigsaw puzzle incorporating psychology and “soft skills” that can tease out what the client really wants – without the client knowing what they really want. Only through this type of “proactive communication” can you achieve the optimal results for you and your clients.

At JetBridge (and hopefully your work environment as well) we’re encouraged to speak up and challenge our clients if we disagree with the best manner of executing the project’s goal. This requires diplomacy and the courage to vocalize your opinions and ideas. Or as our CEO John often says, “Stand up for yourself. Speak up. Speak out.”

So I wanted to share what I now understand as some simple tricks and tips that help international software developers look and sound more professional.

1. Where to talk: Make sure it’s easy for the client to communicate.

 Do: Send a letter where you ask which way/platform is most suitable for the client to use in order to connect with you. If you are suggesting any platform the client doesn’t have any experience with, make a small tutorial/call/text that explains how to use it and its benefits.

 Don’t

  • Be silent and wait for the client to suggest something.
  • Send an invitation to any platform without making sure the client knows how to use it.
  • Be afraid to make better suggestions that may improve communication with the client.

Tips:

  • Always be available, reply to your emails within one day, answer any calls/messages from the client, even on weekends. Just a simple reply where you schedule a call on workdays will do.

2. Understand your audience:

Do: Make sure you talk the way your client understands. Talk with data, prepare analogies, and try to adapt what you are trying to say into something the client will understand. 

Don’t

  • Overload the client with too many technical terms if they’re non-technical.
  • Deep dive into a very isolated and narrow technical part, not thinking what is most important for the client to hear.

Tips: 

  • If the client doesn’t have any prior technical background, use common words to explain technical jargon. (e.g. use ‘system’ instead of ‘back-end’, ‘website’/‘app’ instead of ‘front-end’, etc.)
  • If the information you’re trying to explain is still too hard to translate, try to help the client understand the underlying technical information in broad strokes (at a “10,000 foot level”).

3. Prepare for the meeting:

Do: Prepare a small list of talking points and issues before the meeting. If there will be several other attendees, research, and prepare who they are and what role they play in the client’s company.

Don’t:

  • Be late.
  • Be unprepared and puzzled with the topics discussed.
  • Wait for the client to discuss all the points needed.
  • Have a clear agenda for the call.

Tips: 

  • Know if the meeting will require a video. Prepare any needed programs/apps beforehand so you can instantly access it if the call requires sharing your screen.
  • Check and test beforehand whether your audio, video works properly.
  • If you don’t know the answer you can say you will check in with the rest of the team and follow up.
  • Have a “green screen” virtual background using tools like Zoom or be in a room where there is little background noise and what’s behind you isn’t dirty laundry. 

4. Discuss everything, don’t assume. 

Do: Double-check what the client asked to do before you start because you may have different views of the subject. It helps to eliminate any misunderstandings and wasted time/money.

Don’t

  • Stay silent and be afraid to ask sometimes even obvious questions. 

Tips: 

  • Answer all questions. It may sound too simple, but double-check that all the client’s questions have answers and you missed no important points. Read and check every email or message that was sent.
  • Don’t be afraid to suggest something better for the client. Starting from part of a feature, UI design, or a way to do something. 

5. Rough estimations: Make assurances, but no promises.

 Do: Make sure the client knows that the estimate is very rough and may change. If you’re not comfortable and hesitant to answer, tell that to the client and explain your reasoning. You also can ask for more time to answer. Don’t be afraid to “push back” on the client if it’s her or his fault that the project is being delayed!

 Don’t:

  • Be afraid to say it may take more time than expected.
  • Promise an exact date and time when it will be delivered; it will be misleading if you don’t meet your deadlines and may lower the quality of delivery.

 Tips: 

  • If you need to do more research or you’re waiting to meet some requirements, you can tell the client how long it will take.

6. Status update: Be proactive and reasonably overcommunicate

 Do: Make sure the client knows the status of the projects at least once a week. Inform about extra added features, testing status, and any upcoming changes. The client should be comfortable with the amount of information they get.

 Don’t:

  • Stay silent and make the client call/write you asking about the status repeatedly.
  • Bombard the client with information overload. 

Tips:

  • It all depends on the project of course, but generally do not update the client more than 2-3 times a week. 

7. Delivering (parts/features): find the best way to show and explain the additional feature that you recently delivered.

 Do: Send a small screen recording showing how the feature can be used and where to find it. Or make an appropriate explanation by text or using screenshots. The key point is to make a simple but useful guide for the client to see the feature and the progress. Eliminate any guessing part from the client-side.

 Don’t:

  • Hide it, or think the client will instantly see the difference with the recent update. 

 Tips:

  • Understand your audience and double-check that the explanation is easy to understand for the person with no tech background.

8. Feedback: get feedback from the client as soon as possible. It will reduce the time between feature delivery and overall development.

 Do: Ask the client to review the added feature as soon as it’s delivered. Comment on how they can test it and where to find it. It should be easy for the client to see and understand what they should test. Demand that the client also help in the user testing!

Don’t:

  • Deliver features silently and make it pile up.
  • Make empty promises to “punt” the hard discussions until next week.

Tips: 

  • Encourage more questions and discuss any parts you’re not sure about.
  • Save and document everything the client said, it will help to track your progress, plan any features that you discussed, and not forget anything.
  • Make sure you address the feedback, and the client didn’t repeat any negative feedback repeatedly.
  • Clients shouldn’t be searching for the updates by themselves. Make sure they know what to expect.

Perfecting both listening and speaking skills, fully understanding the intricacies of customer business, brand communication strategies, and its target audience will ultimately lead to success. I might say that every project, as well as a customer, is truly unique but the framework listed with 8 simple steps can perform miracles – not just for your client but for your career.

Decentralizing Social Media

No, it has nothing to do with blockchain.

What kind of language should Facebook forbid? What kind of regulations should the U.S. government promogulate regarding whom Twitter can ban?

☞ Who cares?? ☜
Not me.

A depressing amount of energy and ink is wasted on these questions which shouldn’t even be issues in the first place. We don’t have to base our public discourse on platforms that corporations or even governments control.

Continue reading Decentralizing Social Media

How To Write Effective Tickets and PRs

Roman Kyslyy 2 min read

Although it might be tempting to quickly file a ticket that will scope multiple work segments and give it a short description (that is clear to you and maybe a few teammates), later such tasks may affect negatively on the entire team’s productivity.


Divide Et Impera

Here’s a blogpost from guys who do project management tools for living, on why it’s important to properly size the task and break it into smaller chunks.

A summarized list of reasons:

  • You can’t remember everything. So while working on big pieces of work sometimes it’s easy to lose focus and accidentally skip something important.
  • Smaller tasks are way easier to estimate and describe clearly.
  • Smaller tasks produces less code that is easier to review effectively. Also frequent feedbacks help us to keep ourselves on a right track and improve implementation in the fly.
  • Completing a task feels good. The more often your work is delivered, the more often your brain releases dopamine.

Imagine working on some food delivery service and creating a task like “Implement ‘become a deliverer’ flow on front-end”. It might be worth breaking it down into pieces like:

  • “Create base UI components”
  • “Extend front-end services with ‘become deliverer’ flow API calls with unit tests”
  • “Implement ‘Personal Info’ step layout with Cypress tests”
  • “Implement ‘Transport’ step …”

It is also a good practice to create SPIKE tickets if you feel uncertain of possible implementation ways. Investigation results are good to be discussed with team members afterwards.


Reasonable Ticket Structure

Here’s a list of things that speed up developer’s understanding of the problem ×100 times:

  • Acceptance criteria – an answer to a question “What should we have/know/be able to do when work on this task is done?”.
  • Clear steps to reproduce the issue if it’s a bug-fix ticket (imagine yourself reproducing it at app’s initial state).
  • Screenshots/GIFs/video attachments of known front-end bugs.
  • If you have any guesses where the bug might be fixed, post this info in ticket description.
  • Links to designs really come in handy for layout implementation tasks.
  • Links to open/merged PRs, that would help quickly find code of changes you made.
  • What the motivation is. Explain the problem that you want to solve and when appropriate, present your idea for a solution to the problem but leave room for discussion or alternate approaches.

How About Pull Requests?

Main purpose of a PR is not just to merge your changes into master, but to give other people a good understanding of your work’s context and reasons behind your changes. Perception of all that stuff is way easier when reviewing a short PR that scopes some single logical concept (or at least not too many of them).

Short PRs are good because they:

  • Speed up code review process and consequently the product development.
  • Reduce bugs introduction into codebase.
  • Don’t block other developers and reduce chances of conflicts between branches.

When reading through your finished work try asking yourself “Will other people easily understand what and why is happening here? Will they not lose focus and understand all the connections between changes made?”.

If not, there’s absolutely nothing wrong with breaking your PR into bunch of smaller ones that would be easier to digest.

A couple of great ways to make PRs enjoyable to read through:

  • Add a link to the ticket where changes are requested.
  • Give it a sufficient description of what changes were made to achieve requested result.
  • Add screenshots, GIFs or videos of layout implementation results.
  • Provide steps for local testing, if appropriate.
  • Add comments to your code that you expect to be unclear for others for some reason (although of course we aim to write self-descriptive code needing no explanations).


Try thinking of tickets and PRs that you create as a product that you desire to sell. The more you commit to the effort of creating it – the more grateful and happy will be people working on it and reviewing it.

Cheers!

The Senior Developer Scam

John Sung Kim 4 min read

Think you found a great software developer for “cheap” on a marketplace or thru email spam? Unless you know how to code, it’s likely you’re going to get scammed. Here’s why –

There’s a wave of scammers paying experienced developers for the ability to impersonate their LinkedIn or professional profiles. It works like this:

  1. Scammers (some of them offshore outsourcing companies on marketplace websites) will pay experienced developers on LinkedIn anywhere from $200 to $600/month for the ability to share their LinkedIn account.
  2. The scammers then “sell” the experienced developer’s services to unwitting customers (usually non-technical founders or small business owners).
  3. Instead of the experienced developer actually doing the work, the scammers then have junior talent work on your project.

This scam works because many non-technical founders or small business owners want to believe that they found a $100 bill for $20 (or a $90/hour senior developer for $35/hour). It’s a natural human emotion to want to find bargains, even if it sounds illogical (the global pricing market for software engineers is incredibly efficient – how is it that you found a bargain after 4 hours on Toptal)?

Non-technical customers also don’t know how code actually works, so when they see an MVP (Minimum Viable Product) demoed by the scammers, they don’t realize that the code will break after more than 50 users, or that no company in their right mind would ever pay money to acquire this code base (which they will find out about in technical due diligence – which is always done before a big company purchases a small company). Or that there is a very high chance the app is totally insecure (as in a rookie hacker can break in and steal all your user’s info in 30 minutes).

But by the time the victims figure this out, they’re months into the process of building their app and often $20k or more into this failed project.

Because if it sounds too good to be true…