Dealing with Automation Knowledge Loss

How do "good" companies deal with employee turnover in an extremely skilled position, such as controls engineer/process engineer/chief technician/etc.

When I left my last job, I spent my last month there teaching people everything I could think of. I showed how to connect to all the PLCs, what software was used for everything, how the robot integration worked.

I made very short papers of the processes I was responsible for consisting of contacts, previous failures and fixes including specific part numbers, and processing knowledge which I know nobody else was aware of. I contacted key vendors to let them know that I was leaving, and gave the contact information of my replacement.

I consider all the above part of being a professional, and wish I could have had more time with my replacement. But none of this was required by my employer.

When I started my new job, there was nothing transferred from my predecessor because he had already left 3 weeks prior. My new company did not tell me this - they told me I was starting in a brand new position, and my predecessor was actually supposed to be my employee.

I have spent about 4 months learning things that could have been transferred with 3 days or less of personal interaction and a few word docs.

So how "should" things like this happen? What have you seen that works well?

Muffler Bearing said:

How do "good" companies deal with employee turnover in an extremely skilled position, such as controls engineer/process engineer/chief technician/etc.

When I left my last job, I spent my last month there teaching people everything I could think of. I showed how to connect to all the PLCs, what software was used for everything, how the robot integration worked.

I made very short papers of the processes I was responsible for consisting of contacts, previous failures and fixes including specific part numbers, and processing knowledge which I know nobody else was aware of. I contacted key vendors to let them know that I was leaving, and gave the contact information of my replacement.

I consider all the above part of being a professional, and wish I could have had more time with my replacement. But none of this was required by my employer.

When I started my new job, there was nothing transferred from my predecessor because he had already left 3 weeks prior. My new company did not tell me this - they told me I was starting in a brand new position, and my predecessor was actually supposed to be my employee.

I have spent about 4 months learning things that could have been transferred with 3 days or less of personal interaction and a few word docs.

So how "should" things like this happen? What have you seen that works well?

Click to expand...

.
i have often heard of employers hiring people and giving them impossible problems to figure out without knowing key lost information because former employee left suddenly. then new employee gets fired and had trouble finding a job cause he got fired last job.
.
i would check any high paid job opening. often reason it is high paid is employer has unrealistic expectations and figures they can hire and fire people every week til they find the right person. beware the miracle worker job opening at starting pay of $30/hr
.
ask why former employee left and if they say we are always looking for good employees i would suspect something is fishy. remember if you get fired cause a new job did not work out it makes it even harder to find the next job

Muffler Bearing said:

How do "good" companies deal with employee turnover in an extremely skilled position, such as controls engineer/process engineer/chief technician/etc.

.......
I consider all the above part of being a professional, and wish I could have had more time with my replacement. But none of this was required by my employer.

.

Click to expand...

Not sure what constitutes a "good" company but bigger ones deal with it differently than mid-size ones.
Your last sentence quoted says it all.
Ones that have dealt with the pain demand lots of documentation up front when a system is built. Along with committee reviews of every step or piece of paper.
This cost money and time. Slows everything down. Leads to ton of rules about how things are done and stifles innovation to some extent.
Something that will be tossed in the trash in year is not a big worry, something that will run for 20-30+ years, maintenance is a problem.

There are tons of good/bad experiences and systems to avoid the pain in the software industry.
"here is 82,000 lines of undocumented code, we need you to keep it working and change this input/output a little bit".

It can be thought of as a "pay me now, or pay someone else later" problem. It's not that far from changing oil in your car.
But the urge to get something running and not spending the time and money on extra paperwork is huge.
One can write code, sketch out some wiring on a legal pad, have a system sing and dance at crazy speeds.
Documenting it so somebody else can walk in and work with or maintain it.....much longer time spent on the grunt work here.
This side is the not fun side, hence it often never gets done unless someone upstairs demands it.

