The document outlines a six point plan for designing and running a successful re-training program: 1. Know your developers and tailor the training to their different types and needs. 2. Ensure the training addresses an immediate business need or upcoming project requirement. 3. Include a sample project for delegates to work on to apply their new skills. 4. Involve the development team the delegates will join to help plan and mentor the program. 5. Do not base tenders for training providers solely on time as it can compromise quality. 6. Avoid tunnel vision and allow delegates to gradually progress their skills rather than focusing only on current tools.

1. How to Design and Run a Re-training Program Garth Gilmour (garth@ggilmour.com)

2. About Me... Over 500 Deliveries Teaching since 2001 With positive results Lots of retraining 4 to 8 programs a year Java to .NET .NET to Java C++ to both COBOL to both Graduates to industry

3. Why Are You Here ? To make a buck… To right a wrong… Because you got lost…

4. Introduction and Agenda You get good at what you do frequently Most companies retrain rarely (fortunately) Retraining is on the rise… JEE and .NET furiously reinventing themselves Everything pre JVM / CLR harder to support Recruitment problems due to fewer IT grads This is a 6 point plan for success My top tips for retraining success

5. A Warning! This presentation pulls few punches Feel free to hit back… All examples have happened many times At many companies The technical term is ‘anti-patterns’

6. The Six Point Plan Know your developers Address an immediate need Have a sample project Involve the development team Never tender based on time Try to avoid tunnel vision

7. 1: Know Your Developers Training must be tailored to the audience Otherwise it doesn’t stand a chance There are two classic types of developer Or stereotypes if you prefer No1: The professional programmer No2: The corporate developer

8. The Professional Programmer ‘ I’m a developer working for Mega Corp’ The good news: Unafraid of complexity Works till the code does Capable of taking on a wide range of jobs The bad news: In love with technology Elitist attitude to customers

9. The Corporate Developer ‘ I work for Mega Corp as a developer’ The good news: Company committed Understand the business Customer focussed Develop a speciality The bad news: Resistant to change Don’t learn proactively Can be inflexible

10. Planning a Program Based on Type For professional programmers: Lots of depth, detail and perspective Comparisons with other technologies Free form examples and exercises Pointers to supplementary reading For corporate developers: Tight focus on the systems they will build Structured exercises with setup and solutions Based around a single manual / text

11. 2: Address an Immediate Need Training should never be speculative It must address an upcoming requirement A change of platform in the company New projects arriving from overseas Neither type of programmer adapts well Corporate developers become resentful Which sours their attitude for the future Professional programmers become restless Which can lead to ‘itchy feet’

12. 3: Have a Sample Project If the need isn’t urgent then make it so A sample project is always a good idea It gives the delegates something to aim for It brings all the learning into focus Even for the most dedicated “ Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully.” Samuel Johnson

13. Letting the Knowledge Percolate No one learns on a training course Instead the knowledge settles in as it is actively processed Through discussion, reading, reflection and above all coding The more you can do to help knowledge ‘percolate’ the better Information is useless unless it can be applied

14. 4: Involve the Development Team Most companies put up ‘razor wire’ for no reason Between delegates and the teams they will join This makes no sense! Senior developers should be involved in: Planning the program Creating the sample project Mentoring the delegates

15. Involving the Development Team The team that the delegates aspire to join needs to take responsibility early Its their own future they are safeguarding It can save the company lots of money By ‘in-sourcing’ parts of the training program Without mentoring bad things happen Delegates get frustrated over basic issues Like installing tools on their own workstations A ‘them and us’ mentality develops Between the plank-holders and the newbies…

16. 5: Never Tender Based on Time Tendering is a good thing You ensure the most value for your investment Tender based on: Range of delivery Quality of delivery Previous experience NEVER EVER TIME! Don’t encourage an ‘I can teach that course in two days - honest’ situation

17. Tendering Based on Time Although it is very tempting to assume that all courses can be compressed into the allotted time on the training program the truth is that people learn at a fixed rate and no matter how quickly the instructor speaks or the exercises are truncated there is a limit beyond which people simply switch off and all training becomes counterproductive especially if they feel that this is being done just to keep things in schedule and on budget so you should not create a situation where training companies tendering for your business feel the obligation to compress the material beyond the point where it can be delivered with an expectation of success.

18. Managing Time Efficiently Gaps between courses should be planned Too short and delegates are overwhelmed Too short and they start to lose information A lot depends on what they do in between Time should always be set aside for self-training and working on the sample project Placing delegates on a full development schedule between deliveries wastes their time and your money If I don't practice for one day, I know it; if I don't practice for two days, the critics know it; if I don't practice for three days the audience knows it. Ignacy Jan Paderewski

19. 6: Try to Avoid Tunnel Vision There is a natural desire for relevance Train delegates in the technologies they need Familiarize them with the tools they will end up using However the ‘straight road’ approach can lead to tunnel vision Early adoption of enterprise tools can harm not help

20. Avoiding Tunnel Vision There are alternatives to enterprise tools Which are much easier to use and install Despite implementing the same standards Examples are easy to come by Subversion rather than ClearCase MySQL rather than Oracle or DB2 Tomcat rather then WebSphere Open source tools let delegates learn at home Rather than being dependant on company licenses

21. Tunnel Vision on Sample Projects Tunnel vision applies to sample projects Many teams are reluctant to sponsor a sample project unless it exactly mirrors current projects Again this places the cart before the horse Pilots move from gliders to propeller driven aircraft to small jets to commercial aircraft They don’t get placed in the cockpit of a 747 on day one Developers should move from the console to GUI applications to Web Apps and then Web Services The gradual progression helps knowledge ‘percolate’

22. Tunnel Vision on Sample Projects Experience can be gained in many ways…

23. That’s All Folks! Many thanks for your contributions Hopefully this has been useful to you Further questions and feedback are welcome Good luck with your training programs ! Remember you are always the one in control