Learning Lab: Case Method
I've taken this workshop format from the videos on the HBS Case Method.
Use this template to facilitate an in-person or remote learning lab where the group explores a case study. I've run this with a group of 4-6 people, but larger groups are possible.
- 45 minutes
- 4-10 people
- Use powerpoint to display details
- Use whiteboard to brainstorm with the group
- Treat each other with Kindness, Consideration and Respect.
- No phones.
- Present scenario
- Split into pairs & explore case.
- Brainstorm case together.
- Split into larger groups to practice answering the question again
- Practice answering the question individually.
- Retro on what we've learned.
1. Present Scenario
- Show the slide with the scenario.
- Read it aloud.
- Invite questions + clarify.
Example Scenario: The Family Gathering
- You are at a family gathering when someone asks ‘What do you do?’.
- “I work as a software engineer in the 5G space“, you reply.
- “That’s sounds cool! What’s 5G?“
How do you respond?
2. Split into pairs & explore case
- Split the group into pairs.
- Ask them to explore the question for 5 minutes
3. Brainstorm the case together
- Bring everyone back into the bigger group again.
- Ask each pair what they came up with.
- Write their thoughts on the whiteboard.
- Step back and ask for their thoughts. Further clarify the case and explore different paths.
- Cross out and add thoughts on the whiteboard to explore the case and come up with better information together.
4. Split into larger groups to practice answering the question again
- It's time to re-explore the original case again.
- Split the group into 3-4 people and ask them to re-explore the question using the new information.
5. Practice answering the question individually
- The facilitator goes around the room and asks each person to answer the original case study question.
- Facilitator: "So David, you are the actor in this scenario. How would you answer the question 'What is 5G?'."
- Go around the room and explore the question with each person.
- Ask the group what they have learned today and how they will bring it into their daily conversations.
- Retro on the workshop itself and ask what their favourite part of the workshop was so that you can improve it for the next one.
Asking HN Their Favourite Lecture Series
Posting a Question on Hackernews
I posted a question to the hackernews community asking them "Ask HN: What's the best lecture series you've seen?". Here are the highlights. You can read the full list in the comments.
- Andrej Karpathy: "Neural Networks: From Zero to Hero".
- Andrej Karpathy: "Let's build GPT: from scratch, in code, spelled out."
- Classical Physics by V. Balakrishnan from IIT Madras, India => First lecture => Whole Series
- Gilbert Strang: Linear Algebra
- Ken Joy: Computer Graphics
- Percy Liang and Dorsa Sadigh: Stanford CS221 Learn AI (2019)
- Micromouse 2021-2022 by UCLA
- Robert Sapolsky: Human Behavioral Biology
- Feynman: Physics
- Sussman & Abelson: SICP => Particularly Streams
- Timothy Snyder: The Making of Modern Ukraine
- MIT 16.885J Aircraft Systems Engineering, Fall 2005
- Jeremy Howard: Practical Deep Learning for Coders 2022
- Andy Pavlo: Intro to Database Systems
- Robert Morris: MIT 6.824 Distributed Systems
- Christof Paar: Introduction to Cryptography
- The Maths of General Relativity
- Walter Lewin: MIT Physics
- 3Blue1Brown: Linear Algebra
- Berkeley Psych 117: Drugs and Human Behavior
Lost Communication Moments in Remote Working
Remote vs. In-person debate
As lockdowns lifted, many companies have returned to in-person working with the belief that it is overall better for collaboration and delivering immediate value. This may or may not be true, or maybe it is true in some cases and not others, or maybe collaboration and immediate value should not be the only metrics to look at. Whatever the case may be, it strikes me as obvious that there are some serious disadvantages when working remotely. But the disadvantages do not affect everyone in the same way.
I think it comes down to the question "Do you know what you have to do?" In other words, is your task well-defined enough that you can do it by yourself? In many jobs, this is the case. Developing presentations, organising people to talk to each other, updating a client - these are all well-defined tasks.
But what about writing code for a project which we don't understand? Or analyzing a bug where, almost by definition, we don't know what's causing it? Or learning the basics of a new skill that other people take years to master? How can we be expected to do this by ourselves? The answer is: We can't. And if we can't do it by ourselves, that means we need others to help and support us. We get that help by communicating with them.
Lost moments of communication
- Overhearing an ad-hoc conversation between your two teammates.
- Seeing your teammate red-faced and stressed at their desk.
- Talking to someone in-person and noticing their foot shaking as if they are agitated.
- Signalling you want to interrupt someone's monologue to correct them.
- Turning around to your team and asking them for help (ie. Not needing to setup a meeting just to talk to a teammate).
- Hearing other people laugh at a joke.
- Hearing a happy story that someone encountered this morning.
- Seeing the magic of someone else writing great code.
- Having a conversation in a meeting while your colleagues have a separate conversation across the table.
These moments are not possible in a remote environment, and we make many trade-offs for the benefits of working remotely.
Remote Mob-programming toolkit
This template is inspired by a number of software coaches including Woody Zuill, Kevin Meadows and Llewellyn Falco.
Many teams are called 'teams' by name only. From what I can see, this is because we often do not focus on building team-specific skills. In sports, we focus on growing and developing the team because it's obvious that's how games get won. But in the software industry, we seem to think that the rules are different. Time and time again, we see that only groups of people working together on the same problem at the same time can succeed in complex domains.
This workshop gives people a sense of what it means to be a real software team. It introduces the participants to the communication tools they need to solve problems together and learn together. For people who have not had experience programming as a team before, this is always good fun and people come out of the workshop excited to bring these techniques into their day-to-day work. And that's the facilitator's goal - help your participants have fun and give them something tangible to bring back to improve their work.
Pick an exercise
- For a completely beginner team, I recommend working in online environments to avoid wasting time on misconfigured laptops.
Invite the participants
- Best results are with 4-6 people. Consider splitting up larger groups.
- Sessions should be 90-120 minutes.
During the Session
- Screen sharing: Each participant needs to access and hand-off the code they are working on
- Examples: MS teams
- Timer: Any timer will do.
- Examples: Mob-programming timer app, Google timer
- Any code you want to write must go through the hands of someone else.
- Build on whatever code was written before you - ie. No starting from the beginning.
- Treat everyone with kindness, consideration and respect.
- Driver: The person at the keyboard. The driver doesn't think. They just do what they are told to do.
- Navigator: The person who talks to the driver. They are the only one who is allowed to tell the driver what to do.
- Mob: Everyone else. Their thoughts, ideas and suggestions are funneled to the navigator.
- Facilitator: The person who is coaching and involving the whole team. The facilitator does not take part in the problem solving. They should ensure the team is obeying all rules and ask open-ended questions such as "When was the last time we ran the code?".
- Someone volunteers to be the first driver.
- Someone else volunteers to be the first navigator.
- The driver shares their screen.
- Everyone reads the problem statement.
- Start the timer for 5 minutes.
- The navigator either directs the driver straight away or consults with the mob on what to do.
- At the end of the 5 minutes, rotate the driver and navigator. The next driver can use the 'control screen' option on the first driver's computer.
- With 15 minutes until the finish, stop the session and run a retro.
- What new and useful tools did we use?
- What new thing did you see when we were coding?
- What shortcuts did we see?
- What was fun?
- What did you most enjoy in this session? How can we bring that into your team?
- How did you feel and what caused you to feel it?
Pick an experiment to bring back
- Group similar topics from the retro.
- Talk with the team to select 1 thing and decide on an experiment to bring in over the next week.
Questions for teams' retros
Why use different retro questions?
Most teams have workshops called 'retros' where they reflect on the previous couple of weeks and decide what to improve going forward. For most teams, the retro is treated as another obligatory meeting dictated to them by the scrum rules. Teams that have no experience in effective retros see these workshops as a waste of time, and why wouldn't they? The teams that do have retros often have them too infrequently, taking a retro once every couple of weeks. As a result, teams find retros are 'too long' or inefficient because they try to do too much. Instead of taking retros more frequently, teams stop doing them or give up in putting in effort.
One sympton of inefficient retros is to run the workshop again and again in the same way and without any variety in the questions the team ask themselves to diagnose and introduce changes. After the team has asked themselves "What was good? / What was bad? / What should we improve?" a few times, everyone gets bored. Here is a list of questions to help your team find different and interesting experiments to run.
Day to day questions
Mini 15 minute retros everyday can help supercharge the team by bringing in tiny improvements each day. It also prevents those horrendous 3 hour long meetings at the end of a sprint where the saved up all their problems and ideas.
What was good today? How can we turn it up? "Turn up the good" is a concept from Woody Zuill and Kevin Meadows' 'Mob-Programming' book. When working with teams, they asked themselves this question at the end of each day.
What was the best thing about working together today? This is a good question to see how the team can do more good teamwork together.
How many hours did each person spend working with someone else? What would happen if we increased this? A team is not a team if the people are not working together. Increasing the amount of time people pair and mob-program together could supercharge the team.
How many hours did we spend blocked by someone else this week? How can we reduce this? Blockages and work in progress are huge areas of waste for teams. Identifying where major blockages are is extremely valuable to help teams do more of the fun stuff.
What was our favourite tasks we did in the last 3 months? How can we do more of these tasks?
What went really poorly today? How can we prevent it in the future?
Post mortem questions
In the event the team encounter a critical problem affecting customers, they will need to run a post-mortem on the event to diagnose and prevent future issues.
- What went wrong?
- What made you nervous?
- How can we prevent this happening again?
- Why did this incident happen?
- What else could go wrong that we got lucky with?
- What's the worst thing that could happen in this situation?
Worst case scenario analysis
What's the worst thing that could happen your team? It will likely happen at some point. Don't be the team that doesn't prepare for worst case scenarios because it is too uncomfortable to think about.
- What's the worst thing that could happen us? How to we mitigate that risk?
- If component X crashes in production, how can we get it back up?
- What's our bus factor for each responsibility and how do we increase bus factors of 1?
- What's the worst thing that we own that could happen and impact our customers?
Best case scenario analysis
Analysing a perfect day in the office can give insights into improvements. This is similar to 'turning up the good'.
- When do you love doing your work?
- What does the perfect day look like for you?
- What's one thing you've always wanted to try?
- If we were to fix something permamnently tomorrow what would it be?
- What's something you learned about recently that you would like to introduce to the team?
- What tasks feel stale for the team?
- What's the thing you hate doing? How can we make it less painful?
- What's the thing you love doing? How can we do more of that?
- On a scale of 1-10, how good are we as a team?
- What's the lowest priority thing on our Todo list? What would it take to delete this task from our Todo list?
- Whats the main thing we do or support that we are known for?
Creating learning experiences
I want you to act as a Learning and Development manager.
I will describe an annual planning scenario for a software company. You will use your knowledge of teaching, coaching, mentoring, and communication to provide me with suggestions on what decisions and actions should be rolled out to the company.
Your suggestions include surveys, workshops, talks, interviews, team meetings, games, exercises, or including other parties like stakeholders or line managers, and other useful practices.
My first request is: The Learning and Development manager has been tasked with "improving the company's learning culture" over the next 6 months. The learning and development manager needs to be able to show that the learning culture has improved at the end of the 6 months. Actions should be made towards the individual level, the team level, the management level and the organisational level. How would you handle this situation?
To improve the company's learning culture over the next 6 months, I would recommend the following actions:
Surveys: Conduct surveys to gather information on the current state of the company's learning culture and identify areas for improvement.
Workshops and Talks: Organize workshops and talks on topics such as effective learning strategies, learning from failures, and creating a growth mindset. These sessions can be delivered by internal or external experts.
Interviews: Conduct interviews with employees to gather more in-depth information on the current state of the learning culture and to identify specific challenges that employees face.
Team Meetings: Encourage team meetings where team members can share their learning experiences and provide feedback on the learning culture.
Games and Exercises: Use games and exercises to make learning more interactive and engaging.
Stakeholder and Line Manager Involvement: Involve stakeholders and line managers in the process of improving the learning culture. This can include providing them with information on the current state of the learning culture and seeking their input on potential solutions.
Organizational Level: Implement a learning culture program, which includes a focus on continuous learning and development, encouraging experimentation and risk-taking, and rewarding individuals for taking on new challenges and learning from them.
Measurement: Establish metrics to measure the progress and impact of the learning culture improvement program.
Communication: Communicate progress and impact of the program to the management team, stakeholders and employees to ensure that everyone is aware of the progress and the efforts being made to improve the learning culture.
Celebrate Success: Celebrate and recognize employees who have demonstrated exceptional learning behavior and have been instrumental in the improvement of the learning culture.
By implementing these actions, I believe that the company will be able to show that the learning culture has improved at the end of the 6 months.
I need better detail on each point.
Sure, I'd be happy to provide more detail on each point. Here is a more detailed explanation of the actions I suggested earlier:
Surveys: Conduct surveys to gather information on the current state of the company's learning culture and identify areas for improvement. The survey can include questions about employees' perceptions of the company's commitment to learning, their ability to access learning resources, their willingness to take on new challenges and learn from failures, and their overall satisfaction with the learning culture. Workshops and Talks: Organize workshops and talks on topics such as effective learning strategies, learning from failures, and creating a growth mindset. These sessions can be delivered by internal or external experts. This will provide employees with the opportunity to learn from experts in the field and apply new strategies to their own learning experiences. Interviews: Conduct interviews with employees to gather more in-depth information on the current state of the learning culture and to identify specific challenges that employees face. This can include identifying any barriers that employees face in accessing learning resources, understanding the company's expectations for learning, and identifying any cultural or organizational factors that may be hindering the development of a strong learning culture. Team Meetings: Encourage team meetings where team members can share their learning experiences and provide feedback on the learning culture. This will help to foster a sense of community and a shared commitment to learning within teams. Games and Exercises: Use games and exercises to make learning more interactive and engaging. This can include activities such as learning simulations, case studies, and problem-solving exercises. Stakeholder and Line Manager Involvement: Involve stakeholders and line managers in the process of improving the learning culture. This can include providing them with information on the current state of the learning culture and seeking their input on potential solutions. This will ensure that everyone is aware of the progress and the efforts being made to improve the learning culture. Organizational Level: Implement a learning culture program, which includes a focus on continuous learning and development, encouraging experimentation and risk-taking, and rewarding individuals for taking on new challenges and learning from them. This will help to create an environment in which learning is valued, encouraged, and rewarded. Measurement: Establish metrics to measure the progress and impact of the learning culture improvement program. This could include metrics such as the number of employees participating in learning activities, the number of employees who have taken on new challenges, and the percentage of employees who report a positive change in the learning culture. Communication: Communicate progress and impact of the program to the management team, stakeholders and employees to ensure that everyone is aware of the progress and the efforts being made to improve the learning culture. This will also help to keep employees engaged and motivated to continue learning. Celebrate Success: Celebrate and recognize employees who have demonstrated exceptional learning behavior and have been instrumental in the improvement of the learning culture. This will help to create a culture in which learning is valued and encouraged, and will also help to motivate other employees to continue learning.
By implementing these actions, I believe that the company will be able to show that the learning culture has improved at the end of the 6 months. It is important to note that, it's important to keep in mind that a learning culture takes time and effort to develop, and that progress may be incremental rather than immediate.
List of Software Definitions + Phrases
Definitions are pretty pointless...aren't they?
I remember studying for a physics exam. While my maths skills were pretty good, I never properly learned the definitions of things and, as a result, didn't get good marks in my exams. At the time, I remember thinking "It's not like I'll ever need this...what's the point in learning it?" But learning definitions is not pointless - it's necessary. When you learn a definition, you shortcut what probably took 1000s of hours from different people to get to that definition. The definition of anuthing is likely a far better summary than you could ever come up with.
But here's the catch - just because you know the definition doesn't mean you know what you're talking about. I think this is where the novice falls down. Sure, you can learn off the definition and not be an expert. But...and here's the point...you can't be an expert without knowing the definition. Almthough I complained that I had to learn off physics definitions for my exams, my (excellent) physics teacher easily cited back multiple definitions in each class without looking at any notes. The expert uses definitions to avoid reinventing the wheel.
For example, if I try to explain the software principle of DRY (Don't repeat yourself) without using the principle itself, I end up with a load of gibberish as I try to find different words to describe DRY. Even worse, someone might say "David, you're talking about DRY right?" and will soon conclude that I don't even know the thing I'm describing. Therefore, it seems to me that knowing definitions are not only important, but are necessary. So here is my attempt at gathering and recording any useful definitions I come across to 'parrot' back to the people who are unfortunate enough to listen to me.
List of Software Definitions + Phrases
Note: This is update with anything new I come across.
- DRY: Don't repeat yourself; Used to reduce repition of software patterns.
- Scrum: Empirical framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Agile: A philosophy of iteration and continuous improvement when delivering software; Incremental deliveries
- Kanban: Helps visualise work, maximise efficiency + continuously improve.
- Servant leader: Someone who wants to serve first, lead second;
- Satisfy the customer through early and continuous delivery of valuable software: Agile principle; Requires early and constant customer feedback; More feedback correlates to happier customers correlates to happier workers; So always seek more feedback;
- Welcome changing requirements, even late in development: Agile principle; Requirement always change.
Knowing chess rules does not make me a grandmaster
What are the rules of chess?
Chess rules are simple: Trap your oppenent's king before they trap yours. Of course, there are other rules like how pawns should capture other pieces or how a king should castle. I know these rules and I know them well. My go-to method of procratination is to play a game of chess on lichess.org.
So here's a question: If I know the rules of chess, why can't I beat an experienced chess player?
I know that bishops move diagonally and knights make that weird "L" shape. But if you put me against an experienced chess player, I don't stand a chance. The reason for this seems plainly obvious: Knowing the rules is not enough.
The same applied to all games. While knowing the rules is essential to play the game, they do not inform the tactics and strategies of the game. The rules don't tell me what the best chess openings are or what the best endgame is. They don't explain the traps that happen when I move the queen to this position or the knight to this. They don't tell me the consequences of my move in two, three or four moves time. Knowledge of the rules alone explains none of these things.
How does this apply to the business world?
So we've established: Knowing the rules does not qualify us as a master of the game. Then why not apply the same standard to the professional world?
A Python certificate does not a Python developer make.
A Scrum certificate does not a Scrum Master make.
A Six Sigma certificate does not a Project Manager make.
We should not place blind trust in CVs or certificates that simply say that a person is qualified in subject X.
What signals mastery?
How would we know someone is good at chess? We would play them against someone else who is also good at chess.
The same goes when hiring candidates or evaluating people's expertise. Their CV says have some certificates - great! At least it means they probably have an interest. But we must make sure they can play the game.
My favourite way to evaluate expertise is to talk to the person about problem scenarios in their field. In my opinion, this is how all interviews should be conducted (not multi-day take-home assignments or leetcode exercises). If it's a programming problem, let's talk through it together and come up with a solution on paper first and then write some code. If it's a leadership problem, let's discuss the assumptions, ideas and proposals to solve it.
That's how we check for expertise - we see if they can play the game.
How can I show I'm an expert in something?
At the risk of repeating myself: Show others you can play the game.
Show them that you don't just know the rules but can apply tactics and strategies to real world problems. Write about the times you've played the game. Tell them about the mistakes you've made and what you've learned. Build things to prove that you can build them.
Of course, all of this assumes one important thing: You must know what you're talking about.
While there are shortcuts to achieve expertise quicker (namely focus), nothing replaces putting in the hard work. That doesn't mean you need to spend 2 hours everyday for the next year learning how to play the game (but if you have the time why not!?). However, it does mean that you need to keep chipping away at it. A little bit here, a little bit there - it all adds up. But please, please, don't stop after just learning the rules.
The rules matter.
But playing the game matters most.
A Checklist to Onboard to a New Project
I wrote previously about lessons I wish I knew when onboarding to a new project. Using the information in that post (plus some more lessons I've learned along the way), here is a useful checklist to use when onboarding to a new project.
Questions for the Team to Answer
|What are you building?||Name of product List of use cases in the product|
|What are your responsibilities?||Your team will be asked to deliver code soon. Make sure you know what is expected from you and your team.|
|Who is your team's main stakeholders?||Create a list of important names and emails.|
|Which companies are your team’s main customers?||Write out the main customers you will interact with.|
|Who can you reach out to for support?||Your manager will have organised people to support you as you onboard. Who are they and how do you contact them?|
|What’s the release process?||What does the release cycle look like? Is it daily/weekly/quarterly? What’s the biggest stress during a release?|
Tips for the Team
|Don’t watch videos, start writing code||Once you understand the overview of the project, you need to take control of what knowledge sessions you are given. Unless the knowledge sessions show you how to get your tasks done, they are a waste of time. A good rule is 20% knowledge sessions, 80% building something.|
|Define your goals from day 1||Don’t wait to be told what to do. The team should list their goals on Day 1 and start creating a backlog (if one does not already exist).|
|Start brainstorming improvements||As you get to know the project, make improvement suggestions to the team. Point out problems. Follow up “I can’t believe they did it like that!“ with “Here’s how we could improve it“|
Questions for the Team Lead to ask
Note: Team lead can refer to Scrum Master, Manager or technical lead.
|Who are your main stakeholders?||List down the people you need to contact frequently. Project managers, Product owners, other Scrum Masters…|
|What meetings do you need to attend?||Scrum of scrums, release planning…|
|Create a group chat with your team and the mentors.||Your manager will have organised mentors to help your team onboard to the project. Create a group with them and put your team into it so they can ask questions as they arise.|
|Schedule a weekly retro||This is a chaotic time. Your team needs to feel in control and feel like they are making progress. Weekly retros for 15-30 minutes will highlight any frustrations the team are having and get them solved quickly|
|Help your team put a backlog in place||Your team need goals and tasks to do immediately so that they don’t feel lost. Don’t let your team be tempted to say “We’ll create a backlog after these few weeks of knowledge sessions“. If your team are not completing backlog items, they are not truly learning and wasting their time.|
Tips for the Team Lead
|Don’t let your team commit to work they cannot achieve||Deadlines are likely already set for your team. Push back against any pre-defined deadlines until your team are happy to commit to them. You don’t want to be responsible for somebody else’s deadlines!|
|#noKnowledgeSessions||When a company onboards lots of new teams, they are tempted to organise ‘Knowledge sessions’ for every part of the project. THESE ARE A WASTE OF TIME!! Do not let your teams waste their time in knowledge sessions that talk about abstract information that nobody uses. Any knowledge session should be focused on getting a particular task done. A good rule of thumb is 20% knowledge session, 80% practice.|
|Be the calm in the chaos||Teams come under a lot of pressure when starting a new project. Don’t forget to stay calm as a leader. If you get frustrated, your team will get frustrated!|
What the heck is a 'Learning Culture'?
What is a culture?
If you want an equation, here's mine: Culture = Behaviours + Expectations + Wisdom
Pick any group and you will quickly see that each has their own ways of interacting and behaving with each other.
- County (especially in Ireland!)
- Local community
Cultural behaviours are unconciously picked up when we integrate into a new group of people. If you have travelled abroad to multiple countries, you know that the 'feeling' between coutries is very different. If you have stayed with another family for a few days, the 'feeling' of that family feels foreign, strange and often uncomfortable. A family member of mine says "Other people's families are always very strange". This is true. Different cultures are just that - different. People expect each other to behave in a certain way and give a strange look when that doesn't happen.
If the first part of culture is its peoples' behaviours, then it follows that the second part is what people expect of you. When you go to France, you greet another person by kissing them on the cheek. You must point with your thumb instead of index finger in Malaysia. When you sit down for a meal with your family, you are expected to say Grace. We call these expectations 'customs'. Expectations keep people in check and produce a sense of belonging, protection and safety - an amazing evolutionary strategy we have developed.
Thirdly, wisdom plays a huge role in culture. Over time, the culture's behaviours and expectations become instinct to its people. In other words, the culture's people build a body of wisdom which comes naturally to them.
It is common for people who misunderstand a culture to treat it with resentment. But cultures are formed through behaviours that have given its people support to survive and thrive. In other words - cultures form over time because they work for that group of people. This doesn't mean that change should not happen. But we should be careful not to throw out the baby with the bathwater. Some behaviours are good, others are bad, and some are just different.
The body of wisdom that is built up in a culture should be treated as just that - wisdom. Not a list of rules that have come from 'back in the day' that we need to change and get rid of simply because they are old.
So when we talk about culture, remember: Culture = Behaviours + Expectations + Wisdom
What is a Learning Culture?
If Culture = Behaviours + Expectations + Wisdom, then Learning Culture = Learning Behaviours + Learning Expectations + Wisdom about Learning. You need to understand what behaviours will help your colleagues progress their knowledge. This is the primary purpose of L&D. Without knowing how people learn and what their learning needs are, any L&D individual will fail to understand what learning behaviours should be encouraged.
How is a Learning Culture Created?
Cultures are made up of complex people and, as a result, are complex things themselves. In “Toyota Kata”, Mike Rother describes structured, practised behaviours that are the building blocks of a learning culture.
What behaviours do you want from your colleagues when it comes to learning? Narrow in on specific behaviours, right down to the scenario and task level. As you develop and support different scenarios your colleagues experience, they start building a set of behaviours condusive to their learning. Be warned though - you cannot force people to behave in a certain way. You can only encourage things that they want to do. Focus on the individual's strengths and interests to understand how they can enrich your company's learning culture. For example:
- Someone interested in coaching might be able to give workshops to teams.
- A subject matter expert might be interested in mentoring new joiners.
- A new joiner might be able to become owner of a team's documentation and improve it in some way.
List the Learning Behaviours
List down the behaviours you want to see in your organisation.
- I want people to learn everyday.
- I want teams to continuously improve.
- I want managers to enable change.
Each item is a high-level expectation. Get specific. Divide each item into specific scenarios you want to see.
Behaviour: I want people to learn everyday.
- Scenario: When someone sees something useful, they note it down and bring it to their daily work.
- Scenario: People take online courses in areas that they are interested in at least once a week.
- Scenario: People read books on topics they are interested in.
The more scenarios you can think of, the better.
Next, prioritise your list of scenarios and break them into actions you will take.
Scenario: People read books on topics they are interested in.
- Action: Create a library area in the office with 100 books.
- Action: Enable people to order any book they want to add to the library.
- Action: Have a monthly 'book' day where people share what books they've read and what they have learned.
As you can see, wishing for a learning culture to appear is not good enough - get specific! Otherwise, your colleagues will become disenfranchised with your mission and, worst of all, become apathetic.
Having said this, your goal isn't to encourage every behaviour in every individual. Some encouragement with some individuals is enough. Small wins along the way is the goal.
After you've figured out which behaviours to encourage, the next step is to look at expectations. What should your colleagues expect from each other? The lazy answer of "I just want people to be better everyday" isn't good enough.
Step back for a second. What if someone came up to you and said "I want you to be better today". You wouldn't know what to do.
It is easy to say "I expect people to learn", but without accepting the responsibility of providing encouragement and support, then they are empty words. L&D must put their money and time where their mouth is.
What About Hiring?
It is difficult enough to promote culture amongst people who agree with its principles. It is impossible to do it amongst those who don't. In his book 'Principles', Ray Dalio writes how his company, Bridgewater, hire for a specific kind of culture.
Bridgewater's culture values brutal honesty above all else. If you think this results in a nice work environment where everyone is up front with each other, you would be wrong. It results in an environment many people are not cut out for.
Imagine if every proposal was met with everyone in the room responding with "I disagree with you because XYZ". Imagine if every single action was challenged by multiple people in the room.
A look at Glassdoor reviews shows these values coming through as good and bad, depending on who is commenting.
- "Culture is huge here, managers really like to take an interest in people's inherent personalities and tendencies. As someone who likes a demarkation between work and personal life, such a probing culture isn't really conducive for that."
- "It's not for the weak-stomached. If straightforward feedback induces anxiety, this would not be a healthy work environment for you."
Are these 'bad' reviews, or is it more likely that you need suitable personality traits and values to succeed in such an environment? While this may be an extreme case, it illustrates my point. People with values anti-thetical to the culture will not thrive. So you need to be up front with potential employees from the very beginning.
If you are building a Learning Culture, it needs to be screened at the interview stage.
- Do you work better alone or with other people?
- Walk me through a time you improved someone else's job.
- What is the last project you made outside your work (technical or not)?
No interview questions are 100% perfect, but the goal of any interview is to estimate if this person would fit well in your company. If the person does not display curiosity or enjoy sharing information, then they likely won't thrive in a learning culture where these values are the foundations.
The End Result
Now that you have a list of behaviours you want to see, get to work! Over time, encouraging particular behaviours together with screening for good hires will build the culture you envisaged.