S2E1 – Sabotaging Learning – Tactics for Tech Leadership Podcast

Show Notes

Transcript

Mon-Chaio: Happy 2024, everyone! We appreciate you taking time out of your day once again to join us here on The TTL Podcast. We hope that you had a happy holiday season and are ready now to dive into more learning. I hope that’s why you’re listening to this podcast. Maybe one of your New Year’s resolutions was to commit to improvement, self improvement, and maybe The TTL Podcast is one of those ways in which you’ve chosen to do that.

Ah, two people can hope, right Andy?

Andy: Since this is episode where we’re going to talk a lot about how to destroy learning, I’m going to say one of them is probably to set New Year’s resolutions.

Mon-Chaio: Right, right. But in our, yeah. Right. But in our delusion, but in our delusion, we can hope that many resolutions involve listening to more TTL Podcast episodes,

Andy: Oh yeah, that would be a perfect resolution. That’s a, well, no, no, because I’m saying, because you don’t do your resolutions. So I don’t want them to resolve to listen to The TTL Podcast and then that will cause them to listen to The TTL Podcast. I think that’s how this works.

Mon-Chaio: A little reverse psychology. It works sometimes for my kids.

Andy: Yep. Yep.

Mon-Chaio: But getting back on topic here, uh, as Andy alluded to, we are going to talk about learning as the first episode of 2024. Uh, season two, I might add. And as for how season two is different than season one, well, uh, the year?

Andy: We’ll all find out. Yeah. We’ll see how this makes it different. It might just be a new year.

Mon-Chaio: Right. As for our topic today, it is about learning. Andy and I spent the latter half of last year trying to think about what episodes we should start to do in 2024. And we thought one concept that we think most organizations and most people within organizations actually have a very tough time with is learning. They either don’t really know why their organization should learn, or maybe don’t even think that their organization should be a learning organization. Or perhaps they think they should learn, they’ve tried some things and haven’t really seen any results.

And so we thought, learning is important enough to tackle as a topic and for people to improve. And so we thought we’d embark on this journey as the first episode of 2024.

Andy: Yeah. I was happy to jump in and try to learn on this. And I’m hoping that we didn’t fall afoul of our own take on organizations, not knowing how to learn. I hope, I hope that I know how to learn. But Mon-Chaio, tell me, why would we think that a lot of organizations don’t really know that they should learn or that they don’t think they should learn?

Why would someone get stuck into that trap?

Mon-Chaio: I think it’s one of those things that sounds good to everyone when you say, should your organization learn? Nobody comes out and argues against you and say, no, I don’t want my organization to learn. But I think it’s difficult to get back down into the next level of detail. And that level of detail around why do I think it’s important for them to learn? And what do I think is important for them to learn?

Andy: Yeah. Let’s actually take that one step at a time because we’ve said learning, but we haven’t really clarified what do we mean by learning.

Mon-Chaio: Hmm.

Andy: And I’m going to give a definition, it wasn’t in our research, or maybe your research, Mon-Chaio, found a definition, but this wasn’t in my research. But the way I’ve defined learning for a while now is the detection and correction of error.

Mon-Chaio: Hmm, interesting. Tell me more.

Andy: So, the detection and correction of error, so it’s, learning is that, it’s that cycle happening. It’s that you learn, you discover that what you intended, or what you thought you knew, or, what your ability was, you detected that that did not align with the reality …

Mon-Chaio: Mm hmm.

Andy: … and then you took some step to try to get your thought to match closer to reality.

So that’s either by changing your mind about what you perceive everything to be, or it’s about changing that situation in reality. to be closer to your desired thought. So you can see this pretty simply in, like you, you’re moving your hand towards a glass, and as you’re moving your hand towards the glass, you realize, oh, it was off by a little bit, and so you move it to the right a little bit, and then you continue moving it down, and then you feel the glass, and you, you grasp it, and then you’re trying to take a sip of water.

And all of that requires little aspects, which you could call learning. It’s a feedback loop. Now, in a situation like that, it doesn’t really feel like learning. But in a software organization, for instance, say you’ve got a team that’s doing, you build it, you run it. And that means that they need to handle outages. That means that when the service is down, they need to know how to go and bring it back up. They need to handle communication about it being down. They need to be able to recover it if maybe there was some data loss while it was happening. Those are all things where, very likely, if your team were to just suddenly do that, they would get things wrong. They wouldn’t bring the service up in the time that everyone wants it to be back up. And so they would learn, they would notice that error, and then they’d come up with a way to change that. And so they’d learn, and in this case, they’re learning better how to manage that service.

And maybe it’s done by, they discover that they thought that they would have logs that would tell them very clearly what the service was doing at the time that it started encountering problems. And then they discover they’re completely blind. They didn’t have those logs, or the logs that they had weren’t actually useful.

And so they see that error, and they correct it, they add new logs, and on the next, next time that there’s an outage, they look, and the logs tell them very quickly what’s going on. And they’re very quickly able to bring the service back into a good state. To me, that is what learning is.

