In this episode I wanted to continue the conversation on Learning. In my last episode I talked about why Learning is so important to me personally. In this episode, I want to move onto talking about Organisational Learning.
Or listen at:
Published: Wed, 17 Jun 2020 16:03:52 GMT
Transcript
Wikipedia describes Organisational Learning as:
"Organizational learning is the process of creating, retaining, and transferring knowledge within an organization. An organization improves over time as it gains experience. From this experience, it is able to create knowledge. This knowledge is broad, covering any topic that could better an organization."
And this comes back to one of my core beliefs:
I believe every business is a technology business. For a business to thrive in the modern world it must be able to adapt and change rapidly.
And that ability for a business to adapt and change quickly, comes down to how well the organisation learns.
Traditionally we've considered organisations as machines.
We build out processes and workflows that we expect to be carried out mechanically day in, day out.
We have held the belief that because it is mechanical, it is understandable - and thus predicable. With know inputs, we can predict known outputs.
I'd personally question if that has every really been true - or have we just done a fine old job of convincing ourselves that it is true. We see recognisable patterns; and thus we assume we understand it.
More and more I'm seeing people thinking of organisations as living organisms.
And this seems a better fit to me.
With a living organism, we can no longer predict the outputs for a given input. Its simple too complicated to predict with any level of accuracy.
Maybe we could use statistical modelling and make educated guesses - but ultimately, we can't have utter confidence in the outcome.
We can however observe the outcome.
By observing the outcome, we actually have concrete evidence of the affect - rather than a lot of guessing.
And if we are attempting to achieve a particular aim; then we have a better idea if we heading towards it - or away from it.
I've found that in many organisation, learning is actually seen in quite negative terms.
There is an inbuilt assumption that everything should be right first time.
Anything that didn't work first time is, by definition, a failure.
This is an inbuilt assumption that people should know their job. We are paying them to perform - not to learn on the job.
The organisation puts the failure to learn on the individual.
And as I discussed in last week episode, for an individual to express a desire to learn can be seen as a weakness.
That they don't have the skills that organisation needs. The skills that the organisation are paying for.
Thus, often the organisation will blame the individual, rather than taking responsibility for its own ability to learn.
Many of my episodes keep coming back to the same subject - change.
I've talked repeatably that change is constant. It will constantly be affecting our organisations.
And while I've largely talked about it in terms of technology - and specifically in terms of software development - that change is everywhere in an organisation.
Very little, if anything, remains static in this modern world.
Yes I don't doubt there are businesses out there that have done the same thing year in year out for decades. Repeating that same mechanical steps that made them successful maybe 30, 40 or 50 years ago.
But how many of them still retain their level of success?
How may have performed no innovation or adaption in those year and still retained their place at the top of the pile?
I'm not aware of any.
More likely they slipping away like the Hollywood starlet that hasn't acted for 20 years.
They are mentally stuck in the heady days of being the centre of the limelight, the toast of their profession - while the world has passed them over for the new.
And without accepting change, that is where our organisations stay.
Reminiscing of past glories.
Rather than accepting and moving with the times.
Again I've talked repeatedly about how we can avoid that in software development. I've talked about using the principals that come from the Agile, Lean and DevOps movements.
All of which champion learning at their core.
But again, this is not just a Software Development concern.
Many of the principals from those Software Development movements are equally applicable to all areas of an organisation.
Take for example when I've talked about the experimental mindset present in the Minimum Viable Product approach;
It actively encourages organisations to think in terms of experimentation;
- Start with a hypothesis
- Find the quickest way to test that hypothesis
- Learn from the results
While I introduced the Minimum Viable Product as a Software Development approach, I've also talked about using it for improving the recruitment process.
That ability to test new ideas and respond based on the results is a powerful tool for all levels of the organisation.
As I've said, the Software Development movements of Agile, Lean and DevOps all have Learning baked into their core;
This is to allow our Software Development practices to improve over time.
In many cases you will find the focus of these practices is not on getting work done faster or deliver a specific piece of work;
No, the focus of these practices is to improve how the Software Development team works.
Improving the capabilities and abilities of the team rather than the focus on the progress of a specific project.
Take for example the "Retrospective" practice from Agile;
The Retrospective is a regular meeting of the team - happening every week or fortnight - I've know some teams do them daily.
The aim of the meeting is for the team to look back at the work since the meeting; to discuss what has gone well and what hasn't.
The meeting is a peer led conversation within the team; with open and frank conversation touching on any subject that the team feel approriate.
By the end of the meeting, the team should have identified improvements that it will experiment with going forwards.
Again using a Minimum Viable Product approach of
- Start with a hypothesis
- Find the quickest way to test that hypothesis
- Learn from the results
Thus each retrospective meeting because a part of a continual learning exercise for the Software Development team.
The "Retrospective" is not a status meeting.
It is not a meeting to establish how a specific project or task is progressing.
It is about the team working together to learn to be better at what they do.
It is an investment in improving the team.
Unfortunately, I've known teams to forgo the regular retrospective in favour of "getting the job done".
I've found this short sighted.
The focus on the immediate project in hand, rather than the longer term benefits gained from the team improvements.
Yes you may have delivered that project a day earlier; but think about the negative impacts on all of the future work the team would carry out.
The retrospective improvements are like compound interest; individual improvements on their own they may seem almost inconsequential.
Overtime however, the compound interest pays real dividends.
Think how much a Formula 1 racing team will rehearse and refine their pitstop actions. They will continually refine and refine - maybe only taking milliseconds off at a time.
But overtime, those milliseconds add up. The sum of those milliseconds can make the difference between winning and losing the race.
I now find retrospectives being used in non-Software Development teams.
Which makes a lot of sense to me.
Its a means of helping a team improve how it works.
A means for a team to introspect and, as a group, attempt to achieve Mastery over their given activities.
As I'm mentioned previously, the book Drive by Daniel Pink classes Mastery as one of the primary sources of self motivation.
Another practice I wanted to discuss was the "blameless post-mortem".
A blameless post-mortem is a meeting, generally carried out after some failure.
Say for example you website goes down for two hours or all payment processing fails or there is a security breach.
The aim of the meeting is to understand the true cause of the problems and arrive at improvements that the organisation can take to avoid it happening again.
The "blameless" part of this meeting is critical.
Too often a failure becomes a witch hunt.
We identify the individual at fault and we make an example of them.
We believe that by disciplining or evening firing the individual we will stop it happening again.
We hold the individual up as an example of what happens when people mess up.
And of course this has entirely the wrong consequences.
Firstly, any investigation of the failure degenerates into an exercise in finger pointing - especially if it involved multiple teams or functions. No body wants to be at fault, so everyone tries to push the blame off onto others.
Before too long any investigation has broken down into blame shifting, finger pointing and political backstabbing.
Not at all useful to understand why the problem occurred in the first place.
Secondly, it scares people into being very risk adverse.
In a blame culture, individuals and teams, will become very careful about what they do and how they are perceived - for risk of being blamed for something.
This quickly leads to a culture of crippling bureaucracy.
Nothing is ever done without hundreds of sign off and approvals.
Everything staggers to a halt.
And thirdly, we have probably just fired the one person that may have actually learning from the incident.
A quote from Albert Einstein;
"A person who never made a mistake never tried anything new"
So with the "blameless" post-mortem, the emphasis is in actually understanding what happened - without assigning blame.
Atlassian describes a blameless post-mortem as:
"... brings teams together to take a deeper look at an incident and figure out what happened, why it happened, how the team responded, and what can be done to prevent repeat incidents and improve future responses.
Blameless postmortems do all this without any blame games.
In a blameless postmortem, it’s assumed that every team and employee acted with the best intentions based on the information they had at the time. Instead of identifying—and punishing—whoever screwed up, blameless postmortems focus on improving performance moving forward."
By doing this, you are encouraging individuals and teams to work together to really understand the problem - rather than focusing effort on blame shifting, finger pointing and political backstabbing.
It reduces the aversion to risk and continual growth of smothering bureaucracy.
And it comes out with the entire organisation learning from the experience.
This is another example of Learning being front and centre.
It is in the best interests of the organisation to learn from the episode; rather than find someone to blame.
And as I talked about in episode 11; this really does require a culture change from the top.
The top has to instil the learning culture at the heart of the organisation.
It has to ensure that it acts in a way that is consistent with that message.
It has to ensure that all vestiges of a "blame culture" are rooted out and removed.
It is not enough to tell the organisation it has to learn - and then to blame individuals when they don't.
And in the next episode I'll talk about how we can help individuals to learn.
I wanted to end this episode with a quote from the Agile manifesto I introduce in episode 8;
"We are uncovering better ways of developing software by doing it and helping others do it."
The creators of the manifesto - experts in their fields - highlight that they are still learning and will continue to do so.
This speaks to the maturity and continual learning within Software Development that is uncommon in business today.
Something I hope we can all Learn from.
Thank you for listening.
I look forward to speaking to you next week.