It’s no secret that teams that have a “culture of learning” outperform similar teams that don’t care about that sort of thing. The Internet’s full of articles extolling the virtues of such a culture, along countless articles offering suggestions on things to do that would help you develop your learning culture. There’s a lot of good sense out there, but in my experience, it’s not really possible to develop (or introduce) a “learning culture” as a discrete thing. There is no carrot & stick solution that’s resilient to real life.
The best I’ve been able to do is make it possible for my teams to believe that it’s worth learning new things, growing and sharing. Mostly because it’s more fun that way. As a species, we are if nothing else, driven by emotions. Hopefully positive ones.
Learning new things is a risky business. For a start, if it’s something difficult, or requires lots of practice to master, then you’re going to get things wrong. A lot. Making a mistake is often seen “in the corporate world” as a bad thing. With penalties like “poor performance ratings” if you’re an employee, and terminated contracts if you’re self employed. Ironic really, as we tend to learn the most valuable stuff while making mistakes. So another thing that I do to help my teams, is make it OK to make mistakes, to break things. On one project, that was a counter – everyone was allowed 3 epic fails. On another project, it was “as many as we needed to in order to do the right thing by our customers” (we were very user need driven so we had lots of empathy with our users).
On an explicit front, we introduced “Lunch and Learn sessions” – once a week, for 30 minutes. The list of topics was on a (Product) Backlog – well, a whiteboard with a load of post-it notes on it. Anyone could add things to the backlog, and re-order things as they saw fit, with a deadline of the morning of the lunch&learn day. It started off as me giving the talks, which after a couple of months, saw others offering themselves up as speakers for a subject they were keen on. It wasn’t limited to digital development either. One speaker wanted to talk about macro photography. We were able to round up guest speakers from other projects, and they were usually delighted at the chance, and in payment, we would give a talk to their team in exchange. One session was a live demo – our accessibility specialist brought in a blindfold and some headphones, and we were to try and use the website that we were building, but from the perspective of a blind user. Talk about an eye opener!
On a subtle angle, we used lots of pairing and collaboration techniques to spread the knowledge about, as part of “doing the day job”. We tried to get the default model for solving a complex problem into one where a person finds a teammate with some time and they work it together. So by necessity, we introduced a little slack time to help with this. Irrespective of role, seniority or time on project, we all tried to treat each other as equals (part of our team charter that we signed up to when joining). That made it “OK” for information to flow around, and made it part of being in this team.
If you think all of this sounds like hard work, well you’re spot on. We had to invest heavily into creating the conditions that would make a learning culture more likely to happen, and we had to do it in a way that didn’t completely alienate us from the rest of the world (though there was a rumour that we laughed more than everyone else in the building put together! And despite such frivolity, we were easily the most effective team in the building). We had to sustain the effort too, as we were looking to build a lot of good habits (once an activity becomes a habit, it becomes significantly easier to do as there’s no longer the need for conscious willpower).
Amateur Coach 