I’m Ryan Blunden and during my career as a Developer and Educator, I’ve learned a lot about the development of technical training for organizations, teams, systems and code bases.
In this multi-part series, I will illustrate how L&D and ENG (Engineering) teams can best work together to produce quality, maintainable and scalable training materials that meet the very specific needs of each company’s ENG team.
Having spent over 15 years of my career as a Developer, I understood what Developers needed from their L&D Departments. However getting L&D and Talent Management (HR) staff to understand the nuances of what Developers need without overwhelming them with technical details is very challenging as the complexity grows rapidly. It’s not as simple as defining the learning requirements with stakeholders and find a training course to match. Easier perhaps if we’re talking about the compulsory training required by law. But is it this simple with tech training? Come on this journey with me to see.
This is part two in my series “L&D and Engineering – Let’s Work Better Together!”. In the first part, I described why off the shelf training solutions don’t work for most ENG requirements and in this second part, I want to share with you how and where Developers learn.
But first, we need some context about why Engineers are learning on a daily basis from an almost endless list of resources.
Things Used To Move Much Slower In Software Engineering
Managing the training requirements of an ENG organization 15 years ago was a lot simpler because (generally speaking):
- The rate of systems and software change was much slower.
- Systems were composed of larger and fewer parts.
- The Internet was not yet fully utilized as a way of sharing code, knowledge and documentation.
This meant that the pace of learning required to stay current was slower in most industries, plus eLearning was only just starting to gain a foot-hold. Therefore books and face-to-face courses were the typical way people would learn a new language or system.
Open Source Software Changed Everything
Fast forward to today and the proliferation of Open Source software in technology from Mobile to Desktop to Server and even embedded systems means:
- Software systems are composed of a greater number of smaller components as Engineers can choose to source the “best tool/code/system for the job” from any number of places online.
- Many Open Source projects will release software simply when ready, meaning ENG teams are unable to plan around scheduled updates, adding risk and complexity to system maintenance.
- The increased number of dependencies in most systems means the surface area of things an Engineer must know just to get their work done (let alone innovate and excel) are growing constantly.
So more than any other factor, it is the widespread consumption of Open Source software that has rendered many old learning models obsolete for Engineers.
Why No One Builds Truly Effective Generic Courses For Engineering Teams
With ENG teams putting together their own custom systems consisting of closed and open source software, it is impossible for vendors to create training packages which could account for the infinite possibilities of how these systems are put together.
Generic courses, videos, and books can only teach at the lowest common denominator, which don’t get me wrong, is still useful, but can only take Engineers so far.
This is one reason why DevelopIntelligence for example, constructs custom training courses and materials for each engagement in almost all cases.
To build a great and useful partnership with ENG, L&D practitioners need to study, observe and understand how Developers learn and attempt to keep up with their teams and then build a picture of what could be done to make the learning process more efficient.
The Many Places Engineers Learn
Here is a selection of the places where the knowledge an Engineer needs may be:
- Social Q&A systems and, knowledge base toolsAPI docs (documentation generated from code and code comments)
- Documentation websites or a collection of text documents that serve to explain how the system works, external to the code
- Source code version control comments
- Source code search systems
- Slack or Skype conversations (group and individual chat)
- Screen casts or video demonstrations
- Meeting notes
- Software release notes
So much disparate content. What to do?
One solution that L&D teams could immediately help with, is conveying the importance of ENG teams constantly recording, documenting, and then sharing the capture of knowledge within their respective teams.
For example, if an Engineer requires a 30 minute face-to-face chat about how to setup their machine for developing a particular piece of software, perhaps the interviewing Engineer should document this, making it available for future team members.
What Do I Mean By Document?
I’m not talking about a Word document that sits on a shared server that no one looks at.
The modern era of smart devices and technology means Engineers have numerous ways to “capture” knowledge, for example:
- Audio recording
- Video recording
- Screen Cast
- Photographs of handwritten notes and diagrams
- Documentation system such as MkDocs (Make Docs).
Making this knowledge available can be as simple as email, although finding these resources must also be taken into account as the best documentation will never get used if it can’t be easily found.
Some progressive large organizations such as Twitter have used tools such as Elastic Search to index content from as many of these places as possible, giving Developers a single place to search.
So How Are L&D Practitioners Able To Help?
The situation seems hopeless, overwhelming, and with so much tech specific jargon and systems, how on earth is an L&D practitioner meant to help? The answer is much simpler than you’re likely thinking.
Your job is to help them create knowledge into quality educational content, however that may be. Help it to be found. Help the teams value it.
L&D shouldn’t become the writer (that doesn’t scale), but the consultant, who helps Engineers become better learning content creators.
While ENG team members may not be able to discuss with you what good pedagogy is, they sure can learn how to create documentation that:
- states learning outcomes and demonstrably delivers on those outcomes
- is easier for beginners to understand
- has an on-boarding guide for new team members
- has an index of the most important places to find answers and more information
- builds a culture of people searching documentation for answers first instead of interrupting their colleagues.
And that is only the tip of the iceberg!
Where To Start?
Start by just asking ENG team members and their managers what learning-related challenges are impacting their efficiency and productivity.
For example, the main concern might be the ramp-up time for new team members. Great! Guide them to creating a comprehensive self-paced onboarding guide!
As the ENG team members will be responsible for compiling the content (whatever medium it may be in), your job is to guide them to help make the learning content they are producing better quality as time goes by.
Remember to keep your consultant hat on. They have to own the problem and the solution.
Some More Suggestions For How You Can Help.
- Find out how, what, when and where Engineers are learning, e.g, shared wiki.
- What is working, what is not working and where the deficiencies are, e.g, the documentation does not keep pace with the software as it is not required to be updated.
- Identify solutions, e.g. help ENG teams construct new process rules such as documentation that must be maintained alongside the code and is required for all code commits.
Engineers Are Always Learning! Your Job Is To Find Ways To Support Their Learning
Due to the dynamic and ever-changing nature of modern software, systems, and code, Engineers are constantly learning and using a myriad of tools and content to do so.
Therefore, it’s essential for L&D practitioners to guide Engineers in how they can improve the quality of the educational content they are creating, how the answers can be found more easily and ensuring that the documentation, no matter what form it takes, always keeps up to the date with system/code it is supporting.
In a future post, we’ll tackle this problem from a technical leadership angle, using current and future leaders and influencers to provide curation and editorial review in order to drive the continuous improvement of learning content.
Latest posts by Ryan Blunden (see all)
- Running Linux? You could still be exposed to WannaCry - May 19, 2017
- How and Where Engineers Learn - April 26, 2017
- L&D and Engineering – Let’s Work Better Together! - April 12, 2017