ROWE would essentially encode a normal software job into a mix of goals and expectations. E.g. if you're expected to average some fraction of the team's point velocity over the year, that's written down. If you're expected to jump from a finished ticket to the next, or alternate reviewing and starting new work, that's written down. (A ROWE job description can totally be written to keep you stuck at work if it has availability or response time expectations.)
If you work at a smart company, your manager doesn't spell out much of your job, and ROWE can encapsulate that if you and your manager have a shared understanding of what an effective month/quarter/year looks like. If you're that kind of senior engineer, the exercise should prompt some good discussion about reducing the number of hours you spend on more measurable, less effective tasks.
The goal is to create something that both you and your manager buy into, so they feel good if that's 'all' you do and you feel it's doable to review the list and feel good about it before the end of a typical workweek.
As you might be able to tell, it's not easy to come up with a list that achieves this. Most managers will be too timid, or won't understand themselves well enough, to put the real full expectations of a job on paper.
However, a 'certified ROWE' workplace undergoes coaching so they have a better chance of success, similarly to how some organizations do for OKRs if they want to use them as intended and not as fantasy aspirations.
In practice, if you have a boss that hates ROWE, you're going to have a tough time convincing them that you've met your objectives enough to step away from work for a bit, no differently than how any other flexible work arrangement stops being flexible the moment your boss stops trusting you.
(I'm close to a ROWE-certified organization that has been successful with it for about 15 years.)