I have well over 15 years of experience in the field of software engineering and during that time I have supported, trained and mentored the careers of dozens of developers on multiple continents, but that was always in support of internal career growth and development. A few weeks ago I was asked by my department Director if I would lead a training session for one our direct clients, and I agreed. So last week I had, for the first time, the opportunity to train developers as part of the mission of an externally facing training department. The training session was scheduled for 2.5 days and it was a fascinating, draining and fulfilling experience, and so I wanted to document some of the details of what I would have probably done differently if I had a do over.
Training brief
Share your detailed training brief early and often! For me this was especially important, I was not involved in the initial discussions with the client and so by the time I got to talk to the developers on the ground some details and requirements were lost in translation. In fact as I started to layout the training topics I was immediately challenged about the usefulness of the entire course, clearly client communication and expectations were at issue. This left me with two choices, only talk about what was strictly defined on the signed work order and annoy/bore my target audience or spend some additional time meeting the needs of the client. I elected to do the later, but even then I could only do so by pushing hard through the target material and spending hours of my evening preparing additional content for the final day. In the future (if I do this again) I will ensure that the developers (leads and managers especially) get the detailed training brief long before I arrive.
Own your material
The training material was carefully curated by the former trainer and they were thorough, succinct and accurate. Regardless, those materials were not mine, I never had the time to make that material more appropriate for a presentation that I would give and so I found myself constantly at odds with the pace of the course. In hindsight I would have changed the material to better match my approach and teaching cadence. The truth is I have never done this before, in this format and as such I was the victim of the 3rd order ignorance (I did not know what I did not know). This may have been a case of just not being familiar enough with this particular set of documents but either way it always felt like I was teaching someone else’s stuff, during the potential next iteration I feel I would need to do more to ensure that the course material is second nature for me.
Know your audience
One of the biggest and most inaccurate assumptions I made going into this training course was that the developers were new to the subject and the training material. This was not true, in fact almost everyone was aware of our product and its associated SDK, and had at least one years experience. A few of the developers had been actively working on Corillian products longer than I had and while this initially changed my approach, it ended up being a great boon. During the class folks with more experience were happy to help those with less experience and this was actually critical to ensuring that we covered the material in time. Having this level of expertise listening to your every word does have the potential to highlight philosophical design differences and for the most part I was happy to concede most of those points with caveats, and in doing so I felt like I won the smartest people in the room over to my cause.
Organize a life line
In complex training courses with multiple moving parts something is always bound to go wrong, in fact it should be assumed that something will go wrong. Our course took advantage of Virtual Machines provided by a company called Vaasnet and at least two developers had irreparable issues arise due to faulty VMs. Thankfully I had my Vaasnet support contacts on speed dial and they were able to get us back online in no time, additionally I had contacts at the office ready to research specific issues that came up. Ensuring that I could focus on the training material rather than non-related technical issues was critical to guaranteeing that we kept up with our agenda. I would also suggest the use of an independent Wi-Fi hotspot, relying on corporate networks to allow you access to the public internet is a little naïve in this day and age.
Measure your success (or failure)
Measuring success was something I thought about on the last day just hours before I was scheduled to bring the course to a close, and that was just too late. While I set clear objectives, reiterated those objectives, and also spoke about them in daily reviews, at no point did I survey the group on how well the training went. I am confident in the material I presented, I just believe objective feedback about my personal performance is a really important metric. This was an oversight on my part but thankfully our training manager has already started a plan to follow up with the client.
It is clear to me that I have a lot to learn about training, and while I would describe my first attempt as a passable success I think I also need to refine my approach. This has honestly been an interesting fork from my day to day activities and I will soon have to make a decision about whether I want to do this again.
For the historical record this job was heretofore brilliantly executed by Phil Weber, he has moved onto greener pastures at New Relic, in fact Phil was one of the developers who trained me when I first joined Corillian.
Comments are closed.