The role of the in-house developer is vital and often underutilized. When companies bring in consultants, they do it for one of these reasons:
1. Add manpower – project needs to get done sooner
2. Add specialization – team needs a specialist (DBA, for instance)
3. Bolster skillset – team has junior/mid-level developers but needs a senior level developer or architect
In each of these situations, particularly the first (Add manpower), the company puts the internal/in-house developers in the awkward situation of working with a set of people who they have little to no shared history with. Who do they report to? How do they resolve conflicts? And more importantly, are these new people going to replace them?
Consider this, a team of 3 junior to mid-developers have a combined 8 years at a company that sells insurance. The product they work on (other than doubling as IT staff occasionally) is a desktop application that handles some daily transactions. Technologically & hypothetically speaking, you could easily have this system upgraded by a small team of highly skilled software consultants who worked a project or two in the insurance industry. But then, these consultants would discover that they missed something vital: exceptions to the rules made for certain persons/organizations, specialized/customized/one-time messages or notifications, obscure background tasks/processes, unwritten rules, arcane industry regulations. This was something the in-house developer(s) with a combined 8 years or more in that organization and industry would not have missed if they were excluded from the loop – PM was handling the consultants with no in-house developer involvement, consultants work offsite, feedback loop was too long.
Organizations are living breathing organisms that evolve and adapt to circumstances unique to them. The in-house developer evolved with the organization and possesses the unique intersection of technological skills and tribal/institutional knowledge. This puts the in-house developer at an unique position of advantage – they can (more or less) speak the technical language of the consultants and the local language of the tribe. Additionally, with the right transition plan, they could take over maintenance/customization of this new system when the consultants are long gone. Incorrect/under-utilization or exclusion of the in-house developer, is one of the major, but overlooked, reasons software projects by external consultants fail.
In-house developers can help themselves by taking time to learn the language of the local tribe and the business side of the organization better, instead of hanging out in your ivory tower. Management bringing in external consultants, should dedicate time and resources to lessen the friction between the in-house developer and the consultant. External consultants can make their lives easier and the project successful by learning to work with and harness the unique skillset of the in-house developer.