I am working in the Startup world and noticed that often there is a problem of too many people jumping on the issue, wanting to lead it, make decisions etc

I know it from Corporate world it was totally different. Managers lead, make decisions, employees make it happen.

How to ensure leadership, people aligning vs everybody wanting to show how smart, important they are and making their case and marketing?

If I am a Head of in the area we work on, how to align people around me? As I said, in startup environment it seems challenging.

What are best agile practices, leadership practices?

In other words how to tell, there should be one accountable and topic owning Person (Head of) working with others but also making key decisions, direction? Since now I feel like we are going all possible directions working on topics. Seems very chaoitc and not organized.


Update 1:

What is also bad is that CTO likes to put his hand on almost everything tech and management, creating confusion and also misalignment between decisions made in lower ranks (Heads, managers etc).

CTO is also one of the co-founders

Bonus question: What should be role of CTO in startup?

  • 2
    If you didn't see the same thing in corporate world, it's only because it was happening too high above you.
    – ojs
    Jul 15, 2021 at 19:06
  • 2
    This is hardly just a startup thing. Saw it in gov. Jul 15, 2021 at 19:13
  • Interesting view. Actually could be....as a corp employee I did my things, this mess was not known to me. Here, in a startup, everybody see this mess, I think that makes employees not able to work efficiently
    – dev
    Jul 15, 2021 at 19:13
  • 2
    THis is a common problem all over business. I've worked at startups and big companies and seen it at both. I kind of laugh at the idea of "managers lead" in corporations, mostly managers hide and make little fiefdoms. Jul 21, 2021 at 5:13
  • 1
    This is a very poorly phrased question (or rather set of questions). It jumps between too many things like theoretical problems, asking for best practices, asking for tips on agile, and discussing executive leadership. It needs to be focused more to one specific question.
    – David
    Jul 21, 2021 at 5:34

4 Answers 4


Everyone being involved and trying to steer things is a good problem to have for a small startup. What's probably missing is likely a company northstar. For example, in the early days of Facebook it was getting to 7 friends in 10 days. https://mode.com/blog/facebook-aha-moment-simpler-than-you-think/ Having these kinds of goals allows people autonomy in figuring our how to achieve it while aligning everyone to a certain direction. You don't want to stifle this chaos by applying top down management styles from corporate world. If you are too early to have a true northstar like that you can set a more artificial one e.g. try 10 ideas over the next x months. This won't magically solve your problems but its a starting point. It allows people to reason from first principles about what priorities should be and get to a consensus. I.e. company goal is to get to 7 friends quickly because we have seen this drives engagement. Therefore, improving the add friends screen should be our top priority. "Because I'm the boss" is never a good enough reason to do something at a startup.

From here you should aim to divide up responsibilities and give people autonomy in their specific areas. This allows people more freedom in their own areas but means that while they can suggest things in other places, whoever is leading there can simply decide not to listen.

This is about growth but applies a lot to objective setting and strategy for startups too https://youtu.be/n_yHZ_vKjno


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".


The role of a CTO at a startup varies greatly. Some are managers. Some are hands on architects. Some are figureheads (which isn't necessarily a bad thing)- a place to put a high title on a founder and inventor while someone else directly beneath them did the real work, and he could code. I worked at one of the last and it worked well- the CTO would have been a horrible manager, but the title worked when he had to talk to outside parties and the VP did the engineering management. Roles do tend to be more flexible and more mutable in startups, because there's rarely enough people to do everything, so people wear multiple hats. The smaller the startup, the more in initiative people have to take to get everything done.

As for getting people going in the same direction- its too hard to tell from your post. Are there people who are just being stubborn/not cooperating? Then they need to be reigned in. Or are you expecting everyone to jump when you say frog without any input from anyone else? Honestly your post makes me lean to thinking that, but I may be reading too much into poor wording. At any rate, the best leaders lead by consensus and convincing people of the right direction. If you're telling people how it is and expecting them to do it as a regular occurrence, you're a poor leader at any sized company. Show them why certain decision is right, and they'll move forward.


Often it is treated as a given that a company should only hire the best and brightest and that the mere average should not be allowed fill it's ranks.

I think such hiring practices can lead to the "too many chiefs not enough indians" problem you describe. So my (long term) solution to this problem would be to not just hire the best-of-the-best, natural born leaders but also a fair share of more mediocre people who are a bit more docile and who like taking orders.

  • 1
    I don't see how it solves the problem - as soon as you have 2 people who can give orders (which is inevitable for any company of let's say 20+ people) there is a chance that both the CTO and a manager try to mange people reporting to the manager... Indeed your approach would be fine for flat org structure, but OP's case is clearly already outside that. Jul 15, 2021 at 22:48
  • Or just redefine "brightest" to exclude entrepreneurialism/ambition as a criterion. Jul 16, 2021 at 2:50
  • 1
    Citing Guy Kawasaki: "Steve Jobs has a saying that A players hire A players; B players hire C players; and C players hire D players. It doesn't take long to get to Z players. This trickle-down effect causes bozo explosions in companies." In a competitive business this eventually solves the problem, as the whole company fails.
    – ojs
    Jul 16, 2021 at 7:16
  • Team player != mediocre Jul 17, 2021 at 9:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .