One way to think of it is that you're not always being paid to be doing something specific, but rather to be available on short (e.g. 15 minutes or less) notice.

Sure, some roles require that, but most definitely not the majority.

In development at least, most of the times I hear this, the "availability" is only needed for random unplanned meetings from useless managers that can't actually plan or work asynchronously.

The organization as a whole or individual managers can't do their jobs well and they make the people that actually get shit done pay for it by "standing by" for no good reason.

Ironically, they also completely ruin productivity with these interruptions.

> In development at least, most of the times I hear this, the "availability" is only needed for random unplanned meetings from useless managers that can't actually plan or work asynchronously.

Really? Because it's pretty routine for me to get pinged on IRC/slack/whatever by another engineer who's looking for help with something. Obviously I set the expectation that I'm not going to be able to instantly reply to every ping so some things are going to have to be async, but there's definitely a lot more than just managers that could ping me.

Are those pings that require immediate attention? In my experience, no.

The vast majority of time in my career, if you have a minimum amount of decent planning, you won't get blocked because you can't talk to another person immediately. And on healthy organizations, even if you do get blocked, you can simply work on something else while that particular task is blocked.

If you really scrutinize all these availability claims, they pretty much all come down to lack of planning.

Planning for blockers, planning for communication gaps, planning for maximizing asynchronous work, planning for decisions that require specific people, etc.

So many people are horrified by the word "blocked" when it's most times an artificial block created by their own systems. If I can't move forward on something, I'll start on something else and come back to the other one later.

This. If you have a high-functioning team with good async culture/habits, in my experience "blockers" are not a big deal. I work closely with 5 other people and we are in 6 different time zones and I can honestly say that we are more productive than teams I have worked with in a traditional office setting. Sure, I cannot just walk over to a teammate's desk and ask a question, but I also don't have anyone walking over to my desk to interrupt me with a question.

We are all intentional about _over communicating_ what we are working on and where we will need support from from each other. Everything else pretty much just flows naturally from that. There are (rare) times were I cannot progress on something that day because I need feedback from someone who will not be online for 10 more hours, but it is just a built-in assumption that this will happen and I always have other work queued up that I can do if I get stuck....

Sorry, but you don't sound like a very solid teammate to me.

>> you can simply work on something else while that particular task is blocked.

This attitude is a recipe for massive amounts of parallel WIP, not to mention knock-on effects and blocking dependent work. "Planning for blockers"? You're either being intentionally simplistic or not really concerned with anything beyond your own work. Enter "useless managers" like myself who need to "needlessly interrupt everybody" to try and get things coordinated...

It's not about who can ping you. It's about the expectation of urgency behind that ping. A "ping" from a manager calling an unexpected meeting demands a lot more attention than a ping from a colleague looking for help most of the time.

> Because it's pretty routine for me to get pinged on IRC/slack/whatever by another engineer who's looking for help with something.

That's why when we were all colocated in one building, I was logged out. I made it clear they were welcome to drop by my cube whenever they wanted, but I would not be available by IM. It cut the interrupts by half, easily. People use you as a crutch. When you raise the cost even minimally, they are suddenly willing to solve their own problems.

That's the one aspect that COVID destroyed. Now I have to be online as people can't just walk to my cube.

What I have started to do is to block an hour every other day, and when someone sends me a Slack message that feels like I am just their crutch, I snooze it until that scheduled block of time. It works like a charm. I still keep an eye on the urgent questions that I have to answer quickly, and many questions have evaporated by the time I come back to them.

This is another skill that like knowing when to say no, seems counterintuitive when first entering the working world. Sometimes the correct answer is not to drop everything and slowly explain something for the third time that would have been trivial to Google in the first place. You are not doing yourself or them any favors by being overly available for every little question. The kind of person that does this often has a kind of learned helplessness that they need to be shaken out of from time to time.

> This is another skill that like knowing when to say no

Logging out of IM when busy is a simpler skill :-)

