[erhserhdfd]

> As long as they perform the tasks of their jobs, why shouldn't they be "getting away with it"?

Curious how you would measure whether they are "performing the tasks for their jobs". I think most folks would say that measuring SE output is very difficult to do and as such, most managers give their team the benefit of the doubt that they are working at a reasonable but sustainable pace.

I am not sure that I personally would want to work at a place that places huge emphasis on measuring my output, even if that would free me up for potential OE. It seems like this thinking leads to a commoditization of software engineering work and promotes a very transactional relationship with an employer.

[financltravsty]

I've found it's useful to think of it through a lens of "expectations." The organization that pays me money (my place of work) has a set of goals it wants to achieve. In order to achieve those goals it hires representatives (my boss, his boss, etc.) to orchestrate the achievement of those goals. So now I am hired to help move those goals forward, and in return I am compensated with money.

However, an organization's goals, and its expectations of what it can and requires to achieve, as well as how long it will take, are dynamic. That means its representatives decide what those goals are. If I can convince my boss/skip/what-have-you that certain goals will require more time and more resources, then I can stretch their expectations into the future in such a way that they benefit my ends.

So long as my boss's expectations are met, then I am "getting the job done."

No different than if my boss decides to press screws into my thumbs on another "top priority project that needs to be done ASAP" to put pressure on me so that he can achieve his goals.

So perhaps a better way to measure productivity -- if we are to put a word to it -- is from the age-old intuitive standpoint: does it feel like we are moving closer to, and achieving, our goals? I think an approach any more concrete or systematic than that is just a tool for gaining leverage in the aforementioned negotiations.

[waynesonfire]

"..does it _feel_ like.."

Ahh, that feel word. I love it. Management conveniently also wants to make you _feel_ heard and _feel_ like that promotion is just around the corner.

[november84]

I'm at least 20k underpaid and during our last review period I mentioned this and was told all salaries are being reviewed to get them inline an competitive.

It's been months and I received the same answer when I asked.

They're also actively hiring to expand our team and the upper end for the same role is 50k more than I'm currently getting.

When we hire someone new I'm definitely inquiring how much they're getting... It's unfortunate companies treat people this way.

[harryquach]

Out of curiosity, are you looking for a new position? This is generally how I have realigned my salary with market rates.

[november84]

I began actively looking after the last review. I definitely should have started sooner.

Outside of this salary nonsense it's an overall good place to work though and a pretty cush job. Just frustrating that loyalty is punished because it can be.

[reactordev]

Not the author but I suspect something like this:

Assign engineer 4 stories due this sprint. After a few days, 1 story is done. After a few more 2 more are done. Before the end of the sprint, the last story is done. All 4 stories are demonstrable. All 4 stories pass peer review. Engineer is even around for brainstorm sessions and ceremonies.

Some places go a lot further than this but this is my personal bar as a manager. That you're in standup, that you're doing the work, and that the work doesn't require rework and is accepted by the team.

[erhserhdfd]

Yeah I see your point. A few thoughts:

1. This assumes that that a someone can/will usually accurately scope 4 stories, with proper requirements, and clear peer review standards. In practice, this can be hard to do and inconsistent.

2. If someone falls behind on their assigned story quota, how would a manager know whether that is because the story didn't meet the criteria in item 1, or because the person isn't putting in sufficient effort because of OE or other commitments? How I typically see this play out is most people assume that its not related to effort and try to work with the employee to push back deadlines and better refine the story.

[coldtea]

>2. If someone falls behind on their assigned story quota, how would a manager know whether that is because the story didn't meet the criteria in item 1, or because the person isn't putting in sufficient effort because of OE or other commitments?

