In yesterday’s company newsletter, I mentioned the fact that we sometimes create superstitions about programming (or as we sometimes like to call it, “configuring”) our laboratory informatics systems that are based on fear and avoidance rather than knowledge and proper practices. How do we get past this? (The link to subscribe to GeoMetrick Enteprises’ free newsletter: http://www.geometrick.com/newsltr_signup.htm)
My Own Background
Back when I was first out of college from my undergraduate degree (as I didn’t get my graduate degree until I’d been out of college for some number of years), I didn’t know much about programming software, despite the fact that my early jobs ended up revolving entirely around programming scientific applications and programming as part of my LIMS Administrator position. Fortunately, I was assigned to a senior analyst who reviewed everything I did, at first, and answered questions along the way. These days, we’d call him a “mentor” but I’m happier with the knowledge that I was “assigned” to him. We had specific roles and activities.
The reason I push against the modern idea of a “mentor” is that, too often, there is no structure to it. Too often, it’s just a title. Too often, the idea is that the senior person will help the junior person if they need it and does not take an active role in building the junior person’s skills. It’s usually almost 100% passive, meaning that there is no real guidance. This is especially the case among consultants. The reason that so many consulting companies hire experienced people is that they don’t have the interest in giving the consultants any real training. This is why so many services groups from software vendors and services companies poach customers who have been on the projects – because they’re now trained and experienced. It’s a lot easier to do this than develop people, themselves.
In my case, as two employees who sat in cubicles across from each other, my senior analyst could easily watch over what I did. As an employee, and a junior one at that, my role was made clear – that when the person I was assigned to told me to change something, I was expected to do it over, if required. Luckily, the person I was assigned to would explain things, too. I learned because he was good at explaining why what I had done wasn’t quite right.
Sometimes, customers don’t believe someone like myself can really be that much better than the other resources they’re being offered. The reality is that there is a huge difference in the way people are trained in their early career and, for those that don’t get the proper guidance from the beginning, they probably won’t ever get that chance later in their career and will be left to struggle along forever, basically. Sadly, others will sneer at them as a resource that isn’t really very good, but the sad truth is that no-one ever took the time to make them any good or to help them build their skills.
It has always been the case that junior people who work in services groups are sent out to customers to learn from the customer, regardless how much the software vendor or services group is charging for them. Customers are sometimes informed that the person is junior but that they’ll get a “lot of support from the office and community.” However, a junior person sent to a project on their own is still learning on the customer’s dime. I hear customers accept this situation but, once the person comes to the project, the customer will complain bitterly about the situation. They feel they were misled that the person would work out fine because every else in the world would be on-line to help them.
Reality check: Unless you have senior person actually working on your project as the primary, day-to-day person, they can’t really be guiding that junior person on a day-to-day basis
But even when customers hire someone, when they hire a junior person and expect the person to learn on-the-job and with no real guidance, the situation is the same. Some customers will have a senior consultant around for awhile to make sure there is a knowledge transfer going on to build that junior person up-to-speed. But that is not always the case. Sometimes, customers don’t have or want to spend the money to build a resource to be a good one.
There are too many people that get shuffled around the laboratory informatics industry from project-to-project because no-one wants to give them the proper training and guidance. Everyone wants to either get a senior person or to get someone they think will just suddenly absorb the material and be up-to-speed as if they were an experienced person. It doesn’t work that way.
For customers that feel they’ve been taken advantage of by those that con them into taking a junior resource to do a project all alone, I can feel only some amount of sympathy for you. Stop to consider that what sounds too good to be true is, well, too good to be true.