Retiring employee is reluctant to share knowledge

Question

I have joined a new company recently and am in a bit of a bad situation. The company wants me to develop with their ERP system among other projects. However, it is this one particular thing, where I am just stuck. The thing is, that ERP system is partly serviced by a small firm that develops and sells this system, and partly by an internal employee who is retiring next month.

Employee responsible for this system is blocking passing info. They just share meaningless info about historic anecdotes and only share knowledge that I already had to discover.

They have an undocumented code base, coding style of 70s (lose txt dump, all loops with GOTO), no documentation apart from a few inline comments.

Retiring employee won't document anything, even after multiple requests by me. They are leaving next month and releasing information in a salami tactics way.

On top of that, they gave code execution permission to employees who never coded in their life and don't know what they are doing when they copy paste the scripts.

Time is running out, my boss asks me how this particular project is going and I can only hint that I only recently discovered I'd need more permissions for the system (because retiring employee did not tell me).

Now to my question:

How do I approach my superiors about this without risking to look like an asshole / being fired for badmouthing. Remember, I am still on probation and will be for another 3 months.

Answer 1

1. Why would you "hint" to your boss about the situation instead of being completely honest with them about what's blocking your progress? Be honest and direct. Explain to your boss that you've been unable to make progress due to this other employee blocking your efforts to gain knowledge about this system. This isn't your battle to fight, so don't fight it.

2. Why would you look like an asshole for bringing this to the attention of your boss? Bringing a problem to the attention of management, even if it's a problem due to another employee, isn't being an asshole, it's being a responsible employee.

3. You can bring this to the attention of your boss without bad mouthing the other employee. Just speak to the problem. You don't need to put any negative spin on it.

4. If your boss has told you to go to the other employee, and if you've done that, and if you still haven't received the information you need, then you need to go back to your boss and tell them. You can't force the other employee to share the information and if they continue to refuse to then this is a problem for management to solve, not for you to solve. If your boss won't take responsibility for this then they're shirking their responsibilities as a manager.

Answer 2

I know you're still on probation now, but the more you wait before sounding the alarm, the worse it's going to end up for you. I pretty much guarantee it.

With that said, when approaching your boss with a problem, you should also have a set of potential solutions you can propose as well. If you don't have good solutions to propose, then your boss may try to come up with their own solution(s) on the spot and their solution(s) will either be incomplete or totally unrealistic.

So ask yourself, what could possibly work in a case like this? The guy is retiring. Your boss has little leverage over him. Can you start pair programming with him? If you're not in the same room, can you move your desk closer to him? If he likes chocolate, can you buy him a box of chocolate? If he likes sports, can you learn about sports so you have a common interest to chit-chat about? Or if the rest of your workload is too high, can you ask your boss to reduce it for a couple of months until this transition is complete?

Obviously, my own ideas are half-baked, but you get the idea. You need to brainstorm and think through a number of potential solutions yourself first.

And if there is any bad news to be delivered, it needs to be delivered now, not later. If you wait for things to get out of hand before you tell your boss what happened, your boss won't ever trust you again.

Additionally to that, they gave code execution permission to employees who never coded in their life and don't know what they are doing when they copy paste the scripts.

Interesting. Are those scripts under version control? If nothing is under version control, that's the first thing I would do. I would put everything under version control. What about tests? Could those scripts benefit from better automated testing? Or from being wired up to some monitoring software like Nagios?

Also, do not assume malicious intent. That person may just have a better relationship with those other people he gave execution access to. Or perhaps, he didn't want to be bothered, and simply gave it to them because it was the most expeditious thing to do.

Pair programming is the first thing I asked for. I wanted to make a meeting where they show me how to just simply go about designing and programming a simple query for this ERP system. However, the second meeting they said they were not prepared and gave excuses that this is not doable and everything is well documented.

This is very serious. Raise the alarm! Ask your manager to do pair programming with the two of you.

But prepare your manager in advance, if this guy comes up with the same excuses and says that everything is well documented, have your manager ask you to take over his keyboard and test you on the spot while the other guy is watching.

Tell your manager that he can blame you for being incompetent. In other words, tell your manager to be as hard on you as possible in front of this other guy, since he can't really apply pressure on him directly.

Then have your manager come back the next day and do the same thing again. Even if the guy promises to help you, he's probably not going to do it consistently. That's why your manager needs to make the commitment to follow up and do some pair programming with the two of you once a day or once every two days for the next 30 days.

In other words, you need to hash out a plan for your manager, and think things through carefully, just like if you were playing a chess game 6 moves in advance. Think things through, take some notes, and make sure your manager is fully prepared before he even tries to address this situation.

