Being alpha geek and able to code well doesn't correlate at all with the kind of management and people skills required to run a team. There's a ton of Daily WTF as examples of team "leaders" who are great coders but cannot communicate at all.
The standard MBA solution for this situation is the "surgeon model" used by medical teams. The tech lead makes all the technical decisions, but there's a team leader or manager who makes all the leadership decisions, and does the "people stuff".
That "people stuff" totally includes firing team members who the technical lead doesn't like, for whatever reason.
my mba program emphasized that (1) effective teams can be built from a diverse variety of people and organized in many different ways, and (2) the effectiveness of the team rests on trust and honest communication between team members (technical skill is rarely the limiting factor of a team).
Also worth pointing out: Sometimes (often) the people who are most vocal about this are not the best coders :-)
This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:
> Or you can just start your own company and make your own rules.
When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that.
In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them.
If they are total assholes, you don't want to work there anyway.
But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.