Don't argue when it's a distraction
I'm not going to judge your junior employee's intentions. It is impossible for me to distinguish someone who means well but has a tendency to dig into discussions/arguments from someone who willingly digs into argument to win by exhausting the other person. Both are possible interpretations here. Both should be tackled the same way regardless.
Similarly, I cannot judge who is the sensible one here. It might be that your environment is needlessly complex and the developer's way of doing things adheres to clean coding more; or it could be the complete other way around. But more on that in the next section.
Don't argue unless you have to. Stick to the facts. If you know better, inform them of what you know as a fact. If they raise a point that is not incorrect but off-topic, acknowledge it but immediately steer the conversation back to what you want to have happen.
Some examples based on the scenarios you presented:
For example 'this is company policy, it's how the higher ups have decided we have to do things' was answered with 'But I like to do it this way, I think this is better' - paraphrasing.
"By definition of them being higher ups, you don't get to overrule them. Policy is to be followed."
I had to argue that a circle is egg shaped, if the height and the width of it doesn't match. - This is met with 'Its on purpose, if they are equal (height and width) it seems egg shaped'. So now I have to argue that no, a perfect circle has height = width.
Unless you are mathematicians discussing geometry, none of this discussion is relevant. This probably devolved from the type of discussion that should've gone something along the lines of "[implementation] isn't right, it should be [better implementation]" and leave it at that.
If they ask for more elaboration, help them solve it the way you want them to solve it, rather than engaging them in some broad abstract discussion about the overall concept.
'I find it confusing moving it around' - then proceeds to submit his work into our system.
"It's confusing because it's new to you. If you start doing it, it will become less confusing. What would be even more confusing is to have a codebase with both our structure and your structure intertwined. Follow the team's structure."
It's not just them, though
He pops online (from home) and starts submitting his work. [..] it caused a lot of extra stress on us, that had to make sure the new work he submitted was okay for production. His work wasn't part of the deadline, so it could just have been in the drawer until he felt better.
I'm going to side with them here. Your process is not a good one if one developer submitting some work forces everyone else into immediate actions and blocks the release of the software until actioned.
I'm going to take an educated guess here that he merged his changes into the main branch without any review/gate, and because it's in the main branch, any build you do would include those changes.
This is why pull requests and pre-emptive code reviews exist. A developer's work should not become a shared blocker before it has even been vetted by another developer.
Now, should the junior have followed whatever procedure you have - regardless of whether it could be improved? I'm not going to say no mistake was made on his end, but I would suggest you don't use this case as an example of what the dev is doing wrong - the process is clearly broken because it gives any developer the power to grind the entire team to a halt even when they work with the best intentions (as per your own statement).
- it would probably be thunder from a clear sky from my managers point of view
- I am not a team lead (we have none)
- we don't have a clear line of command
We get to the same "broken process" observation here. The position of team lead is defined as the first person in the hierarchy who all team members report to. Given that your manager is the person you are thinking of turning to, it seems that they are your team lead.
The fact that you distinguish your actual manager from "the team lead" role suggests that your manager has not been managing his direct reports, which means that your reporting system is broken. This is why you've been struggling for so long without anyone noticing or assisting.
- If talking to the manager is the solution - what do I say
- I at a point now, were I can't see any solution but going to our manager. I've been hesitant of this and it feels like an escalation.
It seems to me that your assumption is that talking to your manager is an immediately formal action.
This further proves the broken process. One does not (or should not) go from "clear skies" to "formal escalation at risk of firing" without any steps in-between them. The lack of ability to have a conversation to address an ongoing problem is causing problems to fester to a point of, in your words:
I don't really know what I would say to him without it becoming a rant. I feel like I have held back for too long
If that's the baseline for communication, things are not in a good spot.
In general he comes to work, puts on his headphones and doesn't communicate unless he is asked something.
I mean, that's not great for team communication, but the communication line between you and your manager/lead is clearly not any better.
I think there is no difference in having him coming to the office than having a consultant working from across the globe, he feels like a satellite worker.
Why bring up remote work in a discussion about the junior being unproductive? Are you equating remote work with a lack of productivity?
If being in-office is delivering great benefits to your development process, this may indicate that your process is very tightly coupled, which is starting to match up with the other observations made about your development process.
I'm not bringing these points up to somehow disable your point about an argumentative employee. I'm bringing this up because it can contribute to why you're encountering friction with this employee. None of what I list below is a proven fact, but based on my own personal (and dare I say fairly extensive, i.e. 10 years) experience in broken dev environments, there is a general tendency here to create a chain of cause and effect:
- Complex and fragile business process suggest that the system is very opaque and not designed with a high degree of contextual expertise.
- This leads to "we know how to do things here" that relies on long-standing experience in the company and an intuitive grasp on what works and what doesn't.
- Newcomers don't have this experience. Therefore, they will only learn by obliviously breaking these fragile processes that (a) should never have been this fragile and (b) are not clearly delineated as such (no proverbial guard rails), because the veterans don't need guard rails because they already know about the pitfalls.
- Negative feedback from veterans about "the effort that the newcomer costs them" leads newcomers to become defensive and take an attitude that it's better to not do anything "because who knows what it might break".
- Because of this defensive attitude, the newcomers never engage in the activities that teach them how to work with things, out of fear of getting more negative feedback.
- Therefore, they isolate themselves into their own world where things make sense to them. This counts double for juniors, as even in a normal system they are trying to catch up to practices that they don't understand and are foreign to them. Essentially, the more junior someone is and the more complex/fragile your environment is, both tend to cause the person to withdraw from the thing they don't understand and get negative feedback from.
- Them putting headphones on while they're working is a good example of this kind of isolation.
- When someone (you) approaches them and makes them deal with the thing that they can't understand and fear breaking, they will likely argue with that person about the necessity of involving them in the thing that they are afraid of engaging with. This is human nature. I'd rather not engage with things that historically have proven to garner negative feedback when I engage with them. It'd rather stay in my own space where those things don't exist.
- Generally speaking, environments like these either lack documentation or have a prohibitively dense, overgrown and outdated documentation jungle. Neither is helpful. This is more a theory than a proven fact, but I believe that by writing clear documentation, people will more easily spot the flaws in what they are writing about and be more incentivized to improve things (in the same sense that a person who is being difficult does not want to see themselves in the mirror, a well known bartenders' trick)
This is why I'm not keen on agreeing that the newcomer is in the wrong here. Yes, the specific cases you're picking at are ones where the newcomer is doing something out of order. This is why I agreed that not arguing with them is the correct approach from your end.
But this might be a cherry picked from a tree without observing the tree that grew this cherry. I'm not accusing you of willfully doing so, but your question reveals certain things about your workplace that leads me to believe that the workplace significantly contributed to the newcomers' way of approaching his work/team/mentor.
For a more senior profile, I would hold them accountable for being able to communicate the problems they encounter in the workplace. But this is a junior who needs to be mentored. These profiles tend to lack the technical vocabulary and expertise to express precisely what is broken and what should be the "normal" way to do things. Much like a baby who is sick, the lack the ability to tell you what is wrong, their behavior can only indirectly indicate that something is wrong.
Maybe your team lacks the kind of expertise in how to nurture junior profiles. This is not an unreasonable point to make if your workplace environment is very complex. However, then you should not be hiring people who are this level of junior. You should be hiring experienced professionals who are confident about development practices and therefore have more capacity to learn about your unusual and complex system, instead of being focused on learning the development basics like a junior has to.
What I suggest you do
- Open up a consistent line of communication with the manager. Ideally daily (even if only a "Hi Bob, all good today!" message), but at the very least weekly.
- Bring up topics that are not problems yet, but might be in the future.
- For any issue that requires coordination between multiple team members, make sure that your manager is aware of them. Not necessarily the nuts and bolts, but at least the context and ultimate goal of those activities.
- Fix your process when you see issues. Your stressful release deadline debacle is a great example here. A single well-intentioned dev could bring the whole thing down. This should raise many questions whose answers will help you improve your process, such as:
- Why were we all scrambling so much on the last deadline day?
- Why are we allowing unreviewed work to already impact our release?
- How can we protect ourselves against a single dev (anyone, not just the newcomer) taking down the entire team's work?
- Don't engage the newcomer in pointless discussions
- However, do remember that junior profiles can't always distinguish between what is a relevant consideration and what is a distraction. Them opening up a discussion doesn't mean that they intended to distract from the work, it can mean that they mistakenly think this contributes productively.
- When a particular conversational branch does not contribute productively, cut it short immediately and return to what you were talking about.
- When their point makes apparent sense, even though there's other considerations that change the conclusion; it will usually be better to at least acknowledge their input before explaining why the conclusion is different. However, this depends on the person.
- Strike a careful balance between sticking to the facts and not enforcing dogma. This requires some nuance and experience and is not as clear cut as you would want it to be.
- Do engage the newcomer in a conversation about what they struggle with in the workplace, and genuinely, objectively try to judge whether this is a matter of the newcomer not understanding a good system or a newcomer raising valid concerns about a broken system.
- Realistically, Rome wasn't built in a day, and it won't be fixed in a day either. Even if the newcomer is right and the system is broken, acknowledge their frustration and explain to them that for the time being, they'll have to follow the system as is.
- Do not slack on actually fixing Rome in the long term. Don't keep making promises that things will be improved in the long term and then not actually doing it, because you will bleed staff (either in employment or overall workplace engagement) in the long run.
- Re-evaluate if the kind of junior profile you hire is conducive to the workplace that you're employing them in. Some environments simply aren't welcoming to junior profiles, either because of the complexity of the system or the lack of proper support systems to train and mentor juniors. That's okay, not every workplace can be junior-friendly; but then you should be hiring more experienced (and thus more expensive) profiles instead.