Every single thing you do as a senior leader at your company is generally about delivering value. What this means will of course vary based on your firm and its many stakeholders. But one thing in our present state of affairs is clear enough: In just about any firm bigger than a corner lemonade stand, software is likely going to play a non-trivial role anywhere from being part of a strategically core competitive product, to playing a key role in business processes.

Depending on whose numbers you believe accurate, there’s about 20-23 million software developers in the world as of 2018. In the U.S., maybe 3.5-4.5 million. Discrepancies can easily be attributed to how you count. For example, are QA Engineers software developers? Is a mathematician who works on algorithms, but doesn’t commit code a software engineer? There’s some slop in the numbers. Whatever. Regardless of how you count talented software developers, right now there don’t seem to be enough. (Unless you happen to be pounding code yourself and enjoying having the hot career ticket!) Yes, thousands are in the midst of Python Boot Camps and “Yes, You Too Can Be a Data Scientist”  courses. Still, the bottom line for you as a senior manager is for your current emergency project or other ongoing needs, you don’t have the development resources on staff that you need. And depending on where you are, budget, and all the usual reasons, you may struggle to build internal teams in the currently challenging hiring environment for talent. If you’ve been doing outsourcing for awhile, this article may not be for you. But if you’re new to it or feel like you may be missing something, maybe there’s some useful ideas in here for you.

Quick Back to Basics: Why Outsource at All?

There are plenty of recommendations out there as to why team colocation – perhaps especially for startups – has value. And it does. As well, there’s plenty of thoughts on why it could be best to get the best talent you can anywhere in the world. Which also makes sense. After all, modern tools allow for remote work. OK. So… a stitch in time saves nine, but haste makes waste. Which is right? The usual terribly unsatisfying answer applies, as it often does… It depends on your situation.

Typical reasons for outsourcing

• Custom Design & Development is needed because general solutions are not  available: For whatever reason, available Commercial Off the Shelf (COTS) solutions don’t cover your needs. Some packages may take you part or most of the way towards your needs, but not all the way. You need something either completely custom or elements that extend such software; whether it’s commercial or Open Source.
• Strategic Competitive Advantage: Using off the shelf may work, but if you have some core competitive reason for specialty functionality, and at this point, this becomes a strategic imperative to own the intellectual property. You need to own the capability. And not have any features/functions/benefits that are at the whims or business case of an external partner over which you will have only limited control. (Even if you are a large client. And perhaps even especially if you’re a large client. For example, you could use your heft to drive an external organization’s product agenda, but in doing so, potentially hurt their business. In the end, this could leave you with an insolvent partner.)
• Control: You own the product roadmap.
  • Speed: It will be faster to hire an external firm to quickly scale up a team than it will to recruit.
• Short term needs: It makes no sense to hire for shorter term needs; usually under a year.
• Cost. Cost. Cost. Cost.
  • Yes, there’s no getting away from the perception – and usually, but not necessarily – the reality that costs can be anywhere from 10% – 30% less depending on onshore vs offshore talent. Maybe even less. However, careful here… costs are of course not just about hourly rates.
  • Reduce fixed costs. Leaving aside basic hourly rates, (which could seemingly be higher than internal personnel on a salary basis), fully loaded internal costs might be more than 2x salary.
• Resource Availability: Onboarding an employee or an external firm will always take some time. But it’s sometimes the case that an external firm may have the quality talent you need either “on the bench” or be able to recruit faster than you possibly could for the quality you need for the tasks at hand.
• Subject Matter Expertise: This could be either familiarity with needed technical discipline, or familiarity with a business category.

Partner Size

Company size may or may not matter for your effort. However, for larger companies or larger team needs, typically at least a medium-to-large size firm will make sense for several of the usual reasons: Ability to backfill staff should there be unforeseen individual circumstances, ability to staff larger projects with existing talent, ability to recruit talent if necessary. What constitutes small to large for software development firms is not clearly codified. Both U.S. Commerce organizations and  OECD try to break this down a bit, but not necessarily in useful ways. For the purposes of software development firms, the characteristics can generally be thought of as follows:

