This is the "pieces of flair" debate. If their manager asks for fifteen tickets a month, and they do exactly fifteen, the manager sits them down and asks why they don't do twenty, like their colleague over there.

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.

As a manager myself, here is the problem I see in what you're saying: Most often, the time estimates are set by engineers themselves. I don't tell them "Do this task in 3 days" -- I ask them how many days/week it will take, and we track against that. This relies on my trust that they are working hard and not half-assing it.

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're a manager and are not capable of seeing an overestimated timeline for what it is, you have one or more problems: 1) you do not know your employees, 2) you do not understand the work they're supposed to be doing, 3) you do not understand your product. Either of these or all of them or any combination in between still means you're the problem.

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.

You're describing a scenario where an incompetent manager is both clueless about the technology and doesn't spare even a few minutes to do their job. I'm sure that happens, unfortunately.

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.

Yeah, but this is where knowing your people comes in. If you've got a bullshitter on your team and you know it, you need to be figuring out how to get them not just off your team, but out of the company. If you don't know it, you're not doing your job.

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.

If you don’t trust their estimates, Look up estimation poker. The whole team plays. It’s a good way to keep everyone honest with regards to estimation and allows everyone to learn hidden things that someone else may see.

Is this comment section to devolve into a discussion about software engineering practices? We could now write thousands of pages on that topic or we can cut down to the chase. If the manager can't tell whether his project is on track or not, remember nobody gives a damn whether it takes 50000 lines of code or 500 or that you closed X tickets, then the project has either already failed or the project manager is taking a huge risk with a greenfield project where he is just throwing things at the wall and seeing what sticks.

Surely you don’t blindly accept estimates? Do you dig down and ask what assumptions they are making for how long it will take?

This doesn’t sound like a problem with minimum expectations. This sounds like a project management problem.

I've been lucky to only ever work at places with very technical managers, who don't blindly accept estimates, and actively work with the developers to figure out how to work faster.

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.

Currently a manager, you wrote exactly what I would say, only in a much more robust manner. "Meeting standards" should not be cause for alarm. If it is, there are many things wrong with the company.

The problem with this line of reasoning is you’re assuming everything required to keep a company going can be reduced to a job description, but there’s millions of small, impactful ways employees can contribute that fall through the cracks. Being pleasant to your coworkers is rarely part of the job description, but it can make or break that coworker’s productivity for a whole day.

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.

True; I see your point and mostly agree with you, with the caveat that I'd file those traits as "being a decent human being with a reasonable level of emotional maturity" - things that I personally filter for in the interview stage.

Since when is a software engineer's output measured in "tickets" per month?

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.

This is the best response. I used "tickets" as a rhetorical device because it maps very neatly to pieces of flair from Office Space.

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.

TPM - bug squashing/or MBA manager would be my take. Would bounce if ever that was my metric. Its like GPM but for SEs.

I got reprimanded for not posting enough comments on issues and then was compared to another engineer.. who didn’t post timely comments on issues. At some point it’s not about trying to determine if you’re an underperformer but just that they want you out. Lots more tales from that crypt but I’m happy where I am at the moment

Finally saw "Office Space" recently! Now I know about "flair". 15 is the bare minimum. Look at <dedicated-employee> - he has what, 35 pieces of flair! Don't you feel like a slacker, barely achieving minimum expectations?

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

Exactly, most employees aren't in a position to allocate their own tasks. The entire point of management is to algin what happens in the company with the interests of the owners of the company. If management makes a mistake in allocating work and there is no flaw in execution by the employees the real dead weight lies in management.

Dead weight would be people doing nothing. After those come the negative contributors: they do stuff but is all politicking and scheming, or just waste others time. Doing strictly what you are really paid for is bad now?

“Enough” is not in the vocabulary of corporate vampires. Doing your job to the requirements should be acceptable, and that only works if your org is run by empathetic, reasonable leadership, you don’t tolerate the abuse of being squeezed, or you have a union. If the bar is never enough, you’re being gaslit, and that’s psychological abuse.

That's exactly why most performance reviews are a scam. "Always room for improvement."

And I think that's exactly the original commenter's point: if the company he works for ever decides that "enough" isn't sufficient to satisfy his boss, he's he'll move on.

Working to rule is the first labor action unions start doing ahead of a strike.

If you want to do piecework/hourly work, you should be a contractor.

Working to rule involves malicious compliance, which may very well be harder work than actually being productive. Just being unenthusiastic is not the same thing.

No, dead weight is someone who does little or no work, should be fired, but manages to fly under the radar somehow in order to keep their job.

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.

Apparently you have never continually excelled at your job and been rewarded with zero raises, zero promotions, zero added trust, and zero added authority or influence.

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.

> That's the literal definition of dead weight.

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.

Just doing the job you are paid to do is called dead weight now? That’s the exact ideology I refuse to follow.

The problem is when you tell your manager it'll take you X number of weeks to finish a task, and your manager trusts that you're working hard and that the task simply requires X weeks of work... but in reality you're barely spending any time on it every day, and could easily have done it in a few days. Meanwhile, the rest of the project is moving slowly because they need your piece to complete.

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!

This is kind of a wild take. Estimates should be reviewed like anything else on a team, and if the estimate doesn’t fit the timeline, the team should try to either split up / parallelize the work, drop scope, or look for a creative solution (usually involving taking on some strategic tech debt).

Work planning should be a team effort.

This is completely consistent with what I said. Even as a team effort, you want your manager to trust when you say something has some non-obvious complexity. And the manager wants to trust their team members.

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.

You might be misunderstanding what "minimum amount of work" means. The OP might simply be referring the minimum amount of work achievable without overexerting oneself via extra hours, working weekends, under stress, etc. Someone's minimum amount of work can be hard work. They literally said "I will always finish my work in the time it is expected to be finished." So if that amount of time is not satisfactory, it is up to the manager to ask for the time to be shortened- and then that becomes the new minimum.

Would you use the same argument if your company could easily pay you 2x your current salary but just pays you x?

It’s also a problem when the manager can’t tell if an estimate is bogus or not. It could be exaggerated. It could also be overly optimistic. To be a decent dev manager you need a feel for whether it’s in the right ball park. Or know when to bring in someone else who does.

IMHO (having managed small teams) a manager of technical team members needs to be able to accurately estimate how long something will take and the variance on that estimate. This is a core part of the manager's job. If a manager isn't technical enough to know how to do the tasks themselves if they had to, that manager should not have a job IMHO. This is part of what sets engineer-led companies like SpaceX apart from their "dinosaur" competitors and why SpaceX seems to be 10x better in output.

You’re literally on the literal wrong path of understanding what dead weight is.

I think you missed the productivity porn thread posted here https://news.ycombinator.com/item?id=32335165

No, the LITERAL definition of dead weight is " 1: the unrelieved weight of an inert mass 2: DEAD LOAD 3: a ship's load including the total weight of cargo, fuel, stores, crew, and passengers"

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. "

No that's not dead weight. Dead weight is people who don't contribute and don't get their work done.

Going above and beyond requirements is a personal decision.

Sometimes it’s the even worse folks - the people who do things that are net negatives and need to be drug around by everyone else like they’re an anchor around the companies throat.

Is it? I'd interpret dead weight as being... well a dead weight, say an anchor holding back progress. Or being generous at least not contributing anything even they aren't actively holding things back. Doing "the bare minimum" isn't dead weight though, they are still contributing

>I mean, I will always finish my work in the time it is expected to be finished.

But this isn't what a dead weight does.

> That's the literal definition of dead weight.

You must not have worked in companies with actual dead weight.