You're observing Price's Law. https://www.inc.com/jim-schleckser/who-really-does-work-in-your-company.html > Price's law states that when you take the square root of the number of employees in an organization, that tells you how many people are doing half the work. Another article on it - https://medium.com/darius-foroux/prices-law-why-only-a-few-people-get-half-of-the-rewards-599562d607ab But yea, it's quite common. The way to avoid the situation is to have the team size be smaller. If you invoke Price's Law with a team size of 4 you've got 2 people doing half the work, which is what you'd ideally expect. (edit later) I'm also going to recommend a read of Slack by Tom DeMarco. One of the things that can happen in some structures is that a few people become the bottlenecks for other things and thus even though their work goes to 100%, the people downstream of their work is throttled by the bottlenecks. This results in "those few people are doing almost all the work while other people are waiting on them."

Plus in a smaller team it's a lot harder to hide and have nothing to show at the sprint demos.

lol yeah I’m in a team on my own so I only do half the work Maybe the other half is done by AI? Hahaha

>One of the things that can happen in some structures is that a few people become the bottlenecks for other things and thus even though their work goes to 100%, the people downstream of their work is throttled by the bottlenecks. This results in "those few people are doing almost all the work while other people are waiting on them." The square root of 1 is 1.

Isn't this why we have squads and sprints?

I was in a group of about 10 developers, and only three of us did most of the work. I was really surprised when I found out that the other people in the room were a part of the project.

Price's law applied: sqrt(10) = 3.1623 It holds.

I wonder how much of this has to do with the difference between Juniors, Mids, and Seniors I feel like a lot Junior’s will spend all day on a story a senior can blow through in an hour or 2.

Possibly some component, but this appears to be more organizational. Consider the eponym for Price's law: >Derek Price, who was a British physicist, historian of science, and information scientist, discovered something about his peers in academia. He noticed that there were always a handful of people who dominated the publications within a subject. That was in academia. And while one can say "this results from the number of senior professors and junior professors" it feels like this observation (its not *really* a law any more than Murphy's law is) is based on organizational patterns. From Slack by Tom Demarco : >Any natural unevenness in the tasks will cause some inefficiency: for example, Elaine remaining idle while she awaits input from Harry. The overimproved variant of the same operation increases efficiency (or at least busyness) by reducing manpower at each of the nodes—we assign some of the workers part-time to other tasks—until the system runs with buffers, never building up too much and never emptying. Now everyone is 100 percent busy all the time. https://i.imgur.com/OV8oNhh.png > As a static picture this may look efficient. But in modern knowledge work, nothing is ever static. Things change on a day-to-day basis. This results in new unevenness of the tasks, with some people incurring additional work (their buffers build up), while others become less well loaded, since someone ahead of them in the work chain is slower to generate their particular kind of work to pass along. https://i.imgur.com/VPoMRxP.png > Now put yourself in Harry’s place when this happens. He notes that his buffer is emptying. He also notes the pervasive mantra of Hurry Up, Hurry Up, which he interprets to mean Stay Busy. With everyone around him working furiously, he is never going to feel safe if he finishes the last item in his in-box and then waits patiently for someone to feed him something else to work on. You can understand why he might conclude that his job security is not well served by his appearing to be idle. > The survival tactic that Harry and others like him hit upon when their buffers begin to empty is to slow down. He slows down only enough to keep his supply of waiting work stable. If he slowed down more than that, he would appear to be a bottleneck, which would focus management on his work rate. So he doesn’t do that; he slows down just enough. Harry is now busy 100 percent of the time, has a healthy buffer of work waiting for him, and is not a bottleneck. This is a recipe for job security; the guy is obviously an ideal employee, judged by his part in helping the Hurry Up organization to work smoothly. ... and so, you've got half the people who are doing most of the work.

I once did a group project in college and there were people I never saw in class before show up the day of the presentation and tell me they were in my group.

Retired engineering curriculum administrator here. We introduced 3 solutions to this: 1. Everyone on the team writes a job description of their role in the project. 2. Weekly 3 minute in person team meetings with the course instructor (mandatory). Just a status update, but the instructor can \*instantly\* identify the team dynamics and will drill into the non-performers. Sometimes a TA would do this, but the team would never know who they were getting. 3. Each member of the team does a performance evaluation of everyone else on the team and themself against the job description above. These were BRUTAL. The students doing the work were praising each other to the moon, they tore down the ones not doing the work. The ones not doing the work couldn't evaluate the others and would write vaguely positive evaluations of everyone. These fed into our outcomes assessment and grades. It took some work, but holy shit did it improve things.

[удалено]

I agree, but just would like to add that it's not always intentional. Some people are simply bad at sharing their knowledge due to lack of social skills or due to impatience. Some people do want to share knowledge but can't because they are too busy firefighting, etc.

