Outsourcing is effective.<\/p>\n
It\u2019s cost-efficient. It\u2019s a great way for entrepreneurs, startups, and small businesses to get the required talent.<\/p>\n
And it sucks.<\/p>\n
To be more specific, it sucks away your time, your money, your energy, and your sense of freedom.<\/p>\n
Let me explain.<\/p>\n
First, I don\u2019t think I\u2019m exaggerating when I say this:<\/p>\n
I know the ins and outs of outsourcing more than most people in the industry.<\/strong><\/p>\n After all, I did build a 300+ employee company from the ground up\u2014using outsourced talent. I\u2019ve worked on hundreds of website and app development projects. I\u2019ve spent a huge amount of time flying around the world, meeting clients, and listening to their concerns and complaints.<\/p>\n Now, my company provides as a remote development teams for clients in Europe, America, and Australia.<\/p>\n For the CEOS, startups, small businesses, and solopreneurs who all need work outsourced, we provide tech talent, executive services, and creative work. We get good reviews. In fact, our model has been so successful that we recently just expanded.<\/p>\n And we do this by supplying outsourced talent.<\/p>\n I\u2019m not saying that to brag or anything.<\/p>\n I\u2019m saying it to let you know that when I say \u201cOutsourcing sucks,\u201d it\u2019s coming from someone who\u2019s been there, done that, and lived to tell the tale.<\/p>\n But if I\u2019ve done all that with outsourcing\u2026and I make a living with outsourcing\u2026 then why am I telling you how bad it is?<\/p>\n Outsourcing is profitable…<\/strong><\/p>\n But it isn\u2019t fun.<\/p>\n And when I say it isn\u2019t fun, I\u2019m understating it drastically.<\/p>\n Here are the facts:<\/p>\n Then there are silly detail mistakes that you shouldn\u2019t have to deal with.<\/p>\n You want a luxury entrepreneur lifestyle? You want to build up a series of businesses worth millions? Well you can do it with outsourcing\u2026but it isn\u2019t going to be pretty.<\/strong><\/p>\n It\u2019s going to be a long process of double-checking work, stressing over deadlines, fixing errors that should never have been made in the first place, and losing sleep over things outside of your control.<\/p>\n Does that scare you off the idea entirely?<\/p>\n I don\u2019t think so.<\/p>\n You\u2019re still with me, which means that something about the idea appeals to you. Good!<\/p>\n The fact is, you can save time, and usually money outsourcing.<\/p>\n But here\u2019s what most people don\u2019t understand:<\/p>\n Testing is an integral part of outsourcing, and you cancel out the time and money saved by outsourcing in the effort you spend testing.<\/p>\n Let me tell you a few things I\u2019ve learned over the last 15 years by working closely with developers.<\/p>\n The developer mindset is \u201cHow can I make this work?” But when you\u2019re reviewing and testing, your mindset should be, \u201cHow do I break this?” these are different and conflicting mindsets. You won\u2019t be thinking in a similar manner. That\u2019s a miscommunication disaster waiting to happen.<\/p>\n The developer knows how their code works. So it\u2019s hard for them to look at it with \u201cfresh eyes,\u201d and they will fall into the habit of testing their code according to this knowledge. It\u2019s difficult for developers to remove themselves from a mindset of \u201chow it works\u201d as opposed to \u201chow it should work.\u201d<\/p>\n As someone with a top-level view of the project, you\u2019re aware of the how the entire system is supposed to work. But you developers only knows how their individual piece work. So when developers write a piece of code, it might work fine by itself, but it could break other functionality that they didn’t know about.<\/p>\n Requirements and documentation are not perfect, and often implementation is a result of the interpretation of requirements by a developer. When testing is done by a separate individual, they also provide their own interpretation of requirements and test accordingly. Plus, the developer doesn\u2019t have as much experience than the client regarding their business. He will never know all the quirks, all the processes as good as you.<\/p>\n Many developers are well trained in their craft. But development can be subject to conditions outside your control. Your organization might have a different standard that they are not aware of. For example, most users of your product may be doctors who require Internet Explorer to be installed at their clinic\u2014 but the developer is working on Chrome. Such small details may seem trivial but they can take time and another cycle of testing to fix.<\/p>\n And, finally\u2026.<\/p>\n It has to be said \u2014 this is something we see time and time again. Very rarely do we see a client allocate time for testing. Sure, a developer is supposed to turn the code in as soon as he or she is done with it. But the process doesn\u2019t end there! You need to plan for at least two rounds of testing and adjust your launch dates accordingly. If that sounds like common sense to you, then you might be surprised to find how many of our clients have no idea that this is what they need to do.<\/p>\n Now, I don\u2019t want to imply that a good developer won\u2019t test or shouldn\u2019t test \u2014 quite the opposite. Developers MUST test. But so should you.Only once you get the finished product can you really start testing it as a complete project.<\/p>\n The bottom line is this:<\/p>\n If you are the direct recipient of work from a developer, then you are assuming the role of a tester\u2026 and the role of a tester is to try to break the product to find issues.<\/strong><\/p>\n If you do find issues, that\u2019s a good thing. It means that you are doing your job correctly.<\/p>\n Unfortunately, it\u2019s hard to not get frustrated about this. You spent the money on the product. You spent the time planning, designing, and executing it. Once you send it to development, it should just be done! Right?!<\/p>\n No.<\/p>\n As we just saw, getting your product back from development is only half the battle.<\/p>\n Chances are, if you\u2019re reading this, you are not a professional tester.<\/p>\n That\u2019s okay — you have enough on your plate already.<\/p>\n Still, testing is draining your time and your ROI, for all the reasons outlined above.<\/p>\n Let me lay out a few questions my clients usually have, and how I answer them.<\/p>\n Short version: yes! it\u2019s far better, faster, and a better investment to set aside a small portion of the development budget or testing.<\/p>\n Think about it in terms of ROI.<\/p>\n As you get caught in a vicious testing loop, the time spent testing drags on and on. And you have to pay your developer for those hours.<\/p>\n Here\u2019s a secret: professional testers are much cheaper than developers<\/u>.<\/p>\n A better use of your budget would be to set aside a small portion and get everything tested professionally. It\u2019ll save you time that you can leverage into money. All that effort you spend testing could be spent doing something much more profitable. Launching new products, for example.<\/p>\n But instead, you\u2019re caught in a testing loop, wondering when it will end.<\/p>\n And at the end of it all, there\u2019s the risk of launching an unfinished product and getting poor reviews on launch.<\/p>\n Yes, the developer should be testing \u2014 but it\u2019s a novice mistake to assume that the developer will catch everything. In a perfect world, that would be the case.<\/p>\n But if you want your product to be clean and perfect, you need to do it yourself or have it done professionally. The developer simply isn\u2019t in the right mindset to give you the kind of flawless product that a professional tester can.<\/p>\n Yes, outsourcing can suck.<\/p>\n But it can suck a lot less if you take advantage of professional testing services, instead of taking on all the testing burden yourself.<\/p>\n Just set aside a small portion of the budget to devote to testing. You\u2019ll see a better ROI, better peace of mind, and probably a better product overall.<\/p>\n\n
6 Outsourcing Traps<\/h2>\n
You and Your Developer Are Not On The Same Page<\/h3>\n
Developers Think They Know Best<\/h3>\n
The Sum Might Be Broken By the Individual Parts<\/h3>\n
Even Clear Communication Can be Misinterpreted<\/h3>\n
Some Variables are Outside of Your Control<\/h3>\n
You Might Be Part of the Problem!<\/h3>\n
Two Important Questions<\/h2>\n
My budget is super tight. Can I even afford to have a pro test for me?<\/h3>\n
Wait, I thought the developer should be testing everything?<\/h3>\n
Recap<\/h2>\n