Overengineering code - how to tell engineer to be more efficient?
I have this engineer who massively over-engineers everything he’s assigned to. Something his boss estimated for 1 hour could take him 3 days. He’s very sharp very experienced (15+ yoe), but he codes a 3-br townhouse when his boss asks for a cat litter box. He doesn’t report directly to me but I manage their project. I’m going to have a 1:1 with him and informally micromanage his productivity daily. Any advice for me? For context, both his director and his VP (both used to code) have told him that he needs to cut to the chase and start closing tickets. But he talks back to them and is slow to show change. I’m a mere project manager.
If a PM tried to do daily 1:1’s to micromanage me, I’d tell him where he can shove it. If you got a problem with him, have a honest dialogue with him. If that doesn’t change anything, go to his boss. It’s not your place to micromanage him.
I meant one 1:1 just to understand what’s important to his career. Then manage daily like checking closure status, slacking him for progress etc. I’m the project manager. It is very much my place to manage progress and make sure to deliver sprints on time. Maybe you didn’t read closely - his bosses already confronted him. They’re asking me to manage him now.
pip incoming
Probably he derives a lot of joy out of over engineering. Slapping code together day in and out turns a job into a total grind, especially if the low quality was mandated by the business. I quickly leave jobs that start micromanaging me
I hear you. I hate being micromanaged too. But if your bosses made it very clear that there’s a deadline and things need to be coded a certain way, how would you find a compromise for both parties? Even though it’s no fun?
From the text I didn’t see OP wants to find compromise.
OP, your yoe? This guy sounds not sharp at all. I'd be worried if he's not fired or piped.
I’ve managed projects for 3 years but only 6mo on this engineer project manager role. Used to serve clients. I’ve been managed so I understand how to find people’s “currencies” and sell opportunities and trade apples for oranges. But my tricks don’t seem to work on this engineer! They don’t want promotions 🙃 they just want to code.
Huh. Are you reviewing his code? Is there a code review process? Does the reviewers agrees that it’s over-engineered?
I’m not a coder at all. His director reviews his code and have repeatedly told him to rewrite in very specific simple ways. But he talks back to him and just won’t change behavior. His director wanted to code on the a weekend just so he didn’t need to deal with him. I hate being micromanaged too. But I need a quick method to get him to change.
It doesn’t sounds like it’s your problem to deal with 🤷♂️ You already took it to his director, and his director chose to deal it this way.
It doesn’t sound like you understand engineering very well. Spending more time with him will exasperate the problem. Micromanaging will make it worse. Making it worse might be a good thing if you want him fired. Otherwise if you want him to change, this will not work.
I hear you. I don’t want to fire him, I want him to simplify his code and close more tickets so we don’t delay project demo. When he’s given the freedom, he codes only the way he wants and “trolls on slack” (borrowing the words from his director). Which is why I want to check-in more frequently. So if I do have to checkin daily, do you have suggestions for me? What can you (assuming an engineer) benefit from a daily checkin? What can I give you instead?
Unfortunately a daily check in will not help tasks close out, and there’s nothing you can offer during a daily check in that will change this. Him not doing his job well is absolutely not due to a lack of accountability, but instead much deeper problems. So my advise to you would be to define what you want out of your interactions with him, and assume he will not change his behavior in a meaningful way. Be very honest with him, and say you’ve been tasked to check in frequently. Record which tasks he finishes promptly, and which ones don’t. Record any reasons for delays, as he reports the reasons to you. Then you can present this information to your boss and let them handle the situation from there. You’re basically acting as the delegate to start documenting his demise. If he cares about his job he will start closing out tickets faster, and it will be on his own terms. If you try too hard to micro-manage, boss him around, or pressure him to do what you want, you’ll very likely get less tickets than before. He will simply see you as “yet another idiot trying to boss me around”. If he doesn’t listen to his boss, then why would he listen to you? Maybe you have heard of “herding cats” before? If you want to change a cat’s behavior you have to manipulate their environment and let them adjust on their own (and they will since cats are domesticated). But with engineers, if they still refuse to adjust then it becomes banhammer time (fire them). P.S. Over-engineering is a sign of incompetence, and *not* sharpness. Maybe he’s smart, but obviously he’s not wise and definitely not competent.
A daily check on will only annoy an engineer. Would you do this to a doctor? Would you as someone who has no clue on being a doctor's try to micromanage a doctor claiming he's not closing enough patients?
But even doctors need to meet quotas.
Careful how you deal with this. Consider the possibility that he is right, and that management may side with him. If he quits this morning, he will have interviews lined up by Friday, and maybe an offer or two next week. You, a project manager? Not so hot commodity.
Does Occam’s Razor apply here? https://en.m.wikipedia.org/wiki/Occam%27s_razor
It would apply if OP were qualified to judge code and this was a tech company. Highly probable that JUUL, a vaping products manufacturer, does not appreciate the craft of software engineering. It could also be a fit issue. Startups need to get prototypes out quickly. Maybe the engineer trained at a large tech company where the cost of maintaining a large ill-structured codebase is too high. Too many variables to pass a quick judgement.
The engineer sounds like a great fit for Salesforce. Salesforce build things like he does almost for everything. It takes 2~3 weeks to create a new table. We ship 3 major releases per year.
Be specific with him with not just with the WHAT but also the HOW. Pair him up with someone for a week. Provide training. Do checkins and mini reviews. If all else fails fire him, it’s just not a good fit. The well-being of the team comes before that of the individual.
kiss mvp agile you’re fired one of those should help
Is kiss an acronym for something?
Keep It Simple and Stupid