4

I am in a senior position at my job. A fresh recruit came from the university and I have been working with him for around 8 months now. We work closely together, and since I am in a senior position I have been mentoring him in his work. He is quite skilled in his work, no complaints there, and overall he hasn't required a lot of close monitoring. Although I did start to notice, that when I did give him feedback, it always started off with the dynamic of 'he is right - and I had to prove him wrong'. In a sense that can seem alright, but in the long run, it's a really tiring process. I would find myself arguing with a random blog post he sent, arguing his point. Even stuff that never should be argued I would find myself arguing. 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. In general he comes to work, puts on his headphones and doesn't communicate unless he is asked something. Even then it feels like he wants to get out of the situation. 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.

Some examples of my experiences this past week:

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

  • I had given him feedback on some of his work. Some stuff had to be moved around to match how we do things in the team. The response: 'I find it confusing moving it around' - then proceeds to submit his work into our system. No further communications - when I give him a example (takes a bit of time creating an example) and ask 'Is this confusing?' - he never responded.

  • He was sick one day. The whole team was stressed this day about finishing our work to meet a deadline. He pops online (from home) and starts submitting his work. This was probably in his best intentions. But 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 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. 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, and now it would probably be thunder from a clear sky from my managers point of view. I would prefer if we could sort it out between us, but I feel our communication isn't great, and I am a afraid it could get a little out of hand. I am not a team lead (we have none), so we don't have a clear line of command besides some are more experienced than others. So the hierarchy is quite vague.

How would you proceed? something has to change for me, I don't feel happy arguing simple things all the time. If talking to the manager is the solution - what do I say.

4
  • 1
    Going to your manager is the solution. It is an escalation. Commented Oct 6, 2023 at 16:24
  • 7
    This sounds to me like you're nitpicking the guy to death. WHY were you arguing about circles; that doesn't sound job related, and formal vs. colloquial is rarely a productive discussion unless the difference matters in a specific case. Why do you feel that his having submitted code for review was a problem -- there's no requirement that you merge it immediately, and I think it's great that he cares enough about your project to spend some of his sick time trying to move things forward. (If he was checking the changes directly into working code, you need to fix your process.)
    – keshlam
    Commented Oct 6, 2023 at 20:29
  • 1
    "But I like to do it this way, I think this is better" - Only you can evaluate that, but as a general idea could this be a chance to review your processes? Higher-ups make rules because they can, but that doesn't mean they understand what these rules do because typically they don't do that work themselves. Especially in programming, when teams are lead by non-programmers. There are so many rules outside that only exist to exist. People rarely follow them and those who do have a harder time than others. Of course you can't constantly change everything, but perhaps it's worth a thought.
    – puck
    Commented Oct 7, 2023 at 8:53
  • 4
    To clarify, the argument about circles is relevant, since we do graphical work. I pointed out that he didn't make a correct circle, he found a odd shaped circle being more 'perfect' for the eye. (I don't agree) Commented Oct 7, 2023 at 20:52

3 Answers 3

7

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.
4
  • 1
    "Unless you are mathematicians discussing geometry, none of this discussion is relevant." This is not true. There are other scenarios where the geometry of something is relevant. It seems strange to assume that the OP is getting into arguments of no relevance when there isn't any reason to assume that. Circle vs egg-shaped could easily fit within your suggestion of "[implementation] isn't right, it should be [better implementation]".
    – rooby
    Commented Oct 9, 2023 at 5:31
  • @rooby "A circle is egg shaped when [..]" is a general discussion on geometry, the semantics of shapes, and how to define them. That is not a discussion of "that component doesn't look quite right, it needs to be a circle according to the specs" (or similar). Did one flow from the other? Yeah, very likely. Are they equally on topic for the job at hand? No. I'm not saying that no developer/person is ever allowed to discuss a topic that's broader than the task before them, but this specific developer, who keeps opening up distracting topics of conversation, should very much be kept on topic.
    – Flater
    Commented Oct 9, 2023 at 8:12
  • @rooby: Somewhat comically, but actually very analogous to making broad sweeping statements of what circles are and aren't; the statement "A tomato is a fruit" is not an on-topic discussion when it's responding to a parent telling their kid to eat their vegetables. It's a needless argument about an abstract topic which, intentionally or not, very much distracts from the actual topic of conversation.
    – Flater
    Commented Oct 9, 2023 at 8:19
  • I see your point now.
    – rooby
    Commented Oct 9, 2023 at 8:29
2

Usually the first step is to try to work with someone in order to find a resolution.

However if you have tried that and not been successful, the next step is to raise the issue with your manager. Your manager may suggest that you try a different approach in dealing with the other employee - i.e. instead of "taking action against the employee" the manager may choose to coach you on how to interact with them in a different way. If your manager chooses this strategy, work with them - try what they ask you to do and provide feedback about how effective it was.