I have walked into a shop that needs help with a special machine.
The original manufacture is gone, the PLC is dead, and they don't have even the original ladder or wiring prints.
Oh, this is not good, you are looking at a lot of money. They have $1000 to spend.
They don't understand and why should they? It ran last week, friggen just make it do this and that. Seems so totally easy from the users standpoint.
You just so wish could give them better news but you know what this black hole will eat up..

PLCs, computers took over from old style automation. Made it so easy to build systems .
Also so easy to build hard to understand systems.

So hey, you have a new job. Many strange undocumented things. Time will be lost.
Make some notes, documentation, charts, prints for the future kids while you strangle the workings out of the system. Don't make them lose this time.
Bob

I am not a big fan of ISO or QS9000 etc but I do remember writing many procedures when we got certified. Documentation on how I perform certain tasks and my job duties is very important. When I quit my last job I gave them an extra week to train my replacement on a unique project that I had been working on. I also gave them my phone number to call with any questions that came up. I believe the same as Bob who quoted your last sentence, "part of being a professional" says it all.

I retired 5 years ago. I just got hired as a contractor at my former employer to revive an old product. We had reams of documentation: technical reports, product specifications, testing methods, packaging methods, component manufacturing documents, machine configuration documents, process conditions, etc. All documented at the time they were instituted.

Fortunately, they hadn't had time to go back and purge obsolete files from their systems, and with enough digging, all this information is still available. It will make the project possible.

It's hard sometimes to take the necessary time to properly document things when deadlines loom, but skipping that is very false economy.

We did a project where all we had access to was a video of the machine running and snap shots of each page of the HMI along with a printout of undocumented code. The PLC battery had gone dead and someone shut the machine down during Christmas break. Efforts to get the machine running trashed the HMI and it took a couple of our guys 3 weeks of hard work to completely reverse engineer the code enough to get a new HMI configured, all tag names and settings figured out and the PLC upgraded and documented to where someone could come along after us and provide maintenance and have the ability to press spares into production. I think the bill was close to $40k.

motion guru said:

We did a project where all we had access to was a video of the machine running and snap shots of each page of the HMI along with a printout of undocumented code. The PLC battery had gone dead and someone shut the machine down during Christmas break. Efforts to get the machine running trashed the HMI and it took a couple of our guys 3 weeks of hard work to completely reverse engineer the code enough to get a new HMI configured, all tag names and settings figured out and the PLC upgraded and documented to where someone could come along after us and provide maintenance and have the ability to press spares into production. I think the bill was close to $40k.

Click to expand...

Then your customer got extremely lucky and should be thankful you had capacity. In my experience, most automation companies do not have that kind of capacity in their programming department. I have had several instances in my career where I have tried to hire programmers at any cost and none were available because the machine builder was already booked for a long horizon.

Muffler Bearing said:

Then your customer got extremely lucky and should be thankful you had capacity. In my experience, most automation companies do not have that kind of capacity in their programming department. I have had several instances in my career where I have tried to hire programmers at any cost and none were available because the machine builder was already booked for a long horizon.

Click to expand...

We try never to book that tight, always try to have a couple of guys on non critical projects so that we can cover if someone gets sick or they are pulled off a job for any reason. The job should never own the employee and it should never be at the mercy of the employee.

Other Brother said:

I am not a big fan of ISO or QS9000 etc but I do remember writing many procedures when we got certified. Documentation on how I perform certain tasks and my job duties is very important. When I quit my last job I gave them an extra week to train my replacement on a unique project that I had been working on. I also gave them my phone number to call with any questions that came up. I believe the same as Bob who quoted your last sentence, "part of being a professional" says it all.

Click to expand...

