4 ms·
So it just seem like Pareto principle example. 20% of employees making 80% of effort. I don't know if it is fixable. All I think is folks in that 20% will keep
by geodel 7y ago
So it just seem like Pareto principle example. 20% of employees making 80% of effort. I don't know if it is fixable. All I think is folks in that 20% will keep changing when Companies/HR/Employees make noise about this. One reason is because 'highly engaged employees' may not be highly productive employees.
Just yesterday at my workplace one dev spent whole day to set up Eclipse workspace for a basic Microservice project. It was about 10 min job. Now that person claims to be junior developer not a total novice and I see no reason to doubt that. But setting up similar projects has been explained and demoed in great detail at least couple times in last few weeks. Still anytime something changes he can spend days to do most trivial things. I would think this person would simply burnout if task is given with a end date. It doesn't matter how generous is the deadline.
- jtanderson 7y ago> So it just seem like Pareto principle example. 20% of employees making 80% of effort. I don't know if it is fixable. All I think is folks in that 20% will keep changing when Companies/HR/Employees make noise about this. This actually sounds like it could make for a great system, in the sense that you still maintain the original quality and quantity of output, but you still get to avoid the burnout of that 20% completely, because after some time, it will be somebody else's "turn" to do more heavy-lifting. Obvious problems here are that 1) company/team structures in industry don't seem conducive to this, 2) skill levels are unequal, so to maintain the quality of the 20%, one would need to plan carefully to account for this -- but, it also seems like a good way to help lower skilled workers rise to meet higher standards -- and 3) hinted at before, this needs to be institutionalized in a tangible way, and that seems to require a difficult form of team member assessment/introspection that managers may not be capable of facilitating. Wrt point 2 above, I've heard from sources I trust (but would have to bug them for specific sources on this) the following phenomenon has been observed in education: when you remove top performing students from sections of a course -- say, to join an honors section of that course -- the non-honors version of that course has a void for high-performance students. Interestingly, this void is often filled by the mid-tier students who would have typically performed at B/C level, and now some of them will rise to perform at an A level. It would be fascinating to find observations of this in the industrial setting as well. If I find a source for this, I'll update my comment.
- supernomad 7y agoSo regarding your point 2 I have, at the very least anecdotally, seen this happen in practice. I work in a tech startup and as such we have a lot of highly talented engineers sitting in the top spots throughout the engineering org. We have recently had the case where some of these top engineers have shifted focus and we as a company watched as the engineers beneath them rose to the occasion. This is definitely a phenomenon that can happen, but it has a dark side that I feel is rarely accounted for. While you want to have senior talent and empower your engineers to grow, you also need to have junior/mid level engineers to support them. All to often the reason you have 20% of the employees making 80% of the effort is because they have no supporting infrastructure to help them with their jobs, or they are powerless to leverage the other employees for help without interacting with, sometimes multiple, management levels. When we started to expand the engineering org it became readily apparent what we needed wasn't more senior talent, but more, for lack of a better word, grunts to help with the mundane tasks that the senior engineers shouldn't be working on. This same thing happens in most other organizations outside of software development as well. Essentially one way to ensure that you don't have your engineers burn out, is to ensure they have a team they can fall back on completely outside of management. I personally appreciate getting recognition from my manager and the higher ups at the company I work at. However I appreciate the team I can rely on far more. I think generally HR/Managers should get out of the way more often, and instead of directly acting make it easier for teams to help/support each other.
- granshaw 7y agoUmmm, did you actually observe him struggling and clicking around for that whole day, or was he just slacking off?
- geodel 7y agoI do feel some sincere struggle on his part. He does not seem relaxed. Modifying code/configs and run again. It is just that he did not really understand what is wrong with his setup or based on errors how should he go about fixing it. He even told me that he is spending weekends to finish his tasks. Now I myself have long list of complaints about Spring/Microservice crap and its tendency to bury simple errors in 10 thick layers of abstraction. But that will be more relevant to IT related threads. It is because many other developers are dealing with it and still somehow make it work without spending days for an hour job.
- flowersjeff 7y agoMaybe this is a definitions issue. One's 'junior' is another 'novice' - I say this, as I think that there's been a huge gulf forming in how we view the meaning of words (particularly relative to HR)...
- ikeyany 7y agoHe's not familiar with the ecosystem quite yet. Work with him through it a few times without making it look like he's being "tested".
- bassman9000 7y agoPareto also applies to employees producing 80% of the output and I bet that, if you remove anyone with less that 3 years in the field, the 20% of highly productive strongly correlate to the 20% of highly engaged.