Employee doesn't listen to my demands

Question

So I have a developer working on dockerizing one of our application for production. The thing is that it's already done for development, and he has been taking a lot of time doing it. He also is doing a lot of stuffs that are not necessary, and I had to intervene, because he doesn't seem to know what he's doing (like he wants to put several sites on the same docker container, which would create a single point of failure for multiple sites). I told him to share his progress by pushing the git branch, which he did last week, but this week he ghosted me and stopped replying to me after making some unrelated comment and saying he doesn't like pushing broken code, to which I replied that I just want to see his progress and it didn't matter if it was broken code or not.

He always complain, he blames other people when he cannot do something, so I am not sure if I can fully trust him, and I am wondering what I should do about him. Does dockerizing an application for production take 2-3 months?

Am I being reasonable? I suspect he didn't do anything and that's why he doesn't want to push a branch, which should be simple and can be done very quickly.

I am his manager and I am losing patience with him.

Answer 1

There are 2 possible things that could be happening here:

1. This developer is very incompetent. You have a docker configuration for development, so it should be fairly simple to append whatever needs to be done for production. In theory you already have production infrastructure set up, and documentation (or a domain expert) on how to productionize the application, so it shouldn't be too hard. That said, "hard" and "long" are not the same word; just because it's not "hard" doesn't mean it can't take a long time. If the developer is incompetent, then you should fire him and find one who isn't. You're the manager, that's how you manage.

2. This developer is very good at his job. Good developers say things like "I'm not going to push broken code". That's how you know you have a really good person on your team, when they push back at you like that, because it means they take pride in their work and make sure it's done right. That's how you know, when this person delivers something, it might take a bit longer, but your on-call isn't going to have to jump out of bed at 2am for a severity-1 complete server failure. If this person is a very good developer, and you are not used to dealing with good developers (as it seems you are not), that implies the rest of your team are not good developers, or at least not as good as this person. This means, if this person did not build this application and is only deploying it, then probably the application that is being deployed was written poorly, and there may be extraneous factors preventing it from being deployed properly, such as incompatible configurations, which would add to the expected time it would take for deployment. If this is the case, then you should give this person all the time they need to do their job properly. You should encourage them to checkpoint their work in Git "to make sure they don't lose their progress" (use this as your excuse, don't link these Git commits specifically to performance, and indeed DO NOT use them as a gauge of performance; if you're not asking for polished, working code in these commits, then don't yell at this developer when their Git commits are not polished or working), and you can use those checkpoints to gauge productivity, but don't push harder than that.

Based on what you said, I'm leaning slightly towards the latter. When you said "He's doing a lot of stuffs [sic] that are not necessary", sometimes those "stuffs" are things that are required to get an application from development quality to production quality. I've certainly had my share of managers who tell me not to do those kinds of "stuffs", and I pushed back saying that the application would explode if we put into production like that, and they told me to not do it anyway, and sure enough, as soon as it hit production, everything went to shit. Don't be that manager.

My suggestion is to allow your developer to explain to you what's going on. Perhaps pull him into a status meeting just to have him explain to you what he's done, what he's doing, and what still needs to be done, and see if you can shave down some scope for him to get it done faster, or put more people in to help him out, or something. Or simply, informally, ask some questions, and be prepared to listen to his answers, not just brush off his work as "stuffs that are not necessary". Then, once you've heard him out, you can make a decision; if you believe he is working well and doing what he needs to do, then let him continue, if not then you can fire him.

Answer 2

This is a simple accountability loop:

1. Set Expectations
2. Monitor Performance, support, train
3. Assess Performance
4. Consequences: Corrective action or reinforcement
5. back to 1

That said, my experience is that some employees just never "get it." So the consequences eventually end up being termination.

Answer 3

It seems like you are dealing with an inexperienced developer, who is not used to being managed. Maybe he's done solo/freelance work before and has technical skills, but from what you wrote, you are probably his first supervisor (at least the first who actually supervises).

Your company, your reality. Up to you to know if you can afford to straight up the guy or if you are better off terminating him. If you want to keep him, you'll have to explain a few things that you may take for granted:

1. Be honest about your technical skills:

If you really know how to do something, you are expected to plan well and deliver on time. If you need to learn something, then make it clear while accepting the task, otherwise, you'll be undervalued as an employee.

2. Everybody needs to provide visibility to their managers:

If your manager has an off-hands approach to your deliveries, then he is the exception, not the rule, or you've managed to earn this privilege, that may be revoked at any time. Normal managers want to see either deliveries or partial progress. If you show none, you are giving him reason to believe you are doing nothing, and he'll want to know why. And if you refuse to answer, he'll believe you are refusing to do your job. Hence you should have no place in the company. Now, an employee does not need to cater to the curiosity of every coworker, but it is basically the job of a manager or supervisor to know what the people he's supervising are doing and what progress they're making, likewise, it is part of anyone's job to give their manager such visibility.

3. There is a place to draft code

And this place should be well distinct from code that is ready to use. People should be well instructed not to nitpick draft code i.e. nobody is allowed to complain about code standards in a draft code branch/repository, nor to ask for headers to be filled or documentation to be produced. This alleviates the anxiety of being criticized for incomplete work (image a teacher stole your test at half the time allowed for it and just graded it as it was).

But managers and colleagues giving help should have access to these repositories so they can provide insight and tips on a conceptual level, such as "hey, you are using X tool, have you considered using Y tool?", "No, because it's paid", "Well, but we have a license for it already!".

If you are a more experienced developer, you might also say you want to mentor him into how to break down projects, such that he can deliver code and plan better. Even more important, breaking up a project into smaller pieces is a fundamental part of being a project manager or software architect, if he ever wants to become one.

4. Be very careful when blaming others

Every time an employee blames someone else, you as a manager should know if he's making up an excuse or if this is a fair report. Maybe he's throwing his responsibilities to other people e.g. "Jake needs to change his interface to my system because they're incompatible as of now. It does not matter if Jake followed the specifications we agreed upon a year ago, I decided I wanted it to change and didn't talk to him yet!". So it is up to the manager in place to say "No, you should meet the specifications, unless they're borderline impossible to meet, you are not overworking Jake for your convenience".

A fair question to ask when an employee blames another could be "have you talked to Jake already about this?". A "no" is pretty much an indication that the employee is not communicating well yet badmouthing others. You should reprimand this behavior.

But if it just so happens that everybody else is not delivering, or if everyone else changes their interfaces so that the problem employee needs to rework his deliveries, then the whole office has an organization problem, so you may need to better inspect everyone's deliveries.

But a more interpersonal take on this could be: Blaming others earns a lot of ill-will towards you. So be very sure about your claims when doing so, and know the correct means to it. Never use it as an excuse for your own shortcomings.

Answer 4

This is simple, you are the boss. It sounds like he's just throwing obstacles in your way, honestly. An experienced developer will commit and push code very frequently to their own branch - the only place where there would be a concern for pushing broken code, would be a release, integration, or master. Did you put him in a position to re-architect the whole system? If not, then he's doing a different job which maybe he likes to do, rather than what you've asked him to do.

I'm not usually the "I'm the boss" kind of guy, but you are responsible for the performance of your employees, and they are responsible for their performance, as you, their boss, defines it.

Let me add this: What would you have happen, do you want YOUR boss to come and fire him? They will probably fire you instead for being an ineffective leader.

Answer 5

Make sure there is someway to shadow him or put someone else with him. He will produce or he won't. If he doesn't the benefit of having someone working with him will pay off in figuring out where he left off and what he's done.