Firing one engineer in a very small team who passed a non-running github project off as a finished prototype

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.