Mon-Chaio: Interesting. And Andy, I’m gonna actually disagree with you here. I think that that is an interesting definition of learning and one that I think many organizations take. It feels to me, though, that that definition means that error has to precede learning. How do you learn if you don’t have an error to correct?

Andy: Ah, you induce error.

Mon-Chaio: You can, you can. That may be a tactic that we go into later on building learning organizations. But I think the challenge with that definition is organizations then don’t see learning for some of its ancillary benefits.

Andy: Hmm.

Mon-Chaio: And I think that is why many organizations look at learning as, I have to have a specific piece of learning because I have to correct a specific piece of error. And when error doesn’t exist, then learning doesn’t exist.

Andy: Okay.

Mon-Chaio: Now, there is something where you can say there’s always error somewhere, and you need to be looking for it. I, I like that. For an organization that doesn’t think they have errors, that’s problematic and maybe that inhibits learning. But there are other, as I mentioned, ancillary benefits. There are studies, and we will link them also in the show notes, that show that learning actually contributes to job satisfaction.

Andy: Ah, yes, yes, absolutely.

Mon-Chaio: And the contribution to job satisfaction isn’t necessarily the fact that you are doing your job better, or that things are going wrong less. Simply, the act of learning contributes to job satisfaction.

Andy: It is fulfilling act.

Mon-Chaio: Right, it is a fulfilling act for humans. And in the research paper they do talk about, well, you know, learning tends to make people perform their jobs better, that tends to show rewards in the organization, and that can explain a little bit of the job satisfaction increase, but not a significant portion of it. So, I like to think about learning much greater scope than just saying, hey, you have to have an error, and it’s reducing that error, or moving towards better. I think of learning more as just acquisition of knowledge, and I think that there’s a lot of reason to acquire knowledge. Reducing error is one of them, but reducing future error is also one of them. This thing that I have something in my toolbox that I don’t know, and I can’t see how I would use now, but now that it’s in my toolbox, when I encounter a situation in the future, I can use it then.

Andy: Yeah. So we started off by saying that we don’t think that many organizations are valuing learning. And is it because you think that they’re not interested in that future knowledge? They’re about the, just the execution now?

Andy: I do think so. I think most organizations don’t value learning for learning’s sake, at least in the way that they would have to dedicate time and resources to it, right? This is, again, this thing where you say, I value learning, yes. And if you talk to a hundred organizations, 99 percent of them will say that. But then when you say, what are the time and resources and the tactics you put into it, they won’t have any, and so that really shows you, again, that espoused theory versus the theory in use that we talked about a lot, whether they value it or not. And I think it is really about this, well, what is the value that I get for me? One, if there’s a clear error, if I lost two million dollars because my sales team forgot how to use telephones and didn’t call any clients, there’s a clear error there and I think If you took those hundred organizations that encountered that error, I think a hundred out of a hundred would say I’m going to start a formal learning process for making sure my sales team knows how to use telephones and knows how to dial and knows how to use extensions.

Andy: Mm hmm.

Mon-Chaio: But I think it’s the other part of it where you say, well, there’s not a clear error, or at least not an error that I can quantify the cost and return of learning. And most organizations fall into that trap where I do need sort of this cost return or cost benefit analysis. And so therefore, I can’t really see what the benefit of learning is.

Andy: I think, Mon-Chaio, that’s actually a key thing for a learning organization or for an organization that really promotes learning, is that learning is, it’s not taken as a cost. Learning is taken as an activity that is done as part of your work. It’s a bit like TDD in programming. It doesn’t work well if you have your programmers going to the leads or the managers saying, “Oh, please may I write tests?”

That’s because you’re portraying it as a cost. You’re portraying it as a thing that has to be traded off against the real work. And I think what we’re getting at is the first thing is that you have to consider learning, or aspects of learning, is part of your work, is part of what you do. It is not a separable cost that you’re going to analyze on its own. And that’s not to say that we just do it constantly and it overshadows everything else, but it’s not something that you want to itemize out and try to trade off against things. It’s a thing that you want to get into your pattern of operation, your pattern of work.

Mon-Chaio: Absolutely. And going back to the study that I mentioned, I think it’s a good time now to talk about … there’s different types of learning, and I think when we talk about learning as part of work, it’s lost because people only focus on one of the three types of learning.

So this paper talks about formal learning, which I think is the learning that most people recognize. They define it as “discrete planned events or experiences used to instruct people how to perform specific defined jobs. It’s typically institutionally sponsored and highly structured.”

Andy: Mmm, this is sending me to a course, having a trainer come in and talk to us for a day, that kind of thing.

Mon-Chaio: Mm hmm, or even things like, oh, we sponsor Tech Talks on a specific topic. And we’re gonna do this one hour every two weeks.

Andy: Right.

Mon-Chaio: But contrasted to formal learning, there’s this concept of informal learning. And the paper talks about informal learning occurring in institutions, but it’s typically “not classroom-based or highly structured and control of the learning is in the hands of the learner, not determined by the organization.” So examples of informal learning are situations such as you’re doing your work and your peer is next to you and they peer over and they say, uh, your IDE is structured really weird. Why does it take you so many clicks to create a test?

