Hacker News Reader

Comment by salixrosa | Hacker News Reader

This sounds like it might be good thing for the company. Having employees who have extra capacity is incredibly important for an organization that wants to get things done; if you're constantly hard at work on something important, when something else comes up (someone has a question, there's a bug or an outage, whatever), you either have to delay the thing you're already working on, or delay the thing that came up. This tends to have a cascade effect on most kinds of work, locking up all your people resources.

Plus, those other things you're doing sound like they overall, in the long-term, probably give you a wider range of knowledge, improving your usefulness.

Just wanted to add a voice against that sort of Taylorism perspective on work.

View on HN

I'm definitely not in the same boat as the OP (trying to get away with doing the minimum), but because I hate to be the long pole on a project, I always try to get my pieces done well in advance of when they're required. As I work primarily on infra, I can usually manage to pull this off.

What this means is that often when crunch time hits, I've got excess capacity I can use to help "row the boat" (or maybe bail out water from leaks?). Excess capacity is extremely valuable as lots of folks are really bad at time estimation, so having some more senior "floaters" around can really help get projects completed.

Excess capacity is also useful for longer-term efforts. You need at least a few folks who can get out of the low-level crunch mindset and figure out what needs to be done for sustainability of efforts, or else you just end up in mega-crunch forever.

I've seen something similar backfire for a guy I worked with. He had this idea that he would get his shit done Monday-Thursday and have an easy WFH Friday.

People ended up doing most work towards end of sprint and Friday would usually be really busy - basically he always had to be present and management would offload priority stuff to him since he was done. So he'd end up busting his ass all week. Eventually he got tired and reverted to standard schedule - but this meant his relative performance dropped - I saw him get singled out in a review for performance drop (and not a lot of people noticed when he was going above the norm).

Obvious your mileage may vary, and timeframes matter. I'm talking about getting my pieces done weeks or months in advance of when we need to ship, not days or hours.

I'm surprised he didn't just switch his "light day" to Monday or another weekday.

But the end result would have been the same - he wouldn't finish his tasks ahead of time, he wouldn't have spare capacity on Friday - management notices this and thinks he's underperforming

Seems like if he had done that, he would have been just like the rest of the team, getting everything done last-minute but still shipping stuff.

>if you're constantly hard at work on something important, when something else comes up (someone has a question, there's a bug or an outage, whatever), you either have to delay the thing you're already working on, or delay the thing that came up. This tends to have a cascade effect on most kinds of work, locking up all your people resources.

Working in a retail store/break-fix repair/MSP environment, for a small business in a small city, this is absolutely the case. There is nothing more frustrating than having three customer projects on your plate, all of which are important (think "the email server is down"), and then the doorbell or phone rings and you end up spending half an hour walking an old lady through resetting her facebook password. It's an absolutely massive productivity killer, as well as making the day feel longer.

More employees would be the normal solution, but that's not possible here (we've had more in the past, it wasn't financially viable, apparently). Unless of course they started paying commission based on what people actually got done instead of a regular wage, which I'm not a fan of. (Though to be fair, if we did switch to that, the one employee who barely does anything would either get his ass in gear, or leave, so win/win maybe?)

Sadly, from what I've read the commission-based approach often leads to worse long-term results, especially in software engineering. It depends on the kind of work, of course. The metric I use (and in this case I have no idea how others look at the problem) is the number of decisions the person has to make, especially having long-term effects or effects on other parts of the company. It's hard to make the right choice for the org when you stand to make a bigger chunk of money right now from the other option.

Yep, there was article that recently came up on Hacker News about maintaining some slack in your work schedule so that you can always be responsive when an issue comes up. I'm having trouble finding it because searching for "Slack" on Hacker News turns up a whole other range of things...

I feel like I am in a similar boat to OP. Often feeling like my regular work doesn't take up a full week and not trying to fill up every bit of that 40 hours. I also spend a lot of my time "poking around" and not doing my own work. Seeing what others are working on, learning random things that may or may not be applicable to my job. But performance reviews come around with words like "very responsive!" and "always knows what's going on in the program and can jump in to any project"

I'm assuming you're thinking of this Farnam Street post: https://fs.blog/2021/05/slack/

Yes! That is the one I was thinking of.

I think there's a tremendous value in having insurance/redundancy for supporting existing critical SW projects/infrastructure.

So while day to day there might not be immediate obvious work, much like a fire fighter or life guard; if the servers go down or coworkers leave there needs to be some ballast that can steer the ship.

That said, if you don't actually know much of the companies code base other than stuff you've directly written, you could very much be providing only perceived insurance versus actual insurance.

I used to work a tech support job overnight. Some nights I'd take two calls.

This was expected for the reasons you noted. When there was an emergency someone needed to be idle in the first place so they could immediately respond fully focused.

If you're available for work you're working. Only taking 2 calls isn't slacking. They're paying you to be available and so they should because they're impinging on your free time.

Same story for me, they just needed someone available for emergencies. As long as I could respond when pinged, they didn't care what I did with my time. My boss came in one morning, saw I was playing Fallout 4 on my (personal) laptop, and just asked if it was any good. I finished a lot of books I wanted to read, and had lots of time for personal projects, but ultimately the boredom and overnight schedule were too much. I'd rather feel productive, personally, but for a certain type of person that job would have been paradise.

I whish I had been productive.

I played a lot of Civilization 3 and Quake 3 on company time.

They can pick up low priority tasks and if something of high priority comes in, it takes the precedence. An employee can also learn new tasks, rotate to different teams, cross train, fix old code / refactor, take a sabbatical-on-call, write documentation, etc which do not get in the way of taking on high-burst high-priority tasks. This is far better in terms of company's productivity than pretend-work that the OP is describing.

I don't think its better for the company as you suggest. It is possible to use good sense of prioritization and still have 'extra capacity'.

I don't really have enough information on the specific's of OP's job and what they're doing with their spare time. Reading tech books sounds like learning to me, but otherwise I don't know.

I think that it's really difficult for a lot of people to see the value they're providing outside of the proper business tasks they're assigned, and once there are tasks assigned to fill up all the time, everything breaks down. It doesn't matter if your task is something as irrelevant as "provide documentation regarding this vendor relationship," once it's on the board it can't be dropped and so you're no longer available to try the new tool people are looking for feedback on, or whatever.

The other thing doesn't even have to be high-priority, but if you're at a large enough organization, there are lots of things you'll realize can't be done well because too many people need to be involved, even if it's just a little bit of time. My org can't make any movement on, for example, API clients or API documentation because there are lots of different needs, but by the time you've gotten through the initial conversations it's a six months later, because people weren't available. There are many efforts we can't get done because that effort isn't priority for the team's involved, but requires time from people on those teams.

Ideally, of course, we try to minimize those things. But I've yet to hear of a sizeable org that has none of those kinds of things.

Eliyahu M. Goldratt has some great books explaining in great detail why this is the case: https://www.amazon.com/x/dp/0884272079 https://www.amazon.com/x/dp/0884271536

Also, extra time is where new ideas and new projects come from.

It's better to spend free time on your own, actually. Managers don't like you to spend free time to dig around. I learned it hard way.

Or in productivity, utilization != throughput.

Reply on news.ycombinator.com