Building a learning organisation
This post is my notes for a talk that I recently gave at a webinar organised by a friend.
I learned about learning organisation from Peter Senge's book – The Fifth Discipline – a long time ago. “A learning organisation is a company that facilitates the learning of its members and continuously transforms itself.”
In the book, he talked about five characteristics of learning organisation: Systems thinking, Personal mastery, Mental models, Shared vision, and Team learning.
Here, I share my lessons learned of the above characteristics from a different angle: – Feedback loop – Diversity – Lateral development – Body of knowledge – Continuous learning
An organisation is “a group of people who work together in an organised way for a shared purpose.” (Cambridge Dictionary) So let's discuss from two perspectives, i.e. individual members perspective and group/team perspective.
Ask for feedback:
Without feedback, we will not know what goes well and what needs to be improved. Most companies I know have a review mechanism between us and our boss. And aside from our boss, we need to ask for constructive feedback from our team members, if we are team leaders. We can also ask for feedback from our peers.
Listen to understand:
We need to try to understand the feedback giver's perspective why he/she perceives us in a certain way that led to the feedback he/she gives us.
We may disagree with some of the feedbacks and that is okay. Despite our intentions, others may interpret our actions or results differently from what we envision. The point is to get feedback in order to know how others perceive us and why.
Avoid being defensive and attacking the feedback giver or he/she will stop giving feedback.
Have regular one-on-one:
We need to facilitate the feedback mechanism and one of the ways is to have one-on-one meeting between team leader and individual team members.
We are always busy and urgent tasks pile up unpredictably. If we wait until we are not busy, one-on-one can be forgotten. One-on-one is important, so I suggest we schedule regular one-on-one in advance between team leader and team members. It is easy to set it up for one year at the beginning of the year. We can always change the schedule if needed, but we need to commit to have it.
In my opinion, this is the responsibility of the team leader to schedule this and ensure it happens.
Listen to your “customers”:
We have many stakeholders to please and it is impossible to please all of them all the time. We need to focus on our high priority “customer” (whoever we define as customer amongst our stakeholders) and listen to their feedback.
In some organisation, the “customer” is very obvious. In others, this may be more complicated. The “customer” may even change, despite our team not changing anything. In big companies, sometimes this is influenced by company dynamics.
And our customer's needs can change over time, so we need to always check. When our team members answer “we have always done it this way”, we need to check if the “way” still matches what the “customer” needs.
Get to know and learn from others different from us:
If we hang out only with people very similar to ourselves, we may not learn many new things.
People with different interests learn different things and so when we hang out with diverse group of people, then we discover things they learn which are different from what we typically would have learned.
Different people has different perspective or approach to solving a given problem. When we are stuck at a problem, talking to someone with a different perspective sometimes helps us understand the problem in a different light and discover the solution.
Treat others with respect:
Eventually, misunderstanding or miscommunication can happen. Conflict is a natural course of life when there are more than one people. If we manage conflict professionally and resolve it in trustring manner, the team can come out stronger at the end of it.
Recruit for skill but plan diversity in the recruiting pipeline:
We need to understand the team's diversity profile. And when we have a vacancy we need to fill, try to recruit from places that can complement / enrich the diverstiy. The objective is to find a diverse pool of candidates. This may mean that we need to look in different universities, different job boards, etc.
Ultimately, we select based on skill, whether the candidates can do the job well. But if we have several candidates that can potentially do the job well, we have the option to recruit the candidate that can make our team more diverse.
Respect the diversity in the team:
Diverse group of people have diverse perceptions which leads to diverse reactions. We cannot assume an activity or approach that the majority likes will be liked by the minority in the team. If we put it to a vote, the majority will keep bulldozing the minority and eventually those in minority will quit. We need to find a balanced approach that respects the diverse team members.
Take on new challenges:
We need to step out of our comfort zone and take on new challenges. This could be additional responsibilities, new projects, etc.
Grow our career laterally:
Promotion is not the only way to grow a career. As individuals, we can grow by moving laterally, e.g. change team, change role, etc. This enriches your skill base and strengthens your CV / curriculum vitae.
The higher we go up in the organisation structure, the more diverse the skills we need. If we never grow our career laterally, our skill may not develop diversely enough.
Assign people to also work outside their current domain:
This was inspired by Google’s “20% project.” I call this approach the 80/20 project. (20% is just figuratively speaking; the point is majority and minority of the time.) In this case we assign a team member some role / responsibility outside of his/her team. The majority of the time, the team members work on their main job and then for the rest of the time, they work on a project / role for another team or another domain. The objective is to assign the team member to something different where he/she can acquire new skill.
Take the risk to move / rotate people:
Move / rotate people to a different team / department when there is a vacancy. Having people in the team who have done many roles in the company strengthens the talent base. You develop more people at a given skill, because a given job has been filled by many people who have rotated through it over the years.
If we do the 80/20 approach, then people who have done the 80/20 are good candidates for job rotation. Hopefully, the 80/20 assignment is the domain where they will rotate into. But even if not always the case, people who do the 80/20 show adaptiveness already and hopefully are better equipped to pick up new skills at the new roles they are rotating into.
Body of knowledge
Leave a legacy of documented knowledge:
A long time ago I learned the motto: “If it is not well documented, it does not exist.” We need to document our work / process so that others can understand and take over from us, for example, if we become ill or on a long vacation.
Particularly in software development, years after a piece of code goes live it can have issues. If nobody can understand how to fix it or make changes to it due to missing or poor documentation, there is a risk that it will be thrown away, because it can be quicker for the maintenance team to rewrite the program, rather than fixing a difficult to maintain code.
This topic is not limited just to computer program. In business processes, this is also prevalent. Teams may lose the knowledge why or how something is done a certain way due to lack of business process documentation. So let's document our work well and leave a good legacy.
Share our knowledge with other team members:
We know about clubs (e.g. photography club, etc), community of practice, etc. These are good forums to share our knowledge to others. Sharing knowledge benefits both the receiver and the giver.
Ensure our documentations are well referenced and properly used. If we make good documentations, but nobody knows about it nor uses it, then we are not getting the value we aim for.
Agree on documentation guideline and common knowledge repository:
Non-existent or poor documentation can be the achilles heel of a good team. There is no “one right way” to do it, but it is more important this is done consistently and maintained properly.
Different team will have different guideline and preferences. The important point is that everybody participates consistently. Knowedge management system and learning management system are useful tools, but they are just tools. Without strong documentation culture and learning culture, the tools cannot deliver the maximum benefits.
Define a knowledge handover process:
Organisational knowledge can be (and is often) lost when someone leaves the company (or even when the person changes team / department). We ought to define the knowledge handover process to explicitly manage knowledge retention and transfer when someone moves to another team or leaves the company.
Learn new topics / skills:
We need to always learn about new topics. If we do not learn about new topics, we can be left behind.
At the same time, we need to find our passion and aim for T-shape. On topics / skills that we are passionate about, we need to continuously improve ourselves so we become experts at them.
Invest personal time and effort:
Learn on our own. Set up personal project with defined goal to learn a new skill / knowledge. (For example, we may have built a website using PHP in the past; now try redoing it using Go or Clojure, etc.) Learn by doing.
“I hear and I forget. I see and I remember. I do and I understand.” Confucius
Experiment new practice / process:
Start with something small and quickly measurable whether we succeed or fail (“fail fast”). For example, start with only one small team or one small project. Once the capability and experience is in place, then we expand the scope and scale gradually.
Be mindful of the team we experiment with the new practice we want to start. Avoid one-size-fits-all approach. Different teams have different propensity to being “commando, infantry, or military police.”
“Whether invading countries or markets, the first wave of troops to see battle are the commandos. ... The infantry are the people who hit the beach en masse and slog out the early victory, building on the start given them by the commandos. ... The military police aren’t troops at all but police.” Robert Cringely, Accidental Empires
Balance short term challenge and long term growth:
The nature of experiment is that it can yield less result as hoped for or even fail completely. There is a risk of productivity hit. And we are busy to start with, so we may make the team worse off, if this does not work as well as hoped for.
On the other side of the coin, if we do not master the new skill / process, it can be risky as well. The world around us continue to change and I think it is better to initiate the change from within, before the change is forced on us. We need to push our team for continuous learning.
Let's assume, hypothetically, that it is possible for our team to grow better this week than the previous week, and next week is better than this week. And on and on, consistently week after week.
Compounded growth of 1%
Here, 1% is just an illustration – the important point is the consistency. Consistent growth, even small, adds up.
Learning organisation is not a destination. We do not build a learning organisation and say “It is done, now we can stop.” It is a continuous process.
Similar to gardening, after we work hard to build a beautiful garden, the work does not stop there. We must tend the garden continuously or else the garden will be beautiful no more.
Learning organisation is a journey. “A learning organisation is a company that facilitates the learning of its members and CONTINUOUSLY TRANSFORMS itself.” If we stop transforming, we stop being a learning organisation.
And therein lies our motivation to be a learning organisation:
A learning organisation is an adaptive organisation.