As for version control: The scripts are stored as .txt on hdd and copy pasted into a shell of the ERP program for execution. There is no version control, no tests not anything modern software development would do.

Are there regular backups? If there are no backups, make your very backup at the very least, put it somewhere else, and label your zipped folder with backup_year_mm_dd

And come up with a longterm plan to progressively modernize the rest of these issues.

Answer 3

The tone of your question seems to blame the retiring employee. "Salami tactics." "Blocking." "Meaningless history." Have you considered that the legacy system might have been a millstone around the neck of the other employee who is glad to be finally rid of this junk, and who got lots of information on other systems to pass on before retirement? You do this ERP among other things. What is the colleague doing among other things?

I know about situations where the management decided to run a legacy system with minimum maintenance until the replacement was ready. Which got postponed again and again. Staff got reassigned, staff left, and then someone is being held responsible for the legacy system who has the least tenuous connection to it. Recreating documentation in a case like this can take man-years, and those man-years are not available any more. Have they ever been made available?

What I'm trying to say is find out from your manager, and the retiree's manager, what the priority of this system is. Only if it is top priority for both of you things might work out as you seem to expect. If it is top priority for you but not the retiree, someone higher up has to resolve this.

And if it is not top priority, that decision has outcomes which your managers should know. It isn't your decision to make.

Answer 4

Just tell your manager you don't have the relevant documentation and the system is out of date in terms of protocols etc, so will be difficult to work with without proper documentation. Go in to a bit of detail, not too much unless asked to clarify.

This is what gets things moving. When their system is called in to question they will soon jump to prove it's up to scratch and bend over backwards to make sure you have everything you need. The alternative is they might lose the client. Don't worry about the old guy too much, he's almost irrelevant, he has no incentive to do anything for you.

Answer 5

This is classic S.E.P. Kick it up the tree as quickly as you can. Time is of the essence & you can't achieve anything.

Realistically (and, again, this is not your problem), if the company wants this done, the quickest and cheapest way is probably to rehire him immediately as a consultant (this may even be what he is angling for).

In defence work, if I had an <x> for every time I have seen this happen, then I would have a very large heap of <x>.

Answer 6

I heard a story about this from an intern who got the assignment to add a feature to the program a business was using. The program was build and maintained by one guy who was also about to retire. The guy refused to work with the intern making things very difficult. In the end the intern, boss and university supervisor talked with the guy. The guy just wanted some extra money before retiring and after getting said money he was very co-operative.

Answer 7

Welcome to the real world of software development.

• Your real task is very different.
• Make your boss understand your real task.
• Your predecessor is your friend.

You were thrown into the cold water of reality of software development.

In academic contexts, you always start development at the first step of development.
In practical software development, you normally start after others have worked on the first steps, and you base on their result.

In your situation, you expect to do that by finding out what you need to know, and start to work from that, building on it, maintaining it or working with it.

In many if not most real world cases, this is just not possible. The information that you need to know does not exist in a form that could be written down.

People who were able to work with the system in some way, like maintaining it or continuing development, did that based on their experience with the system to some degree. They know how it is structured, how it works and how to use it. They learned it from others, from developing parts themselves, and from actual experience.

This is hard to impossible to write down.
There are parts that can be written down of course, procedures of installing it in a local system, starting it, shutting it down, find message logs etc.

You see your task as to pick up development where your predecessor left it. And that may even be how your job is described and what is actually expected from you.

But this is not possible.

You need to understand the existing system first, and that is usually hard. And it may be a much larger task than the original task of "Add feature X".

You need to explain it to your boss. He has to understand that "Add feature X" needs to be replaced by "Understand system", "Add feature X".

An important aspect is that you should not see your predecessor as an adversary. He cooperates with you, he is your friend, he has the same goal: The success of the company. You cooperate with him.

If he does not give you a certain information, or does not give you a meaningful answer to questions like "How does this part work", or "Why is this the way it is" it is because he can not. He can not give you the information you need.

So, you have some basic information about the system, but you need much more. You just can not get that information in a straight forward way. If that means that you can not solve your task: Relax, it's normal. Large part of your job is to handle this kind of problems, it would be unusual that you could just solve tasks that are given to you in a straight forward way.And do not be surprised if you need skills that you did not learn as part of your education. You will get used to it - it is somewhat stressful in the beginning, but in part a question of perspective.

So:

• Accept that software development in the real world is often messy and frustrating.
• Explain to your boss that there is an very significant task before you can continue the work.
• Do not forget that your predecessor is cooperating with you, and you cooperate with him. To do this, even if he is grumpy, is part of your work.