• Solo Practitioners
  • Size: These may go by the names independent consultants or contractor developers, but are typically single person operations, maybe one partner.
  • Rates can vary widely based on specialty.
  • Benefits: For small, low risk and tightly scoped projects, this can be a valid choice.  And if truly speciality skills are needed, it may be an only option if fast availability is needed.
  • Risks: Reliability, including both trust issues and unforeseen circumstances faced by a single individual. Also, may be challenging for a single developer to code and fully test their own work. No sensibly reliable ability to staff for 24/7 DevOps were that to be needed.
• Small Shops / Sometimes called “Micro enterprise” or Small Office/Home Office (SOHO)
  • Size: These are typically several to a handful of employees; possibly a dozen or more.
  • Rates will be at low end of country averages given their size and relatively low overhead.
  • Benefits: Personal service. Some minor ability to backup resources. Every client is likely a key account.
  • Risks: Likely a limited talented pool across disciplines and multiple stacks. Unlikely to have dedicated QA function. Likely little or no ability to staff for 24/7 DevOps were that to be needed.
• Medium Sized Firms
  • Size: These may be several dozen to perhaps approaching 100 employees and may focus on design or coding or have both under one roof.
  • Rates are obviously increasing to cover more overhead.
  • Benefits: Still personal service. More capability. Slightly higher ability to backup roles if needed. Usually demonstrable history with quality clients. There may be an additional benefit if the firm is highly focused in a subject matter expertise area that matches your needs.
  • Risks: Likely unbalanced delivery capability across software development frameworks. May be mitigated if firm is inherently specializing in your business category. While possibly may have ability to staff for 24/7 DevOps, this is likely a special case.
• Large Development Firms
  • Size: 100+ employees up through perhaps several hundred. After this, there is – generally – a gap, to get to the next category. (That is, there are many small firms, mid-tier and then a bunch of large firms, followed by a handful that jump to the thousands of employees category.)
  • Rates: In range with medium sized firms; possibly slightly higher, but generally less than the huge firms. Overhead percentage may be lesser than smaller firms as it’s more evenly spread.
  • Benefits: Personal service maintained. Clearer process flow than smaller firms; often some degree of formal project management is assigned, with possible exception for pure team augmentation assignments (vs. milestone based project work). More capability across software frameworks. Likely has subject matter expertise across multiple business categories. Can usually source backup personnel should there be a need. Teams have internal resources to help with challenges. Will all but certainly have demonstrable history with quality clients. If needed, 24/7 DevOps is more likely to be available.
  • Risks: Priority as a client may be somewhat project size dependent.
• Really, Really Big
  • Size: Thousands of employees. These are the Big Names You’ve Heard of. Deloitte, Tata, Cognizant.
  • Rates are generally top of the scale. They not only have significant overhead, but they also – generally – have heavy processes that have non-trival upfront costs.
  • Benefits: They – generally – can do it all. They will have talent across just about every common software stack as well as team members who likely have subject matter expertise across multiple business categories.
  • Risks: Bloat. Extensive discovery costs. Large minimal project sizes and duration commitments. Projects under 6 figures, (perhaps greater), less likely to receive top tier service, but will still pay top tier prices. (If such projects are accepted at all.) 24/7 DevOps likely available, but also likely to be at premium prices.
• The Ugly – This special case bears mentioning.
  • Size: From one to several dozen employees, possibly larger.
  • Rates are cut rate low, at least on surface.
  • Benefits: Seemingly super low cost. May make sense in some highly limited areas where speed to test something is a higher priority over quality, if selected with eyes wide open and the understanding that future re-factoring is highly likely.
  • Risks: These are firms that typically will use templates or ripoff scripts for core functionality and possibly put some weak code around this core. Low quality, low standards and high risk of failure. Final product will all but certainly be starting out with significant technical debt and may suffer in terms of “non functional” requirements such as performance and reliability.

The Onshoring – Nearshoring – Offshoring Question

Whatever the reason you’re outsourcing at all, your primary objective is success. If that means a particular specialty talent, then you’re going to have to go wherever that may be. More generally, here are some considerations.

Onshoring

• What
  • Onshoring simply means you’re hiring resources from your own country. Or at least, nearby geographic location.