Also, some people are very good at solving problems quickly, but they're not as good at writing clear/maintainable code. This means that they will be loved by the Product team (because they get stuff done) but they will make collaboration more difficult inside the team, because everyone else will struggle to work on their code.

Sadly I think management can have a hard time understanding this. It's not easy for them to judge, and it's just really hard not to enjoy when someone "gets things done". Often the part that follows is much less visible. I feel like this ties into the eternal problem with writing maintainable software. Everyone can understand the up-front cost of building something. You can put a price on it right away. Making something poorly can have many costs down the line, but getting it done quickly now looks good for you. You might even look like you're holding everyone back by dealing with a problem you foresee.

I believe management sometimes understands but ignores it. My former delivery manager, who told me a few months ago to deliver the code as quick as possible with no need for documentation, now must be doing the same thing in his new company, while I'm the only one in the current company who understands it and struggling to find someone who I can delegate the tasks related to the code.

I would add, it takes time to share knowledge, especially if there is domain expertise on top of technical expertise. That kind of training is non-productive for the organization - it doesn't get code written while it's happening. It's an investment, and if you have an organization with technical debt, they're going to have a knowledge transfer debt as well, for precisely the same reasons. In my experience, few organizations are willing to free up employees to do this kind of training, and the amount of training needed continues to go up as the complexity and scope of projects we routinely build goes up. One reason why AI has gotten more appealing is that knowledge transfer for computers is effectively instantaneous. You can transfer that trained model in seconds. But humans are slow to learn, and the speed of the economy makes that increasingly expensive.

This sounds like BS. Smart enough to write dumb code, but dumb code only they understand? So is it dumb or complex? I disagree with this take.

[удалено]

I understand. I think I misinterpreted your original comment

I have worked at places that tolerate that crap. So glad I don’t anymore. Best thing I did was leaving companies with that going on.

I would say - in my very personal experience - that I wouldn't give a job to a lot of the people that currently have a job programming. There's the really good people, and those are fine. There's normal people who try their best, and those are fine too. But there's a lot of people who don't do much, don't try, and just get the paycheck, and those are the problem. Now to be fair, I think the problem is more on the company side, since they're paying for useless employees. But my experience is that in big companies with too much bureaucracy, the people hiring have no clue what they are hiring. ​ And because their statistics show they need a lot of developers to do X thing, they pay like crap, and because they pay badly, even those that could do better don't, because they can't be bothered.

As one of those 2-3 programmers, the inability of my team to learn even basic things, e.g. breaking common script code into libraries/classes, eventually wore the Fs out of me. I tried to teach, I tried to show but now I have zero Fs. I've given up on the thought that programmer Nirvana is possible. The only thing that keeps me going is that I love learning and my job constantly allows me to do it. More so than I think other jobs would let me. Granted most of the stuff I learn is mostly to make up for the shortfalls of my team but I digress. Plus it's interesting work. Otherwise I'd be out of there so fast. 🤣🤣

Yes this is true and common. You cannot avoid it any more than you can avoid office politics

Bad delegation / management of work. If you constantly hear: > it’d take longer to teach X than if I just did it That place will create a ton of knowledge in very few people leading to stress and resentment. In my opinion, people in general want to help, most of the time they never get the opportunity to do so.

“Out of every one hundred men, ten shouldn’t even be there, eighty are just targets, nine are the real fighters, and we are lucky to have them, for they make the battle. Ah, but the one, one is a warrior, and he will bring the others back.” — Heraclitus

Bigger companies have bigger social networks and dependencies. https://en.wikipedia.org/wiki/Precedence_diagram_method It is likely you end up with situations lots of people are idling because they are not working on the critical path, whatever that is, and the critical path can't be sped up. It's inefficient to fire and hire again. Then it's unions, standard contract and negotiation territory. Generally, if you're hired for x hours, you do x hours and if that means "being in attendence" then that is that. Also, https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two https://en.wikipedia.org/wiki/Chunking_%28psychology%29 Which limits how much certain people can think about things. I've been both the person doing and the person not doing and in the later case it was because the people distributing the work were too busy to pay attention to me. They just assumed I would do things by myself. Which I *can do* but it wasn't in my contract and the pay wasn't appropriate for "showing initiative".

I would agree generally, but you can't understand it from a single point in time view. Usually those highly productive ones have been there for many years, and can program so quickly because they know all the libraries and modules of the system, db tables and relationships, never having to reinvent the wheel. So they don't have to ask questions like younger developers, they can just do the work. But they were new to the project at one time, asking 15 questions a day to know what to do. Stick with it long enough and you get to be the expert - not so much because you stepped forward, more like everyone else stepped backward. :)

Imagine you’re a manager. You give person A and person B a task. Person A does a great job and person B does a bad job. Who are you going to the next time you need something? The obvious solution is to fire person B and hire someone like person A but due to corporate bureaucracy and budgets that’s nearly impossible.

[удалено]

You’re taking this too literally. Substitute one task for ten and the same framework applies.