They could expect to know the reason this happened (e.g. prerequisite not ready, this design issue is not solvable so we're testing alternatives, etc.).

And if it happens often, they can always fire the person.

To return your own question: "If someone falls behind on their assigned story quota, how would a manager know whether that is because the story didn't meet the criteria in item 1, or because the person isn't putting in sufficient effort?"

Whether that's because they just slack off, or because they don't have the skills so everything takes extra time even though they work hard, or because of "OE or other commitments" is irrelevant, isn't it?

Besides, it is not just "other employment" that would have such a concern. The same is true for e.g. trying to build a personal startup MVP on your spare time or building a simpler passive income side-gig, both things which HN crowd loves, and which employees should totally be allowed to have (and lots of IT success stories wouldn't be possible if they weren't).

[reactordev]

>"1. This assumes that that a someone can/will usually accurately scope 4 stories, with proper requirements, and clear peer review standards. In practice, this can be hard to do and inconsistent."

I highly suggest you focus on this rather than "are they doing the work?". Having accurate estimates and proper scoping of stories is vital to predicting releases and maintaining a road map. If you feel your org is lacking in this, I would focus on this first. As engineers, we need to scope multiple things into the story. Development, Testing, Deployment needs, Documentation. It's not just a "ticket" to do "x". Story points are complexity metrics. Not man hours. Don't feel like you need to complete Y story points to be effective. Story points are relative. Which brings me to your second point.

>"2. If someone falls behind on their assigned story quota, how would a manager know whether that is because the story didn't meet the criteria in item 1, or because the person isn't putting in sufficient effort because of OE or other commitments?"

Quota is why you fail. There isn't a quota. There isn't a set number of stories a person should do. Only what they are capable of. Also, one 8 point story is probably worth more business value than eight 1 point stories. Not always, but usually.

You can measure an individual's contribution to velocity, you can measure an individual's number of stories completed. However, neither of these are metrics of whether that individual is providing business value.

To measure whether an engineer is pulling their weight, talk to the other members of the team about work deliverables. You'll know pretty soon whether or not that individual is supporting the team (and thus may have lower story point totals) or is just absent from the discussions.

You can NOT justify firing someone simply because they have another job, so long as it doesn't interfere with their duties or is during the same hours if hourly. At least not in the USA. There is no law against moonlighting so long as there isn't a conflict of interest.

I mean, you can exercise at-will employment and just fire them because you feel like it, but your reputation will tank.

I know employers want to trap their employees into working just 1 job, 1 career, for 50 years, with no strings attached, and no pension to offer, but the reality is many of us have to work two or more jobs because we can't afford our mortgage or need to pay off those predatory student loans we were promised would be eliminated but weren't.

So here's my take. If you suspect someone is working more than one job, be an adult and have a 1:1 and ask them about it. Ask them what you can do for them to have them commit to only working for you. If you are offended that they dare work two jobs when you believe the company is providing more than enough, I bet you don't have a 7% mortgage.

Instead of leading with the stick, try the carrot. Empathy will go a long way.

[coldtea]

>Curious how you would measure whether they are "performing the tasks for their jobs".

First the product manager should have some tasks in mind (e.g. get the new product X to ship), and an idea of a realistic workload to be done in X time.

No task should be given without a timeframe (which can be flexible or less flexible) for its completion in mind. When tasks are done give the next task+timeframes bunch. This can include new features, refactoring, and code-debt fixup tasks.

As long as those conditions are met, it should be no problem to see if they're "doing their job" or are getting behind etc.

If what they want is: "let's keep this person occypied to 100% capacity, giving them arbitrary new tasks or even busywork in a constant feed where everything has to be done ASAP with no timeframe in mind", it wouldn't work. But that's a slave ship, not a software planning process. Even factory production lines have specific quota to hit.

>I think most folks would say that measuring SE output is very difficult to do and as such, most managers give their team the benefit of the doubt that they are working at a reasonable but sustainable pace.

Well, they shouldn't measure SE output with anything expect whether their targets are met. If they find those targets are too lax, it's not them that they agreed to them. If targets slip, the developer should have a reason -- specific issues preventing it, waiting for other part to complet, an unexepected hard problem, etc.

[coldtea]

s/it's not them that they agreed to them/it's on them for agreeing to them/

[rkachowski]

In recent history we have seen an unprecedented situation where large tech companies make _very_ healthy profit, yet start waves of layoffs a couple of times a year.

This (unfortunately not so uncommon) hand wringing around reducing employment to a "transactional relationship" seems crushingly naive.

[pydry]

I think the causality is probably reversed. Commoditization and development of a transactional relationship with the employee leads to overemployment.

Ive noticed that the places where people do tend to be the ones where 5x productivity is rewarded with 1x the pay and a pat on the back, which is more common than the more rational 5x pay for 5x productivity.

If that is the case then the rational economic agent (a developer) operating in a free market will find an outlet for that productivity that produces material gains in line with their increased productivity.

[friend_and_foe]

I think it's pretty simple: your boss reviews you and says you met expectations.

All relationships with employers must be transactional. Or rather, they are transactional. You either know it or you don't. You're getting compensated to perform duties. Or you're getting compensated for time. Or you're getting compensated for expertise. The entire relationship exists for the sake of mutual benefit in a clear agreement of terms.

[5555624]

>> As long as they perform the tasks of their jobs, why shouldn't they be "getting away with it"? > > Curious how you would measure whether they are "performing the tasks for their jobs".

How do you measure performance? Every job has some sort of performance standards. My manager outlines ine every year and I have an annual performance review (and a mid-period one at six months). If I am not performing up to expectations, I will hear about it.

[cxr]

> most managers give their team the benefit of the doubt that they are working at a reasonable but sustainable pace

Close examination shows that this is just a covert way of saying: a manager, tasked with figuring out whether other people are doing their jobs, decides that the best course of action is to not do his.*

> Curious how you would measure whether they are "performing the tasks for their jobs"

What is this, a public referendum? Another way to offload the costs of working out how to make a given business successful onto others? It depends on the business. And it's work that needs to be undertaken (and the associated costs borne) by the business itself.

*(Only time in my life I've ever gone for the gender-specific rather than the neutral "his or her" or "theirs". The phrasing doesn't seem to work as well another way, though.)

[civilitty]

If they haven't been fired, it means they're performing the tasks of their job. If they weren't, why would they still be employed when the vast majority of states have at will employment?

[ghaff]

Because, at least if times are good, there's a pretty big gulf at most companies between "You're our best employee on our most important project" and "You're an irredeemable screwup who needs to go now." Most companies are slow to get rid of people even if they're just getting by.

[cxr]

Why would they get rid of someone who is getting by? If "just getting by" is inadequate, then they're not really "getting by". The goal in discussing this topic is clear thinking, and these weird, euphemistic/hyperbolic phrases are the enemy.

[ghaff]

It is sort of a euphemism like acceptable, "OK", and any manner of other descriptors that we probably shouldn't use as much as we collectively do. But in this context, they mean it's probably too much trouble to push you out the door right now given the hiring market but we're really not feeling the love.