That's the literal definition of dead weight.
That's the literal definition of dead weight.
They ask the manager, "If you want twenty tickets, just ask me for twenty tickets. Why do you set fifteen as the standard, and then try to use cheap psychological tricks to get me to do twenty tickets?"
I have managed teams going back to the nineties. If I want fifteen tickets, I ask for fifteen tickets. If someone just does the minimum, they just get paid the minimum, but I have set my expectations such that their work is a net benefit to the company, so they keep their job.
If things change and I need twenty tickets, I will ask for twenty tickets. It's not complicated. The "bare minimum" is still enough to keep a job. If it isn't, it's on me to establish a different minimum such that the "minimum" is exactly that: The minimum needed to remain employed.
"Dead weight" is someone whose work is not a net benefit to the company. If I as a manager set a minimum, and someone does the minimum, and they are not a net benefit, WTF am I doing as a a manager setting fifteen tickets as the minimum?
Employees meeting expectations but not being a net benefit? That's a management problem. And if it's across the org, that's a SYSTEMIC management problem.
So if this person is meeting the minimum, either they are NOT dead weight, or there is a management problem. Either way, they are not the problem.
That said I agree with the idea that someone that adds value that is some reasonable multiple of their salary gets to keep their job. If they're not adding value because they can't perform their job or don't care they should not keep their job. If they're not adding value because of how they're managed their manager should not keep his job. If this issue is endemic in the company that probably means the CEO shouldn't keep their job... In an ideal world anyways.
In reality, trying to measure software development productivity objectively always makes me whip out a little venn diagram that shows that what matters and what can be measured have but a small intersection.
But abstracting away from tickets, as a manager you set some kind of expectation for "the minimum." However it is you rate people from "not meeting expectations" to "meeting expectations" to "exceeding expectations," my contention is that it's the job of a manager to make sure that "meeting expectations" means that an employee's work is a net benefit to the company.
Whereas, "dead weight" describes someone who is a net loss to the company. So to me, someone who just meets expectations should not be "dead weight." If they are, I suggest there is a management problem.
If you aren’t willing to do these extra tasks, that’s fine, but you’re doing nothing to keep the company surviving and someone else will have to pick up your slack. It’s in everyone’s best interests to keep the company surviving as long as possible so it can keep paying salaries.
Of course the C level has a lot more to gain, but everyone has to work somewhere so why not do your reasonable best to make a positive impact.
The "minimum expectation" is therefore hard to concretely define. It's not "everyone should fix 3 bugs a week" or "everyone must implement 2 features a month," because the work is always going to vary depending on the specific issues and project needs.
The variability of coding work can make it hard to explain to under-performers that they're falling behind their peers.
If you look at a problem and you estimate a timeline, you'll underestimate sometimes. so when an engineer brings you a significantly longer timeline, ask them to justify it, ask them to show you what they mean. This will eat a few extra minutes out of your day, but it will help you separate the bullshitters from the genuine people, and it will help you understand what they do better. And if you just can't add those extra minutes to your schedule without causing trouble, then the problem lies with your boss, not you. It's your job to know your people and understand what they do, and if you're not given the leeway to do that you'll never be effective.
But, the point that I was making was simply that trust is an essential part of software work, and people who pride themselves on doing only the minimal amount of work, risk messing up this system of trust for everyone else. We all want a manager who trusts us when we say a problem is hard and it will take time. And managers want engineers who when they say they're working on a problem, they're actually putting time and effort into it.
In the (hopefully very rare) case where an engineer puts in a measly amount of effort during the week but pretends they're hard at work, this trust is broken, and in the worst outcome, the manager or company overcorrects and it becomes a shitty place to work.
This can be hard I know with the way contracts are, labor laws, severances, and often times it is easier to just offload the employee to another team, which compounds these problems and makes them systemic. That's the only sticking point I think that takes the blame off management. It should be easier to fire bullshitters.
This doesn’t sound like a problem with minimum expectations. This sounds like a project management problem.
But, the usual pattern for people who work slow, is that some new complication always comes up. And it's not easy to know when the complication is legitimate and will take time to figure out, or something that could easily be dispatched in an hour's time.
As to the parent thread: I make about half what I would be making if I had gone the FAANG route -- but I get to choose what I work on. That is a fair deal in my mind. Working on things that fascinate & inspire me make me a 10x rockstar. But if I'm asked to keep dead code limping along zombie-like, I need to work harder and longer because in that scenario I am a 0.5x sleeper. YMMV
If you want to do piecework/hourly work, you should be a contractor.
Someone who does the bare minimum in order to buy get fired is just a... satisfactory employee. Never gonna get big raises, never gonna get promoted, but gets their work done and doesn't go above or beyond.
Every place I have ever worked has taken advantage of anyone who does more than they are asked. None of those individuals were ever rewarded for going above or beyond. Not a single time.
Doing the bare minimum is what employers do. Why should employees do any more?
I believe it is our moral duty to improve ourselves. I do not believe it is our moral duty to donate effort to an unthankful entity.
No.
literal definition
> the weight of an inert person or thing.
The metaphor refers to people that do nothing and are only a burden. Dead weight cannot positively contribute.
If, on the other hand, the manager's trust has no relevance here, because you are not setting your own time-work estimates, then have at it!
Work planning should be a team effort.
But my comment stems from someone above who said they do the minimum amount of work possible. This sucks for the team, who is working hard and trying to make progress, meanwhile this person is barely doing any work every day in between gaming or reddit or whatever, but (presumably) still joins stand-ups and Slack to chime in with whatever "complication" he's having to work through that day, and always gives the impression that their work is super tricky.
I think you missed the productivity porn thread posted here https://news.ycombinator.com/item?id=32335165
https://www.merriam-webster.com/dictionary/deadweight
Examples of literal in a Sentence:
" The literal meaning of “know your ropes” is “to know a lot about ropes,” while figuratively it means “to know a lot about how to do something.”
I was using the word in its literal sense.
The story he told was basically true, even if it wasn't the literal truth. "
Going above and beyond requirements is a personal decision.
But this isn't what a dead weight does.
You must not have worked in companies with actual dead weight.