1 March 2023
Creating a Culture of Learning and Growth
by Andrew Ek
Software development as a field is somewhat unique in two ways.
First, the tools we use change rapidly (and new alternatives arrive almost daily). We’re still very much in the early days of discovering how to better use the tools we have, and as we find the limits of the existing tools we see replacements emerge.
Second, software developers have to handle a fairly high cognitive load. We must deepen our knowledge of the existing tools we use, while staying abreast of relevant developments in new tools, and we must keep up with the business domains our software models. And then we have the same institutional knowledge questions that every professional has (“Who’s the decision maker for this issue?” and “What precedents for this exist within my team or organization?”).
With “knowledge” work, we need to make space to cultivate and deepen that knowledge.
As individuals, we do this professional development largely on our own time, or occasionally as dictated by the problems in front of us. Thus, the pile of half-finished side projects and half-read technical books. Individual engineers can and should learn on their own time, but in my experience it’s fairly rare to see this learning come back and directly benefit the team.
As team leads and engineering managers, we have some interesting opportunities to build a learning culture, that is, a repeatable, sustainable, team-wide practice of improving our craft during business hours in ways that are valuable to the team and company.
Sidebar: Wait, what’s learning?
When I was a teacher, I (and my then-colleagues) wrote a lot of lesson plan objectives to the effects of “students will learn…” or “students will understand…”. Early in my career I didn’t have a great way of telling whether (or when) students had actually learned what I hoped they would.
The facts were (probably) in their brains, but how could I tell other than asking them? And how could I tell whether they had learned something or merely memorized a definition? We have tools like Bloom’s Taxonomy of Critical Thinking, but even then most of the examples I saw of “higher order thinking” were variations on memorization or specifically directed application. It felt in many ways like I was guessing.
A few years into my career, a colleague recommended to me Understanding by Design (Tighe & Wiggins), which correctly pointed out that we cannot directly observe the brain in the classroom. Instead, we must look at observable behaviors.
This leads me to a further definition: learning is change in behavior in response to new information.
This may mean a novel behavior (learning a new skill) or a refinement on an existing skill, or even better language to describe a problem we hope to solve.
If we are taking in information without seeing a behavior change – even if that behavior is simply taking notes that are accessible later, e.g. through the CODE method described in Building a Second Brain (Tiago Forte) – then what we’re doing is more accurately described as occupying our time with things that feel sort of like learning.
I’d wager that for much of my career, I did not learn from the resources I read and instead largely occupied my time with them. Even when I did learn, I’m not sure that much of what I learned made its way to the teams I was on.
Individually, I do a much better job now of taking notes so that even if I can’t apply what I’m learning right away, I can refer back to it when it becomes relevant. This isn’t quite learning in that there’s not yet internalization most of the time, but it’s at least more usable and useful than “I remember reading something about that once… I wish I remembered where or what.”
A Learning Organization
Most conscientious practitioners of a craft (software development or otherwise) spend at least some of their own time learning more about how to better do the craft.
Individuals, left to their own devices, will learn the things that are most interesting or potentially useful to them as individuals (learning a new programming language, or brushing up on data structures and algorithms for the next technical interview, or learning about how to better care for their pet geckos). These things often do not translate to what the organization needs.
By contrast, a learning organization has team members who seek to build organizational knowledge around things directly relevant to the organization. Individuals are empowered to work collaboratively to identify and solve problems, and are trusted to do so without much external direction.
Learning goes from an individual to a group activity, and is directly motivated by improving business outcomes for the organization. People take ownership over their work and of finding ways to do the work better next time.
A learning organization is a vibrant, dynamic place. Change comes from both the top and the bottom (rather than only from leadership). When new folks are hired, the team as a whole takes responsibility for making sure the knew person knows how things are done. Key insights and core processes get recorded and documented, and over time those become easier and easier to access. As new problems arise, the team feels empowered to tackle those head on rather than simply gritting it out or waiting for management to fix it.
What does this look like?
Every organization will look a little bit different, but these are some practices I’ve had success with:
The first is “professional learning cohorts”. A small group (3-5) of folks identify a gap in their knowledge or something they’d like to learn more about, then over the span of an hour or two per week over 4-7 weeks, with a selected resource, learn in ways that let them fill that gap. The key here is precisely identifying a skill along with a project or task that, when completed, suggests that the skill has at least been attained.
For example, I worked once with a group of developers who wanted to learn more about mobile application development, as they’d had clients ask about it but didn’t have the expertise to say they could definitely deliver. The project they selected was building a mobile app that interacted with a RESTful endpoint on a server they controlled that could fetch, create, and update records, with relevant screens for each. It wasn’t a professional-grade application, but it was enough that when a prospective client asked about mobile application development a few months later they could confidently say they could do it.
Professional learning cohorts should be strictly limited in time and very focused on an end result. It’s better to cut scope than to let these last for too long.
Another variant of this is a departmental book club.
With these types of sustained initiatives, I prefer to see some report or presentation back to the organization at large. These types of presentations often spark some really interesting ideas and possibilities – the folks doing the learning learned how to do something new, which usually opens up entire classes of opportunities that previously weren’t accessible.
The second is internal training conducted by team members (rather than strictly by business or technical leaders). In technical organizations, this means junior and mid-level developers can do 20-40 minute trainings on tightly focused technical or business topics. This is enough time that most participants will learn something both new and useful, but not so long that preparing is a significant undertaking. More senior developers should also do these types of trainings from time to time, but should mostly attend and ask good questions.
The third is a running “neat articles” channel in the company Slack or message board. Ideally folks posting will share the article or resource, a summary, and a few key takeaways. This becomes a searchable shared knowledge bank for the team.
In all cases, what you see is collaboration between folks of different levels and different domains. One of my favorites parts of the Launch Scout apprenticeship program is how often an apprentice saying “I don’t know how that works” becomes an invitation for other junior and mid-level developers to say “Actually, I don’t know much about that either” and then we all get to learn together.
You see folks learning and putting into practice what they’ve learned. And you see that learning being done in public where it can spark conversation and open up new possibilities (rather than being done in private where no one knows about it or talks about it).
You see folks identifying problems, stating those things out loud, and working to find good solutions (or at least better approaches). You should see a number of strategic experiments with new approaches, and a culture of “Even though this didn’t work, we learned more about the problem and that is good.”
What you should see also is folks in both formal and informal leadership positions being really excited about this work, even if it’s not immediately useful.
You should also see a fair amount of this work done during normal business hours.
What prerequisites do we have to have in place?
There are a couple of key practices we might consider as we seek to build this culture.
The first is that we need to ensure that there’s time and space for this learning, and that it’s kept sacred. If everyone in my organization is constantly putting out fires, or if we can’t reliably block off time on my schedule during the day because we’re constantly in meetings, we can’t make the time to do this type of collaborative learning.
The second is that you need a healthy tolerance of failure. Most experiments do not work. You don’t ever want your teammates or employees to say “This problem is far less unpleasant than the consequences of me trying to solve it and not succeeding,” especially when that problem adds friction to their daily work.
The third is that you need this work to come from line-level folks, rather than just management. Every organization has some set of trainings, mandated from on high, that all employees must go through, but that’s not sufficient for a learning organization. You need employees to step into ad hoc leadership roles around this knowledge and problem solving, and your managers need to encourage this.
Finally, you need folks to be willing to let go of their egos. Part of having a learning culture is having people admit out loud that they have things they don’t know or wish they knew better. It needs to be safe to be vulnerable.
When we think about the sum of human knowledge (much less the sum of all the facts in the universe), any individual one of us knows very, very little. However, each of us knows a little bit more about a few things than most of our colleagues do, and that little bit of knowledge helps us to do better work.
Where do I go to learn more?
Harvard Business Review has a really great (and classic) article about creating a learning organization. SHRM did a nice write-up as well of learnings from Coca-Cola’s learning organization transformation. I also really like Andrew Barry’s work at Curious Lion about learning organizations and culture.
