New to Company – Potential Overbearing Peer Problem

Question

I've recently been recruited into a large organisation in the UK as part of a huge hiring drive the business has engaged in with regards to their development function. I'm a Senior Developer, and my manager is in charge of the whole department.

Around 75% of the department are new with more people on the way, so everything has yet to be established at this point in time. There are around 50/60 people in the department at the moment, and the reporting structure is somewhat in a state of flux with varying job titles and odd reporting lines.

As far as I am aware, I report into my manager for your usual HR functions (appraisals, holidays, etc). For day to day tasks, this depends on what project you've been assigned.

I've recently been put on a project. The company implements projects using a very established Agile approach. There is a huge emphasis around collaboration and communication.

The project itself is extremely simple. Myself and a very small team of new starters have been put to task.

The project is being “supervised” by another Senior Developer (who I believe has been here for a few years), who refers to himself outside the organisation as a “Lead Developer”. He's extremely enthusiastic around the whole subject of development, almost of the point of it seeming as though he's “trying too hard”. He's quite bossy in the way he has briefed us, imposing his own deadlines and deliverables and even belittling the difficulty of the task we've been given.

Other people have commented on this person and his personality already.

I've noticed that over the weekend, out of business hours, he has been heavily altering the code (including deleting various parts of the system) even though this project was obviously intended to be for us to cut our teeth on as us new starters as a team. There was no communication/email sent out here – it's just been changed by himself, I assume, to meet his own “standards”.

It's certainly not the definition of team work, and begs the question why a team was needed to complete the project at all.

So the question is; what do I do here?

The first approach is to talk to my manager – do I raise this as a concern with him? I feel he's reasonable, but I'm new to the company, and this developer isn't. It could make my life tricky in the department.

The second approach is get my CV out there and move as soon as possible. This is of course the easy option in some ways - but I would feel as though I was giving up.

The third approach would be to take this up directly with the said developer. This, in my opinion, is the riskiest approach, considering his overbearing nature. Considering I am new to the company, he may consider this as a challenge to his self imposed authority.

Answer 1

Your organization has had a huge flux of new people and you can expect that some folks aren't going to handle the situation smoothly. Having that many people pour into your department challenges stability and really puts stress on the organizational structures.

In your situation, you have a coworker/lead that likely feels threatened and insecure. He manifests this by reacting with overbearing and self-imposed authority. People often act in ways which are opposite to how they feel. By changing a bunch of code without permission nor communication, this person is reclaiming some measure of control and responding to this new environment which he likely didn't ask for.

I think the best way to approach this problem is to make some gestures of kindness to this person. Get to know him and then ask to be clued into the changes he's making. The idea is to develop a level of trust between you and him. Once trust has been established, he is far less likely to act out in unhelpful ways, or at least he's in a better position to be reasoned with.

It might sound like this advice would apply to children and that's not by coincidence. Adults often do act out in childlike ways when they're thrust into a situation where they have (or perceive they have) lost control.

Running to management with this problem will put yet another complex problem on their desk and is likely to inspire an even worse reaction from the overbearing one. You can always quit if the problem becomes intractable but at this point, it is worth making an effort towards a solution. People have survived and thrived in much worse situations than yours. So, I think the "third approach" is actually the safest if you FIRST work to establish trust with this person and work with them as an ally.

Answer 2

It's still pretty early days with this company. Before elevating this issue formally maybe go for a coffee with some other people who have been at the company for a few years also and (tactfully) ask them about it. He may be well known for this sort of thing.

Since you don't yet know the lay of the land, I would recommend being very non confrontational, you can highlight the issues you're having with an email nominally addressed to this guy but cc'ing all involved with the project (including your manager) where you ask a series of innocent questions along the lines of " I noticed the code to complete xyz has been edited in abc way before being released , can you confirm why / what the issue was etc so that we can ensure that we avoid these mistakes in future"

Answer 3

I would approach the problem from a simple perspective. He made some changes on the code but did not let anyone know, right? If he likes authority and power, simply feed it to him. When you have a casual moment (lunch, around the water cooler, etc.) ask him in a polite and yet admiring way (sucking up is a tool to use wisely with seniority employees)

"Hey Name, I noticed you made X changes to ABC code. It looked interesting, what was the code before? I just wanted to know so I can be on the lookout for those kind of situations again. What was the issue with it (make up some generic reasons here such as poor optimization, ram usage, etc)?"

This appeals to his management persona and admires his coding skills subtly without sounding incompetent. Once you know why he made the edit, you have 2 decisions to make:

1. Correct & Worth It: the edit was justified and needed. Thank him and move on.
2. Incorrect & Wasted Time: The best approach here is to turn to team work and deflect the issue and focusing on developing your management relationship by saying

"Oh ok. I just always operated by making sure that everyone feels their work is valued and appreciated. If anyone's code has issues, I want to make sure to show them how they can improve it in the future and teach them some tricks we might know. Also, it's good to keep others in the loop just in case something depended on those codes and there is cross-functionality issues/etc. No? (Add laugh with an "eh" here for a lighthearted effect)"

Answer 4

As an engineer myself, I can attest to the occasionally headstrong developer causing friction within a team; I can also attest to some of the best software developers I know being these people. Of course I can't say one way or another from your question as it was presented short-form. Your peer might be as unbearable as implied, in which case it is entirely appropriate to raise your concerns to your manager. On the flip side, perhaps you can leverage this person to grow within the company.

Ask him why he changed the code over the weekend. What did he think was wrong, and why did he change it like he did? If he's been there a while, there may be some tribal knowledge he has that the newer team members are not aware of. If he's changing the code because he thinks he can do it better, it may be more constructive to perform documented code reviews if your agile process allows for it. This would legitimize his ninja code editing, but it would make it transparent to everyone. It wouldn't be "ninja" anymore, just a common development practice.