Strategies for Effective Training and Education in Information Technology (IT)

Organizations that want their information technology (IT) training and education (T & E) programs to be successful must carefully distinguish between the two concepts. Training is the process by which people gain tangible skills that they can start applying immediately. Education, on the other hand, is process by which people gain knowledge and understanding. Training and education can occur in class room settings, in mentoring sessions, or through apprenticing. Some courses, such as Introduction to Java Programming, are for the most part training. Similarly, some courses such as The Principles and Practices of Agile Modeling, focus more on long-term education. Many courses are a mix of both, a course entitled Object-Oriented Analysis and Design With UML would likely be one such example. The point is that you need both training and education to help round out the skills of your staff.

This article overviews my experiences helping to train and educate people in IT skills such as object-orientation, Unified Modeling Language (UML), Agile Database Techniques, and agile software development in general. Throughout this article I'll use the example of learning agile development techniques but as you can see the advice can easily be generalized to learning any new technique or paradigm. In fact, this material is adapted from my fourth book More Process Patterns, the focus of which was object technology.

The Realities of T&E
The T&E Lifecycle
T&E tips
References and recommended reading
Let me help

1. The Realities of Training and Education

I'd like start by saying that there is no magic when it comes to T&E. It takes time for people to learn things, and often years for them to master it. For example, it takes several months for a person to gain a working understanding of Extreme Programming (XP), and potentially another year or two for them to become truly expert at the process. Agile software development is a whole new paradigm, one that you cannot pickup overnight.

A second issue is that people learn differently. Sometimes people respond best to hands-on training, whiles others prefer lecture-style instruction. Some people like computer-based training (CBT) and others work best in learning teams. Successful T&E programs are flexible enough to support various learning styles.

2. The Training and Education Lifecycle

Figure 1 depicts an approach to T&E which I have found useful. The square boxes represent activities which usually occur within the scope of an initiative, the rounded rectangles are typically associated with the people management efforts within your organization. This approach is comprised of six activities:

Assess
Provide specific introductory training
Provide mentoring and hands-on experience
Provide advanced training
Provide education
Support the learning experience

Figure 1. The Training and Education Lifecycle.

2.1 Assess

It is critical that you get IT professionals the right T&E at the right time, and the only way that you can do this is through regular assessment of their skills. To do this successfully you must:

Directly involve the staff member. Minimally, you need to find out what their goals are and where they think that they need to improve their skills. Better yet, they may have a very good idea as to what training that they need, opinions which they gained through talking with the colleagues and their own research.
Assess regularly. Although many organizations will update a person's skills as part of their annual staff review, this often isn't sufficient. It's unlikely that you'll identify the training courses that someone will need on an initiative starting in August during their annual review in December of the previous year. Good points to assess someone's skills include: during their regular staff review, at the beginning of an initiative, and when they think that they need an assessment done.
Keep the assessment simple. The best way to do a skills assessment is to simply have the staff member sit down and have a discussion with one or more experienced people that understand both the person's current skills as well as what is needed to do their job successfully.
Go at it from different angles. An experienced team lead may be able to give someone good advice for what T&E then need to become a better Visual Basic programmer, but may not be able to provide good advice when it comes to communication skills. Remember, there are different categories of IT skills.

2.2 Provide Specific Introductory Training

IT professionals need specific, introductory training, on new subjects. A serious mistake that I see many organizations make is that they assume that because someone is in a senior position that they don't need introductory training. For example, an experienced Java programmer could very likely benefit from a two-day introductory course in user interface design and a senior executive an introduction to Extreme Programming (XP).

2.3 Provide Mentoring and Hands-on Experience

Once the initial training is complete, your staff is ready to begin applying their new skills. It is at this point that many organizations run into trouble because they mistakenly believe that their staff now has the necessary skills to do the job on their own. Often, nothing could be further from the truth. Would you send somebody to a couple of accounting courses and give them control of your organization's finances? Would you send somebody to a couple of marketing courses and put them in charge of your advertising campaign? Would you somebody to a couple of law courses and then have them defend you in court? Of course not. Therefore, why would you send somebody to a couple of agile software development courses and expect them to develop mission-critical software with their new found skills?

After initial training is complete developers are now qualified to be mentored by someone experienced in the subject. The objective of mentoring is to have someone who is experienced guide novices through the learning process, showing them how to use the new techniques in practice. The mentoring effort should be performed on an actual development team, one in which the trainee is given the opportunity to apply and evolve the skills that they received during training. The best mentors have several years of experience in the technique, have mentoring experience, and have good communication skills.

For mentoring to be successful your mentors must be qualified to do the job. Did you ever take a college course where the instructor was ahead of the students in reading the textbook by only a chapter or two? Or a commercial training course where the instructor just got back from the "train the trainer" version of the course? Wasn't a very good learning experience, was it? The same thing applies to mentors - mentors must have experience in what they are teaching. The bottom line is that good mentors have communication skills and several years of experience in what they are mentoring. If you do not have people with the skills, and many organizations still do not, you'll need to hire from the outside.

