Should You Hire In-House Programmers as Employees or Outsource to a Consulting Firm?

Nov 20, 2017 10:00:00 AM Matt

Hire-Programmers-vs-Outsource.jpg

Well sure, ok, maybe we might be slightly biased on this. We are, as it turns out, a consulting firm in the business of selling outsourced programming. Ahem...

But, nonetheless, I’ll try to be reasonably fair and balanced here. As a consultancy I think we have, in fact, a unique vantage point on such matters, since we spend each day of our lives straddling both sides of this topic: That is, we sell outsourced programming to organizations for whom outsourcing is a good fit; whereas we ourselves hire in house staff programmers, i.e. we are an organization for whom outsourcing is not a good fit.

Ergo, our very business model is a demonstration of the fact that there is not a single “right” answer to this question. Some organizations should hire programmers as employees; some should outsource their needs to development shops. Some should maybe do both. How do you know which kind of organization you are? To answer that you’ll need to dive deep into 4 prerequisite questions.

1) For Your Organization, is Programming an End or a Means to An End?

For Ashday, the core essential product we produce and sell is programming. It’s our thing we do. As such we really want to have full ability to craft, manage, and perfect every aspect of the development ecosystem (more on this below). Some agencies in our industry outsource most or all of their programming needs to freelancers or subcontracted companies; we do not (and I can’t imagine wanting to). For organizations, small or large, whose end product is programming, a very strong case is intrinsically made for direct employment. If that’s you, read no further, go hire some programmers and find a way to make it work. (Or click over to that thing Clint wrote four years ago about tomatoes and taxonomies.)

But what if programming related actives are not your core business offering, just tangential to it or necessary for its operations? What if you produce electricity, or refrigerators, or news, or surgeries, or legal fees? And you just need programming to get that done…. Then the next question is:

2) Is it Cost Effective?

This one can be tricky. On the surface, it would generally seem that in-house programmers cost less than outsourced, if you compare the hourly rate of a dev shop to the salary of a developer divided by the number of work hours in a year.

That’s an oversimplification though. Remember that salaried programmers are not producing code 100% of the time. They also take paid vacations and holidays, go to conferences, sit through meandering meetings, and take extended breaks for ping pong tournaments. They need to spend time learning new technologies, which is a more or less continuous part of the job. They need to fix stuff that breaks on their computers. Etc.  So you’re probably doing well if they’re actually producing code 75% of the theoretical 2000-ish hours in the work year. Also the costs in play are not simply for salaries. You need implied costs of any benefits, training costs, general space and infrastructure costs, and the various costs of tools (more on tools below.)

Brainstorm your next development project with an Ashday Systems Architect!  Request your free session today. 

Also, some percentage of your hires aren’t going to work out. You may roll with somebody several months or more before your realize they're not a fit. The cost of failed employees needs to be averaged into the average cost of successful ones. And, of course, even the ones that work out may eventually leave, taking with them a lot of investment that you’ve made.  There’s also a non-intuitive factor here pertinent to the question of which is more “stable”: we have had, multiple times, the experience of being in multi-year relationships with clients which outlast their relationships with all of their in-house programmer staff ... complete staff turn-over, but the vendor (us) is still there.

Additionally, on-site staff (at least for smaller internal teams) may need to be jacks-of-all trades, versus outsourced firms that are able to let their dev staff specialize more. Thus the output per hour on a particular task can be far greater from the outsourced firm, who is able to assign specialized staff to tasks appropriate to their expertise so as to maximize efficiency.

When it’s all said and done, it’s not particularly obvious that the end cost of outsourcing is higher or lower than that of staff, despite the apparent surface difference in hourly rates. It really can vary. It can be, and often is, the case that it’s much cheaper to outsource.

Nonetheless, it is of course possible to have a cost advantage in-house, as is demonstrated by the very fact that programming firms exist in the first place, and (ideally) operate a profit. The profit margin is not typically huge, but done well it’s certainly present. That margin plus any efficiencies gained (such as through avoidance of duplicative operational/marketing/sales etc staff and costs) is the financial benefit potentially available to be saved by bringing a team in house. This requires a certain scale of operations and ongoing needs, and the savvy to pull it off, but at some point it can be significant.

3) Will the Time Frames Work?

Generally, unless you’re a huge company, a dev firm will probably have more developers and therefore development bandwidth than your internal team will. If quick turnarounds of large projects are important, a firm probably is best. 

