Increasing Knowledge Sharing in an Organisation

The distribution of project-based knowledge can be painfully slow. New discoveries and findings within a project lifecycle can often pave the way to successful product delivery and enhance the knowledge of individuals in the team. So, how do we make these experiences visible to a whole organisation?

At the time of writing this, I can guarantee that somebody, somewhere within our organisation is talking about some form of new tech or how they solved the unsolvable - either in person or via Skype, Slack, Email etc.

We're working across the breadth of the tech stack. We're a multilingual, multi-tech organisation and our use of tech is far-reaching. When we create teams for projects, we find the right people working with the right languages and tech to suit. We don't go with what we always use, and we don't decide on what we're using based on trends. We find the right tools for each project. This freedom to experiment means our use of new and exciting technologies can lead us into uncharted territory. Learning a new system or tool to help us with development could hugely increase the speed of delivery and can give our client the competitive edge they've been looking for.

But what is the point in this newfound knowledge if it is retained by a single team or even a single person within that team? As projects and products evolve, the information learned and used can sometimes be forgotten about - it's still doing a great job, but the team don't talk about it anymore. So, what happens when another team working on a project are looking for that same piece of the puzzle? If these teams are not communicating across the various channels, how can they share this knowledge? The time spent replicating the research already done to come to the same conclusion is costly.

We actively encourage the transfer of project specific experience. Being able to adopt the same processes and tools from one project to another can greatly increase our understanding and decrease delivery time. So how can we access these crucibles of knowledge?

Here are some excellent ways we increase cross-team project experience at Headforwards.

Create Ways to Share

While a lot of conversations happen over a coffee or during unexpected discussions in the corridors, creating ways to share knowledge to a larger portion of the organisation is essential. 

Show and Tell

Celebrate success and failure! We hold weekly "Show and Tell" sessions that do both. Show and Tell gives the teams a chance to talk about new developments on their projects. It also gives them a chance to talk about any hurdles they've overcome during their sprint. This can be useful for other teams who may be facing similar problems. These small but insightful talks give others the ability to follow up with the developers and ask questions in more detail later.

Internal Conferences

Internal conferencing is another useful tool at a wider organisational level. We hold a monthly tech talk aptly named "Headtalks" - if you haven't guessed already, it's based on the hugely popular TED talks. Headtalks is a monthly event that gives anybody within the organisation a chance to present and discuss anything technical that they wish to share with a large audience. It's a popular event and usually sees most of the company in attendance.

Topics people have spoken about: Geotagging, Turning Developers into Testers, Building a RaspberryPi Weather Station, Rolling Your Own Scripting Language, End to End Testing Using Protractor...

We share most of our talks on YouTube which you can check out our YouTube channel here.

Communities of Practice

Right now, we have 3 active communities, all set up and run by the teams themselves. These groups are self-organised and plan their own meetups. By sharing and maintaining a level of quality they would all like to adhere to, these groups can aid in the cross-team distribution of project and code experience. Right now, we have a Business Analysis, Front End JavaScript and ScrumMaster community of practice. As these become popular, we expect other areas of within the organisation to begin their own groups.

Make Space

Communal spaces are becoming increasingly popular with lots of organisations. Offering up "breakout" spaces for anybody to check-in to can effectively enable small groups or even pairs of developers to sit down and work out a solution on-the-fly. This is regardless of which team they're from. Placing seating in high-traffic areas increases the chance of interaction between developers who may usually only pass with a quick "hello".

It's important to remember that meeting spaces don't have to be defined - from a chat while making a coffee, or even over lunch in a breakout space. These are useful ways to enable shared knowledge. I can't remember the last time I walked into our kitchen and didn't overhear conversation around a programming problem. "Ah yes I did something similar the other day. Did you try this function instead?" – A lightbulb moment has occurred.

There are pockets of discussion happening everywhere within the organisation and it's brilliant. I find it refreshing to see this level of chatter around programming problems. There is a clear passion for solving things as a team.

Pair & Mob Programming

Pair and Mob programming are hugely powerful ways to share knowledge. And, although it isn't necessarily going to benefit teams operating outside the realm of that project, it does help the individuals within the team utilising this process to increase their own knowledge and experience.

What's the difference?

Pair programming is self-explanatory, you take two members of the team and pair them up to work together on a task. This helps them increase the technical knowledge of the coding language, but also that of the domain they are operating in.

Mob Programming is paired programming but on a larger scale. Instead of 2 members of the team working together, this is about the whole team getting together to work around a problem. This is a popular technique used by our .NET development teams. Often, I will see a whole team sat around a screen working directly with their client over video chat to discuss and solve problems. Working together strengthens the bond between the team but also allows new and possibly more creative ideas to flourish.

Celebrate Failure

We, as people, learn a lot from failure. A large part of being Agile is about failing fast and communicating those failures. If you successfully remove the negative effects of failing, you can learn a lot quicker. Making sure the team are comfortable enough to admit failure means the rate at which that knowledge is shared with others increases. In effect, this protects others from making the same mistakes.

Written by:

Jake Kimpton

Digital Engagement Strategist