Throughout this topic there is a thread of "only [talented] software engineers can rate software engineers". So what is needed is an association of talented software engineers.
[0] with apology if you prefer programmer or other term.
The IEEE has built what they call a software engineering body of knowledge. I think it's mostly academic bosh. Am I ignorant for not understanding their reasoning? Who builds the first criteria for what a body of knowledge should be? Having read academic SW engineering publications, I'm convinced that academia does not have the total answer.
I'm convinced that, theoretically, there should be a professional organization, and an interview should be a conversation about people skills + a credential check. But I am - today - not sure how to bootstrap such a thing. If something comes along that I think embodies what is really important (both industrial and academic rigor), I will likely leap on that bandwagon and chug the kool-aid.
Just because you have a technical, or ex-technical, person in charge of your team doesn't mean it's going to be well managed. I'm sure that's something we've all seen. Every reason that is true will apply to the guild, in addition to the usual ugly prejudice, artificial supply constriction, and self-destructive conservatism that all real guilds, associations, and unions display.
The top people don't need to join, because they are well known and have reputation. The people that do want to join are those who need the trimmings of an endorsement. So gradually it turns into a grouping of people slightly below average trying to improve themselves. Plus, the people who are attracted to this type of thing work in industries where others are bedazzled by credentialism, like academia and government. A group of people dominated by academics and public servants telling me how good they are? Thanks, I'll pass.
Peer review aka open source.
1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives.
2. Then you have the disaster zones - again they are easily recognisable.
3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term.
If your development team isn't effective, it's a management problem, not a developer one.