Andy: Hmm.

Mon-Chaio: You’re like oh, I don’t know. Why? What are you doing? And that is an example of informal learning.

It’s much less structured. It’s not about I’m learning a specific topic and I have three weeks where I’m dedicated to this topic. Because I would say that given these definitions, even organizations where they say look, let’s say Google 20 percent time, look, find a topic you’re interested in learning about, learn about it. Even though it’s self driven, that’s still considered formal learning. It’s still specific set aside time, very structured. But informal learning is not that.

In the paper when they talk about job satisfaction, they found that informal learning contributes to 41 percent of overall job satisfaction. Another 35 percent is accounted for incidental learning, which we haven’t talked about, but is closely related to informal learning.

And only 26 percent of the variance is accounted for by formal learning.

Andy: Oh, interesting.

Mon-Chaio: And so for most organizations who only think about learning as formal learning, they’re really missing the point, in my opinion.

Andy: I, I really like this. I’m going to use it as a perfect example of confirmation bias that I really like it. Because to me, I mean, you’ve done these due diligences, I’ve done these due diligences, we’ve worked in companies, and everyone seems to want to do pull requests. I have a suspicion that a lot of people doing pull requests believe that those pull requests are resulting in informal learning. I don’t think they are. I think there may be a little bit, a very tiny amount. There’s a very small amount, but basically they’re not.

Because one of the alternatives to pull requests is what Mon-Chaio and I are familiar with, which is pair programming. And pair programming, if you’ve never done it, it is just a treasure trove of informal learning. That is, you’re spending eight hours a day not only getting your work done, but informally learning all sorts of things about how to think about your domain, how to use your IDE, how to get better at your language, how to test differently, how to deploy.

And then it spreads through the entire team as people rotate their pairs. And so I think that is an amazing way of thinking about it, which is that it’s a mechanism for informal learning built directly into the way you do your work.

Mon-Chaio: Mmm hmm.

I like that, and you’re right, we both experience sort of the same thing around the poll requests. People wish it was informal learning, but it’s not. But it can be, it can be. In the right organizations, it absolutely can be. And so, I think this might be a good segue into this idea of, let’s say an organization now because of The TTL Podcast, thank you very much, please donate to our Patreon or we don’t have a Patreon …

Andy: We don’t have a Patreon, so don’t direct them at Patreon. They’ll just get confused.

Mon-Chaio: That’s right. Uhh, but an organization now says great now I understand that formal learning only accounts for a small part of job satisfaction, that informal learning and incidental learning is a big part of it, now I want to do it. I would say even organizations that understand that don’t know actually how to do it because they haven’t built the right environment that’s conducive to learning.

Andy: Yeah. So, moving on to a little bit of what that environment might look like, let’s talk a little bit about what that environment might not look like. What are common things that might exist that would actually start getting rid of this? And I think one is you start creating a little bit of a competition around it.

Maybe you didn’t even mean it to be a competition, but maybe you thought it was just a reward, that someone who could bring up the most interesting thing that they learned, they get a gift certificate to go to Pizza Express to bring a little bit of the UK into this.

Mon-Chaio: Do they eat pizza in the UK?

Andy: They do, they do.

Mon-Chaio: Okay.

Andy: And Pizza Express brought it to the UK. Pizza Express created this entire thing in the 60s to have pizza as a night out. Sorry, a little history lesson. So, So you have this little competition about learning, but what are you doing now? Creating competition can backfire pretty easily on creating a learning environment because, eh, inadvertently people want to start holding on to the things that they could share because now there’s a reward for holding on to it. There’s a very interesting study from the 1950s. I’m not going to get into the ethics of it, working with children in summer camps and not telling them what you’re doing, but they found that the most effective way, or at least for them, the way that they created a lot of conflict, was they set up competition between groups. And people will define their groups and if you have something that they can compete for, they will start competing for it. And if you give them something very clearly tied to learning, they will start competing over learning.

So, I think that’s one of the ways in which organizations can very quickly, inadvertently create a disastrous learning environment. I shouldn’t say disastrous. It doesn’t always go terribly wrong. But work against their desire to have that learning environment.

Mon-Chaio: Right, it creates a headwind against learning, right?

Andy: Yeah.

Mon-Chaio: Yeah, I’m sure you have others, let me chime in with mine and then maybe we could kind of alternate here. Another one that I like to think about with regard to learning and headwinds is stress.

Now, we know stress produces cortisol in the human body. We know that cortisol is a short term performance-enhancing mechanism, but it actually hinders neuroplasticity. There are numerous research papers on this. Um, I will link one of them. And so organizations who Intentionally induce stress into the environment in order to reap the benefits of those short-term gains of cortisol – to your point around competition, that’s one way to induce stress.

