Suppose you are the manager for a 6-person IT team within a local retail company. Part of the reason you were hired is because the company's internal software systems are poorly structured, poorly documented, and are becoming very difficult to maintain.

Two of the developers have been with the company for many years, and know that the owner of the company is very loyal to senior staff. These developers are quite skilled, and understand the company's systems very well - probably better than anyone else on the team. Unfortunately, they prefer to work on a very ad hoc basis, and do not take structure, processes, organization, or documentation at all seriously.

Discuss your options for handling this situation, what you would choose to do, and why.

SAMPLE SOLUTION There are two overlapping issues here: the need to get the company's software systems back into an effective, maintainable form, and the need to get the two developer's on board with a process that can produce and maintain effective systems. As manager, I would set up both individual and group discussions with the company owner's, the team as a group, and the individual team members. In these discussions I would attempt to draw out each person's perception of the current state of the system, its weaknesses, and the things that led to those weaknesses. I would then attempt to convince both the group and the individuals of the importance of improving our business processes. In the early stages, we need to develop a good, team-wide understanding of the existing systems, and one way to do that would be to put the two "ad hoc" team members in the role of teachers/knowledge base while the rest of the team documents the existing system. I would attempt to get the two ad hoc developers into some tutorials and workshops on current best practices, while at the same time stressing the value of applying these practices as a team. Hopefully team pressure and encouragement can get them to buy into what we're selling. Once we have a good understanding of the current system we can start identifying opportunities for improvement - interacting with our users (and of course the owners) to chart a course of action for both the short and long term. If the two ad hoc developers continue to be a problem, I would continue the process of discussions with them, the owners, and the rest of the team to try to keep things as functional and cordial as possible, but would gradually shift the two developers workloads to areas where they could have minimal impact on the rest of the process - rewarding the participating team members with the "plum" design and development aspects of future projects.