Helping a colleague take constructive criticism

Question

I work with a colleague who is a very talented network engineer. He is in his late 40s or early 50s, and is probably the most experienced person on our team in his area.

His work is always well-done and timely, and he is always willing to help others and even other teams with design or troubleshooting. The problem arises in culture. Our environment is in a government contractor in the US, and as such everything is tightly regulated. Our change management process is much more restrictive than I have found at any of my previous positions.

My colleague owned his own consulting firm before this, and basically ran several small enterprise networks (full-stack) on his own, where any change he made was done quickly with little or no documentation. Here, we have several forms to go through, it often winds up that a ~5 minute configuration change can take an hour or more to submit, let alone getting approved.

My colleague often becomes frustrated by this, and does a sloppy job writing change requests, or ignores doing it all together. This creates a backlog for the rest of the team, and confusion in that we are never sure which version is the most up-to-date. On many occasions, the backlog is so bad others or myself have stepped in to write his change requests for him, further slowing us down.

He has been approached about this by two mangers now, but he perceives every criticism as an attack on him personally, to the point he was shouting about being the "most experienced in the company" in a meeting. It's obvious to me the managers are unwilling to further provoke him, and he feels he is over-worked as-is, and sees the process as a hindrance of which he need not take heed.

My question is: is there a way I can approach him or others to make it known to him that his behavior is actually slowing the group down, and offer to help him learn to get through the process more quickly so we can all work faster? I know this is not necessarily my place, but he seems to get especially defensive around managers, in thinking maybe my more even status as a colleague will be more to his liking

TL;DR: my colleague is not listening to the advice or criticism of management, and it is hurting the team. Is there a way I can help my interacting with him directly or with others?

Edit: I know this isn't "in my job description", but I'm not looking at this as any different from mentoring an intern. I also see this as a learning opportunity for myself and by no means claim infallibility in this situation. The process is young and a pain for everyone, but only one person seems to be taking notable exception.

Answer 1

Perhaps the sandwich technique.

Give some praise, before making the criticism then a little more praise

But with the criticism - an explanation and get the person to understand why and get that person on board.

In the future when they have not demonstrated the same problem, give them praise.

Also note - you could be wrong as well.

Answer 2

It is unlikely you can do anything to help him if he does not want to be helped. You're more likely to be seen as a further annoyance in that case.

You can ask if he thinks a mentor/"translator" might be helpful and offer to play that role or help him find someone he would be comfortable working with. But if he says no, having management put him on notice may be the best thing for the company, and maybe even for him.

Answer 3

I am not sure what you can do for your colleague.

The problem starts with your colleague failing to recognize that he is working in a different environment where forms have to be filled and be approved before any action can be taken. I don't see him as having made any effort to adapt to this environment say by filling out the forms properly (*).

Your colleague repeatedly screams that he is the most experienced individual on the team. Let's say he is, but he is not the most effective member of the team because you are all cleaning up after his haphazard compliance with procedure - at the expense of your own time and your own work. In other words, your colleague is functioning less than optimally as a member of the team.

I am afraid that until he chooses to take a more positive, accepting and adaptive attitude about the regulated environment that he is working in, he will continue to be a management issue to your team and a headache to your management, as you all pitch in to make up for his unwillingness and sometimes outright refusal to adapt to his environment. Which raises the question as to why he chooses to work in this environment in the first place, knowing that this environment is regulated. His temper tantrums and any complaints about the perceived inefficiency won't make this environment change let alone go away. This environment is here to stay and it is a given, whether he likes it or not. Just because he doesn't like something is no reason to make everyone around him suffer on account of his dislike - he is not being fair to the team. Your colleague feels overworked? Overworked doing what? He has to cut back on whatever the number of issues he is working on and start documenting his work, because compliance is no less important to the client and the team than resolution. One more time: compliance is not a mere inconvenience and imposition, it is a REQUIREMENT.

Your colleague's behavior is an issue for your managers to deal with. They have the authority to lay down what he has to do and to take various disciplinary steps to compel him to comply. I'd say at this point that you and your team must escalate to your management and let your management deal with him. If he can't take criticism in general and criticism from his managers in particular, it's his problem. If he doesn't like criticism, then he won't have to take any criticism if he chooses to comply. Right?

