I joined a small software dev startup in the moment they started scaling up. The software was a working prototype, a very complex one (multi-threaded CPU and GPU app pushing top notch gaming PC to its limits). A few months after growing from 3 to 6 developers (including me), the company hired in bulk a team from another company, to leverage on their experience in publishing software. I implied we would set up some software engineering methodology, but we're still just coding: no design, no coordination, no team management, no planning, no tests, no release procedure and... no debugger (ouch).

Now the management (2 people aka the CEO and CTO) is expecting that the prototype magically becomes a product, ignoring whatever my colleagues or I suggest about how we should work. We are asked bug-free releases of our application with 1-2 days notice, but we can't even build the debug version of our app and it's not a priority to make this possible. We (all together) told loud and clear to the management that there would be no quality in our product if we keep doing software without doing engineering. One of the points, for ex., was that we needed to properly setup our software project and dev environment (including a debugger) in order to make a bug free application. We pointed that "we do software, not miracles" so the management asked us to... do miracles.

At this point I don't know what to think. Why hiring us if they don't trust what we say? Or if they do, why not listening? I agree pleasing investors and partners is a must for a startup, but the feeling here is we're driving a prototype car too fast and in the direction of a concrete wall.

I'm tempted to give up and find a job with better conditions, then I remember how my previous boss was and I'm ok to make another effort in this company, because they deserve it. Finally, I'm writing here because I'd like a couple of opinions on if and how I should retry persuading them or if there's something wrong with my expectations.

  • 6
    A lot of startups fail, and a lot of startups are run by people with absolutely no skill or intellect, just people who can talk. If you don't believe in the product, I recommend you do your 9-5 and don't get yourself hassled. Aug 18, 2022 at 14:00
  • 1
    Here's a really good case: theguardian.com/news/2021/sep/07/… (Warning: Quite long. And danger of banging your head on the desk).
    – gnasher729
    Aug 18, 2022 at 15:29
  • 2
    Can you give concrete examples of suggestions you made, that were ignored?
    – Helena
    Aug 18, 2022 at 16:59
  • 2
    The word "insist" was a little strong for what you meant: insisting implies that you would be refusing to accept management's decision. (People do use it to mean various levels of intensity though, and it can be hard sometimes to tell how serious someone is.)
    – BSMP
    Aug 18, 2022 at 17:59
  • 1
    Not sure I understand why my question was downvoted 3 times without comments, not that it is important but on SO the people explain why they downvote and it helps posting well formed questions.
    – user125932
    Aug 19, 2022 at 8:16

5 Answers 5


Why don't they listen to you? Because they are the managers and therefore automatically know better. Insisting that you are right will be ignored at best, because they are managers, and therefore you are wrong. (I know this is a stupid way to act, but it happens in real life).

My recommendation: Be on the lookout for a better position, and if you find one, you sign the contract and give notice. If you don't find something better, then there is no rush as long as you get paid.

As long as you get paid on time, you can stay and do your best. If payment is delayed or stops or is reduced, you go and look for a better position, with a lot more urgency this time.

  • " Be on the lookout for a better position" ++1. Also you now have the kind of experience that will be useful in the future. Aug 18, 2022 at 20:20

Startups fail. It's a risk we all take when we create one. It's OK to take their money and deliver garbage as long as you let them know it's garbage.

  • 1
    This is right. You may not be aware of all the reasons management makes the decisions they do. There could be factors at play you can't even conceive of. If they are paying you a fair wage for your work, then keep taking their money. You have no obligation beyond warning them of the problems you see. If they choose to ignore your warnings, that's on them. As long as the check's clear, who cares.
    – mikem
    Aug 24, 2022 at 7:45

For small startups, remember that most startups fail and most fail on execution not because the idea was a bad one. A tech focussed startup that doesn't build a strong engineering culture is likely going to fail sooner or later.

Ultimately, understanding how long something takes to build and convincing shareholders to invest sufficient money into making it happen is the CTO / CEO's job. You should ask yourself whether you feel confidence in their ability to do this. Frankly a CTO at this early stage that needs to be told about software dev approaches as opposed to seeing it in the codebase because they work it on it is a red flag to me.

As much as I would like to say keep trying and be positive. Your post contain too many start up red flags. Disconnect between management and staff despite being small. Tech focussed company not actually good at tech. Don't give up on startups totally but you must interview more carefully with them and think like an investor.


We are asked bug-free releases of our application with 1-2 days notice, but we can't even build the debug version of our app and it's not a priority to make this possible

You should be using version control with different branches. It's okay to work in branches where your code might not compile due to still being work in progress, e.g., due to big refactorings still in progress. But that is not the main branch of your code that should always build successfully. I don't understand why you blame that on management. This is how you self-organize as developers.

