While preparing my talk (video) for the last Italian Agile Day conference, I spent some time retrospecting on my past projects. As people who attended know, this retrospective step ended up completely thwarting the original purpose of the speech: looking back in the past I discovered more than I expected.
To be completely honest, some of the inspiration for the talk came from Alistair Cockburn closing keynote at JAOO 2007 , I rarely invent anything. Connecting the dots is my job.
My key factors for successful learning
(OMG, I wrote this title like I know this stuff... and I actually don’t) While retrospecting on my past projects, I didn’t focus on normal success conditions. I focused on the amount of relevant knowledge learnt during the project. This allowed me to look at the past with a different perspective, seeing things that I probably overlooked in the past. From the perspective of learning, the key factors that most influenced the outcome were:
- Team attitude
- Motivation
- Context.
Team attitude is a tricky definition. Because it states 2 different things: that the attitude is relevant, and that I actually need a team. Of course I’ve learnt a lot also in projects where I was a lone consultant: I did some stuff, I solved some problems, I spent some time thinking about what I actually did. But the real massive amount of learning happened in projects where I had the chance to solve complex problems as a team.
Interestingly I couldn’t find any connection to the role I was playing at that time. Didn’t really made a difference if I was a junior developer or a project manager, or a senior architect. Didn’t really made a difference if I was supposed to be managed or managing (I hate this definition, but that used to be the past). Didn’t really made a difference if I was supposed to learn from the colleagues or to teach them something.
The one single thing that made a lot of difference was the attitude me and my colleagues shared in those difficult projects.
Learning attitude patterns
People made a lot of difference also in the business outcome of the project (yes, that boring on-time and on-budget part) but could give me from the very beginning a grasp about what I was going to expect. Let’s make some examples with somewhat stereotypical approaches.
“I know what I am talking about” that the kind of sentence often heard in organizations. To me, it means “I don’t feel any need to improve”. I’ve met some person like this, but luckily they were not in my team. Sometimes they were part of the organization we were supposed to work for, almost always they were part of the problem. I don’t want hem in my team. Plain and simple.
“That’s all clear to me” ... No. It isn’t. People that for some reasons pretend they’ve understood everything needed to solve the problem, are part of the problem as well. Quite often, under the surface they look for hints about what the boss said, and keep pretending that everything is fine. Walking timebombs.
“I have no clue about what we’re going to do” Now we’re talking! The most effective colleagues I’ve worked with always started the project with fear. They called me out for a one on one talk, and with fearful eyes told me “I know absolutely nothing about the topic of this project”, and - believe me - their faces were even better when I answered honestly “I have no idea about it either”. But that conversation was honest, we defined a common ground, and we started learning collaboratively assuming that we didn’t know all the things and that we needed to share information to solve a common problem.
Confront this profile with the previous two. Would you share information with those colleagues also? A lot less, ...they won’t need it anyway: they (pretended/assumed) that they already know the stuff. They basically shut themselves out from any possibility of collaborative learning. Ok, that’s basically Socrates statement: “The real wise man is the one that knows that he doesn’t know”. ...But not only.
Focusing efforts in the right direction
What’s striking me more and more, is that the attitude we had sometime towards learning new things as a team, was incredibly effective also because it was efficient. We din’t waste any time in pretending that we were better than we really were. We did have a massive amount of work to do, but we didn’t have any knowledge debt, and we didn’t spend a second studying things that people around me expect me to know but I don’t.
Don’t you smell something familiar here? It smells like your dirty little secret to me. Make me think about movies where one of the characters did something wrong in the past and lives in the fear of being blackmailed... Ignoring a key skill, it’s not as bad as committing a crime, but the mechanics in our mind are not that different. Our brain start working in “I can’t let them discover my secret" mode, which is a dangerous slope: it makes you feel like “I am not the person they expect”.
It doesn’t matter how bad is our secret, the mechanics are similar: shame and fear of humiliation (even if only at the coffee machine level) are powerful triggers, and would lead to the wrong behavior, and also to learn less in the long run. Because stress is preventing from effective learning, because one can’t enjoy collaborative learning, and because a lot of time won’t be dedicated to learning but just to cover-my-ass activities which are brain draining (how many brain cycles are you spending deleting compromising SMS from your phone or wondering if your girlfriend can actually see what you posted on that other girl's wall on Facebook?).
To be honest, in a software project, your fault (if we want to call it like that) is really little. Telling that you’ve actually never understood OOP, or that you’ve never actually shipped anything to production isn’t a fault, it’s just a honest starting point. Stating where you are exactly and honestly right now would save you and your team a lot of troubles in the future.
When is the moment of staffing the team for a new project. Now I know exactly what I want. I want people with the right learning attitude.
Only knowledge gap?
Not really. The more I look into the problem, the more I realize that the mechanics are the same whether it is knowledge or learning debt, technical debt or motivational debt. Failing to acknowledge where we really are only exacerbates the problem. But that’s a topic for a whole new post. I also didn’t say much about motivation and context... Stay tuned.
