For IT leaders the topic of knowledge management is no man’s land. There is a silent assumption that it happens on its own. Well, to some extent it’s true, because as software developers we are used to the fact that not to fall out of circulation in our field we have to learn new things all the time. But that’s not enough. It’s not enough if all the team members (in fact half of them) will get to know something on their own. If the team is to work efficiently, they need knowledge that is consistent and up-to-date. And in this case cutting-edge technologies skills have a small value only.
Therefore, dear leader, you need to know that it is important to be mindful in managing the development of your team’s knowledge. It is often treated as secondary aspect of the functioning of the team – or even ignored, since it is not coding, it is difficult to put it into schedule and people somehow do without it. Well, as the old saying goes, the devil’s in the detail and this “somehow” makes a big difference. Based on my experience, the best teams that I have ever met in my life had really well-developed methods of team knowledge management.
Why is it so important? Below you will find selected pathologies that really happen, and heuristics that usually work well:
- lack of architecture documentation – Yes… yes… Currently we are all Agile, so we don’t need any documentation. It’s high time to put these excuses aside. You DO need the documentation. Especially the high-level one. What I mean are the drawings which document the system from the bird’s eye view – context diagram/drawing, component diagram/drawing, architectural mantra, diagram/drawing with the main mechanisms that we developed (i.e. the frameworks). When you don’t have these documents, it is particularly difficult to talk about solutions, changes in the system or introduction of a new person, because we have no point of reference. Without it, how do we know that we are talking about the same thing? How do we know the structure of our system? Low-level documentation (sequence diagrams and diagrams of particular functionalities) is not very useful. This is rather a temporal type of documentation that we need for the development phase, so a simple ad hoc drawing on the board is perfectly enough;
- lack of strategy for introducing new hires – sometimes you have it, but it’s rarely done in a correct way. In most of the cases (assuming that you have one), the strategy boils down to providing the new person with a few days of chaotic introduction which is more about organizational matters (company procedures), environment configuration, repo, etc. And, perhaps, a couple of words about the system… “He/she’ll will find the rest in the code.” And what happens then? The new person gets to know the system based on its code. Instead of 2 weeks, it takes 3-4 months to (more or less) look around the system, its building blocks, the preferred solutions and the domain in which this system works. Yup! Getting to know the system on your own is several times longer than mentoring provided by a selected team member. “Well…., but someone has to spend time on it instead of coding.”
At this point leaders/managers unconsciously use local optimization, which means that they want to use the new person ASAP. But it’s no use, because for the first months such a person is inefficient.
Apart from the strategy to introduce new people (i.e. a 2-3 week plan that specifies what, when and who should teach the newcomer), you need to complete the previous point, that is the high-level documentation which will shorten the time needed for mentoring. BUT it is important not to treat it as a document to be read (“There you go, just read it.”), but as a tool and a starting point for the discussion with the mentor. The document itself – regardless of how well written it is – is of no use; - people do not know the code/the system – this problem is a direct consequence of the previously mentioned two problems. Due to the fact that people don’t know the system very well or their knowledge is rather peacemeal, they waste their time on searching and other people’s time on answering their questions. Apart from that they have to learn as they code and many times copy the solutions they find – not even knowing if they are desired or not;
- lack of consistent rules – currently the shared coding standard has in fact become (nomen omen) the standard, but it’s not enough. Because of the fact that there are many other factors that influence code readability or cleanness of the architecture which should be shared – consider, for example, clean coding rules, implementation patterns used and building blocks (architectural mantra). If you haven’t set that and you don’t monitor it, it leads to the erosion of the architecture caused by application of inconsistent solutions. At first you might not notice it at all, but over time, with the development of the project, you start to struggle with the snowball effect;
- lack of exchange of knowledge in the team/between the teams – it often happens that you neither have money nor time for trainings, but I have the impression that leaders/managers do not appreciate the most valuable tool that they have – the knowledge and experience their people gained in their project. Can you think of any better source of knowledge that is tailored to the needs of the team? You have to create the environment for the exchange of knowledge – let a part of retrospective be a time for promoting good solutions that are worth popularizing, create a base of code examples (e.g. how to code a good service or a controller), stimulate short internal trainings such as “What have we learnt using the X library?”, let your people work in pairs – if not all the time, at least at the beginning and at the end of creating a solution. Not all the developers can work together – sometimes you have to put effort into teaching them how to do it, i.e. how to find a common solution when there are different vantage points.
Dear leader, building the environment of continuous learning should be one of your main goals. Thanks to it you will have well-motivated and efficient people who will create consistent solutions.
What will you get if you don’t initiate such a process? You might already be familiar with it – there will be implementations of the same mechanisms in difference places. You will have problems if someone leaves the team, because knowledge and expertise will be linked to particular people.
Lack of exchange of knowledge means lack of motivation and boring environment, so over time you will start struggling with higher turnover in your team and the outflow of knowledge and experience will be more and more noticeable. Apart from that the general expertise of your team will decrease. In fact, it will stop at one level, which in software development means regress. - lack of knowledge updates about system – each developer or a leader who has some experience is aware of the fact that systems change faster than we think and in a different direction than we have expected. Therefore, all the arrangements about system architecture, libraries and mechanisms used will have to be modified. Leaders often forget that they have to put effort into implementing and maintaining the change. One of the most frequent mistakes that leader or (the main) architect make is that they are the only people who know the direction of the system and “the currently correct” version of the architecture. Sometimes they even forget to announce it (that’s odd, right?). Sometimes they only write an e-mail and send a document. And that’s not enough.
First, you need to gather feedback from people and know what difficulties they see in applying the vision and what resources they need. Second, in the first phase of implementation you need to have the method for monitoring changes and focus on design during code review, applying verification lists (checklists) checking key assumptions. And you should do retrospectives, which through the analysis of problems and successes will enable you to monitor the efficiency implementing architecture vision. - lack of places to gain new knowledge – many companies have a strategy like that: here people learn on their own. This is perfectly OK. I am the representative of this way of thinking as well ;-)
But this approach has its drawbacks.
First, when you learn on your own, you limit yourself to the context that you know. It is hard to go beyond it. For this reason it is much harder to find other, more novel solutions and a different approach to the problems that you have to solve, because your perception is limited by your so far experiences. Second, learning on your own is often snippy as you collect a lot of information, but you can’t glue it up as a whole. That is why self-learning leads to the impression that we still have a lot to learn. It’s hard to tell what is grain and what is weed. You need a few years of experience to learn how to distinguish between these two and say: that’s enough. Third, other people serve as the best inspiration that you cannot substitute with individual work. Most of our ideas stem from contacts with other people – be that personal contacts (which I perceive as the most efficient) or contacts through internet.
This is the reason why trainings, conferences and events that are not fully connected with what developers do in their everyday job are extremely valuable. Your task as a leader is to focus and catalyze the knowledge and experience gained, for example through the following question: “How can you use what you’ve learnt there?” And don’t let them give you short shrift by fast and simple answers. Dwell on and you will get a more conscious and knowledgeable team member.
Below you will find a short cheat sheet (click to enlarge).