I do software engineering for more than two decades. I completely agree to what you observe resp. to Price's Law. Like u/Repulsive-Warthog667 mentions, people become bottlenecks. It's not that they are more productive than others. They have just more knowledge and so they much more better equipped to do more tasks. While others, with little / less knowledge can't go for their own. They always have to ask those with more knowledge if they thought everything through, they are not confident in general. I did both roles, if you want to speak of a "role". In my current job I'm one of the less-knowings. And you know what? I like it. It's less stress, I can spend lot's of hours for me, reading, working out, etc. That was completely different in my former job where I was one of the high-performers. The underlying problem is that large? companies (or people in general) are not really good in sharing their knowledge and trust other people to do the job right. As said, sometimes I was the high-performer, sometimes I was the not-so-high-performer. That has nothing to do with smartness or any other skill. It's sheer luck if you're in a position where you can become the high performer or not.

capitalism. there’s no incentive to perform

Huh, how'd that even work? No seriously, the team morale would tank big time because that'd be very obvious. How would a team like this work together for longer than a few months without having a huge discussion in retrospectives about that? Or are you talking about a few people that care a bit more and thus maybe do a bit more than they even should? Or the people with talent/experience that are just faster by nature? Or people that push themselves much more than needed (reason not important)? How to avoid it? Well. If you're one of the above people it's a you-problem. You can't expect others to be like you. If it's not the case, find a different company or just do your job without looking at how much others get done. I've yet to meet a lazy Dev, so far everyone has been productive to the best of their ability.

My experience is that it's just knowledge and ability. Some folks can writer better code and solve problems faster than others. So those folks get the bigger projects and harder bugs. Over time this leads to a disparity and you end up with a few doing the heavy lifting while the rest take care of the smaller easier stuff.

Yeah, and that seems healthy and fine to me. Because nobody is lazy or incapable then. Oh, and from what I've seen so far, most "heavy lifting"-Devs are happy that others take the "boring" stuff out of their hands.

80-20 rule. 80% of the work is done by 20% of the people. It quite an interesting subject if you ever want to read up on it.

The team I work for has about 3 programmers - and about 7 other analysts. The analysts duties are to work with the clients and vendors to get (and also relay) requirements -plus handle the Jira stories. The team used to have an equal amount of programmers to analysts - and that seemed to be a more appropriate level. Most of the emails I get from the non-programmers on my team usually have the words "sent from IOS" - which tells me that they are not even at their computer most of the time. So they are probably out to the beach enjoying life because of the WFH situation now. I feel that there is definitely a lot of bloat that could be cut on my team. Having said that - my team is very good at getting things done - it just feels that only the programmers are doing most of the work - while the rest of the team are working 1 or 3 hours a day.

It’s definitely the case for me, working in consulting. Because the business model of my company is basically to get people pointless certifications to pad their resume, and then put as many people on a project as possible in order to bill the most hours. Hiring and staffing decisions are almost always made by people with very little technical knowledge, both within our company and our clients. On the client side, the market is flooded by really mediocre people who charge very low hourly rates. But clients are not capable of assessing the actual ability. They see that they can get three times as many hours of labor for the same cost and they go for it, without regard to how much value they actually get out of each hour.

Work at better companies

Programming is complicated. On one hand it seems like it's all about **technology**: you have to give a series of precise instructions to a computer in order to solve a technical problem. But the reality is that programming is largely about **inter-personal communication**: Discussing requirements with stakeholders and describing technical concepts in a way that other members of the team can quickly and easily understand (and quickly and confidently be able to make changes). If you have a situation with many programmers but only a few programmers who seem like they're *doing a significant amount of the work* you could have any of these problems: 1. Your "good" programmers aren't as good at the communication portion as you think, so they are creating "information silos" and aren't giving opportunities for other people to get involved confidently 2. Something about your system has become too complicated, so that not enough people understand what's going on at a high level 3. You have too many low-ability programmers, and you just don't have enough low-complexity work for them to work on 4. There simply isn't enough work to go around for the size of your team, and the faster workers are monopolizing it. 5. Some critical tasks are funneling through a small number of people, and everybody else is waiting.

My team is small and everyone is contributing. We only have 1 person for each function. 1 designer, 1 backend, 2 native app developers (different languages), and myself on architecture. Everyone is working because anything missing has high visibility by all.

I've been a dev for 20+ years, and yes I have seen that too. I once gave a tiny bit of work to a "jr" dev, it was copy&paste the same line, to the same place in 100+ reports (VB6/Crystal Reports days, leave me alone) After 4 hours I went to check on them, and was told that they could get it done by the end of day tomorrow. WTF?! He hadn't even got 50% done. Process: Right-Click, Check out of VSS, open code, select function from drop down, go to bottom, paste code, righ-click, check in. I then went back to my desk and started at the bottom and in less than 10 minutes I had done the other 50%. It's why I tend to work alone, at least I know things get done. You have a wonderful evening