I'm currently working in a small software R&D startup, the technical department of which consists of me, my supervisor, who we'll call Bob, and a DevOps engineer. I've been with the company for about half a year, and in the past few months began to notice that due to the lack of things common to the industry, which didn't seem as evident during the 3-month probation period. We have not moved closer to a working product due to Bob's design philosophy, which consists of little planning, lots of coding, little re-planning, lots of re-coding.

My attempts to steer the approach towards building the application "properly", by using an existing methodology, or, at least, a philosophy different to the one I've described above, have been met with no particular enthusiasm, bicycles are being engineered for tasks that do not require them, and the overall process is quite hurt. To add to it, the company's current software infrastructure, is managed by Bob and it actually works to a degree.

I have mostly made up my mind (possibly incorrectly) about the very low possibility of success for such a thing (I've worked in one startup before this, and the approach was very different, despite the same 2-programmer setup), and am preparing to quit. However, I've managed to build a good relationship with the CEO, and am not impartial to the state of his funds and his idea.

My question, as it stands, is this: Is there anything I can do to perhaps salvage the process here instead of cutting my losses?

Considering the length of Bob's stay at the company, I think the CEO is more inclined to trust his ways than the industry standards, as they've been working for the previous projects. Do note, the scale of these projects is far smaller than the current one.

closed as unclear what you're asking by Philipp, gnat, OldPadawan, Rory Alsop, IDrinkandIKnowThings Jul 17 '18 at 13:06

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Perhaps take a step back from the notion that Bob's way of operating are wrong (as indicated by your description of steering the approach to building an application "properly"), and realize that the lots of coding he may be doing is a form of quick prototyping which is actually a very commonly used tactic within (software development) companies? – nbokmans Jul 16 '18 at 13:37
  • 5
    Reminds me of the saying "weeks of coding can save you hours of planning". – Erik Jul 16 '18 at 13:38
  • 2
    @nbokmans We are past the prototyping phase, we've gone through several iterations of that in the same manner. Right now, the milestone is an MVP, and with the fundamentals changing even now, we're nowhere near it. – Ivan T. Jul 16 '18 at 13:40
  • Who is the person driving the changes in the fundamental process? It seems that is the source of your pain... And one all too common in Software Development. – IDrinkandIKnowThings Jul 16 '18 at 18:13

Is there anything I can do to perhaps salvage the process here instead of cutting my losses?

In my experience, no there isn't.

For a quick answer, you mentioned that you went out of your way to explain why the current processes should be changed. Assuming you explained it well, it's not likely to change in the future as I'll explain later. You also mentioned that the probability of success is lower than what it should be. A startup either succeeds or fails with a high probability of failing. If you aren't seeing the right signs for that small chance of success, keep things professional and move on to your next opportunity.

For a longer answer, a startup is a place where ego has a higher probability of running wild due to the nature of the situation: starting something from scratch. This situation often fast-tracks people to elevated titles or, at bare minimum, an elevated sense of importance. Your average product manager is now managing their own project with no one to report to. Your normal developer is now leading others as well as making their own decisions about development. At a fundamental level, people just have more control over decisions than what you'd normally have at a typical company. Those people either have the capabilities necessary to back up that ego or they don't and they run the company (or their portion of the company) into the ground (or there's some luck involved). Changing that ego and direction isn't something you can do by having a logical discussion. Ego is ultimately changed by the person it belongs to, not someone else. If the probability of success (in your mind. Doesn't really matter whether it's right or wrong) isn't high, then you either stay and buy into the processes or you leave and go somewhere that is more aligned with the processes that you know work. Doesn't seem like much of a loss to move onto a better opportunity.


The fact of the matter is, the company should have a goal of creating usable, working software, and there needs to be efficient ways of tracking progress/managing expectations/setting goals for feature delivery. It doesn't sound like this happens based on your question. Coding with a loose purpose and causing re-work is very costly - both monetarily and in terms of motivation. This is why some companies have yearly, quarterly, monthly planning - to identify, allocate, and set expectations around work/features.

For example, when you go into work, how do you know what to work on? Does Bob tell you what to do? Does that work get the company closer to its' goal? If not, it should be a conversation and you need to express that you strongly feel the need to re-align expectations and understand the direction of the company.

If people aren't willing to have this conversation or hear your perspective, then, personally, I would not feel like a valued employee and would do exactly as you said you are doing - preparing to quit. If you were the CEO or a key stakeholder (unsure if you are or not) - this conversation would be very different as you'd want to salvage as much as possible.

  • To address the questions in your second paragraph: yes, assigning tasks to me is Bob's responsibility; when I don't see the value in a specific task for our product, I ask him to explain it to me, and more often than not I'm given a vague answer of "we'll need this in the future". – Ivan T. Jul 16 '18 at 14:24
  • For me, as a developer, what I'd like to know is Define "the future". But then again, this puts you in an awkward scenario as you're directly questioning Bob and exhibiting behavior that you don't trust his judgement and therefor the work you're being assigned – Mark C. Jul 16 '18 at 14:25

There's not enough information here for 3rd parties to speak to the merits of the conflicting technical approaches.

So all we're left with is that

1) It seems the company is unlikely to change

2) You are unhappy enough that you are prepared to leave

Depending on how close you are with the CEO, you can go have a private talk, explain your reasons and begin a transition out. The risk here is that if you misjudged the relationship you may be forced out earlier than planned, however if you judged it correctly, being openly communicative can leave you both with a mutual understanding - they of the fact that the company's practices did not fit what you believe in, and you with the fact that they feel constrained by circumstances to their present course.

Or you can find a position that you feel better about, give a traditional short notice, and leave for that. While generally considered economically smart, the risk there is that this "correct but coldly formal" ending may leave both sides with the feeling that you abandoned the situation.

In the end, the means of departing, just as the decision to depart, comes down to what matters most to you.

Not the answer you're looking for? Browse other questions tagged or ask your own question.