.
ISO certified company does not mean company has official procedures for everything. amazing amount of info is labeled reference material and not always sorted and stored for fast or easy finding. amazing amount of info old timers do not bother writing down as they just remember it. of course new person is at a total loss trying to guess non standard terms or slang which often can be interpreted 10 different ways
.
like finding a needle in a haystack looking for a certain reference material not properly labeled mixed in with a few 100,000 other files. then there is the hard copy manuals on equipment. you got error 146Z, good luck finding what that means if machine has over 3000 pages of manuals, assuming you are not missing the one manual that has the info.
.
i have seen tons of old manuals and paperwork dumped in the trash cause somebody thinks not needed and was doing a 5S cleaning. then find out absolutely no info found online and original manufacturer no longer has any info on 50 year old machines

DMF_TomB said:

.
ISO certified company does not mean company has official procedures for everything. amazing amount of info is labeled reference material and not always sorted and stored for fast or easy finding. amazing amount of info old timers do not bother writing down as they just remember it. of course new person is at a total loss trying to guess non standard terms or slang which often can be interpreted 10 different ways

Click to expand...

You make a very good point there.

It's amazing how almost every manufacturing process requires equipment to produce acceptable quality parts, but how little scrutiny is placed on the maintenance of equipment and associated documentation retention. I would figure it would be a cornerstone of quality - having a process robust enough and documented enough to be reset to a known good condition after repairs.

Muffler Bearing said:

You make a very good point there.

It's amazing how almost every manufacturing process requires equipment to produce acceptable quality parts, but how little scrutiny is placed on the maintenance of equipment and associated documentation retention. I would figure it would be a cornerstone of quality - having a process robust enough and documented enough to be reset to a known good condition after repairs.

Click to expand...

.
i was a construction field machinist 20 years and a maintenance machinist 12 years, i often had gigabytes of documents saved on 3 different storage devices including 4th copy on computer network. what i worried most about was old hard copies of manuals and stuff like maintenance work records, adjustments around people who want to 5S or throw out stuff they have no use for. we often had to hide stuff from the 5S police

CarbideBob said:

It can be thought of as a "pay me now, or pay someone else later" problem. It's not that far from changing oil in your car.
But the urge to get something running and not spending the time and money on extra paperwork is huge.
One can write code, sketch out some wiring on a legal pad, have a system sing and dance at crazy speeds.
Documenting it so somebody else can walk in and work with or maintain it.....much longer time spent on the grunt work here.
This side is the not fun side, hence it often never gets done unless someone upstairs demands it.

Click to expand...

Spot on... When creating new work systems/procedures, too often little thought is paid on problems down the road... And like you said, it's going to cost the company. Do they want to pay up front, or suffer & pay later on? The choice is theirs, but there's no way to avoid paying... It's much better off to go ahead and pay upfront. Chances are, if they can't afford to pay for the documentation upfront, they can't afford to pay for it later on either. (Weather it be the financial costs to recover a downed cell, or the lost production time, and so on...)

(Edit: Man, I could make this argument about much, much more than automation & documentation too... Basically, anytime there's an opportunity for one to "cheap out" - weather it be on new machinery, or a new employee, or whatever "it" may be - whenever there's the chance to cheap out, I believe it's always wise to stop and ask, "Is this really going to be the best/wise/smartest move? Am I really going to "save" now, or am I just delaying the "costs" until later on, when it's going to hurt much, much worse...)

Not that I'm very experienced - I'm actually a relative newbie to all this stuff, but I've seen many companies that don't care enough about documenting things, and cross-training employees to see it through - and they suffer for it eventually. (And not just in automation, but in many, many areas of the business...)

I'm one of the key members at my job now, and the rest of 2015 is looking rough. We are buried with new work to push out. We still have the day-to-day struggles to keep up with. I still have 2-weeks of vacation to take before January 1. (And I'm sorry, but I'm not giving up my days-off just because the company won't let me roll them over, no matter how much it's going to hurt them...)

