Startup scaling but ignoring its seniors' warnings - retry or give up?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.