I’ve been providing technical training for testing teams for over 10 years now. Most of my experience has been with creating and leading internal training for technology teams within aerospace companies for topics like data acquisition, electro-mech deployment testing venues, or ‘how to build a testbed’ developer instructions. I’ve also gained some broader context in recent years for supporting ‘standardized’ technology training for diverse testing teams across industries outside of aerospace. I’ve put together this list of success-oriented training tips based on lessons learned from creating content, implementing training suites for progressive sets of classes, and first-hand instruction deliveries. Note these observations are not based on any one organization and this post should be considered an opinion piece.
1. Share Real-World Scenarios Where ‘The Technology Broke.’
Some training classes prioritize focus on the positive ideal usage of tools and nominally performing systems. Learning the limitations of tools and toolchains, example fragile design patterns and configurations, and real-world scenarios of system failures can provide some of the best motivations for learning how not to design fragile systems. I’ve been on many teams that are presented a crystal-clear ‘opportunity for learning’ including self-disintegrating or terminated flight vehicles, countless connector issues (oh so many), failed decelerator deployments, near misses in ground-based sequence testing, site-wide power loss during critical operations, and even a broken wind tunnel facility just to summarize a few. Some of these adventures may likely make it into future dedicated posts. Don’t forget to share these types of scenarios during related training to inform and motivate developers how to avoid fragile systems and configurations.
2. Commit to Dedicated Training Time Blocks with Compelling Training Outcomes
Buy-in from team leads and commitment from learners to not ‘work during training’ is essential. I’ve seen many learners miss learning outcomes (sometimes entirely) due to supporting ongoing work emails or other work-related emergencies during multi-day training sessions. The need to block out time is essential to learn more technical materials by maximizing engagement over an entire class.
We want learners to feel like a given training session will help boost career skills and make daily duties easier. By having compelling outcomes and easy to digest ‘modular’ training topics learners are more likely to want to participate. There is nearly nothing worst than a group of learners that have been ‘volun-told’ to take training and are resistant to being involved in the course. Instructors can also help to reduce these types of barriers to learning by asking participants to share answers to questions like ‘What do you want to get out of this class?”.
3. Participatory Formats are Required to Maximize Engagement
There are numerous modes of learning including combinations of visual, auditory, & kinesthetic types and other factors like individual or group-based learning. One ‘hands on friendly’ and interesting learning model is the “Experiential Learning Cycle” that describes a progressive staged learning process (Kolb, 1984). The interaction of concrete tinkering and experimentation with other cognitive focused steps can provide some insight into how instructors can drive learning cycles with hands on and more conceptual learning approaches.
It can be challenging to accommodate a large groups of participants individual preferred learning modes; however, by including participatory formats we can help engage multiple approaches. For example, including hand-on self-directed exploration followed by group discussions can help create engagement for a wide range of learner modes. Often times topics and exercises take on a ‘design cycle’ and serve as a process for exploring a build (or build step), testing (or unit testing), and discussing results (when unexpected results happen). This is exciting to see the ‘meta’ work from a mock training exercise start to take the form of a ‘real’ mini design cycle. It’s also a great team building opportunity for colleagues to teach each other and communicate select tricks and design approaches.
My advice is to insist that most of the class is participatory. Perhaps over 80% of the time is a good goal for participatory-interactive modes. Hand-on demos, guided or team oriented developments, and other applied discussions are always more impactful than lectures, slides, or other one sided formats. Some of the more impactful learning objectives can come from demonstrations that are broke (intentionally) and the collective debugging often seeds some fun interactions and competitions.
4. Advanced Design Patterns Need to be Integrated into ‘Introductory Course’ Materials
Many times advanced design patterns and frameworks can be either put on a pedestal as ‘to be learned later’ or overstated as too complex for introductory courses. From my observations this can lead to developers thinking these tools are too complex to learn and even establish an assumed barrier for adoption. It’s critical for learners to at least have awareness of a full scope of tools being used by fellow architects in developer communities and among fellow internal teams.
We all want to get to the ‘fun parts’ of designing and building. Sometimes not allowing for a segment of fundamentals first can cloud the design spaces by not understanding how to use tools and toolchains as intended. For example, some toolchains have inherent usage cases or limitations based around an typical design patterns or popular deployments. Make sure at least some fundamentals are included up-front before later topics.
Finding the right balance and order of content are essential steps for making training content match progressive learning goals. I personally like no more than 20-30% of introductory fundamentals, roughly 40-50% of mechanics of toolchains, and segmenting the balance of time for at least introductory applied design and interactive discussions. Some organizations have so much enthusiasm or bulk design work to complete it may be worth considering separate classes for how to adapt developer tools for specific designs and organizational constraints.
5. Incentivize Trainers & Architects to Continuously Evolve the Course Content
I’ve worked in organizations where architects either didn’t like conducting training or thought that training was a separate chore for other ‘mid-career’ members. Clearly one can imagine how this might lead to more brittle solutions or training outcomes that do not align with architectural goals and guidelines. My direct advice is to incentivize the instructor roles and jobs such that developers are wanting to become instructors by including recognition items, perks, or compensation and awards for successful training deliveries.
Larger organizations may benefit from using both external instructors and internal instructors. External trainers need to be actively working with the tools being presented to stay current and have a wide experience base for how to apply tools for building generic example designs. Internal trainers need to also have the applied design experience for the given organizational constraints or specific application areas. Finding the right individual with both instructing skills and active developer skills can be challenging. Consider the widespread impact instructors have on your organization, products, and teams when selecting instructors.
6. Sandboxing & Prototyping for Iterative Learning and Embracing ‘Fail Early & Often’ Cultures
You might not believe that some organizations willing to spend ‘literally’ millions on production test cells may choose not to have much if any dedicated development testbeds. Testbed hardware costs alone can be a major factor in this decision. Having spare instruments and sandbox capabilities outside of controlled production environments are essential for developers to be successful and efficiently debug testbeds. These venues open the value propositions for not ‘doing it live’ as the meme goes. Unit testing, interface testing, and other prototype testing can be some of the best money-time spent as this behavior leads to cultures that seek out failures early. Build development testing environments and see the benefits of more stable and robust production tests.
7. Consider External Supplier-Provided Training; HOWEVER, Ensure that Project-Specific & Application- Specific Training is Available Internally
I’ve both participated in as a customer and provided standardized or industry-agnostic training as an instructor. These externally provided training classes can be very valuable training formats to get the latest training ‘straight from the source’. As these types of training materials are often created in the spirit of a general audience there are project-specific or organizational-specific contextual items that are missing. Including internal out-briefs or other internal training may be required to help understand the differences between general industry-agnostic ‘best practices’ for a given toolchain and the real application of a given projects organizational constraints for the related solution. Advanced instructors will be able to communicate the duality of a ‘best practice’ and the differences for an individual design instance or application focused practice.
Closing Thoughts
Here's to hoping your organization has collaborative and engaged technical training established. Also, most developers will need training and benefit from additional mentoring with a more one-on-one style mentorship. My first testbed development was only a success due to the confluence of external training (as the skills didn’t existing at that org. yet) and some considerate internal mentorship for the testbed design lead. Don’t forget to ask for help when the learning curve appears vertical and happy training 😊.