• Why
  • Colocation: When onshoring means “right down the block” as opposed to somewhere else in the country, there’s the ability for colocation, meaning the potential frequent in person meetings, and therefore tighter integration with team members than might otherwise be possible. (Note that this isn’t necessarily the case… onshore might still be a firm located in another city. If you’re focused on onshoring, consider if your partner needs to be able to get to you via the metro, a car ride, or if the time and expense of an airplane is still ok.)
  • Communication: Typically, communication will be fairly smooth given both language and cultural similarities. As well, any time zone differences are likely to be small.
  • Regulatory Compliance: You may not have a choice. For some projects, government, possibly finance, healthcare, gaming… there may be security reasons why onshore teams are required. This may be somewhat ironic given that cloud based products might still have offshore components. It may be possible to geo-partition data for domiciling of data constraints, but if there are citizenship requirements of some sort, you may be stuck locally.
• Why Not
  • Cost. Cost is typically a top factor. When talking about the U.S. in particular, high costs can be a non-trivial deciding factor, even though quality of personnel is generally considered very high. The cost of doing business in the United States, from cost of office space, to housing, etc., is generally fairly high. And that’s before getting to talent supply and demand.
  • Talent: Demand is high not just for hiring employees, but also quality firms. While this is a cost pressure issue for talent, it’s also a simpler supply availability issue. That is, even at a higher cost, can you even find the personnel you need quickly enough for your project needs.

Nearshoring

• What
  • Nearshoring means outside your country. For our purposes here, outside the United States. Perhaps obviously, there may not be a truly strict line between Nearshoring and Offshoring, but the difference may generally be thought of as being within a time zone or two and an airplane flight not more than a handful of hours or so. From a U.S. perspective, these would typically be South American or Canadian locations. In South America, advantages include, (generally), solid English proficiency, similar or the same time zone, and relatively easy travel logistics should that be desired. LATAM (Latin American) Governments are also pushing to be technology hubs. In Canada one cost advantage can also be had based on generally favorable exchange rates.
• Why
  • If you have Clear Requirements: Any form of outsourcing benefits from when you have clearly defined requirements.
  • Cost: As always, you’re seeking the best possible cost/value. Look at the cost for office space alone, not just in major U.S. cities, but even in secondary cities, vs. the cost in, for example; South America, or Eastern Europe in the case of Offshoring. Next, consider the Cost of Living Index for employees. For whatever macroeconomic reasons, costs from housing to a bottle of soda pop is significantly less.
  • Proximity: While colocation is unlikely, any desired in person meetings are likely not overly burdensome in terms of air travel and cost. Expenses if traveling to the partner may be less than most U.S. cities.
  • Talent. Software development is – or is alleged to be – among the most meritocratic of professions. You can produce quality code; or not. There are plenty of non-U.S. regions where people have grown up with quality technical education, a solid work ethic, and now have built skills in software development.
• Why Not
  • Quality. This is subjective and anecdotal, however – while there’s always exceptions – you do hear the occasional horror story about projects going off the rails due to inadequate quality.
  • Cost: While likely less expensive than Onshoring, may still be more expensive than Offshoring. When the costs are really low, then quality considerations need to be paramount when considering a partner.

Offshoring

• What
  • Firms outside of the country, and further away than “nearshoring.” While there’s no bright line definition, the common sense definition might be multiple time zones, and a flight over an ocean. Again, from the U.S. perspective, this may mean EMEA, (Europe, the Middle East and Africa), APAC, (Asia – Pacific – East Asia, South Asia, Southeast Asia, and Oceania.) India is well known as a software outsourcing location; though also known to have quality issues if not careful about firm selection. (Though of course, that’s always the case wherever you’re shopping.) As well, India is 9.5 – 12 hours different in time zone from U.S. east coast time. This can be either a negative or a positive depending on how well managed. Eastern Europe continues to emerge as a powerful location; with STEM focused early education, a burgeoning software industry with a reputation for quality, general cultural alignment and generally solid English speaking professionals.