On the flip side, dev shops are juggling more than just one client.  If you tend to have myriad small needs that come up frequently, and must be tended to almost immediately, it can be hard for an outside firm to accommodate because they may be in the middle of a big thing for some other client which they can’t just drop. Internal staff though can often turn on a dime, because it's your dime. That is, they effectively just have one boss (you) setting and modifying their priorities, versus competing clients.

4) Can You Build and Maintain a Healthy Development Ecosystem?

A final key question to ask if you are considering hiring devs, is whether you are able to build and maintain a healthy development ecosystem. By this I mean the harmonious instrumentality of four critical things: staff, tools, processes, and culture. A bit on each:

Staff

This is your would-be in house developers/programmers (as well as, depending on size and scope, architects, designers, testers, UX experts, etc.) AKA the geeks (I'm using that term, self-referentially, in only the most loving of ways). These folks need to be focused, smart, honest, and very knowledgeable in their field. They need to have brains that are wired for rigorous logical thinking plus creativity plus attention to detail. 

Such people can be exceedingly hard to find.   Therefore once found, you’re going to want to keep them around.  So they need to be excited about their job, and paid well. It’s important to remember, for morale and retention, that developers (good ones at least) love to solve problems. That’s why they got into this field. Now solving a problem one time is fun, but solving the same problem one hundred times is not so much.  To keep the interest level up, you’ll need to be able to provide a steady stream of interesting new challenges, or at least opportunities for abstractions of the previous challenges.   And you’ll need to make a continuous investment in ongoing education – technology is always evolving and developers want to evolve with it.

Considering Outsourcing? Consider Ashday!  Request your free consultation today. 

Tools

Abraham Lincoln famously said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” (Though I’ve just done some research and it appears it was probably not actually Honest Abe, but an anonymous lumberjack who said that. In my next post we’ll investigate the increasing evidence that an anonymous lumberjack delivered the Gettysburg Address.) 

Point being, having good, sharp tools is important. The developers’ primary tool of course is his or her brain. But I’m talking here about the bevy of other physical and virtual tools that must be put at the disposal of said brain (and that of its encasing body).

For instance, you want to provide really good computers (newer Macbook Pro’s are usually a hit), multiple large monitors (high resolution), and expensive ergonomic chairs (versus the free kind available out back near the dumpster). Adjustable standing standing desks have been very popular with our staff (Veridesk Pro Plus 48).

Equally important is the vast constellation of software tools that the are the stock on trade of this game. IDE’s, data inspectors, ticketing systems, continuous integration engines, vm provisioners, browser simulators, design introspectors, Star Wars meme generators, etc.

Process

If you’ve nailed it on staff and tools, great. But you also need to be able to run their operations. That takes proper processes. Great staff and expensive tools can utterly fail if the processes are wrong. You need to think about processes for general software lifecycle (Agile school of thought is helpful here), dev & devops, quality assurance, etc. 

And, in general, you need processes at every level that implement intelligent “systems thinking” to effectively control the various complex systems that you will be building and managing. More thoughts on that here.

Culture

This final one, culture, is harder to define. Lots of people try to define it, but I’m not sure they ever succeed in a comprehensive way. Maybe it’s similar St. Augustine’s take on defining time – “If no one asks me, I know what it is. If I wish to explain it to him who asks, I do not know.”  

But definable or not, it’s exceedingly important. It has to do with corporate values, and a sense of dignity and purpose in labor, and relations between people, and respect, and beliefs about software philosophy, and leadership philosophy. It has to do with how people talk and dress and smell. It has to do with what’s hanging on the walls, and what music is playing, and whether the fridge is full of energy drinks, beers, or kombucha.  It’s myriad things collectively creating the “feel” of the place. No two are the same.  Somewhat ethereal, somewhat elusive, and yet you’ve got to get it right for programmers to be happy and stick around.

So Now What?

If you navigated through all four of these questions, and feel like in-house make sense, then it very probably does. You can start advertising for programmers in places like Stack Overflow, and Indeed, and on your own site and social networks. You can start networking in local programmer groups - checkout Meetup. Maybe even start making relationships at a local university’s C.S. department to look toward the long term future.

Or if, after all that, in-house isn’t for you then find a good dev shop and let them get to work. 

 

Topics: Drupal, Hiring