Should I bring in CEO where a junior software engineer was hired in position of senior, and I am risking termination due to lack of collaboration?

Question

I was hired at the beginning of April by a Swiss company as Senior WPF engineer, and because of COVID-19 lockdown was unable to be registered as permanent, so they hired me as a contractor for two months until June when hopefully lockdown would be lifted, and from that point, I would work as permanent and have a contract already signed.

Me and one other candidate, let's call him U is a person in his fifties, were hired to two Senior WPF Engineer positions, through the process of: Programming homework, then extending that homework in front of CTO who is a go programmer and claims to know little about .NET, meeting with HR person who did the character assessment, then PM who was agile scrum master and is now in charge of the project we are working on, and final meeting with CEO.

In the company, we do work akin to lean startup with maximum focus on quarterly OKRs. In a team of four, us the new hires and two contractors, we work in agile with biweekly sprints.

Due to sprint and daily scrums, it becomes quite visible how well people perform, and U started talking about doing things with lots of pre-planning while it does against the companies work methodology, I privately sent him a link and suggested to read about lean startup he replied he knew it well, yet for a few weeks was suggesting things that were opposite. In another two weeks, it also became apparent that he produces code, very slowly and very little of it and we aren't talking 'lean' code we are talking, old .NET3.5 kind of code like adding strings with +, zero linq, and introducing exceptions like opening the file and then trying to delete it in the next line and getting IO. exception.

First clash between us was when he didn't like source control and wanted to work directly on the master branch. He started working on it anyway and I and contractors went to PM to step in and we convinced him to do every user story on its own branch. After this, I was very busy with introducing new modules into the app so we interacted very little.

The next clash was when he tried to add 3rd party source code project to our solution when I suggested importing .dll, he argued that we might need source code in case we need to fix a bug in 3rd party control, this time PM said he is not .Net developer and that I should bring this with CTO. So I did and CTO convinced him again.
After this, I spoke to PM and CTO that he puts OKR at risk and that he is not a Senior WPF Engineer. I have been prooving them in various metrics that he is heavily underperforming and doesn't know the stuff that seniors should. Both PM and CTO would say that they are not experts in .Net and that I and U are experts and we should sort it ourselves out. At this point couple of weeks ago, I simply backed off and started focusing on working like crazy to hit OKR.

Since my contract is expiring in two weeks and borders are still closed I reached out to HR to ask what do we do in regards to contracts. When happened next, I got a meeting with HR, CTO, and PM and have been given a written warning and two-week pending performance review in regards to lack of collaboration. They said that we need to work together more closely and come up with decisions together.

Normally I would be out of the door, but I have invested a lot of myself into the product being released and succeeding, I like the job itself and the company is working with the latest methodologies and other teams are performing very well, also the corona crisis makes another remote job harder to find.

I can't understand, why would PM sabotage his own project since up until meeting we were meeting OKR and this warning is a huge risk if I leave. Also, why CTO would not 'see' that U is constantly suggesting weird things like API instead responding with version string (e.g 1.01) sending a file with a current program version inside. Even without any .Net knowledge, one capable programmer can smell another a mile away and I think CTO is quite good at least in regards to the system design. Company is up to 50 employees and I have direct access to CEO

What do I do? Should I bring this up with the CEO, or I am better off shutting up and collaborating and how do I go about it?

UPDATE:(epilogue) Initial 2-month contract got extended, but then they sacked me 3 hours prior to product release, with 10 days left of the contract.

Collaboration doesn't fly if you have to also deliver...

Answer 1

I find this situation rather difficult to resolve without looking to leave, at least in the long run.

---

Personal opinion

Judging another employee is indeed not your job, however it is your job to ascertain product quality and following of best practices and processes.

The other response and the comments are exploring the fact that the exact motivation behind U's is not known to you, which is true. However, I have trouble agreeing with the suggested not-a-kid-out-the-uni or brings-something-different-to-the-table paradimes. This is because the problems you describe are gross mistakes on U's part. I am specifically referring to the code practices, as well as lack of basic understanding of version control. This is something that is to be expected from any senior, no matter their experience or educational background. For example, having worked with a lot of developers over the course of my life I am yet to encounter a senior or even mid-level developer who is not familiar with at least some form of version control.

What should you do?

Focus on the product, not on U. The PM is responsible for the product, therefore they should be able to make decisions and communicate with both U and you. If escalation is required, then it should be communicated between the PM and the CTO. The CEO is the next higher escalation stage. Because I said you are supposed to deal with the product rather than the other employee, your communication should not escalate to the CEO - either the PM understands why the situation is problematic and takes further steps, or the PM decides this is not worthy of attention, in which case you should follow their directions and focus on delivering proper code and following processes.

Should you run into problems with the product due to the actions of U, then you communicate these problems solely on a fact based level. E.g. a mistake may happen because pushes to the master were undertaken by U (best practices are best for a reason) - this should be pointed out to the PM without mentioning U, the PM should be able to find this out on their own who was responsible if they are interested in doing so. Either way, you will not be able to push U out of their role without severely shooting yourself in the foot.

If the PM (or superiors) do not recognize these problems, then your situation is unlikely to imporove. In this case searching for a position in a different company appears to be perfectly justified.

As for the collaboration with U - it should be kept professional and again as fact based as possible. If there are disagreements w.r.t. code quality, processes and so on, then these should be documented.

Why this is not likely to work out in the long run

If neither the PM, not anyone at a higher level decides to intervene with U's bad practices, then frustration is guaranteed. You can collaborate with U to the maximum degree possible, but this is hard when U is working actively against your actions with their actions. E.g. if you aim to establish proper version control, branches, merge requests and code reviews, while U wants to just produce and push to the master, then there is a limit to the collaboration you can achieve. These things work against one another.

A few problems on the horizon:

• If U and you are disagreeing on processes and PM has no intention to intervene, then you are at the same level in the company hierarchy as U. Obviously you should try to be helpful and provide information on why best practices should be followed, but you have no authority over U and without the PM there is little else you can do, if U still does not follow best practices.
• When best practices are not followed in a company, then my experience is that your own skills may suffer as a result. It is very easy to succumb to bad/lazy practices and rather hard to reestablish proper processes once you are in an environment again, where these are cherished and expected.
• As you already received a warning from HR / CTO / PM which I would label a confrontation the well is already poisoned to some degree.

---

Best advice I can give is one of the most common in the developer world. Train yourself to let go of the product. It is not yours. It is not your baby. You get nothing out of it. What you get is your paycheck, so don't be invested too much in the code and the software. It belongs to the company, it does not belong to you.

You yourself said, "normally I would be out of the door" and frankly, so would I once I had the next opportunity lined up.

Answer 2

This is a bit of a false dilemma.

You should bring two things to your meeting:

• A reasoned point of view on areas you think the team needs to improve on to meet OKR
• A personal plan on how you will improve collaboration with U

Frankly, judging the skill level of U is not your concern.

You need to understand that there is a very real chance that U was brought in because he is not another "kid out of uni". The expectation from higher up that you will both bring something different to the team, but such a benefit can only be realised if there is collaboration.

CTO seems to be aware of the different mindset and comfortable with it, so you need to tailor your conversation around that. You should seek advice about what to do when U deviates simnifically from best-practise and can't be made to see reason.

Given the current environment and your contract status, my advice would be for you tread very carefully in the short term, and make sure you are proactive at improving things at a personal level.