no coordination, no team management, no planning

I don't understand this. There must be some sort of requirements and planning involved on who is working on what. Otherwise, all developers might implement the same feature. Or even whatever they want or see as a fit for your product.

I implied we would set up some software engineering methodology, but we're still just coding: no design, no coordination, no team management, no planning, no tests, no release procedure and... no debugger

Okay, so you've identified problems in different areas:

  • specifications
  • resource allocations and timings
  • insufficient processes coverage, build processes, and releases

I would start to adress the resource allocation:

  • Do you co-workers see the same problems?
  • If that's the case, discuss it as a team and come up with an idea on how you want to organize yourselves.
  • Depending on the severity of this change, you can do it without bothering the CTO (which I assume is your boss). Otherwise, discuss your suggestions with the CTO and offer to take the lead on bringing more structure into the team's workday.

I'm failing to see how this is all the company's fault on how you are working as a team. You are 6 developers but nobody is bothering to try to implement some structure? I assume that you are all adults who should be capable of self-organizing. Why don't you try to take the initiative especially since it's has been the same situation for months?

Apart from getting a better salary by changing jobs, the chances are high that your next employer is more organized. You need to decide in what kind of environment you want to work in.

  • "There must be some sort of requirements and planning involved on who is working on what". That's what you think.
    – gnasher729
    Aug 19, 2022 at 15:11
  • Thanks for not answering "give up", I appreciate. I get your point, I always tell myself that if I'm a goalie and my team loses, it means someone scored in my goal while I was there to avoid that, so I failed. That's precisely what pushes me to keep trying to ask for the things we could not set up spontaneously, either because it costs money or because there are doubts on what to chose and nobody wants to be responsible. It's not for nothing that being "responsible" for something is a role in a company, it goes with a salary and moreover with some decisional freedom that we don't have.
    – user125932
    Aug 19, 2022 at 16:28
  • I understand that you don't want to take on additional responsibilites without a raise. You need to decide for yourself if the current situation is endurable for you or if you want to improve your current situation without additional compensation. I'd choose the latter
    – citronas
    Aug 19, 2022 at 21:43
  • If a 6 person team needs planning and structure I would argue something is wrong. This is a small enough group that if genuine technical leadership existed e.g. 1-2 very strong programmers who could reach consensus with each other on technical matters. Then stuff will just work. If not, no amount of planning, adopting prioritisation frameworks etc etc will fix it. At this size individual talent and personalities beat out structure and planning Aug 20, 2022 at 3:48
  • 1
    @Citronas thanks again for being the other bell, ringing out of chorus, it's important to hear it. Applied to the specific situation, the points you named are not the problem, unfortunately. They ask garbage, we warned it's garbage and still, they ask for more.
    – user125932
    Aug 20, 2022 at 10:40

If it's a good idea, go ahead and do it. It is much easier to apologize than it is to get permission.

  • Grace Hopper

Sometimes you have to work around management and do the right thing even though nobody told you to.

If you have bad organization, then self-organize. Sit together with the other developers (sans executives), talk about what problems you see, and find solutions. When you need a team manager, elect one. When you need a release procedure, agree on one.

And when something needs to be done so you can work properly, then just do it. Next time the executives tell you to fix a bug, tell them that it is impossible to fix it without a debugger, so you will now go and create one. When they ask you what you are doing, tell them you are fixing the bug - enabling debugging is part of fixing it. Same with a new feature. If they request a new feature, tell them that in order to create that feature, you first need to create a proper software design document. If they disagree, say that creating this document and then coding this feature will be faster than coding it before you have a design document, so you will do that now.

Will it mean that you can not stick to your 1-2 day deadlines? Yes, you can't. But you can't anyway. Failing deadlines, especially when they were decided without input from the developers, is nothing unusual in the world of software development. So your executives should get used to it.

  • Makes sense, to a certain point: we took the initiatives we could take, but there are two problems. The CTO is also the main dev, he makes us surprises like full refactoring over the w.e., we can't force the boss to follow our rules, he just won't; setting up tests and dev env also requires spending money (in our case), so we can't just decide it, we tried to pay with our money and be reimbursed because we needed cables and we had 2 days to set up a specific hardware config to replicate the one of an important customer and debug the application, but then we were told not to do it anymore.
    – user125932
    Aug 19, 2022 at 16:14
  • 1
    @L.C. Huh? The guy is actually involved in development and still does not see the issues? Well, then all you can do is work-to-rule and watch the ship sink while you look for a better job.
    – Philipp
    Aug 20, 2022 at 20:32

You must log in to answer this question.