So this is not my real account. Sorry about that.

I run a startup where all fulltime employees also have an equity stake (with vesting and a 1 year cliff). One of the engineers we (I) brought on board around a months back is not really (at all) working out. His interviews and live coding sessions were fine. We are all remote (~30% could be onsite but now we chose to be fully remote).

The company is exploring a new photo application. Design has started working on the initial stages (user research, user stories, etc.). Simultaneously we wanted to test the feasibility of doing some advanced things like filters, overlays, etc.

So the idea was while the designers would work the preliminary sketches, engineering would do a feasibility study of some of the more advanced features. In order to start with these advanced features, the first step is obviously a simple photo capture / display app.

The engineer in question was tasked with this. In one on one calls, as well as in group sessions, he communicated that the simple image capture / display is done and he had started working on the more advanced things. This is the first task he has been given as the new engineer on the team.

I asked for a code review session to see his progress. During this, I discovered that even simple image capture or display wasn't working right. Later I found out (and he agreed) that he essentially copied the code of a purportedly full fledged photo app from another repository on github. This in itself (reusing code) is normal but what was shocking was that none of it actually worked. It was obvious he did not even test any of it before declaring that he was done.

I consider this a serious breach of trust. In principle, this is also a matter of competence, but in practice, getting a simple image app up and running is actually very straightforward - there are many ready to use components. He chose not to use the components and put together the app himself, but just to clone a pre-made entire app. And he didn't test it. This to me indicates supreme negligence, laziness and carelessness.

During the code review he mentioned he did not do anything because the designs were not ready and that he'd start once they were. This is in direct contraction to earlier understandings and agreements.

I think I should fire him summarily because it is only been a month.

Questions around this -

  1. What and how much should I communicate in the firing message? Should I have a conversation first and try to work things out (and risk more excuses and problems at a later stage)?

  2. What should I communicate to the small (around 5-6 people) engineering team? Asking them to use/test the app he uploaded will suffice because they are all engineers. Or should I just say he left due to personal/whatever reasons? Or that I fired him due to lack of commitment / breach of trust?

  3. In terms of "experience", I am around the middle and I run engineering. There are some very senior engineers and a very junior guy. Would it make sense to have a semi-consultative session with the senior engineer? What do I tell the junior who expected to be working under the guy I want to fire?

  • 54
    You may wish to consider whether you want all these specific details in this post. If they are genuine, they may identify you, your company, and the people involved. I suggest that to answer this question we don't need to know exactly what the software does, for example. Commented Apr 25, 2022 at 10:44
  • 31
    "I run a startup" vs "In terms of "seniority", I am around the middle and I run engineering". These cannot both be true - you are either in charge or you're not. Commented Apr 25, 2022 at 10:46
  • 38
    @BittermanAndy The photo app is an example. We are not making a photo app in reality.
    – user134392
    Commented Apr 25, 2022 at 10:52
  • 15
    Be fair with the guy. As I understand, you tasked him to do a preliminary stub application before any of the details (design, engineering) had been sorted out. I've been in his situation a few times before and every single time, the code had to be severely refactored, because some important contraints had not been considered and we didn't want to have spaghetti-o code right from the start. I'm not going to comment on the copypasta he did, but I can understand him not testing this throwaway-stub to the core. Commented Apr 25, 2022 at 12:28
  • 17
    In support of @antipattern's comment; was it clear that a working application needed to be built? Because I see potential leeway for creating a mocked application that uses a local image/video in order to emulate what the actual capture would contain. I'm also a bit puzzled as to how a single engineer without any specs and clearly any mid-progress oversight is expected to bang out an app that would only be used as a stub for further R&D and how you immediately consider summarily firing him for not delivering to your quite frankly vague requirements.
    – Flater
    Commented Apr 25, 2022 at 13:31

4 Answers 4


If you're going to fire someone, just fire them. If you have the authority there is no need and little benefit to be gained by telling anyone else the details. Just start finding a replacement.

Dancing around and inviting more dialogue when you have already been lied to a couple of times, makes no sense to me.

This to me indicates supreme negligence, laziness and carelessness.