• Why
  • All the non country specific benefits of Nearshoring, plus…
  • Cost: When shopping globally, there’s more selection and therefore you of course have the opportunity to select among even more cost/value options. The usual caveats apply… cheap doesn’t necessarily mean good.
  • Talent: There are regions, such as Eastern Europe in particular, that have become known for having quality software development talent. India has long been a go to for outsourced tech resources as well.
  • Time Shifting Teams: Often, operating across several time zones is seen as a negative, and it can be. However, used properly – and likely with some overlap – it can be a positive benefit. Consider: Teams have some workday overlap and do their product, design, or technical Sprint meetings. Then the engineering staff works while you sleep. In the morning, there’s work product for review and the ability to relatively quickly offer feedback by afternoon. (They key is making sure there’s some overlap in work schedules.)
• Why Not
  • Fully Loaded Costs: If you think for even a moment that the only overriding important factor in offshoring or outsourcing in general is “lowest cost per developer hour” as a good idea, then offshoring is a bad idea for you. Actually, outsourcing in general may be a bad idea for you. There are some overhead costs operating an external team and these may include some travel for meetings not otherwise needed. Most often, the overall costs will make these additional expenses trivial. But they must be considered. Again, cheap quite obviously doesn’t necessarily mean good.
  • Team Integration: If your own team lacks the project management and relationship skills to work with those across your potential partner’s time zones, and potential communication barriers, there could be challenging headwinds for you.
  • Communication Barriers: Even when partner employees speak English well, there can be cultural barriers that challenge understanding. Indian firms, for example, are known to be potentially high quality. However, besides – depending on region – having a 9.5 – 12.5 hour time difference from Eastern time, Indian contractors have been said to sometimes suffer from communications challenges in spite of speaking English, thus requiring atypically more Project Management support; likely form an onshore based bilingual speaker. Not every experience will be as challenging as described here, but this is something to watch out for in some regions. (Note: This is just an example. Every region has its own potential challenges.) Edit: I was informed that link to the article went to 404. Apparently, the authors took it down. Possibly controversial content? I any case, there is an archived version available.
  • Quality: As with nearshoring, quality checks are critical. At the risk of political incorrectness, there are some general guidelines that seem generally the case. These include Eastern Europe and several Asian regions as being relatively high quality, whereas others seem to experience more significant challenges in terms of quality and failed projects. India may be considered a wildcard, where larger firms working with larger established firms can do well, whereas medium and smaller lack the resources to assess quality or manage projects tightly enough to extract needed quality. These statements may very well engender some firey criticism, but… there you go. Do more web research on your own to seek out general perspectives, while of course always remembering individual firms may always be exceptional; one way or the other. It is possible that some negative aspects of Indian outsourcing is more related to the fact that there’s billions of dollars in business here, and therefore, there’s just a higher number of failed projects; even if as a percentage it’s small. There is unquestionably a high degree of talent in the region. The issue is – as always – choosing a reliable partner. See this article Are Posts Like “Why Outsourcing to India Is a Bad Idea” Just Weak Arguments of Competitors? for a seemingly balanced opinion.

Hybrid

• What
  • Variations on Onshore – Nearshore – Offshore Themes
  • The shape of this can vary. A firm may have onshore assets such as project management, perhaps design, and then have engineering offshore. Or a handful of senior architects onshore, in multiple cities close to clients, with other engineering offshore. The flavors vary.