There are others. Challenging deadlines, artificial deadlines. I’m challenging the team on the deadlines to say, oh, you said it would take two weeks. Why not one week? How about three days? Competing, saying other teams, oh, you know, there’s team B that’s also working on this, we’re gonna see which one of you finishes first and in the higher quality. All of that decreases neuroplasticity. And decreasing neuroplasticity means that it’s much more difficult to learn.

For those folks that don’t know, the way learning works mechanistically is there’s this concept of short-term memory. And you have to take what’s in short-term memory and build it into long-term memory, and that requires neuroplasticity. And so reducing neuroplasticity keeps your learning in short-term memory, where it’s quickly forgotten. So I, I would say that’s another way that people create environments that have headwinds or are not conducive to learning.

Andy: Yeah. And to add onto that, because I think people would say, oh, well, I’m not trying to create competition, I don’t want to do that. So I don’t have good news for group either, because there’s another way that you can destroy learning. And this was in a paper that I found that was talking about how different communities of teachers created learning environments for their students and also for themselves, and three types of these teacher groups that really inhibited learning, not only for themselves, but also for their students.

One was called the toxic group, and the toxic group were the ones that they had a very strong group identity , but their group identity was based on the negative take on almost all aspects of things around them.

Mon-Chaio: Mmm-hmm.

Andy: And so they had this such a strong identity of themselves, but around this negativity that they didn’t set up a good environment for themselves or for others to learn in.

Mon-Chaio: So they would be what, the naysayers?

Andy: The naysayers, they were the ones, since this was about teaching, they were the ones that would often hold everything up to the union contract. And be like ah, no, no, no, sorry, that’s not, that’s not what teachers do, the contract doesn’t have that in it, so we’re, I’m not going to do it. And everything would be huddled up to that, even whether or not it really mattered or not.

So they would have this very toxic approach to things. It was described as they’d ” derail emerging solutions to problems, and blame everyone but themselves for mediocre student or adult learning.” So that’s one and you’re like, oh, yeah, I wouldn’t create that and if I saw it I would try to get rid of it.

Cool. All right. So the next one is how you might try to get rid of it. Maybe you’d say, you know what? I’m just gonna step back I’m gonna let them do their thing. And so the other group was the laissez-faire team And this was a group that created a group identity around themselves, but with the idea that they shared little beyond a desire or belief in their right to be left alone to do their thing.

Mon-Chaio: They were psychologically safe in the wrong definition of that.

Andy: Yes, yes, absolutely. And it describes them as “teachers or administrators coexist pleasantly, but are disconnected from institutional goals and from each other’s work and work concerns.” And that’s starting to hint at what the troublesome research into children found, which was to get the conflict to stop, to get them to work together, thing that they found worked was shared goals.

That the groups that had identified independently and were in conflict with each other, the way to bring that together was to actually get them to acknowledge and work towards shared goals. And the laissez-faire group, there’s no shared goals. Not with the institution, not with each other. That’s all they want, they’re not going to go for any shared goals. Which means that they’re not going to learn anything or much. So you’re like, okay, okay, fine, fine. I want them to have an identity, but I don’t want people fighting. Okay, so the next thing was that they found that the other type of problem was what they called congenial communities.

They say there are “‘happy’ or ‘nurturing places’ to work. These groups send off the false aura of smoothly functioning teams. Considerable effort goes into building and maintaining adult relationships and comfort, but unlike Toxic or Laissez-Faire Communities, they have no difficulty with requests to collaborate.”

But the problem is, they’re not holding themselves to account.

Mon-Chaio: Uh huh.

Andy: They are going to take the lack of conflict as their ultimate goal. Remember our very first episode on the BART model? I’m, I’m actually been fascinated how many things reference back to this. In there, they had that there’s two tasks. There’s your primary task, which you might say, Oh, that’s our shared goal, that’s what we’re trying to do. And then there’s your survival task: how do you keep the group or yourself continuing? And the congenial communities have elevated their survival task to be unassailably more important than their primary task.

So they found these three archetypes of different groups that destroy learning. So you might wonder, okay, well, what does that leave? Where do we stand then, if all of these things that it seems like, okay, yeah, I don’t want toxic. So I’ll leave them alone. Oh, I don’t want laissez-faire. So, okay, well, I’ll just make sure they’re not fighting. Oh no. Okay. Now that doesn’t work either. What are you left with? And what they had was that what you’re left with is what they called accountable communities. It says “they are the much desired but rarely achieved ideal” for functioning teams.

They are demanding. Okay, this is gonna harken back to our psychological safety episode.

Mon-Chaio: Uh huh.

Andy: “They are demanding and sometimes uncomfortable places to work. Labeling a community as accountable means its members have moved beyond merely working together well in service of students in general. The team takes direct responsibility for monitoring its own actions and for calling others on behaviors and stances that are not helpful to the mission.”

Mon-Chaio: Uh huh.

Andy: They are a psychologically safe group that calls out when things are not heading them towards their primary goal.

Mon-Chaio: And I love how all of these topics connect together, because we do tend, I mean, we’re an episodic podcast. We can only talk about so much, so we do tend to focus on a single topic, you know, it makes for an easy title, and it makes whatever. But the fact of the matter is, all of these things tie together.

