3 ms·
> as I have the results delivered And how do you define the results ? What if the employee gradually slows downs working like one hour less per week every mont
by ttoinou 5y ago
> as I have the results delivered
And how do you define the results ? What if the employee gradually slows downs working like one hour less per week every month, in a year they can go from 40 hours per week into 28 hours per week with normal work expectations.
And that wouldn't necessarily be a "bad employee trying to get more from you by doing less". For example, maybe your team performance is getting worse. Let's say you have a coworker that is sick and gets normal pay for less quality work, and another coworker that just got a baby and got less time for work. The teams got less focused on work gradually in time and the employee feels "entitled" to work less on you and do something else with his/her time
- egorfine 5y agoIt boils down to working with people with inner motivation to deliver. I guess my experience is more relevant to small and highly integrated teams.
- egorfine 5y agoAlso bear in mind: results of software developers are not defined by hours spent coding. > less focused on work gradually in time This might happen. It's a leader's job to keep in touch with the team and watch out for morale.
- ttoinou 5y agoSaying it's the manager's job to deal with that doesn't solve the issue of helping managers deal with that job. The question remains open. I gave a specific example where a manager can't "Keep in touch" because the work was gradually slowed each month, in a way that the manager can't see that time spent declined, he can only think that it's the employee's normal productivity
- md_ 5y agoMakes sense. But it's well-known that software delivery estimates have huge error bars. I frankly would have limited insight if a skilled engineer reduced output by 30% in order to work a part-time job. Ultimately, the challenge here is that managers and engineering leads just don't have a great ability to know how expensive a project should be, which is sort of bizarre given that for a lot of software the development costs are the primary costs!
- egorfine 5y agoI strongly believe that software development estimations are futile.
- md_ 5y agoRight, but my point was that if you can't reliably estimate how long something will take, you can't estimate how long it ought to take, and, by extension, can't estimate if it's taking longer than it should. So, as a leader, how do you know if someone is over or underperforming?
- egorfine 5y agoUnfortunately, there is no algorithmic solution to this. It's like porn: hard to define, but you know it when you see it.