(*) I am right now working on behalf of my firm with a client who is a medical provider. Needless to say, the medical provider industry is heavily regulated and any proposed change in our IT posture must be documented and approved before implementation action can be scheduled. I view the approval process as a cost of doing business and I don't try to dodge the inconveniences. Unlike your colleague, none of us on the IT team seems suffering from any wear and tear. Pain shared is half the pain.

Answer 4

I was in that situation, I didn't like it, so instead of being annoyed at having to fill out a bunch of worthless stupid forms, I just made a checklist that went through the complete process, and when I needed to do this, I went through the checklist, and because all the steps were nicely documented it took me five minutes, no sweat.

Something like that is what your colleague needs to do. He needs to realise that with something like this, there is no point in fighting the system (because that just creates more useless stupid work), but figure out how to do it as smoothly and efficiently as possible.

And he needs to realise that at some point if you refuses to do these things, yes, the criticism will become personal, and then he sets himself up for trouble. There is also the psychological problem that by fighting the process and hating it, you will be much less efficient at doing it, which makes it much more and much more unpleasant work.

Like I said, I had a checklist for the process to click about a dozen buttons, type text into half a dozen forms, and it was done in no time. At each of the dozen buttons and forms I could have stopped for five minutes swearing and being annoyed at the process, and it would have taking me an hour and completely demotivated me for the day.

Answer 5

What I will be saying comes from direct job experience as someone who works in the IT Security profession as an IT Auditor. To help your colleague understand the reasoning behind such procedures, it is helpful for you to help him to first understand the intent behind proper change management in the SDLC. Benefits of proper change management are numerous, but likely among the most relevant to your colleague is that the procedures protect him during his work.

If he were to make a mistake that broke something, having followed SDLC change management procedures means the change that broke functionality is at least documented and easier to detect, and hence revert from. The previous sentence assumes that the change management procedures are robust to include requirements for documentation of all changes, and a tested fallback plan in case the change fails in production environment.

We are never sure which version is the most up-to-date.

This is problematic. As an example to illustrate what can go wrong and how it unnecessarily increases the risk to your company, consider the following hypothetical scenario

1. He creates sloppy change request without clarity on whether this is the final version to be implemented in production

2. As a result of his carelessness, you implement the change incorrectly, such as opening the wrong port on the firewall.

3. Sensitive company data leaks through the open port, assuming loss is undetected by other forms of protective technology (ex: DLP)

4. The open port is used by an external hacker to gain entry into your company's network. Once a hacker has gained unauthorized entry, there are countless ways he / she can make your life miserable: Backdoors, logic bombs, DOS/DDOS are just a few such methods.

If the change is documented, its easier for him to revert his actions and also simplifies detection through peer review of completed change requests, assuming this requirement exists or you have a more fundamental problem to worry about

@Agentroadkill You should approach your line manager and illustrate using an example such as the above, what can go wrong, and how such mistakes cost the firm money. True, the requirement for documentation can be burdensome, and slow down your team's work, which is a legitimate concern, but the impact from a poorly implemented, due to a poorly documented, change request crashing / destabilizing the system is many times more severe.

Answer 6

Don't put too much effort in trying to change this.

It's unlikely he will change. He clearly thinks he knows better (when in reality, he doesn't).

One thing I would try is this:

You should have a timer. Every time he puts a sloppy CR in/you have to do it/you are confused about versions because of him, start the timer. Stop it when you're back on track. Get your team to do this for a week/month/sprint or another suitable period of time. Log the total, write it in big text on a whiteboard and tell him we are losing X hours a week because of you.

I'm going to assume this doesn't work though, as if management have mentioned it to him and he hasn't changed his behaviour, then it's unlikely you'll manage it.

After this you need to still log the time lost. But this is for your protection.

Eventually this situation is going to lead to a versioning mistake or something which could lead to a deployment issue and that will have someone's name next to it. It could be your name. This guy, through laziness/stubborness could land you right in it. He is more of a hindrance than a help.