Mentors should participate as active members of your team, not just as teachers. For a mentor to be a productive member of the team you will need a ratio of one mentor for every two or three novices, anything more and the mentor will be too busy mentoring to get anything done on your team. There is nothing wrong with this, as long as there are other experienced people available to develop the complex portions of your application. teams consisting of one expert and a large number of novices are likely to fail.

Mentoring is in addition to training and education, not a replacement for it. One of the roles of a mentor is to help your team to see the big picture and will need to refocus the team occasionally by explaining how new methods can be applied to solve development problems. Mentors should be involved throughout the entire initiative, especially at the early stages of it, so that the learning process gets off on the right track.

My experience is that when you're adopting a new technology such as web services, or a new paradigm such as agile software development, that the mentoring process typically takes between six and twelve months. The mentor is needed full-time at the beginning of an initiative and then only a day or two a week towards the end when your development staff become self-sufficient. The trick is to slowly wean yourself off your mentor by having them transfer their skills to your staff. Good mentors make you independent of them, bad mentors do not.

2.4 Provide Advanced Training

After several months of hands-on experience under the tutelage of an experienced mentor, developers should return to the classroom for advanced training. The experience that developers have gained gives them the knowledge that they need to understand and absorb the material presented in the advanced courses. For example, an advanced modeling course is likely to concentrate on analysis and design patterns and an advanced programming course will convey a series of programming tips and tricks. Advanced training courses often combine both training and education aspects.

2.5 Provide Education

In addition to providing advanced training courses, you should also consider supporting educational opportunities such as:

College and university courses. Your local post-secondary schools, or virtually local schools via the web, very likely offer a wide range of courses. One of the easiest ways to ensure your staff gets a good education to pay for these courses. Many organizations will only pay for IT and business related courses but my experience is that the wider the range of knowledge within your staff the better. A medieval literature course will likely help to improve someone's writing skills, for example. If you're interested in ensuring that your training money is well spent, only reimburse the student once they've passed the course.
Degree/diplomas. If someone on you staff is interested in pursing a degree/diploma at night school, then I highly suggest that you support them in their efforts.
Professional certification. A viable alternative to degrees and diplomas is professional certification such as that sponsored by the Project Management Institute (PMI) for project managers or vendor-based certification for specific technologies such as Java programming or Oracle DBA certification.

In the end, if someone has a diploma or certificate all it really says about them is they put in the time to earn it. I've worked with many people that don't have any sort of certification or post-secondary education and they've been great developers. Similarly I've worked great people that do have these things. Fundamentally a diploma or certificate gets your foot in the door, after that it's up to you.

2.6 Support the Learning Experience

There is far more to the T&E process than formal classroom training. To support the learning experience you can promote:

Learning teams. Learning teams are small, cross-functional groups of people who are given the task of working together to learn a particular new technology or technique. Learning teams are often asked to produce a small application for the company, perhaps something for the human resources or marketing departments. They are usually asked to spend between 20 and 50% of their working hours on the mini-project, devoting the rest of their time to their current responsibilities. Members of the learning team will still need initial training and mentoring, otherwise they are likely to flounder.
Reading groups. A common technique is for a group of people to choose to read a book together and then to get together and discuss it on a regular basis. For example, you might choose the book Agile Database Techniques and then once a week get together to discuss the contents of one of the chapters. This motivates people to not only read the book but to actually focus on and understand the material.
Bag-lunch training. These are one-hour mini-lessons held during the daily lunch break. The sessions are typically given by an expert in the subject, usually but not always one of your mentors, and will cover a wide range topics. One lesson may be about test-driven development (TDD) and the next about agile requirements management. Successful bag-lunch training programs typically involve 2 or 3 sessions a week with each individual session being given several times so that everyone has an opportunity to attend, minimally you should try to give a session once a week. Bag-lunch sessions are easy to do and really give a boost to the learning process.
Information access. Get people access to the Internet, magazine subscriptions, and books. There is a lot of information out there, much of which is free for the taking.
Mentoring. See provide mentoring and hands-on experience.
Computer-based training (CBT). CBT is also a valid T&E approach, especially when combined with formal training and mentoring. Many organizations provide their employees access to introductory CBT courses before sending them on formal training courses, giving them a head-start on learning. Unfortunately, CBT by itself is of minimal value by itself. Most aspects of software development are simply too complex, and evolve too quickly, to be captured in a CBT course. Furthermore, when you have questions about something you need to talk to an expert to get them answered. A computer cannot do that for you, although a mentor can (mentoring and CBT are a powerful combination). In short, CBT is only part of the solution, albeit a potentially important one.