But I digress... Anyway, Like Bob said, documenting, training, & cross-training isn't sexy, but it needs to be done... Me being a key member at work... - I could get sick and be off for a week, or two or more. I could get a better offer and leave. In either case, the company is to suffer, unless I try to make an effort to document and train others (which I try to do) AND the company allows time for me to do, and actually makes it a priority... (they don't...)

-----------------------------------------------------

Anyway, as to the original question - how should good companies deal with key-employee turnover? My gut reaction is that "good" companies don't deal with much turnover, because they satisfy their key-employee's to the point where they continue to happily serve the business. These key people stay with the business, and become fixtures of the institution, continuing to help the "good" company stay "good". (Or if they do leave the business, hopefully they go to a vendor or customer of the business and are still able to interact, & help serve the business even at their new role...) I guess the reality is that every business at some point however will lose a key-employee, so the question then becomes, "what then?"

In any case, I think you handled it about the best way possible. You gave ample notice, you made notes for those left behind. You even went so far as to notify vendors, etc... It would be silly to ask for anything more.

Best of luck at the new venture. You'll get it sorted out before too long.

any good company should have all job positions with a primary person and a secondary person in case of sickness and vacations.
.
if company management does not feel the need to have backup people trained in multiple job positions so they can back fill when one person is sick or on vacation or decides to retire thats just plain incompetence on management to manage a company
.
too often i see boss not wanting to waste money having a 2nd person learn from another person as thats 2 people doing one job. sooner or later thats trying to save money not training backup people will catch up to the boss. if boss has worker spend time making procedures on everything that helps. but normally you do work procedure at least once with the procedure writer before doing work procedure by just reading the procedure. either way that is spending on writing procedures and 2 people working together at least some of the time
.
worst thing is one expert person keeping private notes on stuff. he leaves and nobody exactly sure on most of what he was doing as former employee was keeping private records as a job security thing. if boss did not know that than it is the boss's fault

I gave my last job 3 weeks notice, stayed 2 weeks extra when they asked and despite being 8 months into the year when I left they stiffed me out of 100% of my year end bonus. So I am very happy to have taken so much knowledge with me that is costing them a fortune to re-aquire! For one of the tasks I did they still haven't found a replacement after 2 years. When you see drawings from them that are obviously copied from a different job with tons of wrong info you know there is no one doing what is required. Yes it is really poor management.

DMF_TomB said:

any good company should have all job positions with a primary person and a secondary person in case of sickness and vacations.
.
if company management does not feel the need to have backup people trained in multiple job positions so they can back fill when one person is sick or on vacation or decides to retire thats just plain incompetence on management to manage a company
.
too often i see boss not wanting to waste money having a 2nd person learn from another person as thats 2 people doing one job. sooner or later thats trying to save money not training backup people will catch up to the boss. if boss has worker spend time making procedures on everything that helps. but normally you do work procedure at least once with the procedure writer before doing work procedure by just reading the procedure. either way that is spending on writing procedures and 2 people working together at least some of the time
.
worst thing is one expert person keeping private notes on stuff. he leaves and nobody exactly sure on most of what he was doing as former employee was keeping private records as a job security thing. if boss did not know that than it is the boss's fault

Click to expand...

a

The challenge with this that I have seen where I work is that the code gets so deep, and one person winds up with his own little baby that they are the only one who really knows it. Then in our case there is an urgent rush by the customer who each day they don't have our machine is unable to ship a $7.5 million jet engine, they in turn are being pushed hard by their customer who can't ship a $100million aircraft!

At that point damn the documentation, damn teaching and or spooling up anyone new on it full speed ahead! The good thing thought that I have seen about all of this is that as the engineer who finally learns some of these mission critical skills in the company you become so damn valuable you really don't have to worry about job security.

I am lucky to right now have a great mentor who has been teaching me a ton about these custom machines we make. Without him we are left with several million worth of paper weights and the customer has a lot of aircraft that won't leave an assembly line. I have never seen a guy getting away with telling his boss to go F-off so many times but he understands that he holds more cards than the guys who own the company at this point.