And so it’s really interesting to see it all tied together in some of these research studies as well. I really like that they ended up on this model of accountable groups. Because you’re right about the psychological safety thing. Going back to, what was it, the, not the laissez faire model, the congenial model?

Andy: Yeah, the congenial communities?

Mon-Chaio: Right. One of the things you said is they have no trouble collaborating, but their survival task ends up being the primary task. The other thing about learning organizations is, especially when you start to think about the definitions around informal learning and incidental learning, it requires other people to interact with you in order to learn. Getting back to the accountable group, to hold each other accountable means that you have to be there. Well, in mind, I’m not saying you have to physically be there. And so, another way to destroy learning in your team is to make interactions incredibly formalized. And when interactions are incredibly formalized … hey, you have an API,

they have an API. The only time you need to talk to each other is when your APIs need to agree. Oh, and by the way , I scheduled an hour of fun every two weeks between your two teams and an hour of tech talks every two weeks between your teams. Have at it. Right? When your interactions are formalized, that ends up destroying learning and the opportunity for learning.

Andy: Hmm. Yes. Interesting. So I think we’ve given people plenty of stuff to, to think that, oh my god, I’ve been destroying learning through my organization for years and I was trying not to. Where can we leave them to help them out, to understand a little bit about, okay, this is what you can do. These are things that are probably more likely to work. We’ve touched on a few. There’s the accountability one. There’s the pair programming is a very specific tactic that there’s plenty of stuff to talk about. What else is there?

Mon-Chaio: I would say the first thing is understand that there are many different types of learning, and that informal or incidental learning is often, if not always, the primary learning model that you should try to foster within your organization.

Andy: Yeah. Just from my personal experience, formal learning, when I was sent to courses or things like that, it was most fun, it was most interesting because I got to do something different for a while. The things I learned from it, usually I didn’t even retain.

Mon-Chaio: Right. One of the biggest problems is that retention of formal learning. Formal learning tends to be a set amount of time and then it’s gone. And we know that when you put all of that stuff in short term working memory, if you don’t use it, it goes away rapidly. And so that is the reason why most formal learning programs fail. They don’t have to fail,

Andy: Mm hmm.

Mon-Chaio: but they almost always do.

Andy: So if you don’t want them to fail, you need to make it highly relevant right then, so that when they leave, they can practice it, to retain it. So if you have people who are working on the front end and you’re like, oh, you need to all understand the database better and you send them to a course about MongoDB, and then they come back and their work is still about front end and never about MongoDB, that was probably just a wasted day. It was probably fun, there was a bit of that effect out of it, but not in terms of learning and having your front end engineers understand how to manage a MongoDB.

Mon-Chaio: Mmm hmm. And we did talk at the beginning of the episode on sometimes learning isn’t to solve an immediate problem. Sometimes it’s a tool in your toolbox. But honestly, in that case, it’s not even a tool in your toolbox because you’ll forget 80 percent of it within a week. So how can it possibly be a tool in your toolbox?

We’re not saying that formal learning is bad. We’re saying formal learning to the exclusion of all other learning is bad. But formal learning has its place, if done correctly. So, can we talk about some ways in which to do formal learning more correctly?

Andy: Ooh, that’s a good one. I didn’t look much into this so I’m going to go off of my own beliefs and understanding at this one. For me, formal learning makes sense, not as a thing to pick up a new skill, but as awareness to understand that there are things out there that I could research later. It’s just to start building a map. I got a master’s degree in software engineering, not because I thought, oh, this is going to make me a better software engineer. I got it because I thought, and I think I was right, it exposed me to ideas that I wouldn’t have been exposed to otherwise, which meant that when I went back into the workforce, no, I don’t remember exactly how to do a formal proof using abstract data types, but I do know that such a thing exists. And if needed, I could look it up and use that little bit that I did retain, to get myself back into it a little bit more quickly.

Mon-Chaio: Mmm hmm.. That makes a lot of sense to me.

I think the other part of that is you need to be able to retain that information to your point of you don’t remember how to use formal proofs. I think that’s probably okay because some of that information is retained and so even if you don’t remember you can say, hey I’ve encountered this type of thing in the past. I can look it up but there exists this type of thing that I didn’t know about and perhaps it’s useful to my thing now, let me like go research it again for an hour. Oh it is or it isn’t.

Andy: Mm hmm.

Mon-Chaio: I think the problem with formal learning is people don’t distinguish it between the intellectual understanding of that topic and the actual skill development needed in that topic.

Andy: Mm hmm.

Mon-Chaio: There’s an article from Harvard Business Review that I’ll link in the show notes. They use the analogy of swimming. I often use the analogy of learning to play piano, but I like their swimming example, so I’ll just use it here. The author mentions that they’ve been coaching swimming for over a decade because their kids are there, their kids do swimming. And so she knows all of the legal stroke techniques, she’s received hours and hours of training, video lectures, demonstration and everything on what’s proper, what’s legal technique, how to do kicks and pulls, what’s wrong, what’s right, what’s most efficient. But, you throw that author into a pool, that author cannot swim at all. Can’t swim. Right?

