Creating a Culture of Learning
Posted on April 9, 2023 • 6 min read • 1,135 wordsCompanies can do better to encourage learning and growth of their employees.
Stop me if you’ve heard this before:
CFO says: “What if we pay to train our employees, and they leave the company?”
CTO says: ….
If you are in a “management” position (or if you aren’t, imagine what your manager would say), what percentage of the work week would you like your team to be learning and growing at their job?
This is how I start out my talk on creating a learning culture. I’ve heard ranges from 5%-10% and even 20%. I immediately ask people to do the math.
5% = 2 hours a week. 10% = 4 hours a week.
How much time does your team actually spend? In a majority of cases, it’s 0% (or slightly less). Why is that? Is it because the team members don’t want to take time to learn? Maybe. More likely is that they feel the pressure to spend all working hours (and often a few more) focused on getting the current project out the door.
One of the easiest ways a company can create an environment where its workers want to come to work is to promote learning as a cultural value.
Don’t just say it’s important. Don’t just give them a “book budget”.
Set aside actual hours during the work week that teams are expected to spend learning as a group.
The benefits of learning as a group can bring about major positive changes, not just for the employees, but the team and the company as well.
These benefits include:
At a large health insurance company, we had a team that had a strong culture of learning. We decided early on that we wanted to take time to practice and get better at development by doing a Code Kata once a week. We set aside the time and asked the whole team to join us. The team decided on a format of using FizzBuzz to practice. We used Test Driven Development (TDD) and Pair-Programming and worked to focus on one theme a week.
The outcomes for the team were many-fold. We became better at writing software. We learned to communicate and express our ideas with a common understanding. Without planning it, code standards and conventions organically spread and became agreed upon throughout the team, and were adhered to in our production work.
Other teams took notice of our learning practice and we invited them to join us. This lead to the creation of a class that we could use to teach other teams to use TDD, Paired Programming and Code Kata. Many of the same benefits were realized by these other teams. Other teams would join us for our Code Kata, and the combined teams would then learn from each other.
And then, one day we decided to try another experiment. We decided to go beyond Code Katas. We had always had some personal learning time, and we decided to try learning together.
We set up a learning marketplace, much like an Open Space marketplace, and allowed team members to put ideas into the marketplace. The idea didn’t have to be directly connected to production work.
Some learning ideas we had were:
Once we had a list of ideas, the rest of the team put their initials next to what they were interested in learning. The team then formed groups and got together to learn what they had chosen. At the end of the learning time, everyone returned to the marketplace board, and each team would report the outcome of their learning time. This learning time not only allowed us to gain knowledge, but it also allowed us to innovate. Out of this learning time, the company gained numerous ideas that went on to become full projects.
We expanded a team to create a full microservice architecture for our data service.
We created dashboards for visibility and velocity gain.
We started Mob Programming on production code.
And most of all, we enjoyed working at a company where we felt that our value to the company was recognized and nurtured as we learned.
Where do you start? Sometimes the hardest part of creating a culture of learning is: where to start?. Here are two ideas that have worked for other companies.
Code Katas are practices of writing code to focus on a single area of improvement. They are simple problems that can be repeated over and over with the focus not on solving the problem, but on writing well-crafted code. Kata sessions usually run about an hour. Bring the whole team together to discuss the focal point of the Kata practice during the session. Have a single focus or theme for each practice session.
I suggest starting by picking one of the four rules of simple design:
Get out of the need to solve the problem. Focus on the intended learning for the Kata session. Remember to save some time to talk about learning at the end of the Kata practice time.
Experiments The simplest way to start learning as a team is to try an experiment. Gather the team members that want to take the time to learn, and come up with an experiment around learning.
To be a valid learning experiment, there needs to be a start date and an end date. Time-boxing the experiment will allow you to evaluate how it’s going periodically so that you can choose to continue, change or end the experiment.
Experiments are a great way to get buy-in from management, as they are short and can be evaluated for value at regular intervals. At the end of the allotted time, remember to have a retrospective and discuss what you learned, and whether the experiment was a success, and whether to continue it, re-frame it, or stop it.
No matter how you take time to learn, take time to learn as a team. The benefits you and the rest of the team will recognize will be significant and long-lasting.
And stop if you’ve heard this before:
CFO says: “What if we pay to train our employees, and they leave the company?”
CTO says: “What if we don’t, and they stay?”