"Slacking off" doesn't enter into the equation. Is your output worth more to the company than it costs to pay you to produce it? If yes, then great there is no problem to be solved.
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.
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.
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.
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....
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.
Logging out of IM when busy is a simpler skill :-)
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.
>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.
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.