How do you encourage an employee to not go all the way down the rabbit hole?
9 comments
Timeboxing. When you delegate something, provide a time box. People either lean expeditious (ie. make sure you include logging, tests, robust error handling, take your time with it) or perfectionistic (ie. I trust you to write great code, try to timebox it to under a day, send up a PR at the end of the day with your WIP, you don't need test coverage for this, etc.). It's one or the other. More or less bucket people and then coach them on it. Also, try to put them on projects that benefit from their approach.
Or simpler if done anyways: make estimates on how long things should take and if estimates are not met by a large margin discuss why.
The first step would be for him to see that this is not ideal.
The first step would be for him to see that this is not ideal.
I’m curious, have you actually spoken with this person? Why does he do this?
Some engineers do this because they lack confidence. They’ll optimize the shit out of a solution because code reviews are a form of work inflicted torture. If this is the case, you need to think about your culture and whether this person has a reason to dread code reviews. This is not meant to insult you, but as someone who worked through his own self esteem issues decades ago, I’ve got to tell you, I didn’t appreciate the way you’ve disparaged him in this question. For example, ‘it turns out he’s been working nights at home...’ is not appropriate if you want to help someone through self esteem issues. The appropriate way to bridge that is to start with a compliment - the cat is working on his own time to help you...
Other engineers do it because they’re obsessed with learning and understanding. I see this a lot with young engineers - they have this idea that they can’t just use a library, they have to be able to build it from scratch if you give them a pile of sand.
In this case, we’ve all been there. For the love of all that’s holy, if you’re on Hacker News, you’ve gone down rabbit holes like this. Those rabbit holes make us hackers...
If this is the issue, it’s time for real talk. I wish that I understood everything but I don’t have enough time to understand everything and keep a roof over my head. At some point, you’ve got to trust in your team, your tests and your instincts. Fuck, I just resisted the urge to learn about trinary because there’s no way trinary will pay my bills this lifetime. But 21 year old Greg would have spent three years in that rabbit hole.
Some engineers do this because they lack confidence. They’ll optimize the shit out of a solution because code reviews are a form of work inflicted torture. If this is the case, you need to think about your culture and whether this person has a reason to dread code reviews. This is not meant to insult you, but as someone who worked through his own self esteem issues decades ago, I’ve got to tell you, I didn’t appreciate the way you’ve disparaged him in this question. For example, ‘it turns out he’s been working nights at home...’ is not appropriate if you want to help someone through self esteem issues. The appropriate way to bridge that is to start with a compliment - the cat is working on his own time to help you...
Other engineers do it because they’re obsessed with learning and understanding. I see this a lot with young engineers - they have this idea that they can’t just use a library, they have to be able to build it from scratch if you give them a pile of sand.
In this case, we’ve all been there. For the love of all that’s holy, if you’re on Hacker News, you’ve gone down rabbit holes like this. Those rabbit holes make us hackers...
If this is the issue, it’s time for real talk. I wish that I understood everything but I don’t have enough time to understand everything and keep a roof over my head. At some point, you’ve got to trust in your team, your tests and your instincts. Fuck, I just resisted the urge to learn about trinary because there’s no way trinary will pay my bills this lifetime. But 21 year old Greg would have spent three years in that rabbit hole.
It's interesting that this person is basically an extreme version of something that happens all the time in this industry.
I've seen so much premature optimisation / abstraction on virtually every project I've worked on.
The people that do this stuff are often very persuasive, and it can be hard to be the person who suggests the "dumb" alternative.
Often their arguments are actually correct, e.g. "we need to do this thing to make it more maintainable / scalable", it's just that in so many cases, the project is never going to be maintained or scaled.
I've seen so much premature optimisation / abstraction on virtually every project I've worked on.
The people that do this stuff are often very persuasive, and it can be hard to be the person who suggests the "dumb" alternative.
Often their arguments are actually correct, e.g. "we need to do this thing to make it more maintainable / scalable", it's just that in so many cases, the project is never going to be maintained or scaled.
"but it turns out he's been working nights at home to develop the optimal avatar" is this a joke?
Seems extreme. You could always use it to advantage though - have you got some bigger projects upcoming which need thorough research?
This is not a great solution.
Very few problems need unlimited, unbounded research. An effective employee limits him/herself to only the biggest problem and risk areas, rapidly focusing on the biggest unknowns and ignoring the little stuff.
If the project is very complex, you MIGHT need to understand the whole thing in excruciating detail... but then you still must take that huge corpus of knowledge and distill it down to software (or a verbal summary for the team!) focused on the highest-risk areas.
In this particular case, I think it may help to focus on the business value and timeline. "Your goal is not to do the best X, your goal is to deliver Value Y in Timeline Z. Give me the best one of those you can, but if I don't end up with Y by Z then you're doing it wrong." Help him understand that perfection is not the goal, and that failure to deliver is imperfection.
If the project is very complex, you MIGHT need to understand the whole thing in excruciating detail... but then you still must take that huge corpus of knowledge and distill it down to software (or a verbal summary for the team!) focused on the highest-risk areas.
In this particular case, I think it may help to focus on the business value and timeline. "Your goal is not to do the best X, your goal is to deliver Value Y in Timeline Z. Give me the best one of those you can, but if I don't end up with Y by Z then you're doing it wrong." Help him understand that perfection is not the goal, and that failure to deliver is imperfection.
He doesn't understand what the business values. Show him that.
Nights? Or just I worked on it last night while also learning inkscape or something? Maybe he's trying to master a technique that he'll use in other places. The way you said it makes him sound bad.
Nights? Or just I worked on it last night while also learning inkscape or something? Maybe he's trying to master a technique that he'll use in other places. The way you said it makes him sound bad.
> turn a 30 minute task into a 3 hour task
Not a bad thing at all. If he is an engineer, it is due diligence, which is in fact his job.
> a 1 week task can turn into a 3 month task
This is more of a management problem than a personal issue. If you are letting him drag out a 1-week task over 3 months then either he has way too much leeway in delivery scheduling, or it wasn't worth his time in the first place and it should never have been assigned to him.
Also, who is estimating these tasks?
Not a bad thing at all. If he is an engineer, it is due diligence, which is in fact his job.
> a 1 week task can turn into a 3 month task
This is more of a management problem than a personal issue. If you are letting him drag out a 1-week task over 3 months then either he has way too much leeway in delivery scheduling, or it wasn't worth his time in the first place and it should never have been assigned to him.
Also, who is estimating these tasks?
Hard to change someone’s nature. I agree with @viraptor put them on something requiring indepth research. :)
It sounds like a mental issue, and not simply a habit. You might want to ask a professional.
For example, we needed him to put an avatar in Jira (if you have ever used Jira, you'll know the avatars are actually pretty useful). We're at the end of a 3 week sprint and we finally got him to upload a "placeholder", but it turns out he's been working nights at home to develop the optimal avatar.
Attention to detail: 11. Time management: 3.