Sometimes it is. I don't want a Head of Product deciding how keyboard events work and I doubt the engineers want that either.
Sometimes it isn't. Like when that phrase puts an early end to a conversation the team still needs to have.
Take the patient booking example from my last email. Patients need to choose an available appointment without using a mouse.
I'm pretty sure that designers and engineers can work out how the calendar behaves, where focus moves and which component to use. They understand that work and they're the ones those decisions belong with.
Now suppose they discover that the solution they chose, the calendar, can't support keyboard use within the planned timeline.
Now that's a different conversation. They need to consider a different approach, reduce the scope elsewhere or revisit the release date. Shipping the calendar as it stands means some patients won't be able to book at all.
An engineer can't make that trade-off alone. Neither can a designer. They also can't do it if it's just the two of them together in a room. They need input and agreement from the wider team.
This is the distinction I care about most. Technical decisions belong with the people doing the work. Decisions that change who can use the feature need shared agreement.
That doesn't give anyone permission to exclude people, no. It just means making the constraint visible so that everyone can agree on a way forward.
If we call it "an implementation detail," we're not removing any of the work. We're just dumping that decision onto someone else later in the process, when there's less time to respond appropriately.
Whenever I hear that phrase now, my ears prick up and I ask, "is it though?"