markdown guide
 

Both methods of hiring are acceptable, but the choice depends on the purpose. If a company has enough resources to hire and take care of an in-house team, and the country doesn't suffer from a skill gap, then why not?
But if the budget is limited and there are no needed specialists in the country, then addressing a vendor is a smart solution.

The advanadge of the former hirig method is direct participation and control. While the drawback - it requires significant investments.

When speaking about vendors, the problem is to find a trusted one. Also, there is not much information about how staff augmentation model works , so people tend to consider it unreliable. The pros of cooperation with vendor is shared responsibility and cost reduction.

 

Having worked on both sides of this, I've found that it depends a lot on the organization and the reason an outside team is being brought in.

The best situation is where the vendor team is needed to supplement the work load of an in-house team. For example, if the business has 6 epic level projects that need to be done by a certain time but only has the in-house staff to complete 2 within the time frame, then bringing in a vendor can allow all of the projects to be completed in time.

Another situation where it can work is where the vendor is brought in when there is no in-house team and the organization doesn't want to have one. How well this works depends on the quality of the vendor team and management support. I've seen low quality teams come in and make a mess of things and situations where it worked very well.

A situation that can go bad is when a vendor is brought in because management has lost confidence in the in-house team. The in-house team is usually berated and treated poorly by management. This can turn ugly quickly as conflicts and resentment escalate.

A similar situation is the "mythical man-month" scenario in action where warm body vendors are brought in to increase the staff size on a troubled project. But, there's lack of a plan and bringing the vendor team up to speed actually slows down the lagging project.

 

We changed our setup from vendor to internal and we see the following advantages very clearly:

Try and error - because of no budget pressure the new stuff does not need to be at 100% - we first can see if it is working for our users and customers.

Business-Pressure wont work anymore - with our internal team the struggle with developing with time pressure was way more visible than with external vendors

Speed - we increased speed because of direct discussions between our business and the developers. As a result, the features got more advanced and more sustainable.

Importance of tech in our C-Level - Even our CEO, CFO and CMO realized that an internal tech team is very valuable, even for a fashion brand :-P we refactored a couple of order intelligence features and saw that our vendors ... made a little more cash than it was worth it ...

 

Our company does both in-house development and are consultants.

There are old blundering companies out there that actually don't have a clue where to start building a good dev team, or they do have a dev team but doesn't have the expertise for what they want to build. This is where consulting comes in, and hopefully they'll learn what a good dev team looks like. Although, big consultancies usually are just in it for the money and never really go about it the right way and ends up wasting client funds (and worse yet, client funds might be public funds...).

For the devs, consulting or contracting might be for them. In the UK it pays well and it's for you if you don't like the.. monotony of a single project for a long amount of time. You'll miss out on things like company benefits and the camaraderie that comes with being permanent staff.

 

Having been on both sides of the fence, I find that I look at code quality differently as an in-house developer than as a contractor. With contract work there are two kinds of time deadlines. 1) When the client needs the feature. 2) When the money run out. You can exhaust the budgeted labor cost well before the client's deadline. So as a contractor, there is far more pressure to just "get things done" and worry about quality as a secondary concern. But as an in-house developer, I might have to deal with the code for many years to come. So, I tend to take more time to keep quality high. However, this can make in-house development even more expensive than can be quantified by salary+benefits vs contract budget. Whether that is worth it depends on the business goals. Dev availability for in-house might also be a concern.

 

Pros of In-house:

  • In general, people (should) feel that they are more part of the mission of your company/project, rather than just guns for hire.
  • If there are core knowledge/know-how, it is more kept "in house."
  • Efficiency of communications, sometimes, the communication channels can be faster and more efficient.
  • Generally more longer term, so for this reason, companies are more willing to invest in people who are learning on the job.
  • More cost efficient in the longer term. (since the Vendor's management company usually takes 50% cut or more from the money, before it goes to the team members.)

Cons of in-house:

  • Takes a lot of time and energy and cost (if you use recruiters) to put together an in house team.

Pros of Vendor:

  • Probably quicker to put a team together. Since the vendor most likely have a team ready.
  • If you know it is going to be short term, it might be more cost efficient. Or you know you will have a lot of frequent add on people or drop off people.
  • Supposedly, there is less training time since the expectation is that vendor's dev team should be experienced, and should not need to be learning on the job on the specific skills (such as a language or framework). But there is still a lot of learning (about the specific project and existing code base) and to be ramped up.

Cons of Vendor:

  • Depends on the vendor, sometimes you don't directly control who gets put on your team.
  • Quality of vendors (and the individual team members even) varies greatly.
 

I'm in house but I'm not a lot different to the people we work with. Does it come down to scalability and cost?

Classic DEV Post from Jun 6

How do you onboard a new team member?

My team have a lot of roles to fill this year and recruitment is underway. I'm curious, when you joined your team, what made it a smooth experience?

Ben profile image
A developer in Hong Kong. Learning And Rethinking as a developer. Welcome to contact me and make friend with me. Cooperation is welcome.