March 1, 2017 at 20:57Knowledge sharing goals in an IT company
“Knowledge is power,” and I believe that companies should promote a culture of knowledge sharing between developers. Retention of information by employees is not the right way up the career ladder and will not make anyone a key person in the long run. A number of activities, united by a common name, resembles a win-win game in which both sides win. By increasing the effectiveness of each individual developer, companies achieve higher goals in the most efficient manner. The main difficulty that impedes the promotion of these activities in companies is the lack of a direct link between investing in them and return. I have not seen a clear system for assessing the progress of these activities. Therefore, I painted for myself how the goals of knowledge sharing are related to real processes in the company.
Often you can find the following list of goals:
While this list fully describes activities in the discipline of knowledge sharing, it is very abstract and does not give an idea of the expected results. In my opinion, different people can understand completely different things by reading these points. Someone will think that it is necessary to learn everything new, someone will think about fundamental knowledge. Trying to make these points closer to ordinary people, I got the following goals:
The most obvious task of the discipline of knowledge sharing is the dissemination of information between developers. In companies where parallel work is underway on several projects that need to be integrated with each other and maintain version consistency, this is currently playing the most important role. Awareness of one team about the principles of operation of the component of another team with which they are integrated leads to the creation of more adequate solutions and reduces the number of iterations for debugging. If you do not take into account the integration between projects, then this activity will reduce the likelihood of re-creating the same in different projects.
Activities in this area help to achieve two goals from the first list at once: to reduce risks and increase the effectiveness of developers. Someone may notice that by spreading knowledge, the developer loses its exclusivity for the company. I think sometimes this becomes the reason that developers do not want to quickly share their knowledge on one of the areas in development. As someone said, only shitters do this. I believe that the fear of losing their exclusivity is associated with the fear of being insufficiently competent in the subject. At the moment when a person tries to talk about this topic, the question of his competence will be posed with an edge. I don’t presume to put forward psychological theories here, but I know from myself that when telling others, even if you do not fully understand the topic,
A slightly less obvious task of knowledge sharing, in my opinion, is to align the skills of developers and their terminology. About skills we are talking mainly about pulling the less experienced to the more experienced so that they can participate on an equal footing both in the discussion and in the development. Again, this is useful both for the company itself and for the developers themselves - win-win game. I focus on pulling up skills, because a set of skills is determined by projects. Education has a too abstract definition. Before moving in this direction, you need a little research of your teams to determine the cut according to the skills required in projects and the level of developers. As a result, it will be clear which of them requires additional action.
Another aspect of the task is the unification of terms used by developers. I met situations when standard terms in the company were used to describe unusual things. For example, the term milestone was used for what the rest of the world uses a user story. In addition, there are many more mistakenly used terms, jargon, and so on, which, in itself, is not critical at all. If the team does not change, no one comes and leaves, everything is fine. As soon as some fluidity appears, communications can be lame. In companies with many projects, there may also be a difference in the designations of the same thing. For example, location and property mean the same thing in two different projects: a particular restaurant.
Another useful result of activities in this direction is the creation of expert groups. I imagine this as a group of people who like what they do and they infect others with their “love of the topic”. Usually these are informal team leaders, who are the drivers of many things in development within the company.
This task is related to training developers. Like the previous two, it is also beneficial to both parties, although in this case the company has to worry more. By investing in activity data and developers, a company may lose the latter. This is probably the reason why some companies do not invest in this area. But it seems to me that the reason for this is that the idea is understood too superficially and without connection with other tasks. I’ll clarify that here I mean technical skills.
In my opinion, this task should be solved by expert groups. And only in critical cases, an infusion of knowledge from the outside is necessary. This is important because training and improvement will occur due to improvements within the company and the motivation of the developers themselves. And the company needs to invest in encouraging such “drivers”. This ensures maximum interest of the participants in staying in the company. And, as a result, there will be a movement in the direction of another important task: innovation.
The result of activities in this direction is a set of ready-made solutions, approaches and templates, coordinated with expert groups. This kit may differ from the accepted standard in the IT industry, but it is working for the company itself. This is not only about technical solutions, but also about design, development processes, monitoring methods and all other possible practices that allow companies and developers to achieve common goals. It may look like a knowledge base on wiki, c examples and on GitHub. A distinctive feature of this area is the explicit work in expert groups in technical areas and the identification of such groups is also part of this task.
In the comments, tell us about the situation with the exchange of knowledge in your company? What difficulties in the development of this discipline did you encounter, how did you decide?
Knowledge sharing goals
Often you can find the following list of goals:
- train developers
- increase developer productivity
- build expert groups in areas
- reduce development risks
- encourage innovation
While this list fully describes activities in the discipline of knowledge sharing, it is very abstract and does not give an idea of the expected results. In my opinion, different people can understand completely different things by reading these points. Someone will think that it is necessary to learn everything new, someone will think about fundamental knowledge. Trying to make these points closer to ordinary people, I got the following goals:
- spread knowledge between developers
- align skills and terminology
- pull up to the latest IT industry standards
- develop internal development standards
1. Disseminate knowledge among developers
The most obvious task of the discipline of knowledge sharing is the dissemination of information between developers. In companies where parallel work is underway on several projects that need to be integrated with each other and maintain version consistency, this is currently playing the most important role. Awareness of one team about the principles of operation of the component of another team with which they are integrated leads to the creation of more adequate solutions and reduces the number of iterations for debugging. If you do not take into account the integration between projects, then this activity will reduce the likelihood of re-creating the same in different projects.
Activities in this area help to achieve two goals from the first list at once: to reduce risks and increase the effectiveness of developers. Someone may notice that by spreading knowledge, the developer loses its exclusivity for the company. I think sometimes this becomes the reason that developers do not want to quickly share their knowledge on one of the areas in development. As someone said, only shitters do this. I believe that the fear of losing their exclusivity is associated with the fear of being insufficiently competent in the subject. At the moment when a person tries to talk about this topic, the question of his competence will be posed with an edge. I don’t presume to put forward psychological theories here, but I know from myself that when telling others, even if you do not fully understand the topic,
2. Align skills and terminology
A slightly less obvious task of knowledge sharing, in my opinion, is to align the skills of developers and their terminology. About skills we are talking mainly about pulling the less experienced to the more experienced so that they can participate on an equal footing both in the discussion and in the development. Again, this is useful both for the company itself and for the developers themselves - win-win game. I focus on pulling up skills, because a set of skills is determined by projects. Education has a too abstract definition. Before moving in this direction, you need a little research of your teams to determine the cut according to the skills required in projects and the level of developers. As a result, it will be clear which of them requires additional action.
Another aspect of the task is the unification of terms used by developers. I met situations when standard terms in the company were used to describe unusual things. For example, the term milestone was used for what the rest of the world uses a user story. In addition, there are many more mistakenly used terms, jargon, and so on, which, in itself, is not critical at all. If the team does not change, no one comes and leaves, everything is fine. As soon as some fluidity appears, communications can be lame. In companies with many projects, there may also be a difference in the designations of the same thing. For example, location and property mean the same thing in two different projects: a particular restaurant.
Another useful result of activities in this direction is the creation of expert groups. I imagine this as a group of people who like what they do and they infect others with their “love of the topic”. Usually these are informal team leaders, who are the drivers of many things in development within the company.
3. Pull up to the latest standards of the IT industry
This task is related to training developers. Like the previous two, it is also beneficial to both parties, although in this case the company has to worry more. By investing in activity data and developers, a company may lose the latter. This is probably the reason why some companies do not invest in this area. But it seems to me that the reason for this is that the idea is understood too superficially and without connection with other tasks. I’ll clarify that here I mean technical skills.
In my opinion, this task should be solved by expert groups. And only in critical cases, an infusion of knowledge from the outside is necessary. This is important because training and improvement will occur due to improvements within the company and the motivation of the developers themselves. And the company needs to invest in encouraging such “drivers”. This ensures maximum interest of the participants in staying in the company. And, as a result, there will be a movement in the direction of another important task: innovation.
4. Develop internal development standards
The result of activities in this direction is a set of ready-made solutions, approaches and templates, coordinated with expert groups. This kit may differ from the accepted standard in the IT industry, but it is working for the company itself. This is not only about technical solutions, but also about design, development processes, monitoring methods and all other possible practices that allow companies and developers to achieve common goals. It may look like a knowledge base on wiki, c examples and on GitHub. A distinctive feature of this area is the explicit work in expert groups in technical areas and the identification of such groups is also part of this task.
Additionally
In the comments, tell us about the situation with the exchange of knowledge in your company? What difficulties in the development of this discipline did you encounter, how did you decide?