I think transferred knowledge is greatly overrated.

Most people re-write any code they are given to maintain, so what it was previously is mostly irrelevant.

When I have a junior working on a software project, my standard joke is "Hurry up and finish it, so we can start re-writing it."

Code bases that get used a lot I find have been re-written many times, often 10 times or more.

Muffler Bearing said:

How do "good" companies deal with employee turnover in an extremely skilled position, such as controls engineer/process engineer/chief technician/etc.

When I left my last job, I spent my last month there teaching people everything I could think of. I showed how to connect to all the PLCs, what software was used for everything, how the robot integration worked.

I made very short papers of the processes I was responsible for consisting of contacts, previous failures and fixes including specific part numbers, and processing knowledge which I know nobody else was aware of. I contacted key vendors to let them know that I was leaving, and gave the contact information of my replacement.

I consider all the above part of being a professional, and wish I could have had more time with my replacement. But none of this was required by my employer.

When I started my new job, there was nothing transferred from my predecessor because he had already left 3 weeks prior. My new company did not tell me this - they told me I was starting in a brand new position, and my predecessor was actually supposed to be my employee.

I have spent about 4 months learning things that could have been transferred with 3 days or less of personal interaction and a few word docs.

So how "should" things like this happen? What have you seen that works well?

Click to expand...

use the comment function on all programs using terms everyone knows. if the operators and maintenance call it a pusher, label it as a pusher. make machine specific shopping guides, especially if the company makes up it's own spare part numbers. make block diagrams, trying to troubleshoot an automated machine with a wiring diagram is nuts.
try to make all machine programs similar. we had american, chinese, german, and spanish machines. that is four completely different styles of programming, not to mention comments as they never bothered to translate the spanish.
when i retired, i gave all my notes and stuff to folks on shift. stuff i used everyday. more than likely it was in the round file before my car left the property.
scott

jscpm said:

I think transferred knowledge is greatly overrated.

Most people re-write any code they are given to maintain, so what it was previously is mostly irrelevant.

When I have a junior working on a software project, my standard joke is "Hurry up and finish it, so we can start re-writing it."

Code bases that get used a lot I find have been re-written many times, often 10 times or more.

Click to expand...

Your world may be different from mine, but at first glance this sounds awfully wasteful at the very least. My context is a product that consists of around a million lines of code and growing ~35% per year, worked on by about a dozen engineers at the moment.

In my environment, junior devs building virgin product are given regular feedback from more senior members from the beginning so that their final version (what goes into production) hopefully doesn't need to be rewritten for a while unless the requirements change.

Likewise, no one sets off on a wholesale rewrite of some module without a justification. Not only do changes cost time, they risk introducing new, unknown bugs. When developers see something that bothers them they can flag it, and we allocate about 20% of available developer-hours for discretionary maintenance, which the engineering team gets to use to address their concerns without needing to convince business management it's important. Obviously this requires building trust that they will use this time wisely. In my experience this has led to a stronger product as well as happier engineers, which means less knowledge transfer needed when they don't quit

There is one big exception to this, which is the principle that you should start by building a prototype, and then if you decide it's a good idea, to immediate start over from scratch to build the production version. I do agree with this and have used it in my company, though at times it hurts.

My case is different in that I'm maintaining and extending a single large codebase/deployment for a very long period (13 years so far) versus lots of small somewhat standalone deployments. Still, I believe there are many practices that make sense at any scale. Good software engineering practices have a very large ROI in terms of saving developers' time and increasing quality, and they also serve to attract good professional developers and repel the code cowboys who talk a good game but build buggy, unmaintainable pieces of $#@!.

I suspect the employer just tells all the sales reps to quote an entire rework, with support, for the latest and greatest.


I once heard that Honeywell was gunning for security surveillance contracts, went to some large entity (the post office?) and told them they'd replace all the Pelco with Honeywell.

At a price the customer couldn't refuse.