And I think there’s a lot of people, especially in these more intellectual fields, who say, well, if you have an intellectual understanding of something, hey, I showed you how to write a scalable unit test. There, now, you know, right? But practice is so, so important, not in just reinforcing, I’ve talked about that short term memory to long term memory thing. Practice is what reinforces that cycle and gets it built in. But also it takes that intellectual understanding and creates the actual skill component to it. So if you’re going to do formalized learning, you need to build in that reinforcing part, that skill development part, which I tend to call practice.

Andy: Yeah. There’s this whole idea called deliberate practice. You’ve probably heard of this. In looking into this, I was looking up deliberate practice, what is the foundation of it? And I found a meta study that talks about deliberate practice and looked at all the various other studies that had looked at it to figure out, does it matter? Because it’s not clear how much deliberate practice actually matters, or at least when they were doing that research.

And the assertion had been that if you do the deliberate practice, most of your ability is going to be determined by the amount of deliberate practice. Now, the research found that that wasn’t true, but deliberate practice was still useful. So by the statement, in terms of the outcome of how good you are that statement would say that deliberate practice contributes more than 50 percent of the explanation for the outcome. But that’s not what they found.

They found it contributed at most about 28 or 30 percent explanation and at worst 1%. Now, I’m not going to say from that, don’t take the deliberate practice as meaningless. They were looking at research that studied athletes, and that was for elite athletes. Where deliberate practice was no longer the defining contributor.

They don’t know exactly why, but the suspicion is, is that by that point in their careers, the basic skills of deliberate practice are not what makes the difference anymore.

Mon-Chaio: Mm hmm.

Andy: But for everyone else, deliberate practice is very useful. It’s not the only thing. Unfortunately, this paper did not get into what the other factors are, that wasn’t part of their research. But yes, you have to practice. Because it causes that ability to actually perform the skill.

And to bring that to software engineering, in my software engineering degree, one of my courses was on testing. And I can tell you, having done TDD and lots of testing before that course, that course did not at all set me up to be able to actually test software. It gave me a great theoretical foundation in model-based testing and how to create categories of conditions and that kind of stuff.

But that didn’t mean that I actually knew how to test software.

Mon-Chaio: Mm hmm.

Andy: I had a good theoretical understanding, but the skill development wasn’t there.

Mon-Chaio: The other part of that is skill development has this idea of putting it into practice, but also making it a habit. I don’t know if there’s a better word for it than habit. If you read the research around learning, one of the biggest things is your short term memory is very, very limited. The size of your short term memory store in your brain is really limited. And so as more context comes in, it drives other things out, like a cache, right?

In order to truly learn something, you have to make it such that that thing is not required to live in your short term memory for you to be able to do well. And the only way to do that is through repetition and practice, deliberate practice. So, in the testing example, if I am not well versed in unit testing, I need to be in my short term memory. Maybe every time I write a test, I need to keep a checklist by my side, right? Okay. Remember these four things. Okay. Remember mocks. Okay. Remember only one API per test or whatever the things are that I have to remember. I have to keep that in short term memory. That means that I can’t think about, or I don’t have the space in my short term memory to think about the bigger term issues in my software, in my tests.

Practicing those things, and moving them into long term memory over years and years of deliberate practice means I no longer have to have that checklist. It’s natural. It’s nature. And now I can devote my short term memory space to more important things.

Andy: Do you remember early on, when we were teaching ourselves, because there was one else around us, but we were teaching ourselves unit testing and TDD. I’m pretty sure that on our desks or somewhere nearby, we had a Right-BICEP. Do you remember the Right-BICEP?

I’ve looked, I’ve looked for this again and I can’t find it anymore.

So Right-BICEP is a rubric that it was the functionality has to be right. So you want your happy path, and then you want to do the BICEP, and the BICEP was boundary, so what are the boundary states? What is the inverse? What’s the white space around your feature working?

Mon-Chaio: Mmm hmm.

Andy: What, oh, and then see the CEP is where I fall apart and I don’t remember it anymore.

But there was this rubric that I remember us using as we learned this. And what it does is it means when I look at tests, I’m like, oh yeah, yeah, I can see that you’re missing about four cases here because you’d never did an inverse, you don’t have a boundary. I can see that there’s a boundary on that variable.

And it just means that that is just a aspect of the way that you’ll end up thinking about the skill. And if someone hasn’t done that, very likely it’s fairly ad hoc. I watch people who haven’t had that kind of approach in training and it’s variable outcomes. They have a checklist or anything to go through in their head.

Mon-Chaio: And it’s interesting, when is the last time that you used Right-BICEP, as a framework in your work?

Andy: Well, obviously a long time since I can’t remember what it stands for.

Mon-Chaio: Right. So, you had your formal master’s in computer science more recently than you used Right-BICEP.

Andy: Yes. Yeah, it was not part

