Where IT organisations have heterogeneous technical environments it is not always possible to know what your colleagues are working on and which challenges they are facing. This blog post will discuss various ways to share information in an IT organisation.
How many people are working at your company? What about just your office? How many of them are working on different projects? How many people are working on your project? Are they all working with on the same component with you, or is there a split between, for instance, a backend and a front-end?
Having such heterogeneous environment with a magnitude of technologies and products, it is not always possible to know what your colleagues are working on and which challenges they are facing.
It's clear that it is helpful to facilitate knowledge sharing between people in your organisation. For example, there are two product teams, each has a few members working on the server side. If they happen to use the same technology stack, say, Java and Spring, then they can exchange lots of experience and war stories. Should they use different stacks, say Play! Framework vs Spray, they can come up with important evaluation and choose the best tool for the job. Equally, if you are working on the backend, it can be very advantageous to learn about front-end development, as it can teach you new approaches and paradigms. Plus, you never know when you might step into the realm of front-end development.
So, how do you ensure that you and your workmates have a chance to find out about all the cool stuff you are building? Of course, every project might have its own internal wiki where you describe its architecture, technology stack, coding guidelines etc. Although it can provide very detailed reference information, it can be a very dry read. Plus, it is easy to get this kind of information lost in the myriad of pages and API specifications.
This also appears to be a pull-like approach, where interested parties have to go to a portal and look for information there. In other words, we expect people to be already interested in something, as opposed to get them engaged in finding out about your project.
They provide an opportunity to freely discuss technical challenges and copy-n-paste code snippets without worrying that you share proprietary code outside your organisation. They can also lead to discussion which can result in setting company’s coding guidelines and standards. However, this approach is limited to asking specific or slightly open-ended questions. And no-one would use it present their favourite framework. Our experience also suggests that it might be difficult to get everyone engaged in an internal questions portal.
A better approach would be something more engaging and interactive. What we have found to work at NCR CoDE is a weekly round of presentations. We call it "Dips 'n' Discussions" (formerly "Code & Cake").
Every Friday at 1 o’clock we gather at the breakout area for an hour and listen to presentations from other team members. Everyone in the company can talk about their projects, exciting new technologies, and interesting techniques for solving common problems. Sometimes, we also have controversial discussions - such as how many return statements a method can have and whether checked exceptions are a virtue or vice.
In our experience, this approach appears to be the most engaging. Even if some people don’t present very often, they still take part in lively discussions and ask presenters lots of questions.
While contents of each weekly sessions varies from talking about functional programming to writing lightweight RESTful services in Java, we have recently introduced a permanent part. Now, a member from each team must give a brief summary of their week. Such a summary normally includes both high level information – ‘we have shipped feature XYZ’ and something more technical ‘We struggle with framework ABC’. If someone wants more details, they can always speak to a member of the team after a meeting.
Of course, someone has to do a little bit of coordination work to enable us to run the weekly presentations. In our organisation, that person is me. However, I find it to be a worthwhile task. I just need to be very observant about what my colleagues are doing on daily basis. And when I hear about something that might be of interest for a wider audience, I always ask them to present.