Friday, May 14, 2010

Transitioning the Team

Other than with start-ups or other new ventures, when it comes to employee resources, you’re going to have to deal with a varied mixture of “legacy” skills and attitudes. It should go without saying that any serious transformation effort is going to face a certain amount of resistance and push-back—especially from those who rightly or not feel threatened by the change represented by the transformation.  Building a team supportive of transformation will require a great amount of patience, good communication and a dosage of well-focused leadership.
A famous sculptor once remarked that creating the statue of a horse from a block of granite was all about removing the “non-horse” parts from the block. No matter the organization, there is always an existing team that can be crafted via training and reassignment to support the transformation goals.  As with the proverbial sculptor, you will need to remove the “non-team” parts represented by what might be an ossified and unmotivated staff (pardon me for sounding so Zen-like!).
Traditional team dynamics demonstrate that the greatest resistance to change is usually generated by just a few. Since it is not realistic to assume you will be able to completely create a brand new technology team, your mission then is to weed-out the unredeemable trouble-makers from the working-bees who are perhaps afraid of change, but are nevertheless  professionals who will gladly follow through once they’re given a clear direction. As a bonus, with the benefit of fresh eyes and renewed objectives, you will also be able to identify the diamonds-in-the-rough, the unappreciated team members who have been waiting patiently for a chance to shine (and believe me they exist in every mid or large sized organization) but had never been given a proper role to play. When given a chance and a fresh challenge, these individuals can become natural stars when allowed to spread their wings.
Add to this dimension, the need to make a frank assessment of the skills of those in the group vis-à-vis the skill-sets needed for transformation, the time and funding available to repurpose these skills, and the realization that you will need to fill the natural skill gaps presented by the introduction of new technologies. Consider too the fact that, yes, you are dealing with human beings, not machines, and you can see why this area of the transformation process is usually the most sensitive and difficult. It doesn’t matter if you have the most wonderful architecture in place, or that you are using the most amazing technology, or that your project plan is a paragon of beauty, if you can’t deal with the human dimension, the project will not succeed.
Dealing with this type of challenge requires a clear understanding of team inter-relationships. Most importantly, it involves applying a wise combination of informed intuition, fairness and decisiveness in order to resolve or remove the elements that might impede the effort. In the end, once you have defused those interested in obstructing the project, you will be able follow the kind of staffing plan that allows you to make delicious lemonade from the mix.
In the end, when staffing the new system with existing resources the approach to take is one that requires a case-by-case assessment of individual competencies and attitudes.  Work closely with your Human Resources team to do this. When defining a more appropriate taxonomy of the various skills in your existing area, you will find that certain workers can be retrained to handle new technologies. 

The diagram above shows a generic, sample roadmap of how different resource types can be utilized for the new system. Business analysts, for instance, will usually have the easiest transition simply because the business processes supported in the new system are, for the most part, the same as those of the legacy environment.  A few motivated legacy operators may be able to continue operating the new system after significant retraining, but many might be better off assigned to performing Q/A functions on the new system—after all, who better to spot inconsistencies or trouble in a new system than someone already acquainted with the operation of the old?  
Alas, you will also find that a percentage of the existing workers will never be able to switch to the new system under any capacity. The latter are more likely to be seen in environments that have sustained investment in legacy technologies over many years. In this type of “stagnant” environment you are more likely to find a core team of, say, COBOL programmers who, when faced with the possibility of losing their employment, will demand to be allowed to code in Java.
Truth be told, someone who has been working for decades with procedural languages such as COBOL will not have an easy time moving to modern object oriented technologies. Object orientation is more than learning the syntax of a new language. It’s also about dealing with the conceptual shift represented by object oriented concepts and development methodologies. Some of the most serious coding disasters I have witnessed involved programmers given responsibility to develop mission-critical applications using new programming languages they were completely unfamiliar with.
I realize that what I am saying may not sound politically-correct, but the reality is that only a handful of procedure-oriented developers will ultimately be able to manage the transition to utilizing new technologies. You would do better to focus on college graduate with baseline training in modern systems, apprenticing them to those on your current staff.  Does this mean that the old-timer’s only route is retirement?  Not necessarily. A proper analysis of the skill-sets in your organization can be well-timed to use each employee’s skills in a way that is consistent with their abilities. For example, while the traditional COBOL programmer might never become a Java developer, there is probably no one in the organization with better understanding of the business rules and processes than someone who has been implementing these applications for years.  Perhaps it is time for the COBOL developer to consider retraining as a business analyst or a quality assurance tester?
The mark of a good leader is not in his or her ability to wipe a slate clean, but rather in his or her ability to identify the various hidden strengths inside the organization and to make everyone contribute to the maximum of their capacity. That can only occur, however, when one is completely honest about how unrealistic it is to try to make change happen without ruffling feathers.  That is, after all, the nature of change.