In a typical (small) startup, the CTO is responsible for ensuring that technical problems are being treated, that people with the right skillset are available, and that the product is being developed or improved as the business pitch/value statement requires.
I've seen some small startups where the CTO would do a lot of coding and be a very hands-on person himself, but in these cases, there normally wouldn't be a middle manager between the CTO and the engineers/developers.
One (possibly cultural) problem that your staff may have is that everyone may be trying to show leadership potential. And they think they should do this by bossing others and imposing their ideas. This is something that a good manager needs to prevent.
One solution I would employ is telling each and every employee in a one-on-one meeting that they will all have their chances on transitory leadership roles before anyone gets promoted. This avoids part of the haste to show off.
Second, people should have clear responsibilities and interfaces as much as possible, preferably even before ideas can be brainstormed. This way people always know who decides what and who executes what. I have different conversations with people who own products to which I collaborate, versus conversations with people who collaborate on projects I own. For example, I need to be very nice and not too stubborn when suggesting something that requires rework to a different project owner, while I justify but impose changes in projects I own. Try breaking up your projects into features and assign each employee as the tech lead of a feature. Explain to the tech lead of the moment that someone else will be the lead of the next feature, and that true leadership also requires people to enjoy being lead, while good professionalism involves respecting other people's responsibilities.
Third, it may come down as a personal matter to a lot of people, but keep in mind that some degree of autonomy is important to everyone. Unless you are pretty much lost in your job and have no idea of what you are doing, you'd be annoyed if someone wanted to micromanage every detail of your work and deliveries. So once the last step is clarified, make sure to tell people that they should know when they aren't executing something that some degree of freedom and personal style should be allowed to the actual executioner. So tech leads and managers should not ask coders to do things in the exact manner that these tech leads would have done themselves, but rather they should specify requirements. A delivery is not wrong if it meets requirements, and incomplete/incoherent requirements mean poor leadership.
Do motivate people to exchange ideas about how to approach problems, but try to make sure that in every discussion, everyone knows who has the final word on each part of a project. And make sure that managers/leads know that they don't always have the final word when talking to coders. Likewise, the CTO has authority over managers, he should have enough trust to know when he is supposed to question but not override a manager's decision.
Speaking of the CTO again, he's probably a shareholder in a company. This means that sometimes is better to make him happy than to do what is the utmost best for the company (though normally, you can convince the CTO of what's best, if you are right, this is much more difficult for a non-technical shareholder/owner). Remember the phrase "generate value" (and not profit/earnings) for shareholders. Happiness adds to that value. too
One good practice when there are layers of management is that upper levels don't talk to people being managed by middle management directly (in applicable cases, which I'll make clearer soon). So, if you make a decision and ask the coders to use a certain pattern, the CTO should not tell coders that this pattern is bad and they should do differently without talking to you, as the coders will not know who to follow and trust. Instead, the CTO should talk to you, get to an agreement on what should be done (you should have some level of autonomy, but he needs to be made happy at the end of the sprint), and then you convey the decisions to your team of coders. When C-levels override managers in public, they end up having no middle management in practice. So if the CTO wants to impose something, he should preferably do so in private when talking to the responsible manager.
It may happen that in some projects, the CTO should be the actual project manager, and act as such, but these cases should be made clear and distinct to all employees such as: "Joe (the CTO) is the manager of project X, to which Bob is only a contributor, meanwhile Bob is the manager of project Z, so Joe avoids getting involved directly in it".