| > As someone that has been on the hiring side, I always prefer to build a full time team, even if that means paying for someone in my team to learn something new. > The part that consultants don’t talk about is that you have to pay them to learn your code / company too. Nobody can just jump in and add value immediately. So you’re paying for onboarding hours, you’re paying for other employees to educate the consultant, and so on. as somebody who's been on the team, i agree on this. in my previous job my skip-level management insisted on handing off some crucial infrastructure work to external consultants. results: 1. we on the (internal) devops/sre team did not know how parts of our infrastructure worked 2. when changes were needed, the first lenghty step was to figure out what was built by the consultant, and how (the manager did not like to pay the extra hours, of course) 3. when help was needed to troubleshoot something along with developers, we (devops/sre) ended up playing the role of messenger, and stuff that could have take anything from 2 hours to two days ended up taking up to two weeks It was a frustrating job, so of course some people (me included) ended up leaving the company. I still see the value of consultants as people that can bring the knowledge you need when you need it. However if they're going to work on something long lived, the manager must be enforcing some proper knowledge transfer during the consultant employment and at the end of it. |