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.
I agree with you: This is a cultural issue. Unfortunately, I also think that it has multiple root causes. Here are just a few that I can think of:
1. Developers don’t think that users may still run into a problem because the developers “know” that their design is wonderful so there’s no need to help users through the rough spots.
2. Developers and other types of engineers are tinkerers and problem solvers so they WANT to solve the problems they encounter — even if that ends up taking much, much more time than simply reading the manual. So, unfortunately, even if the information is available for these types, they’re just not going to bother using it or creating it.
3. Distrust. Knowledge owners may be fearful of putting what they know in the community commons if they’re worried that their employers will dump them once they’ve given up everything the know.
4. Most engineers think documentation is a waste of time. So, instead of creating good documentation for one another, they create crap documentation that doesn’t really help anyone, leading to more of “most engineers think documentation is a waste of time.” Rinse and repeat.
These are just the first things that popped into my head so I’m sure there are quite a few others. How to “fix” it? Well, talking about the potential time saved might be one way. Plus, there’s always the notion the if you share the answers to questions before their asked the second time, you’re saving yourself time and hassles in the long run (like preventative medicine!).
Interesting topic, thanks for sharing!