Taking any kind of responsibility for a spec is a fools mission. In most shops, doing specs is not highly regarded work. You don't earn much respect or career progression. You will inevitably make mistakes and have failures that make you look foolish and incompetent. You will get blame for this, and other stuff besides. Your successes will be the invisible non existence of a problem no one expected. There will be no praise, no raise.
This is true for technical and non technical "owners" of a spec. A spec might be the most important and expensive thing a department head is up to. Most determinant of department success. They will absolutely not proceed without a liability shield between them and responsibility for the spec.
Heads-I-Win-Tails-You-Lose is just an extreme condition on the spectrum of mismatched odds in organisational world. The place where successes are overcompensated and failures undercompensated is the smart place to be.
Only fools go on fools missions.
More realistically, someone is hired for the gig. They maintain a strict CYA trail, documenting who asked for what using which system... and blame/responsibility is dispersed into the system. At this point, it's boring.
Yeah, occasionally a process gets designed that looks like "random people who have no real incentive to do a good job put together a spec and send it to me for review/sign off." And the expectation is that it's just a quick once-over on my part so "can it be turned around some time this week?"
I always explain that in this kind of process, all the responsibility falls on me. If they write something that's incorrect and I miss it, it's never that the spec writer should have known better, it's that I reviewed and signed off on it. Which is fine, that's part of my role, but if that's the responsibility I'm taking on then the spec review is going to be scheduled as a real deliverable with real time attached to it and if you need it ASAP then you can pick something else to de-prioritize.
A good one is "we spent 6 months working with the customer to build this spec, now we're short on time, can you review this week?" Well, if it's so complex that it took 6 months to build why do you think it can be reviewed in a week?
It's this idea that spec review is just a quick review but the reviewer is then responsible for anything that's wrong with it that causes a lot of issues in my world.
Thanks. It could be worse, I'm in a position where I can just push back on that crap. The only really frustrating part is when the same people do it over and over and I have no real easy way of influencing them because they are outside my org.
Sounds like something a software architect/designer should do or anyone who gives specific orders in a hierarchical organization.
There is always a spec. Either explicitly written down or scattered among emails, tickets and other ad-hoc communication. You can't escape it. Those who decide to do or let other people do have the responsibility anyways.
Taking any kind of responsibility for a spec is a fools mission. In most shops, doing specs is not highly regarded work. You don't earn much respect or career progression. You will inevitably make mistakes and have failures that make you look foolish and incompetent. You will get blame for this, and other stuff besides. Your successes will be the invisible non existence of a problem no one expected. There will be no praise, no raise.
This is true for technical and non technical "owners" of a spec. A spec might be the most important and expensive thing a department head is up to. Most determinant of department success. They will absolutely not proceed without a liability shield between them and responsibility for the spec.
Heads-I-Win-Tails-You-Lose is just an extreme condition on the spectrum of mismatched odds in organisational world. The place where successes are overcompensated and failures undercompensated is the smart place to be.
Only fools go on fools missions.
More realistically, someone is hired for the gig. They maintain a strict CYA trail, documenting who asked for what using which system... and blame/responsibility is dispersed into the system. At this point, it's boring.