It's just plain theft.

  • 46
    Failing to produce as an employee is not theft, at least in any jurisdiction I am aware of. I'd be careful about casual use of terms with legal weight when talking about firing someone.
    – Yakk
    Commented Apr 26, 2022 at 3:45
  • 6
    @user134392 "Or should I just say he left due to personal/whatever reasons?" If you are going to fire him just don't do this. Either you tell the other developers what happened or you don't. Making an excuse or not telling the truth will just make you look like a boss that can't be trusted regardless if you were in the right or not for firing an employee
    – John Doe
    Commented Apr 26, 2022 at 8:15
  • 18
    I believe this answer would benefit from removing the the accusation of thievery and lies, because that unneccesarily emotionalizes the decision. After all it's OP's judgment call if firing is warranted or not. Commented Apr 26, 2022 at 9:48
  • 4
    It's very odd if someone is fired for the company to provide precise details about what they did. Generally they will provide some vague boilerplate statement, if they feel they have to say anything ("He wasn't working out, we felt he wasn't a good fit for the team, etc"). Aside from anything else, you have to be very careful legally when accusing people of anything bad.
    – Stuart F
    Commented Apr 26, 2022 at 12:52
  • 4
    You don't tell anyone the details, it's none of their concern. Just gear up for a replacement.
    – Kilisi
    Commented Apr 26, 2022 at 13:06

You basically have two choices:

  1. Fire the guy without discussing it with anyone else first. Tell the team why you did it in as much detail as you want, and deal with the consequences if they disagree with your assessment of the situation.
  2. Discuss the situation with one or more of the senior members of your team. Hopefully you trust their judgement (if you don't, you've got bigger problems). Maybe you have misinterpreted something here and your team will convince you to change the plan. If they agree with you, that makes firing him a lot easier because you know you have the support of your senior staff.

Nobody here can tell you which of those to do; it's a question of where your trust lies (in yourself or your team).

  • 19
    @user134392 I'm very confused why you would fire someone and then seek an opinion on whether you should or not. #1 and #2 here are mutually exclusive options, not a series of steps. Commented Apr 25, 2022 at 20:53
  • 7
    Your comment is concerning if I understand it right? It sounds like you weren't honest with the senior engineer, which seems like a trust issue in that relationship too, on your end? Not saying you had to ask the senior engineer's opinion, but since you decided to, it seems questionable from an ethical standpoint to pretend to them that you hadn't fired the employee when you had already done so. And if the senior engineer even learns the true timeline of events, it may erode their trust in you.
    – bob
    Commented Apr 25, 2022 at 21:32
  • 8
    Also what would you have done if the senior engineer had said "No way--don't fire them!"? Would you have lied and pretended to then later fire the employee, or try to hide it? Definitely not the best approach. Honestly if this is your first position like this you might want to look into (no rudeness intended at all here) some management training.
    – bob
    Commented Apr 25, 2022 at 21:35
  • 3
    It’s legit, I’m just questioning how it was portrayed to the senior engineer. Asking “What would you have done?” is very different from asking in a deceitful way.
    – bob
    Commented Apr 26, 2022 at 1:30
  • 4
    @bob: oh right, I see what you mean now. Sorry, yes, "asked if I should fire him" is not actually the same as "asked if I should have fired him", so if the questioner literally did the former as they said then ofc you're right, they're lucky to have got away with it. If the senior engineer had said "no" only to find the person was already fired then it would have severely damaged that senior's trust in their boss. Especially in a context where that boss is firing someone for (perceived and/or actual) dishonesty, that's a pretty catastrophic look! Commented Apr 26, 2022 at 1:37

My initial response is to hold your horses.

Miscommunication about tasks and expected results happen. Especially, in new teams and with new developers. How can you be sure your guy correctly understood what you mean by a "feasibility study"? If the task was not communicated properly, you and the process are at fault, not the developer.

I would start by asking someone else to mediate the situation. If the issue is poor communication, come together as a team and fix it. If it is negligence/sloppiness, let the developer know it will not be tolerated.

Regardless, as an organization, you will need a mechanism to objectively resolve such issues. Take it as an opportunity to practice the mechanism.

  • 1
    What do "done" and "worked" mean for a feasibility study? I could interpret it as checking the documentation of some library that confirms if something is possible or not. Commented Apr 26, 2022 at 13:51

Do the same thing you would do with a new hire.

Consider that hiring a new person (both deciding to add one person and choosing which person) is something that affects the team in a similar way as deciding if you fire someone. Only you decide whether you consult hiring decisions with the whole team, or a part (e.g. the TL, seniors, etc), or with none of them. Same as what you inform them, you may offer some information or none at all on why you decided to hire someone, to the whole team or to a part of it. You should follow the same process when firing someone.

You must log in to answer this question.

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