You are dead in the water.
As a developer friend likes to say, these people are Zombies. They are dead but just don’t know it yet.
It is imperative as a development team that you own your build. By own, I mean that you maintain it and are able to run it in your development environment’s with no direct connections to external dependencies.
A great test of how well you have achieved this goal is whether you can, with minimal knowledge of the project, perform the following task. Run your build from the command line in a freshly cloned repository and then repeat the build command with your network disconnected.
At the other end of the spectrum here are a few anti-patterns and smells to watch out for when considering a projects build process:
- the build can only run on the CI server
- pulling dependencies from network shares
- pushing build outputs to external locations without the ability to bypass these steps
- the foul cry of ‘It works on my machine‘ from team members. Also checkout the build version which tells the sad tale of Phyllis
- endless change requests flowing around the system trying to get the build modified
- and above all, the existence of ‘build experts’
Self restraint is required at this point to derail my desire to rant about the importance of every team member to be able to run the build locally. Suffice it to say if you get this bit right you will be raising your quality bar at the same time as reducing the friction and cost of getting someone new onboard to work on the project.
Stone Soup Developer 
Amen! I wonder how such a basic problem seems to be so persistent.
The anti-patterns around external dependencies are interesting. I would probably put everything needed to recreate the output in my repo if it were practical, but I could settle for trustworthy nuget feeds with specific versions referenced in the repo to ensure the dependencies follow the same chronology as the source code.