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