• Why
  • Potentially best of all worlds.
  • Communication Barriers Mitigated: Typically, hybrid companies will have some components of management, (from Project to Product), and possibly design, who are onshore. As the primary interfaces to development, they can help mitigate any potential misunderstandings. (Due to either or both being bilingual or simply from team experience and shared personal experience with particular colleagues.
• Why Not
  • May be unnecessary for your project type.
  • Cost: With more onshore components, will likely be somewhat more costly than pure offshore management.

Making Choices: Some Selection & Consideration Criteria

There are lots of considerations when hiring an external partner. Here’s just some of the basics to consider…

• Communication: English & Cultural Understanding
  • This is being written from the perspective of U.S. based clients. It’s a good idea to assess English speaking proficiency of any potential partners. Both basic language and cultural alignment is critical. Full linguistic fluency may not be required. However, it’s critical you can be assured that fundamental understanding of requirements is occurring.
• Good Fit:
  • This is part cultural and part company size. Does you partner have the scope of capabilities and team availability to handle your level of job?
  • This also includes development methodology. Are the firms processes and procedures a good match for your work style?
• Cost Structure
  • Pricing is obviously a component, but you’re looking for alignment across pricing, billable methods regarding milestones or time & materials, payment terms, and so on.
• Experience plus passion. More than just code.
  • Your business partners will ideally be not merely “resources that can write code,” but passionate craftspeople with whom you can connect on a personal level. Quality may very much be about compliance to specifications, but it’s also about effectiveness in getting the right things done. So by all means, test for technical competency, but also assess passion and commitment to your vision insofar as you can.
• Talent competition is extreme right now.
  • As of this writing, there is a world wide demand crunch for quality software development talent. Understand that part of your shopping for development partners may be as much – sometimes even more – than just finding technical ability. If at all possible, find specialists that particularly love to work on your type of projects. It may be tempting to find a low cost solution and be done. This might not end up being the fully loaded costs though. At the same time, take care to understand what depth of subject matter expertise you need. For example, you may be a healthcare specific company, but your project is essentially all about data transference with new partners. You might not need healthcare expertise nearly so much as serious expertise with microservices and APIs. So do understand the type of talent you’re really seeking.
• Depth of Bench
  • Most dev shops of reasonable size will have a good spread of product and project managers, design people, business analysts, senior architects, and developers at various levels across technology stacks. Exceptions might include highly focused specialty shops. Either way, you should see a breadth and depth of experience that can be brought to bear on your particular challenge.
• Software is getting expensive.
  • It is true that with much out of the box software, development frameworks, cloud services, and so on, that many aspects of software development and deployment are more efficient and less costly than ever. At the same time, the complexities around custom development of late can include regulatory, security and scaleable architecture needs unlike ever before. Simple apps, (web or mobile), may be relatively inexpensive in both historical and real terms. But solid, reliable custom applications will still cost at the higher end of the spectrum. And there’s of course a huge difference between a simple pretty app with a tiny content management system vs. something driven by complex back end server processes. Make sure to budget accordingly.
• Close Collaboration
  • Avoid throwing requirements over the fence with the expectation that final results will be just what you had pictured in your mind at the outset. There’s a reason Agile software development is in vogue these days. It’s not just the latest bright shiny thing. It works. It works because you can both see and feel progress in reasonably short increments of time. And adjust as necessary. But to do that, you have to maintain contact. You have to show up. You have to be available to your partner teams as necessary. While this may seem basic, it can be the case that critically important stakeholders fail to offer their input in a timely manner. And this will often be to ill effect.
• When Things are Failing
  • This is really a topic for an entire article. There’s an old expression with regard to hiring employees. It may seem rather horrible, but it goes like this… “Hire slow. Fire fast.” This doesn’t mean a failed Sprint, (or even two), warrant triggering contract exit clauses. It does, however, mean you need to watch deliverables closely and if results are falling too far short of expectations, demand corrections quickly. If fixes cannot be quickly achieved, you’re better off making hard choices early.

So Let’s Go Software Shopping…

Let’s stop here and not get deeply into how to find a specific quality software development partner. Suffice it to say that personal recommendations from trusted colleagues is always a good initial route. And there’s all manner of directories and search terms that can quickly build you a nice list of prospective partners.

What it comes down to is there are really two major considerations when looking for a software development partner. Quality and Reliability. These are not the same thing. Quality is related to actual skills and output, and reliability is the ability to deploy those skills to consistently deliver solid, working code and products. Software development is almost always a bumpy road. Requirements change, bugs happen even with the best developers and firms, and so on. Of course, you have a budget and the money is important. But sometimes, you just can’t afford cheap code any more than you can afford a cheap car. That is, if lack of quality or reliability results in too much re-work to make fixes or ongoing maintenance, what have you really saved? This is obvious. But some folks just go body shopping for the cheapest deal anyway.

Outsourcing development – or components thereof for your needs – offers lots of value that can generally be realized reasonably quickly. At the same time, just as with anything else in your business, if you’re not paying attention, efforts can spin off in unanticipated ways. Hopefully the information here will help you in your goal to build something great!