Mon-Chaio: And yet, you can remember the details of Right-BICEP much more clearly than you can remember, I’m guessing, how to do a formalized proof with abstract, I don’t know, something, whatever you had mentioned earlier. Would that be an accurate statement?

Andy: Yeah, probably, yeah.

Mon-Chaio: So why is that, do you think?

Andy: ‘Cause I practiced this a lot more.

Mon-Chaio: Exactly. You did it so much more!

Andy: I did a few formal proofs in my degree, but that was about it. So I know they exist. I know the basic structure they’re going to need to take on, but that’s about it.

Mon-Chaio: We’re talking about formal learning and the importance of deliberate practice. But I think this also shows why informal learning and incidental learning is so much stronger, is by their nature, they’re more closely connected with the problems you’re dealing with day to day. And therefore the practice itself comes more naturally.

Now, I don’t want this to be construed as I’m saying, hey, don’t focus on formal learning because if you just do informal and incidental learning, practice comes for free. That’s not it at all. You still have to dedicate time for deliberate practice, but it certainly is a lot closer to the learning than it is often for formal learning in organizations.

Andy: Yeah. So, what we’ve said so far is kind of very much at the individual contributor level, the Right-BICEP or that kind of practice. Can we come up with something managers or, CTOs, or VP Engineering, team leads, what kinds of practices can they practice to make sure that their teams are practicing?

Mon-Chaio: Do you have one off the top of your head you wanted to contribute?

Andy: I don’t, I was actually thinking about this. I was like, ooh, we were staying very low level, can we bring it up a little bit?

Mon-Chaio: So we already talked about understanding the difference between formal, informal, and making sure that all of that types of learnings exist within your organization. We kind of touched on the environment, but I think for a leader it’s important to set the environment for learning. So what does that environment look like?

If you remember back to our Amy Edmondson episode, Organizing to Learn, there’s a lot there about building the right environment for how you learn, a building environment where you’re asking questions. That sets up this idea that people understand that learning is paramount. But a key here is also, for me, getting people together, getting them together for incidental work. So building organizations and structures and culture that force people to come together because the further apart they are, the less likely they are to learn.

Andy: Yeah, using the idea of information radiation, that Alistair Coburn would talk about, that you want information just kind of flowing around. And so I would say as like a anthropological technique for managers, look for information radiation, understand where that’s happening. Not so much a practice you can use, but a thing you can look for.

As you were talking, I did come up with, I think there is a practice. Thinking about the checklist idea that we were talking about where you can have the Right-BICEP next to your keyboard as you’re working. And you brought up the idea that ask questions. You can create a checklist of ways in which you want to behave that would produce those better outcomes.

So if you should be asking questions, have a checklist next to you as you’re in a one on one with someone. How many questions are you asking? Are you curious? Are you truly interested? How much time are you talking versus the other person? So you can use that as a prompt to deliberately practice your way towards acting that way just without thinking. I shouldn’t say without thinking. Without effort.

Mon-Chaio: Yeah, I like that. And then hopefully you will internalize it as you practice it. You yourself are practicing this learning, and maybe one day you won’t need the checklist like Right-BICEP. But at least to start, I think that’s a great tactic.

I think I have two more. One is create space for deliberate practice. Remember, learning is something that you do, it’s not extra, and so part of that means you want to create that space, especially if you’re doing formalized learning, which again, we’re not saying don’t do it. You should do it. There’s very valuable ways to do it.

So do it and then create space for deliberate practice once you finish that formalized learning. That’s not because formalized learning is so far removed, like, oh, I’m in software, I’m teaching you to play piano, now you have to dedicate space to play piano. But often formalized learning is stuff that’s not immediately relevant day to day, but you want to still keep in your mind that’s going to be relevant later.

So set aside time for that. However you do it, whether it’s an hour Friday, you know, you’re all going to practice this thing, we’re going to get together to practice it or whatever. In that, accountability is also really important. It’s like anything you do within your organization. Things you don’t hold people accountable for, or that their peers aren’t holding each other accountable for, just aren’t going to happen.

Andy: Yeah. Some organizations do like dojos or coding katas, those kinds of things. All taken from martial arts where, well, it is just practice. There is a lot of practice that goes into those kinds of disciplines. And I think the terminology we’ve adopted into software, and we can make use of it.

And I think you can also do that kind of formal practice for things that are not the technical, once again, going back to what can a manager do. If you accept that a lot of the influence that as a manager you have is through the way that you talk to people, through the way you present to people, you can practice that. That is a practicable thing. You can practice presentation. You can practice public speaking. There’s the Toastmasters Club, which is all over the world. They still exist. They’re everywhere. And they teach you how to present, how to speak publicly, how to present your ideas. But there is also what I was saying about you can have that checklist.

You can also do that checklist after the fact. You can have a time where you deliberately practice a conversation that already happened.

And our friends Jeffrey Frederick and Douglas Squirrel wrote a book called Agile Conversations. In that book, they talk about having conversational dojos, because the idea is you can grade yourself on how that went and you can practice doing it better. And role play is a really useful way of doing that deliberate practice for some concept that you learned about.

