Nurturing healthy team learning cultures has never been more important for engineering leaders.
The average shelf life for tech skills is estimated to be about two and a half years. The things that our engineers learn today about React hooks, AWS Rekognition, or building CI/CD pipelines, for example, will not be the exact things they need to know three years from now. As such, folks in the engineering sphere find themselves on continuous learning curves.
A good learning culture will not only help in this vein but also with dev retention and productivity. Having the permission and encouragement to upskill on the job, during working hours – rather than on evenings and weekends – can increase engineers’ satisfaction and thriving.
Despite the importance of a healthy learning culture, leaders and individual contributors (ICs) constantly field signals that it’s not okay to learn: staff reductions, an endless supply of support tickets to investigate, and a buildup of technical debt are just a few of the things distracting our engineers from taking the time they need to learn.
The collective manifestation of beliefs: Team culture
What does a healthy learning culture look like to you? If it takes the form of an engineer solving problems independently, with nothing else to help them apart from technical documentation, you might want to reframe your approach.
A healthy learning culture is brought about with the help of each member of a team. But here, it’s managers that will have outsized influence. Leaders can have a marked effect on the extent to which and how publicly individuals engage in learning at work. If a team’s principal engineer believes focused upskilling should happen outside of company-paid time, that belief may trickle down to more junior team members and shape the learning culture of the entire team.
When unhealthy learning cultures like this take root, you run the risk of accumulating learning debt. Learning debt is a concept introduced by my colleague Dr. Catherine Hicks in her white paper, It’s Like Coding in the Dark. Dr. Hicks describes learning debt as “a cumulative failure to support learning, created when code writers’ investment in long-term understanding is disincentivized”. She emphasizes that this debt particularly emerges when engineers know they need to upskill in order to complete critical work, but believe that their leaders and teammates don’t support that learning.
If the passing up of on-the-job learning opportunities happens repeatedly over time, and enough learning debt has accumulated for an individual, a team, or a company, engineers can quickly get into the space of no longer knowing the things they need to know. And, ultimately, this impacts their overall efficiency and productivity.
An intervention: The learning-themed retrospective
Learning-themed retrospectives are a great way of addressing this problem. I used this technique for my own team and had positive results. The retrospective I led was done synchronously over Zoom, with myself and my team working together to create continuous, positive discourse.
I made it clear that the goal was to steer the team away from negative upskilling beliefs, and take a closer look at how such beliefs may have weaseled their way into our own learning culture. As with any retrospective, we hoped to walk away with a set of action items that would allow us to begin chipping away at any learning debt we had accumulated and prevent its further buildup.
Part one: The icebreaker
We started with the icebreaker question, “What is something you’ve tried but failed to learn outside of work?” This open-ended question gets people to think about their learning approach and contribute to the wider discourse. In their book Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larson argue that folks are more apt to participate throughout a retrospective if they’re invited to speak and share within the first few minutes of it.
To guide the conversation, I provided my answer first. I recounted how I had tried but “failed” to gain beginner-level proficiency in Icelandic that summer (to prepare me for the extended time I was to spend in Iceland).
This also served as an opportunity to clarify what “failure to learn” meant. What constituted a failure, anyway? We agreed as a team that “failure” encompassed not learning the thing we set out to learn for any reason, including contextual and environmental reasons, rather than simply a failure of motivation, discipline, or follow-through on the part of the learner.
Part two: Context and rationale
Software engineers are typically critical thinkers who must be convinced that something is worth their time and energy – especially when there is code to be written. Explaining the reasoning for holding this session (in my case, this was Dr. Hicks’ research) can help everyone get on the same page.
To that end, I summarized the research on learning culture which ignited my idea for this retro. I also voiced the connection to be made between learning debt, our individual beliefs about code learning, and our team’s learning culture.
(When I hold this type of retrospective again, I’ll ask my team to read Dr. Hick’s paper before we meet so that rather than using that in-person time for summarizing the paper, we can discuss Dr. Hick’s ideas around learning culture and learning debt.)
Part three: Sharing a personal learning story
Knowing you’re ignorant of something and not taking the steps to recover that knowledge gap can lead to feelings of guilt. What’s more, sharing those feelings in the open at work requires a decent amount of vulnerability.
To encourage this vulnerable sharing, I relayed my own learning story. I recounted how, a couple of years earlier, I had applied to my current position with no practical Python experience, despite the job posting asking for someone who had written “hundreds of thousands of lines of production Python code.”
I ended up getting the job, of course, but for the first couple of years, I accumulated a lot of learning debt. I explained that this happened both because our team culture was so centered on rapid feature delivery ( I didn’t want to slow us down by taking focused time to learn), and that I believed I’d been given a gift by having been hired with no Python experience, and therefore, shouldn’t use company time for upskilling.
Part four: Inviting self-reflection
I then asked my teammates to think about a time that they had needed to learn something for work, which they then never had the opportunity to get around to. I gave them several minutes to think about this and to describe the situation and context in a Slack channel that our team regularly used for retrospective activities.
We held off on analyzing the reasons they hadn’t learned this thing, because our next activity was the “Five Whys”, a task recommended by Derby and Larsen that aims to unearth and analyze root causes.
Part five: Root cause analysis with Five Whys
The Five Whys activity gets participants to ask the question “why” in response to a problem. This is done five times to five separate answers until a root cause is discovered.
To kick off this activity, I gave everyone the starting question: Why didn’t I end up learning this thing? I posted my own Five Whys sequence based on my experience applying for my current position in my Slack thread as an example of what this line of questioning could look like:
Q1: Why didn’t I end up learning Python as quickly or as fully as I had intended when I first joined the company?
A1: I didn’t think I should take company time for upskilling in Python.
Q2: Why didn’t I think I should take company time for upskilling in Python?
A2: Our team was moving so fast to deliver new, customer-committed features that I didn’t want to ask for dedicated upskilling time.
Q3: Why didn’t I want to ask for this upskilling time, even though I knew I needed it?
A3: I didn’t want to slow my team down, and I didn’t want to reveal to my teammates how little Python I actually knew.
Q4: Why didn’t I want my teammates to be aware of my actual Python proficiency?
A4: I was embarrassed about how little I knew relative to other team members.
Q5: Why did I worry about how my teammates would perceive me, rather than take the opportunity to get mentored by more experienced Python developers?
A5: I was holding myself to unreasonable standards and probably suffering from imposter syndrome.
My question-and-answer sequence revealed that a combination of team culture and self-beliefs had prevented me from seizing an opportunity to increase my Python proficiency.
With my above example to guide them, I gave everyone about five minutes to complete this task, directing them to record their sequence in their own Slack threads. I then asked if anyone was willing to talk us through their learning story and the five questions they had asked to analyze its root cause. We spent a bit of time at this point just listening and responding to each other’s learning stories.
This part of the retrospective constituted the bulk of our time together, as not a single person on the team lacked a story. It was fascinating to see everyone connecting over this idea of habitually failing to ask for learning time – periodically accumulating learning debt – both because of the team cultures they’d been a part of, as well as those personal beliefs about upskilling that they’d held throughout their careers.
I wrapped up this exercise by asking everyone to think of an action item around on-the-job upskilling they’d like to take based on their reflection, and to post it in their Slack thread.
Insights from our retrospective
What did our team discover through our learning-themed retrospective?
We learned that what had felt like individual experiences were in fact shared by most – if not all – of us. Each of us had passed up learning opportunities, and each of us had accumulated learning debt at some point in our careers. This discovery opened up the opportunity for us to connect and commiserate over times that we’d held limiting beliefs about code learning, or times that we had been members of teams with unhealthy learning cultures.
We were also able to dissect why engaging in on-the-job learning sometimes felt so difficult for us, connecting those challenges back to our beliefs and team culture. By understanding those root causes, strategies and actions were devised to prevent learning debt from accruing further.
