- 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
Setting Up a Training Process
Having formal training processes in place to allow developers to be trained on new technologies is a key factor to successfully transitioning those developers. Many times, new technologies such as Java are adopted with such speed that traditional training organizations within a company can't keep pace with the changes. This is where creative approaches can be useful:
Supplement your in-house training with local university extension programs.
Partner with hardware and software vendors or integrators to obtain training resources.
Use job rotations to place developers within other organizations that are already using the technology you want to adopt.
Create virtual teams of experts within the organization to share best practices on a new technology and train their peers.
Consider Sun's Field System Engineering (SE) organization, which employed the last approach in the list above. As Sun prepared to publicly announce the Java platform in early 1995, Gary Oing, manager of the SE programs office, recognized that the normal field-training infrastructure couldn't possibly train the entire SE organization in time to support the initial Java technology rollout. Instead, the Java Action-oriented Community of Expertise in Sales (ACES) program was founded. The Java ACES were a small group of about 50 SEs who received special training in Java technology and then actively spread this knowledge through the entire field SE organization. Specifically, software development in Java was one of the key focus areas of the Java ACES. The program was so successful that it has continued as the Java platform evolves and has launched similar programs in other fast-moving technology areas, such as high-performance computing (HPC) and data storage systems.
A large software development organization will undoubtedly include some developers who resist developing new skills in order to transition to a new technology. You shouldn't expect or force every developer to transition. It's important to remember that not all developers need transition to a new technology when it starts being introduced into an organization. Sometimes a developer's knowledge of legacy (or soon-to-be legacy) systems is so valuable to the business that management should never think of letting that person go.
During a transition period, consider using consultants to augment your internal staff. At the start of a project, consultants can help train your developers and help out in areas where you haven't developed a critical mass of trained staff. One of the transition mistakes to avoid when using consultants, however, is having them take the lead role in the implementation of a new technology without involving and training your own staff. In many organizations, consultants complete the first project on the new technology while the internal staff continues working on their existing projects. At the end of this cycle, the organization is no closer to having transitioned the development team. To address this issue, we recommend having at least a 1:1 ratio between your internal staff and consultants on any transition project. In addition, be sure to budget for at least a 20% overhead for consultants to complete on-the-job training.
At the tail end of an organizational transition, consider outsourcing any remaining development or maintenance of legacy applications. But note that outsourcing maintenance is perhaps a riskier proposition if the majority of the application knowledge base stays with your organization and transitions onto new projects.