In our Brownfield Application Development book, and in previous posts on this blog, Kyle and I have talked about the different personalities that you can encounter while working on a development project. Unfortunately many of the types we listed, and that you see and remember, are negative. Because development is such a social task (whether you like it or not) conflicts in personalities, styles and objectives are easily surfaced. Add on a heavy dose of introversion and natural social ineptness and you have a cauldron of simmering conflict just waiting to bubble over.

During the hiring process HR and dev teams do their best to eliminate candidates that are obviously going to bring these types of issues with them. Sometimes it works, occasionally they slip through and you have to deal with them. Unfortunately, it’s very rare to see the same diligence applied to the transfer of people from one internal team to another. The results can be disastrous. About a year ago this happened to my team (I say my because I was the tech lead for the project).

We, as a cohesive and very productive team, were ticking along meeting deadlines, turning out high quality code and generally getting praise from the clients for these things. Management decided that we had more work that we were going to take on and decided to transfer another of the already on-staff developers to our project to assist with the new work load. Don’t start thinking the Mythical Man Month and adding resources to an already late project. We weren’t late. In fact we were ahead of project schedule at that time. On top of that the work being assigned to the new team member was isolated in it’s own branch with a thought of it being included in a future release, not the one we were currently working to finish.

Knowing that this developer would be working in isolation I decided that the impact to the team was minimal and shed any worries I had at the time. Things moved ahead for a few weeks before they came to a crashing halt. I won’t get into details about what happened but the underlying problem was that the developer recently assigned to our team didn’t have the same beliefs or culture as the rest of the team did. The result was a series of very animated and heated conversations that led to a requirement for serious and significant policing of the development actions of this person. In the end the original team had to declare to management (above the project management level) that having this individual working on the project was adding significant risk to the current release and had already jeopardized the following release. The result was that the offending developer was removed from the project and a 100% re-write of his code (four months effort) was required to bring it to the project’s quality standard.

The lesson that I wanted to convey from this incident was that you have to be diligent in the screening of any person joining your team, regardless of if they are an external or internal hire. Blindly accepting a new resource since they are already within the organization doesn’t preclude them from introducing risk and conflict to the project. If you are a team/technical lead, architect or manager for a team, you have a responsibility to protect your team from distractions, morale killers and risks. In this case flags should have been raised months before this individual joined the team, but trained with it. The statement “It doesn’t matter what the client wants, I’ll give them what I think they need” was boldly stated and I failed to remember that when the speaker was pushed onto our team. I failed my team by not filtering based on this past interaction. Don’t let internal recruitment cause you to fail yours.