Something I’ve noticed around here, as I listen to somebody talking to a new hire, is the way we seem to be doing training, and discussions of our application. When I get asked what I do, or what my1 company does, I talk about all the good stuff, and how we impact the companies we are deployed at.
However, I’ve noticed a shift when it comes to when people talk to new hires (or even prospective new hires) about stuff. I’ve noticed it starts off with a few good things, but as soon as it gets into an area of greyness, all the bad things about the system come flooding out. For example, when training a new helpdesk technician, the primary goal of the training should be an understanding of the system, how to perform all the basic operations, get data entered, etc. Once all these are covered, they should be given the chance to explore, and play about a bit, then given some further details into common issues we experience. The problem is, the training ususually starts on the login screen, a brief mention of the next page, and how to start entering data, and then the first common issue is mentioned, and then that’s where the training stops. The next few hours is spent discussing every little bit wrong with the system, and usually ends up in a bad comment, or two about other departments{^2].
This isn’t the only place this happens either. One of our other departments hired a new member of staff, and the similar kind of discussion came up. It started with a description of what the new person would be doing in the department, and a little background on the department, and application, then trailed off on a knee-jurk solution to a “maybe” problem, that has come up before, and went nowhere. This then spinned into a discussion about how we have certain issues on other parts of the application that make the departments job a little more complex.
Where I work, they do regular corporate “team building” excercises (which large corporation doesn’t?). We do one through a company called Senn-Delaney. One of the items that they try to nail home2 is the importance of not “bad-mouthing” (edit: and prejudging) other departments. It generally has a bad result. This is a perfect example of what happens, as it ends up resulting in department a, not liking department b, without understanding anything on their side.
So now, we have new support guys, have a pre-programmed notion that our development department sucks. Now this is a pretty common conception at any company, mostly because the development guys usually don’t have to deal with the customers complaining about stuff, and their code usually works as originally designed, but not what the customer entirely wanted3. But I’m a firm believer in letting people uncover stuff on their own, especially when they are in the position of customer support, and should have some ability to explore problems themselves.