Objectives for sharing knowledge in an IT company
“Knowledge is power,” and I believe that companies should promote a culture of knowledge sharing among developers. Keeping information by employees is not the right path through the career ladder and will not make anyone a key person in the long term. A series of activities united by a common name resembles a win-win game in which both parties win. By increasing the efficiency of each individual developer, the company achieves higher goals in the most efficient way. The main difficulty that hinders the promotion of these activities in companies is the lack of a direct connection between investments in them and returns. I have not met a clear system for assessing the progress of these activities. Therefore, I described for myself how the goals of knowledge sharing are related to real processes in the company.
Often you can meet the following list of goals:
While this list fully describes the 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 about what is necessary to learn everything new, someone will think about fundamental knowledge. Trying to make these points closer to ordinary people, I had the following goals:
The most obvious task of the knowledge sharing discipline is to disseminate information among developers. In companies where there is a parallel work on several projects that need to be integrated with each other and maintain consistency of versions, this moment plays the most important role. Awareness of one team about the principles of work of the component of another team with which they are integrated, while leading to the creation of more adequate solutions and reduce the number of iterations on 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 efficiency of developers. Someone may notice that by spreading knowledge, the developer loses his exclusivity for the company. I think that sometimes it becomes the reason that developers do not want to quickly share the acquired knowledge about one of the areas in development. As someone said, only shit do. I believe that the fear of losing its 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 put squarely. I don’t undertake to put forward psychological theories, but I know for myself that telling others, even if you don’t fully understand the topic, helps put brains in place and supplement knowledge to the level necessary for a confident level.
A little less obvious task of sharing knowledge, in my opinion, is leveling the skills of developers and their terminology. About skills, it is mainly about pulling less experienced to more experienced ones, so that they can take part on an equal footing in discussion and development. Again, this is useful both for the company itself and for the developers themselves - a win-win game. I am focusing specifically on tightening skills, because a set of skills is determined by projects. Education also has an abstract definition. Before we move in this direction, we need a small study of our teams in order to determine the cut by the skills required in projects and the level of developers. As a result, it will be seen which of them require additional actions.
Another aspect of the task is the unification of terms used by developers. I have come across situations where standard terms in a company have been 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 still many mistakenly used terms, jargon, and so on, which, in itself, is absolutely not critical. If the team does not change, no one comes and goes, everything is fine. As soon as some turnover occurs, communications may limp. In companies with many projects, there may also be a difference in the designations of the same. For example, location and property mean the same thing in two different projects: a specific 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 with their “love for the topic” of others. Usually these are informal leaders of teams that are the drivers of many things in the development within the company.
This task is related to the training of 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, the company may lose the latter. This is probably the reason why in some companies there are no investments in this direction. 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 will clarify that here I mean technical skills.
In my view, this task should be solved by expert groups. And only in critical cases it is necessary to inject knowledge from the outside. This is important because learning and improvement will occur due to improvements within the company and the motivation of the developers themselves. And the company needs to invest in the promotion of such "drivers". This ensures that the participants are most interested in staying in the company. And, as a result, there will be movement in another important task: innovation.
The result of activities in this direction is a set of ready-made solutions, approaches and templates agreed with expert groups. This set may differ from the standard for the IT industry, but it is working for the company itself. It 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 direction is the obvious work in expert groups on technical areas and the identification of such groups is also part of this task.
In the comments, tell us how it is 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 meet the following list of goals:
- train developers
- improve developer efficiency
- build expert groups for directions
- reduce development risks
- encourage innovation
While this list fully describes the 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 about what is necessary to learn everything new, someone will think about fundamental knowledge. Trying to make these points closer to ordinary people, I had the following goals:
- spread knowledge among developers
- align skills and terminology
- pull up to the latest IT industry standards
- develop internal development standards
1. To spread knowledge among developers
The most obvious task of the knowledge sharing discipline is to disseminate information among developers. In companies where there is a parallel work on several projects that need to be integrated with each other and maintain consistency of versions, this moment plays the most important role. Awareness of one team about the principles of work of the component of another team with which they are integrated, while leading to the creation of more adequate solutions and reduce the number of iterations on 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 efficiency of developers. Someone may notice that by spreading knowledge, the developer loses his exclusivity for the company. I think that sometimes it becomes the reason that developers do not want to quickly share the acquired knowledge about one of the areas in development. As someone said, only shit do. I believe that the fear of losing its 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 put squarely. I don’t undertake to put forward psychological theories, but I know for myself that telling others, even if you don’t fully understand the topic, helps put brains in place and supplement knowledge to the level necessary for a confident level.
2. Align skills and terminology
A little less obvious task of sharing knowledge, in my opinion, is leveling the skills of developers and their terminology. About skills, it is mainly about pulling less experienced to more experienced ones, so that they can take part on an equal footing in discussion and development. Again, this is useful both for the company itself and for the developers themselves - a win-win game. I am focusing specifically on tightening skills, because a set of skills is determined by projects. Education also has an abstract definition. Before we move in this direction, we need a small study of our teams in order to determine the cut by the skills required in projects and the level of developers. As a result, it will be seen which of them require additional actions.
Another aspect of the task is the unification of terms used by developers. I have come across situations where standard terms in a company have been 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 still many mistakenly used terms, jargon, and so on, which, in itself, is absolutely not critical. If the team does not change, no one comes and goes, everything is fine. As soon as some turnover occurs, communications may limp. In companies with many projects, there may also be a difference in the designations of the same. For example, location and property mean the same thing in two different projects: a specific 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 with their “love for the topic” of others. Usually these are informal leaders of teams that are the drivers of many things in the development within the company.
3. Pull up to the latest IT industry standards
This task is related to the training of 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, the company may lose the latter. This is probably the reason why in some companies there are no investments in this direction. 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 will clarify that here I mean technical skills.
In my view, this task should be solved by expert groups. And only in critical cases it is necessary to inject knowledge from the outside. This is important because learning and improvement will occur due to improvements within the company and the motivation of the developers themselves. And the company needs to invest in the promotion of such "drivers". This ensures that the participants are most interested in staying in the company. And, as a result, there will be movement in 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 agreed with expert groups. This set may differ from the standard for the IT industry, but it is working for the company itself. It 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 direction is the obvious work in expert groups on technical areas and the identification of such groups is also part of this task.
Additionally
In the comments, tell us how it is with the exchange of knowledge in your company? What difficulties in the development of this discipline did you encounter, how did you decide?
Source: https://habr.com/ru/post/323018/
All Articles