When you communicate with your manager stick to the facts: Employee did X and that caused problem Y. Resist the urge to give opinions (Employee ... is bad at their job) your manager needs to make that determination for themselves and to do that they need facts. Note: There is an edge case on this point that if you have seen a number of mistakes in the past, it's fair to say that you don't trust the output of the Employee as a result you check everything they submit - I would bring this up in the context of asking your manager if you should continue to check it, because - you are "wasting" time checking the other employees work, however letting it hit the fan may be a bigger problem for your manager - hence your manager may want you to continue checking the work (you need to know what they want you to do).

2

Although I did start to notice, that when I did give him feedback, it always started off with the dynamic of 'he is right - and I had to prove him wrong'. In a sense that can seem alright, but in the long run, it's a really tiring process.

Unfortunately this is the typical burden of teaching a complicated subject to someone whose role must involve complicated judgments with a large amount of autonomy. It's not reasonable to simply declare things are wrong - there has to be enough said to explain why it is wrong, and how the conceptions which led to a wrong judgment should be properly altered.

The sense that such reproduction of knowledge becomes overwhelmingly tiring, can be an indication either that you are allowing complexity in your own work to spin out of control, or that the company is not allocating the right amount of resources to reproduction of knowledge in an area that is necessarily complicated.

A specific possibility to be considered is that, when there are a large number of wrong ways to do things and few right, it might be more appropriate to involve yourself earlier in setting the correct approach and getting things right first time, rather than letting others do as they see fit but then stepping in to veto the results (and also being annoyed at having to explain/justify that veto).

It's reasonable to let learners stand on their own two feet and make mistakes once they're at the stage where they know and accept what is right and wrong in principle, and their error can be shown to be an oversight on their part of something they were already taught. But it's not reasonable constantly to waste their time letting them travel significantly down the wrong road before intervening on some criteria they couldn't have known about.

This is an error on your part and will undermine your credibility as a useful authority and mentor, especially if you don't have any qualities or interactions that massively outweigh these errors.

Learners are more likely to forgive if they think you are a generally effective teacher, than if they have come to think you are mostly an incompetent.

If you generally feel that you don't have the time for proper engagement, you should regard that as your problem.

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.

This seems like a silly argument, and I can only assume that the argument was not about how circles are defined, but about how the proportions of the shape perceived by the eye, differed from the proportions measured in some other way, and there is a difference of opinion about which measurement should take primacy.

You have to be careful about distinguishing matters of fundamental importance, and matters of style or mere opinion.

In general he comes to work, puts on his headphones and doesn't communicate unless he is asked something. Even then it feels like he wants to get out of the situation. 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.

Is it possibly a sign that the working environment is overly gregarious and overly stressful?

I believe people don headphones largely as a reaction to an environment that is overly busy. Partly it silences the noise of that busyness, partly it provides the stimulus which a radio may provide in a quieter environment, but above all it acts as a "do not disturb" sign and deters casual interruption.

What's the difference between the noise of busyness and the noise of the radio? The radio may have your attention, but never demands it, and tends to consist of a steady drone rather than arbitrary bursts and crashes of noise natural to an environment that is busy with people.

Poor relationships (such as the difficulties you have come here to ask about), and stressful conditions which affect all colleagues, may also contribute to an alienating environment where people don't really want to be.

5
  • My feedback was and is never 'veto' its 'good work, can we modify those 2%' - it seems to me he wants to avoid those 2% ekstra work. (just rather not do it,), and would rather negotiate his way of it. Commented Oct 7, 2023 at 20:34
  • @JonasPraem, 2% work would suggest say an extra 10 minutes of adjustment for each day of work completed independently. That certainly sounds quite reasonable. You've since said this in a comment below your question: "he found a odd shaped circle being more 'perfect' for the eye. (I don't agree)". That's not "negotiating his way out" of additional work, that's standing by his own judgments and reasons for having done the work in a particular way. I have to say, this isn't very compelling in your favour. It sounds like nitpicking. (1/2)
    – Steve
    Commented Oct 8, 2023 at 9:18
  • At the very least, if you do go to a manager to arbitrate, I'd expect there to be a series of compelling examples, not "we had a difference of opinion about whether a circle or ellipse looked better aesthetically - I told him to fix it on the spot and he argued the point". At the very least, I'd be asking whether you could have just stated your remark on the point, without it having to be fixed - was it necessary to fix something already done? (2/2)
    – Steve
    Commented Oct 8, 2023 at 9:21
  • Just wanna say, I love working with music (thus headphones) whether am I'm at the office or remotely, helps me get into the zone. Doesn't always mean "don't talk to me".
    – Jemox
    Commented Oct 9, 2023 at 9:09
  • @Jemox, I like music, but from a shared radio which has a social function (assuming people aren't falling out over the station or the genre). I've never worn headphones in the office. Arguably, even if the "do not disturb" sign is unintentional and undesired, it has a deterrent effect. As I say, it's most likely to occur when an environment has become over-gregarious, and contains too many people. Most people, if they want to listen to music, naturally choose a mode that shares the listening with others if they can.
    – Steve
    Commented Oct 9, 2023 at 12:41

You must log in to answer this question.

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