Successfully Transitioning Developers
- Why Transition Developers?
- Setting Up a Training Process
- Transition Issues
- Does Transitioning Work?
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As IT managers try to evaluate the impact of new technology in meeting the company's business goals, they must weigh not only the merits of the technology but their ability to successfully transition to that new technology. Choices must be made, including whether to hire different developers or whether even to implement the new technology. Successful software development organizations are constantly faced with new development tools, new languages, and entire new computing paradigms from which to choose from year after year.
Why Transition Developers?
If your software development organization is planning a major shift in development methodologies, many of your developers' technical skills will become instantly outdated.
We are often asked by managers anticipating an organizational transition whether they should retrain their developers or simply hire new ones. While technical skills are very important to developer performance, mature processes and developers' business and personal skills can play an even larger role. New technical skills can be taught, if the individual has a sound computer science background. Business skills, including knowledge of corporate culture, the company's business processes, and domain knowledge, can take years to develop. Personal skills, such as dedication, flexibility, and leadership, are usually established early in one's career and are not at all likely to be taught. Software development technology is constantly changing, and healthy organizations should be continually looking for opportunities to transition developers to newer development technologies and methodologies.
Established IT organizations don't typically make a wholesale change in their technology overnight. This makes it easier to transition development organizations on a piecemeal basis. Before switching to a new technology, organizations typically pilot the technology on a prototype or small project. After gaining some experience with the technology, a strategic decision may be made to start employing that technology on new projects. It typically doesn't make sense to make major changes to a development methodology or underlying technology midstream in a project. Even after all ongoing projects have been completed and all new development is being done with a new technology, legacy software must still be maintained. Here's how we map the technology lifecycle of an IT organization to the mix of developers in the group.
In any software development organization, some developers are likely to be "early adopters" of technology. These are the individuals we target to become part of new pilot projects whenever a technology transition is being considered. We are often asked how to spot these early adopters. Generally, it's fairly simple. Every mainframe development group probably had one or more developers who experimented with web browsers during the early days of the World Wide Web in 1994–95. Maybe they did this on their home PCs, or took classes at the local college. We look for these or other signs of interest in new technology when selecting developers to pilot a new technology on the job. As these developers gain experience in the technology, they can then move on to become the design leads and mentors for other developers, as new projects with the technology are started.