Creating a Knowledge Sharing Environment
What will you do if you invest into employees and they will leave your company? Well and what will you do if you don’t... and they stay!
How much time by average do you think we spend per week looking for information, writing emails or collaborating internally?
At some point we all are having troubles accessing the knowledge we need, thanks God Google exists, to do our daily jobs. Not only to access it but as well to make people who actually have the knowledge to share it. We need to realize that sharing knowledge doesn’t mean loosing it but actually developing it.
Aside of process biased right chosen tools we have for sharing a knowledge we can think of and encourage many less official ways how to share the knowledge itself. You need to make your teams to intensively collaborate and sometimes it really takes more than just setting up a global knowledge sharing tool. So what is it then?
Speaking high-level you should think of mentoring as every employee needs a mentor not only at the beginning. Think of sustainable development and attachment with current trends or developments outside of your company. You also need to make sure that all employees are rewarded for sharing the essential information, not for specific tasks done! Recognition is on of the most important ways to get job satisfaction so do not underestimate it. Together with rewarding we need to make sure of building trust within teams and creating non-competitive environment. Individual measurements destroy everything as people will start to work against each other. If you don’t trust your co-workers you will be way less willing to share the knowledge with them. If you are individually, wrongly, being measured or monitored then you also loose the motivation to share the knowledge you may be building for some time. Mentoring, rewarding and building trust within is basically investing into your employees. No immediate return of investment mind you as it will take some time.
So after we realize we need to build mutual trust, making sure of mentoring and having recognition plan in place what are the ways how to encourage less official though more natural ways of sharing the knowledge?
We shall start from pair programming, coming from agile development this is a technique where two developers work together at one workstation. One driving the timebox writes the code while the other reviews each line as it is being created. Two of them switching the roles frequently. This is mainly used in development team as a way of sharing knowledge where one developer is senior to the other one. Learning curve and also the knowledge transfer here is guarantee to be very fast and efficient.
Costly? Yes quite so, but soon you will have more developers with deep project knowledge and also code is less likely to become defect cluster.
Taking previous technique to another level, we can speak of cross team pairing. Make fewer assumptions & ask more questions are the main ideas aside of visibility of other teams and having broader scope of this technique. We basically apply pair programming technique but we take two resources from different teams. Also we don’t have to limit our focus to development, we also can successfully apply this for validation or different activities which are part of software development.
Having more focus towards development itself we move to coding dojos or so called kata programming. Coding dojo is a non-competitive collaborative meeting where a group of developers sits together to work on programming challenge. Such can be either taken from their daily job (cracking a bothering piece of code) or simply abstract exercise. They all while having fun will encourage themselves deliberately improving their skills in front of others. Usually outcomes are being presented.
Imagine the benefit out of such short (usually 1-2 hours timebox a week) session. Think of optimized functions, readable and changeable code, implementation of unit tests and shared best practices which are willingly followed.
Moving towards generically used practices let’s talk about lightning talks. lightning talks are very short sessions taking usually only about 5 minutes which are typically scheduled in a single track, that means all the audience is in the room meaning even if some subjects are not interesting enough for everybody, the next one comes right after. Due to their nature, lightning talks don’t go very deep, based on the presenters ability content shall be focused on what really matters. Remember to make your point and make is quickly. This technique shall be used to actually hook the audience and want them to come and ask more questions in the coffee break
Really detaching from official meeting but maybe that’s why so much used we can talk about so called brown bag sessions. Brown bag session is a casual meeting occurring usually during lunch time. The funky name comes from the idea that participants bring their own lunch at the meeting, however you can practice this even going out together into restaurant. Why would you want to use this? Usually such sessions are used to convey information which employees need to know. Think of HR training's, company-wide updates, markets trends. Sometimes topics are going the non-work related direction however even such are surely beneficial. Topics for brown bag sessions are actually limitless.
Lastly let me mention hackathons. Have you ever been confused what hackathon is? Getting an ideas only from the name it suggests like hacking something together J No not really, hackathons are gatherings (internal or even externally organized) where developers, designers or basically whoever meets and code under specific say extreme manner over short period of time. They are likely to last few days or even over weekend. You can say it is a competition yes not limited to developers to create something cool.
Why such event? To teach & learn, to solve problems, to create something new, to meet same-minded people and to build something fun and rewarding not to mention improvement for your products.
On top of that recently hackathons are used internally for technical people and nicknamed hack day. Having such day, you are allowed to work on literally anything. Finally fixing the technical debt your team has created, fixing that everlasting postponed bug or simply nap, yes you read it right.
We end here however there are more techniques to be used to encourage people to share their knowledge the only what we should remember is we need to motivate them to do so… Mentor, trust & reward.