What is the half-life of knowledge and how is it affecting us project people. Plus five tips on how to best handle it. And a huge plot twist at the very end.
The wild sixties
In my opinion, you have to start from the very beginning to understand something. In our case that means we have to go to the year 1962 Not only did cars look really good at the time, but this year Fritz Machlup also postulated the concept of "half-life of knowledge". Machlup - one of many Austrians chased away in the dark 1930s - was one of the first to understand knowledge as a resource. The term information society goes back to him. And just in 1962, based on the half-life that we know from physics, he defined a key figure: the time that passes until half of our acquired knowledge has become obsolete or wrong.
At the risk of undermining myself in the second paragraph of this article. But it has to be said that the concept of half-life of knowledge is not free of criticism. Mainly, that the concept is simple and generalizing. And yes, that is partly true. Sure, such a knowledge obsolescence is highly dependent on the particular subject area. Knowing how to recognize rock formations will not be as fast-paced as expertise in IT. And often we also find huge differences within one subject area. The knowledge of a web developer will be outdated faster than that of a mainframe software developer.
But we have to be careful here: sometimes outdated knowledge will still help me to squeak through work. I can often observe this attitude with people who have huge comfort zones. And yes, there are environments, where the 50%, leftover from my initial knowledge acquisition is enough to get the job done. Is that great? Or rather sad? Everybody has to decide for themselves. But the fact is: even in these areas, there is still something like a half-life of knowledge. It only has a smaller effect than perhaps elsewhere.
In any case
In any case, one thing is true. And I know, I am mentioning this often and at any opportunity. The world is turning ever faster. So I hope that here and now no one contradicts me:
Our acquired technical knowledge will be usable for shorter periods of time.
The half-life of knowledge was already very short for technical professions in 1962. At that time, it was said to be about 10 years. (Compared to 35 years in the 1930s.) Today, just 60 years later, it has become even shorter. And I do not want to go into more detail here on possible causes. I want to encourage you to think about the subject. In other words:
What does that mean for me?
Two things. First, let us have a look at the obvious: in the worst case, my team is constantly losing knowledge. And yes, I know that my wording is incorrect. The knowledge itself does not become less, it is less applicable. But in the end, it comes down to a loss of knowledge, if you are asking me. And that means that even the best knowledge sharing concept can only be half the battle. My two cents. Before I can share it, I have to have the knowledge. And if it is constantly losing its topicality, I have to make sure that my team, my organization has the ability to constantly acquire new knowledge. A learning organization
So we have to create an atmosphere that encourages knowledge acquisition. I can do that quite well with easy access to learning platforms and a time quota available for continuing education. I have often experienced a value of 10% to 15% of the working hours here. That sounds like a lot at first glance. Especially when a project is about to be completed. At second glance, and considering the half-life of knowledge, that seems like a reasonable value to me. And now it is crucial to motivate team members to take advantage of this offer. After all, it is in both their interests. And in my experience, the best motivation is the role model here. If I want to do things for the better, I have to lead by example.
The look into the mirror
So hopefully we have found a good approach for our team. With that and thus we are finished. Aren't we? Hm. Because of all the focus on others, we completely forgot about ourselves. We project people are just as affected by the loss of knowledge of course. Even more so than others who often work within teams with similar subject areas and topics. And how can we keep our knowledge up to date? Ideally, we can access the same structures our teams have. And if we are lucky, we are part of a Project Management Office, which ensures a lively exchange of knowledge and knowledge acquisition for us. In any case, it needs our awareness that we have to constantly practice knowledge hygiene here. That we constantly develop and change. (Here we are again with my favorite subject Kaizen.) We must not overlook this in the stressful everyday project life. Otherwise, at some point, the dust settles and we realize that all the others have moved on and we are left behind.
And how do I deal with that half-life of knowledge?
As I said, the concept of half-life of knowledge also has critics. But maybe what was state-of-the-art in 1962 is not that up to date anymore. And so maybe the whole thing is proof in itself. Have fun thinking about this!
Life as a project manager is not easy. On first sight, we may only have one single role. But we are much more than what the doorplate in front of our office is saying. We are planners, facilitators, controllers, handlers, organizers, mentors, presenters, helpers, impediment-scavengers, carers, managers, servant leaders, humans and often even friends.
But out of the many hats we are carrying on our PM-head, two stand out in particular: one says "Project Manager", the other one says "Team Member".
Let's take a closer look at these two different roles
On the one hand, we are part of management. We administrate, we control, we are emissaries of evil. On the other hand, we are members of the project team. We are celebrating successes together, we dive through depths together, we are part of the family.
As a project manager, we are responsible for the successful completion of projects. We prepare, we plan, we manage. We are responsible for controlling the projects. And it doesn't matter if we are part of a functional, project or matrix organization: to our co-workers, we are one of those "up there". Even and especially when our desk is located in the middle of the team room.
..and team member
If we do everything right, we are in the middle of our teams. At least we have that feeling. And with distributed teams, that's no different. There is the spatial separation, but we are the fat spider in the middle of the network, where all information converges. And we are the maven, who distributes this information to others. So we are clearly a team member, a part of the group. Especially when talking about longer projects, or teams that have existed for a long time, there is a special bond between the project manager (or Scrum Master) and the team members. Of course, it is: you have been through a lot together and you are going to experience a lot more together. That is the material that welds a group of people together.
So far so good, but where are we now?
So these are our two main roles in my eyes. And none of us is just one or the other. When we are organizing a meeting or demanding metrics, we are part of the management. When we are having coffee together in the office kitchen and talk about our weekends or we are working out a plan together, we are part of the team.
And this issue won't get easier if we are not only in charge of project management-related tasks but work as part-time project managers. I have seen this several times in agile software development: a Scrum Master that is part time-developer. Or the developer is part time-Scrum Master. And there are the smaller companies that simply don't have the resources to have a full-time project manager. So projects are often led and managed _en passant_. In these scenarios, the team has even more difficulties to determine _who_ is communicating with them right now.
But what does the solution look like?
There is a book that I loved when I was a child. Herbie's Magical Hat by Otfried Preußler. There, in this children's book, I found a solution to our problem. Herbie (or Hörbe as he is called in German) is a Hutzelman (a kind of a Brownie) from the Siebengiebelwald (the Seven-gables-forest) - one of thirteen. And those thirteen Hutzelmen have something very special: Doppelhüte - double hats. A hat on top, which protects from sun and rain (and at night from evil dreams). And a hat below that keeps you warm. And for us, it is essential to realize that we all are wearing such a double hat. We have to be constantly aware of that. And in some situations, we should aim to wear only one of those two hats. This makes it clear to everyone involved who is in front of them.
Communication is everything
In this situation - as everywhere else - communication is everything. When changing roles, we have to communicate this to our teams clearly. If, as a project manager, I want to raise an objection during the Planning Meeting that has nothing to do with Scrumstuff, I have to preface an "I'll say that as a team member". Or, "I'll take off my project manager-hat now."
And vice versa. When I'm playing table soccer with team members and want to communicate some organizational matters, it must be clear to everyone that I am now speaking as a project manager and not as a team member.
The hard slog always pays off
Yes, that is difficult. But clear communication and role separation not only has the one clear advantage that your team members always know which hat is talking to them. It also helps us tremendously in our daily work. If we make ourselves aware, what role we are currently taking, we can structure and document our work much more clearly.
So when our current role is clear to us - especially in those stressful situations - we are not only facilitating the people around us but also are greatly empowering our lives. And I know, this takes some time to get used to speaking out loud, what role I am currently in. But trust me, it pays off a lot.
Of unpleasant surprises
Imagine yourself managing a project where not a single problem arises during progress. No issues, no uncovered risks, nothing. A nice idea, right? And now reality. Each and every one of us encounters problems and obstacles throughout every single project. Even with the best and most granulated Risk / Impact Probability Chart, we won't have all the risks on the radar. And even if we capture and reduce risks before the project's executing phase starts, over time all kinds of hurdles will be popping up.
Of course, you can handle it in a way that seems very prevalent to me. Just ignore the issues and hope that they will disappear. Funnily (or actually tragically) they never do that by themselves.
Let us have a look at Scrum
Old project stagers have to smile when Scrum Masters are proudly showing their impediment backlogs. Because, even if the average Scrum Coach is trying to tell us that collecting problems that are slowing down the team is an invention of Scrum, such lists have been there since project management exists: Issue Management is the magic word here. Such emerging problems have to be
And most importantly, they have to be managed. As always and everywhere in project management: it needs someone to take care for. Someone who is collecting and maintaining these issues. But which format is the right one for such an issue list?
Let's take a closer look at the Impediment Backlog format. Because we can find several takeaways there. But first things first, what is that? An Impediment Backlog is a document (analog or digital) in which a Scrum Master captures all the stones that are in the way of the team and that have to be cleared away. These are usually collected during the Daily - the brief meeting during mornings where everyone tells what was done yesterday, what's going to happen today, and what's stopping them from being productive (or even more productive).
Many small stones are cleared away easier than a big one
And here we can notice something. Such a Scrum Master does not (only) project work, but also a lot of operational work. Daily business. Of course inside a project environment. And, of course, the border is indistinct and depends a lot on people, phases and, above all, needs. But such an Impediment Backlog is mostly consisting of "small" problems. Issues at the daily business level. We won't find many huge - and huge means insoluble in that form - chunks there. In other words, in such an Impediment Backlog we have many issues that we can get rid of very quickly and easily. Many small stones are cleared away easier than a big one.
Prioritization is half the battle...
Another big advantage of such an Impediment Backlog is that it is not just a list, but a backlog - that is, a prioritized list. The most important - in our case the most serious - problem is always to be found at the top. This helps me to help my team. The issue that bothers them the most is the one I am going to tackle first.
..and clarified responsibilities are the second half
And such an Impediment Backlog is also a very elegant and easy solution for responsibilities: the Scrum Master is responsible for all the impediments that are on the backlog. No RACI matrix, no pushing around and no denying. There is one person and that one takes care. This does not mean we can not delegate topics that are on the list. But the responsibility should lie with the project management.
That may seem out of place at first glance. Why should we, as project managers, carry the can for other people? But we are talking about issues here. These are either risks that have become alive or even problems that have arisen unexpectedly. In my opinion, we are facing a roof that is on fire in that case. And the solving of such issues should be a particular concern for project leaders. But you all see it that way, right? And so it is only fair that we have the responsibility for resolving the impediments in our own backlog. My two cents.
Where there is light, there is also shadow
That sounds almost too good to be true. And in my experience, Impediment Backlogs also have some weaknesses. Or to be more precise, their handling has. I often see well-behaved Scrum Masters who are writing down all of the topics their team tells them about. In fine writing, with a box to tick it off. And then they grab all of their colorful marker pens and start drawing circles around and lines between those list items. In my opinion, impediments (or issues in our case) are tackled the moment we hear about them. They are far too important not to start immediately. Only when I have to wait for something - that is, a dependency - the issue becomes part of the backlog.
"Open your eyes, open your ears, Helmi is here"
Back in my childhood days (a long time ago) there was a television series in Austria called Helmi, which had the purpose to teach us careless children the responsible use of the traffic regulations. And in the show's title song, it said, "Open your eyes, open your ears, Helmi is here." And we should all take that to heart. Even if my team is holding a Standup Meeting where they are talking about any stones in their way every single day. Who says that they really are thinking of every single one? And who tells me that an issue does not show up two minutes after the meeting ends? So we should always keep at least one ear on the team.
And an important notice (a point that is discreetly concealed in the Scrum Guide). We should not ignore the distinction between issues and risks just because one is using an Impediment Backlog. Even if the two words are used quite synonymously. But a risk has no business on an issue list or in an Impediment Backlog! For risks we have our good old Risk Management, all with plan, identify, analyze, execute, and so on. Only when a risk becomes alive it becomes an issue.
Maybe we project managers should include the term Impediment Backlog in our vocabulary. Such a prioritized listing of all issues that are blocking our team - and thus jeopardizing our entire project - and that we can (gradually) work off is a valuable tool for our daily project work. Because even without such a list it is already complicated enough.
What good teams have in common with good bands.
As a trained guitar player I love some good jazz. Well, I love all kinds of music. But even those who are not much into jazz music at all, have to admit that they are astonished when musicians seemingly effortlessly deliver the wildest improvisations. But what is behind this genius? Dark arts? It is said that Jimi Hendrix never had a single music lesson in his life. So is it all talent? Or is there more than just pure musical sense? And what does all this have to do with teams?
First, let's clarify what jazz improvisation - or generally improvisation in music - actually is. Improvisation is when one or more people make music without previously written down fixation. That is, the played notes and melodies arise spontaneously.
Again, what does that have to do with teams?
In our daily project work, we are experiencing this every day. This interaction of people, which has not previously been fixed. And even if our planning is good and detailed and almost perfect - at the implementation level we are owing much to the spontaneous ideas and inspirations of individuals.
And here is our big 'but'. As in making music, this is only working when the people involved know exactly what they are doing, and are prepared well.
Learning from the best
Here we can learn a lot from musicians like Miles Davis, Chet Baker, or Judy Carmichael. Good improvisation has a rock solid basis. Because none of the above just went on a stage and started playing music. On the contrary, there is a lot of training and rehearsing and preparation behind it. So spontaneous improvisation is not so spontaneous at all. And it is not totally free either. There are chords and scales and a lot of formality. Does that ring a bell? Let me say it in other words: there are methods and processes and a lot of formality. Ha! Our daily business, right?
Of course, I can handle projects without these methods and processes. And there are certainly some Jimi Hendrixes of the project management world, who can do without formality and without their company going bankrupt. But personally, I have never experienced a haphazard project that did not go up in flames at some point. Did you?
So what are these good jazz bands doing and what lessons can we draw from them?
Conclusion - how can I use that for myself
It does not matter if I am building a team for a big project from scratch, or if I am working with a veteran group. But I always try to create an atmosphere in which teams can live those above points.
I can not force formality and rules. This has to come from the team. I can only pave the way and make suggestions. And mutual consent and trust can also not be created on command. They come naturally when team members feel secure. And only when everyone has agreed on basic rules and everyone knows how things are going, valuable improvisation can arise.
Oh, if anyone still wonders if it's true that Jimi Hendrix never had any music lessons: Jein, as we say in Austria. Yes and no. Billy Davis (https://en.m.wikipedia.org/wiki/Billy_Davis_(guitarist)) showed him a few things on the guitar. And Buddy Guy (https://en.m.wikipedia.org/wiki/Buddy_Guy) once claimed in an interview, that he had given Hendrix some lessons. So by and large, Jimi Hendrix is self-taught. But that is a different story.