Mon-Chaio: It’s really interesting that things like Toastmasters exist and code katas exist, but manager practice sessions, I don’t think I’ve actually ever seen one. I haven’t seen one in meetups, I haven’t seen a community of managers that get together to practice. So listeners, if ever any of you start one, please let us know.

We’d be happy to participate. I think those should exist more. Absolutely.

Two more things, Andy. I know we’re running long, but I think they’re important. One is to get back to the idea around stress. I want to read a quick quote from one of the articles that I am going to link.

It says: “Availability is needed for informal learning because informal learning requires time and attention as with any performance demand. Informal learning may be conceptualized as a form of extra-role behavior. As such, individuals may not engage in informal learning when confronted with multiple time intensive performance demands.”

So just like practice, you gotta set aside time for it. Now, how do you set aside time for informal learning? It’s not like setting aside time for practice, where you say, look, we have formal learning, we have deliberate practice. It’s around that availability. It’s making sure people get together. It’s lowering the stress of the environment so that people can say, I have time for this.

And the last thing that I ran into is an article called “Does fun promote learning?”

Andy: Does it?

Mon-Chaio: It does, uh, in very interesting ways. There’s the fun of the environment, and then there’s whether the leader themselves, support fun in their own way. It’s an interesting article. I’m not going to go into the whole thing, but there is a really interesting portion that I just want to read. The article says: “The significant relationship between fun activities and learning from others may be attributed to fun activities putting employees in more frequent contact with others in non-task situations. When employees are afforded opportunities to socialize with one another, higher quality relationships are more likely to develop, which can open the door for exchange of ideas.”

And so getting back into tactics, and you’ll hear this a lot with a lot of our episodes and a lot of our tactics, bring people together. Andy mentioned look for information radiation. When your communication channels are small or are very formalized, that’s a red flag on how your organization is going to be able to learn.

Andy: Mm hmm. Yeah. And I wanted to go back on your thing about building in that informal learning, that you have to have a low enough stress level. It brought to mind the book Slack. Now, I think slack in organizations is a touchy topic because it sounds like, oh, you want to slack off.

Mon-Chaio: Mmm hmm.

Andy: But slack is how organizations are able to adapt and adopt and change. Because slack gives people that space for the informal learning. If your developers, the only thing that they can think about is I need to push this next deploy, push this next deploy, push this next deploy, they’re going to be less and less willing to put some slack in there, to talk to each other about, hey, you know what, let’s refactor this because it’s getting a little hard for us to work with. Let’s figure out how we can make it a bit easier. And so that informal learning will be lost.

Mon-Chaio: Right. We really aren’t talking about this idea of let’s just reduce everyone’s workday by 20 percent or let’s just reduce everyone’s workday by 10%. People like to quantify slack time, which I think is really, really dangerous.

It’s more a cultural thing around, do you give yourself time to recover? There’s a idea for executives that all executives should take time at the end of the day to journal. Why? It’s based on brain research around you need to give your brain some down time to reflect. And so slack is around that. It’s around this time to reflect where you’re not, to use research-based wording, you’re not task bound on something that just has to happen right now, right? It’s that reflection time. It’s space. And so, you need that time.

Now, getting back to accountability, that’s not time for you to just scroll your newsfeed or whatever. That’s that peer accountability, right? And so all of it sort of fits together in creating a learning organization.

Andy: Yeah, nice! Well, Mon Chaio, I think we can leave all of our listeners with quite a few ideas that I’m gonna struggle to sum up, but let me see what I can do.

So, there’s two types of learning that you really need to think about. Formal learning and informal learning. Most of your effort should probably be directed at making sure that the informal learning is really happening. When you do do the formal learning, you want to take on some sort of tactics after that formal learning to bed it in, to make it become real and turn it into skills.

Now, within your teams, you don’t want a toxic team, you don’t want a laissez faire that you never want to touch them team. And you don’t want a congenial team where their primary goal is actually to just survive and not have conflict. What you want is an accountable team. A team that holds themselves and each other accountable to the goal that they’re after.

And then you want to build slack into that system. You want to make sure that they have time to have that downtime, to have that reflection and to have that reflection with each other. You want information radiation. You want to move what they’re learning and have that space and that slack so that that information can move and can be put to use.

Anything I’m missing in that?

Mon-Chaio: And fun!

Andy: Oh, and fun! Yes. You want to have fun. Fun will make it all better. So …

Mon-Chaio: I love it. I think that’s a great summary. Hopefully you have learned something. And remember if you have learned anything here, this is more formalized learning. So do some deliberate practice, to put it out in the real world.

Now, if you need help with that, definitely let us know. We’re more than happy to help. Email us at hosts@thettlpodcast.com. We read and respond to almost every message we get, probably every message we get. Do email us. We love to hear from you. Also, please like and subscribe on your preferred podcast platform. That really helps us out as well.

Alright, so until next time, be kind and stay curious.

S2E1 – Sabotaging Learning

Show Notes

Transcript

Comments

Leave a Reply Cancel reply