There's an opportunity cost question. If your output is worth more to the company than your costs, but it would be easy for them to hire someone at the same cost who has more output, then you're at risk.

> but it would be easy for them to hire someone at the same cost who has more output

History has shown that it's not easy at all to replace someone. It's difficult to find good people and convince them to join you and it can take a long time. If you can write code, you should always have the upper hand on your employer especially if your co-workers also realize that.

People are not replaceable parts. HR would absolutely love it if all developer 3s were the same - and it should be the case that one developer 3 is more like another developer 3 than a developer 2 - but people are different and have their own quirks and strengths.

And, of course, you're ignoring training costs which are usually a big factor in companies that aren't incompetent. That Senior Dev that's 15% above marketing asking rate but who knows your system inside and out... do you really want to spend six years training a (potentially highly proficient) newbies on all your systems and the subtle intricacies. And how long will it be until you, the manager, trust that new Senior Dev like you did the old? How many fires will you both need to walk through until you see an availability alert and just trust the Senior Dev either is dealing with it or would be ringing your phone if they need extra resources?

It can take quite a while to get a new employee (again, even a highly proficient one) to that place where in a meet your product team can be going over a proposal and your Senior Dev raises there hand and proceeds to calmly explain the incompatibility with the current system and how much it will cost to overcome those incompatibilities - and if they remain silent then you know they've done those calculations and consider it in hand.

Hiring a replacement is an extremely complicated calculations that most companies just punt on - for good reason.

The vast majority of people have been replaceable parts since the days of Henry Ford. If you're not one of those people, congratulations on your privilege, but I bet you're not as irreplaceable as you might believe.

It's a spectrum. You can replace someone to operate a cash register in a week. You can't replace a surgeon in a year, depending on how specialized and renowned. But sure, the majority of lower income work is more replaceable.

>but I bet you're not as irreplaceable as you might believe.

Given all the tech layoffs, maybe. But I think that has more to do with lacking either the money or interest to invest in certain products given economic forecasts.

The fact that your typical tech interview is a month+ and at least 3 (usually 5 or more) rounds of interviews suggest that it's not trivial to replace a dev. Tech is probably middle of the road to train, which is why they'd rather grab interns from college instead of setting up apprenticeships that can fine tailor towards the exact business needs.

While the situation might be different in the US, I can tell you that in Europe, particularly in Germany, there seems to be a changing work ethic in the software development field. Our company, based in the south of Germany, has increasingly been hiring talent from Brazil and India over the past year. We're not just bringing them in for developer roles, but also for management positions. It's not about having them work remotely to save costs; we're actively sponsoring their visas and handling their relocation. Here in Germany, it feels like some individuals prefer to work as little as possible, maximize their earnings, and are resistant to fixed deadlines or essential tasks and meetings. This trend is concerning, and I'm genuinely worried about what the future holds for our industry here.

> Germany, it feels like some individuals prefer to work as little as possible, maximize their earnings, and are resistant to fixed deadlines or essential tasks and meetings. This trend is concerning, and I'm genuinely worried about what the future holds for our industry here.

You should rest easy because all of those things lead to more relaxed and happy employees which leads to less turnover, better output and higher quality software. Software development is a creative field and companies that treat it at as such are rewarded.

> You should rest easy because all of those things lead to more relaxed and happy employees which leads to less turnover, better output and higher quality software. Software development is a creative field and companies that treat it at as such are rewarded.

That's populism. Software development can be some moments very creative and fun, but it is mostly a hard work. Specially as full stack dev/devops, doing scrum, you have to do everything.. filling bug, tracking problems, looking at telemetry, deploying, discuss new features, improving pipeline..

It does enter the equation, because idle time «working» or slacking off at work could be better spent pursuing other interests that improve quality of life and most likely increase productivity over time.

I don't think this time should be labeled as "slacking off". It's just not working and there's nothing wrong with that if you've already met your obligations.