Software development is a fast-moving industry. With new programming languages, concepts, and technologies to master, two-thirds of respondents told the Cloud Native Computing Foundation it’s “getting harder to keep up with the pace of change in software development.”
The outdated two-day training sessions focused on people working on theoretical problems and a rigorous curriculum, taught via slides and controlled exercises, didn’t get results. The ROI is non-existent, and developers might have gotten some awareness, but applying this knowledge proved to be an insurmountable gap.
Product and engineering teams need different ways of learning. Learning that aligns with their context—codebase, problems they’re solving, and challenges. Many software engineers didn’t start learning coding in classrooms. The State of JS report found 75 percent of developers started through self-teaching—more than any other format. (I fall into this majority; my college’s computer lab became a second home.)
When helping teams improve productivity and performance, I lean into developers’ enthusiasm for relevance—can I apply this learning now? This aligns with the 70/20/10 model: 70 percent of learning is through on-the-job experience, 20 percent is through colleagues and friends, and 10 percent is through formal training.
3 Tips to Engage Teams
Here are three tactics for engaging product and engineering teams in immersive learning.
- Solve real-world problems, not hypotheticals.
Formal training relies on controlled scenarios that address checklist items. Students must apply these scenarios to real-world situations when they leave the classroom. They finish training, spend time dealing with other priorities, and when it’s time to apply what they learned last week, it’s gone.
I’ve learned best when trying to accomplish something on a real project. When working with teams, we put this wisdom into practice.
We identified a real-world outcome and determined what we needed to learn to accomplish it. I helped a team increase unit test output (a metric related to how much code developers write) by learning design methodology Test-Driven Development (TDD). We worked together to adopt this new practice in the flow of work. We put in measurements and found test output increased by 640 percent. While this metric isn’t the point of TDD, it shows the practice working.
Tailor immersive learning exactly to a project/problem teams face—they’ll care since it’s relevant now. The payoff is obvious.
A key ingredient of immersive learning is making experienced and emotionally intelligent practitioners available to teach by example. Our mantra is “Show, don’t tell.” There’s no curriculum. Just working together, hands-on.
This style works over longer timeframes versus two-day training sessions. The results are overwhelmingly stickier, driving sustained impact on teams’ results. Leaders must consider this trade-off, asking themselves what they want. Is it awareness? Or impact?
- Encourage experimentation.
There’s a profound relationship between learning and experimentation. The most effective teams learn by testing hypotheses, observing results, and pivoting or doubling down accordingly.
Experiments might be scientifically rigorous, comparing test and control groups and looking for statistical significance. Sometimes we’ll use established metrics. In software engineering, the metrics advocated by DevOps Research Agency (DORA) measure the performance of software development teams by assessing their delivery speed, deployment frequency, stability, and recovery from incidents. Baselining these metrics might tell if teams are learning and, by extension, improving.
Experiments can be simple. I’ve had teams try collaboration methods, like pair or ensemble programming while adopting new practices/tools. Small tests like this take a chance on a gut feeling—try it, see what happens, and pivot if needed.
The goal is trying something new and whether it works. Experimentation works as a training technique when two conditions are present:
- Teams feel psychologically safe. They trust that sharing a bad idea or an unsuccessful experiment won’t put them at risk.
- Leaders are comfortable relinquishing some control. They should articulate an overall vision, encouraging teams to test and explore as they determine their role in implementing that vision.
Teams with freedom, safety, and bandwidth to experiment have everything needed to sustain continuous improvement. They’ll start solving problems as they crop up.
- Develop coaching as a skill.
We discuss coaching as a role that starts and stops: We bring in coaches to teach a new concept. Then it’s over and they leave having transferred their knowledge and skills. That’s one level, but coaching investment compounds when coaches foster an environment where peer-to-peer coaching happens.
We worked with a team that had many internal handoffs and bottlenecks. When showing us their Jira board, I could see they modeled their work as a series of queues and working states. Seven or eight states—developing, checking, testing, and so on—all for an eight-person team. I asked them what their goal was. “We want to be engineers.” Until then, the team had several roles: developer, tester, architect, etc. I suggested their workflow might be holding them back.
We created a matrix of skills (not roles) and people. We created duos and trios of people with different skill sets to work on one work item at a time. The experiment was successful, and all handoffs were removed from their Jira workflow.
The value of peer coaching goes beyond upskilling. It helps everyone view the team as a gestalt where the whole is greater than the sum of its parts. Peer coaching changes the culture by challenging traditional power dynamics. Seniority matters less when a junior team member knows something a more established player doesn’t.
Learning should be a cultural tenet, not a one-time activity.
Mastering new skills and tools isn’t a survival trait for fast-moving landscapes of digital transformation, information technology, and software product development. Instilling a culture of learning pays dividends for developers, designers, and their employers. In prioritizing learning, increased productivity and performance are happy and profitable side effects leaders can expect.
Don’t limit training to teaching in a vacuum. Training encourages teams to adopt learning as a cultural tenet. Good training sets people up for lifelong learning. Immersive and experiential techniques are the best ways to ingrain learning within teams’ cultures. Don’t tell teams what they need to learn, show them. They’ll take it from there.