3. Training and Education Tips

I would like to share several tips and techniques that lead to success in training and education:

Get your staff into the habit of learning. The rate of change in the information technology (IT) industry is simply too fast to allow someone to train once and then sit on their laurels.
Just-in-time (JIT) training is critical. Give your people training when they need it, not several months before or several months after. People will forget the majority of what they have learned less than a month later unless they apply their new skills immediately after training. Training typically occurs within the scope of an initiative, often at the beginning of it, so remember to include training in your team plans.
Educate as well as train. Training gives you the skills to do your job, education gives you the knowledge to understand your job. The most important thing that an educational program can do is to explain the interrelationships of the concepts and techniques.
Expect to train in a variety of skills. Software development is complex, and successful IT staff need a wide range of skills. For example, a Java developer will need training in the fundamentals of the Unified Modeling Language (UML), user interface design, database design, and test driven development (TDD) to name a few.
Perform skills assessments for everyone. You need to understand someone's current skills before you can develop an effective training plan for them. You'll also want to assess their skills on a regular basis to ensure that they are receiving the training and education that they need, many people unfortunately do not actively manage their own training plan.
Recognize that not everyone learns the same way. Some people learn best in the classroom, while others learn best by sitting down and working with a language, and others learn best through working with others. Because no training and education approach is perfect for everyone you will want to create an approach that can be modified to meet the needs of individual students. Flexibility is a key success factor.
Motivate everybody. Motivating junior developers is typically no problem: They are usually chomping at the bit to improve their development skills. Unfortunately some experienced developers aren't so eager, perhaps they are afraid they will not be able to pick it up as fast as others. Given time and a flexible learning environment everyone can learn the new skills required in modern information technology shops, they just have to want to learn. A good strategy is to make the benefits of the new technique/technology, as well as the potential risks, apparent to everyone involved. If people understand what's in it for them, they'll be far more motivated that those who don't.
Expect to deal with bruised egos. A significant problem with transitioning experienced developers into new technologies or techniques is the fact that overnight they are go from being a recognized expert to a recognized novice. This hurts. Developers need to realize that if they apply themselves they can become experts once again, it just takes awhile.
Expect the "I've done it before" syndrome. It is quite common for experienced structured developers, especially the really good ones, to initially convince themselves that they have been doing object orientation, or agile, or [INSERT TECHNIQUE HERE] all along. This is because new techniques always build on existing techniques: For example I have argued for years that there is nothing new in agile software development, it's just a packaging of existing techniques which work really well. Familiarity with some of the underlying principles of a new technique makes it easy to convince yourself that you've been doing it all along. This problem is usually self correcting because as soon as someone starts to work on a real team with good mentors they quickly realize that there is a lot more to to the new technique than what they originally thought.
Recognize that you cannot retrain everyone at once. Except in very small IT shops you'll never transition your entire staff to a new technique all at once. It's too risky, it takes time to learn the ins and outs of new techniques within your environment, and frankly there are basic logistical problems you need to deal with. You need these people to keep your existing legacy systems up and running, but at the same time they want to be involved in the exciting new initiatives. My advice is to keep them up to date on what's being learned on the team, let them know when and how they will be brought on to it, give them access to new tools on off-hours so they can learn on their own, invite them to bag-lunch training sessions, and give them access to books and magazines. Not everyone can be on the first team, but they can still be involved in the learning process. If you do not involve them you risk losing them.
Recognize that some colleges and universities are still not familiar with the new techniques that you want to adopt. In the early to mid 1990s business in North America were actively adopting object technology, yet it wasn't until the late 1990s that object-orientation was being taught in most schools and many were struggling with the subject in the early 2000s. Similarly, in the mid 2000s businesses are adopting agile software development techniques yet many schools have yet to catch up. The point is that traditional sources of training and education may not yet be available to you.
Getting people into training quickly. Once you have made the decision to adopt a new technology/technique get training in it as soon as possible. Although it is a very good idea to do some reading on your own, the bottom line is that it is too easy to misunderstand an issue and not realize it. Professional instructors can help you to learn the technique properly and to avoid gaining bad habits.
Teach from experience. Good instructors practice what they preach and that their hands-on experience gives them the confidence and the ability to address tough questions.
Recognize that people do not quit because they are trained. I'm often shocked to discover IT organizations that are unwilling to train their staff because they don't want to lose people to their competition, the implication being that they prefer to have staff that nobody else wants to hire. The reality is that developers quit because the money is not good enough, the work is not interesting enough, or because they do not like the people they're working with. For example, agile software developers are paid more than non-agile developers (because they're worth it), and any organization that enters into agile software development had better be prepared to pay their people what they're worth after training them and to provide them with interesting work. Agile developers are in demand and your competition would love to poach them from you. Treat your people well and they'll treat you well.