Answer 8

Turn information into documentation, and the "interviews" into collaborative steps of a structured process. The end result is the delivery of the ERP documentation, and providing the information you need is part of fulfilling tasks in the project.

With this framing you will be able to show progress or lack thereof, measure the time it's taking the employee to fulfil those tasks, and, most importantly, create a paper trail if critical information is not being shared by the employee before retirement or termination.

Answer 9

Could I suggest you make a questionnaire that is listing main components of the system.

Like:
Permissions
Apis
Databases
Functions
Stakeholders
...

Then partially fill it in with the stuff you have discovered already, CC your manager, and sent it to the guy asking him to fill in the gaps.

Be as detailed as you can about stuff you don't know, this way if there is info missing higherups will see that you asked and that info wasn't provided, or provided incomplete, false, etc.

Then if he comes back with missing info resend back with extra questions.

Answer 10

There's a lot of stuff in the other answers. They all point to "going to the boss" and that's partially correct. @joequerty's answer basically says "go to your boss" in several different ways. Of course you have to communicate what is going on to your boss, and yes, that is risky for you but not as risky as letting this slide until the retiree is gone and you're left "holding the bag".

The problem with most of the answers, however, is that "the boss" won't necessarily be able to do anything. The guy is retiring presumably after a long career. The only leverage available is perhaps some kind of cut-off of his exit package (if there even is one) for failing to cooperate. There's probably nothing for him to lose and it seems like the individual could be disgruntled or burned out. If you've tried developing rapport and communicating with him and tried leveraging management-- there's not much more you can do with this person! Write him off.

The other problem with some of the answers is that they assume this is a mere "hand-off" requiring some hours of very structured "knowledge transfer". It's not. This is an ERP system. It's guaranteed to be an ugly bloated piece of enterprise software that, figuratively speaking, has many layers of duct-tape that were wrapped around it in haste under pressure from bean-counters in both your company and from the ERP vendor. These systems always have to adapt in ad-hoc ways to unforeseen and ever-changing business requirements. It takes time to get through that history and understand why things are the way they are. There are no shortcuts, you'll never get a phone-book-sized knowledge dump. The best you can hope for is enough fluency to be able to research the system and come up with solutions after a lot of effort.

Here are some other things you can do:

• Since this is an ERP system with a vendor behind it, you should be able to make contact with the vendor and arrange for onboarding support. It will cost money, but that's OK if it helps you get to success. ERP's have their tentacles in every part of the company and they're vital to operations. As much as the people with the purse-strings may feign economy, they will gladly to shovel money towards the ERP vendor to keep things going smoothly. Your engagement with the vendor will likely last for a significant amount of time, so be sure to take care of the relationship.

• On your company's side of things, there are other people you'll want to get to know: the power users of the system. They are the people that will help you get oriented when things aren't going right. If you know all of them and develop relationships with the right ones, they're invaluable to making sure everything is running properly. They are your customers and that should be taken very seriously. These are likely the folks who have been given "code execution" permission. Find out what their workflow is. They know what they're doing domain-wise (better than you ever will) and have been given special permissions because they're trusted. Learn to trust them too! And learn as much as you can from them. It doesn't matter if they've never coded anything-- you have bigger problems now.

Answer 11

Assuming you had a talk with this employee regarding this issue and the employee basically you are certain you cannot have any more collaboration from them...

Then the next step is having a written record of your interactions with them.

Start writing emails to this employee and always CC your bosses. If the employee replies without the CC, reply again adding the CC of your boss (I often just reply writing simply "+ ), citing the old email so that your bosses have a complete history of your communications with them.

Whenever you speak with them send a summary email about what you talked about and any pending action point on both parts and keep your boss CC'ed at all times. If the employee does not fully satisfy your requests send an email, maybe attach what they provided and explain what is lacking etc.

If your boss tells you that you are annoying them tell them this the CC is needed because the other employee wasn't collaborating productively without it and you need a clear written record of interactions in case things go sour.

---

Be aware that this employee may really don't give an F about anything given their situation. They might be trying to delay the knowledge transfer to after they retire so that they can force your boss to hire them as consultant at 5 times the pay grade... if that's the case it will not be possible to fulfill your job and there is nothing you can do to change this and this is why it is so important that you document all your interactions notifying your boss, so that they can understand where the blame lies.

Answer 12

You need to book a full day for a proper system handover where you talk to each other, mailing back an forth just isn't working here.

If you can't get the information you need, ask your boss for some consultant hours from the company that developed the system. It'll be way cheaper than having you try to figure everything out on your own.