In the New Year we are instituting a No Talking rule in my office. If anyone has a question, they have to write it down and pass it to a colleague who will then write down their response. This should cut down on the amount of chatter and conversation that, obviously, is having a huge impact on productivity.

There will be no more talking in our office, the conversations will stop!

I am, of course, joking.

What I’m actually pondering is how to extract the casual knowledge that currently exists in the heads of the development team. The little snippets of information that take seconds to utter when prompted by a nearby colleague, but which remain out of the grasp of the product documentation and thus are invisible to anyone not sitting in our office. You know the type of thing:

“Hmmmm, hey Alice, my build failed with error 4932, any idea how to fix it?”

“Ohh sure Lewis, just set property 73 to false and it should run just fine.”

The above names have been changed to protect the innocent.

This kind of conversation happens everyday, across the breadth and depth of our (very large) product and, as we have development teams around the globe, it is a real problem and one we need to solve.

The No Talking rule might sound ridiculous but it may be one way to help people realise just how much information they impart to each other, face to face, that isn’t captured anywhere else. That’s the theory at least.

I work with smart people, they are friendly, helpful and professional. They go the extra mile and genuinely want to do a good job. I’m not just saying this but they are one of the best groups of people I’ve worked with, but that doesn’t change the fact that they way they work is flawed.

Ultimately the challenge will be to change the culture, just enough, to be more info-centric. For example, if the software build system breaks, the developers fix it, yet it seems obvious to me that our information channels are broken and my perception is that they don’t care enough to want to fix it.

How do I get them to invest in this idea? Talking to my girlfriend she rightly suggested that one method that might work would be to pitch it as a time-saver. If every developer was to count the number of questions she was asked over the course of a week, I think they’d all be surprised at the number. Whilst not all of the questions would be something that needs documented, I’d warrant a fair number would be. As I said to a during a discussion with a couple of team leads last week, I’d much rather my team was inundated and overrun with requests to add information to the product documentation, at least that way we’d know the size of the problem.

So maybe I will suggest a no talking day, or maybe there is another mechanism out there that the developers will buy into. Maybe the first step should be to ask them what they think, are they even aware this problem exists (I’m sure they are, it’s just not the most pressing problem in their day to day list).

Regardless, one way or another, it’s something we need to fix, preferably without stopping the conversations.