7

I am working in a small IT start-up of ~20 people.

Most of us are very technical and senior in our respective roles with very little overlap in our specialties.

One of the first hired guys - let's call him Dan - is a decent programmer but isn't really an expert on any of the main topics we are working on. As there was nobody else at first when he was hired, he started working on a lot of those topics anyway, the best way he could. While he did a decent job given the circumstances, a lot of the calls he made were not ideal, and these "mistakes" were highlighted every time a new hire with more experience joined our team.

Our management is of course very aware of this and actually expecting it: Dan is facing absolutely no blame for any of those mistakes - quite the opposite - and that makes total sense. I joined shortly after Dan and I, too, had to work on things that I barely knew anything about at first. It's just start-up reality: you just can't start with the perfect roaster of people from day 1 and mistakes will be made. It's fine.

Obviously, the more experience people we hired, the more changes had to be made. And now Dan is getting more and more defensive. He constantly tries to defend his choices, his designs, even when faced with people who have been experts in their fields for +20 years and come up with very factual points explaining why X or Y is not ideal. He just says "no, I disagree" without giving many explanations. To makes things trickier, a very experienced guy was put in charge of Dan and all of sudden, Dan had a boss who wasn't the CEO anymore.

I get how the situation can be frustrating for Dan, slowly losing his leadership over the codebase, whereas he was one of the first people to join, but at the same time we have a functional product to ship: good technical decisions must prevail, not ego.

Now, Dan pretty much has issues with all the various teams we have, but with me it feels even worse: while I have not 20 years of experience on my topic and am significantly younger than the others - including Dan by a couple of years - I was still hired for my particular skillset, track record and expertise and I am the only one in the company with experience on a very important aspect of our product. I was hired not only to implement things on the product, but to train all the other employees on "online & cloud development, operations, security and systems reliability". All the other employees, no matter how senior they are seem to enjoy my trainings and keep saying they are learning a lot - I myself am learning a lot from them too in their fields, so it's really a great vibe all around.

I recently started working with Dan's team on a key aspect of our product, and had to develop or redevelop some of the things Dan's had been working on. To be 100% honest: his stuff would just never scale in production. Communication with him has been a nightmare:

  • Dan: "Why are you changing things? We've always done like that."
  • Dan: "Why are you doing things so complicated? You know, keep things simple."
  • Dan: "We don't need that complexity. It was working before."

Now, the "complexity" Dan is mentioning is everything that is actually required for me to make a good job: I can't debug an online service without decent logging, error handling, monitoring. We are making a product that needs to scale for hundreds of millions of elements, which will never be able to fit all at once in memory, so this needs to be accounted for. I could go on: there are always good reasons why I must "complexify" things: we are getting something for it.

I tried to explain before making the changes, doing prototypes to demonstrate and explain better: no luck. No matter how patient I am with my explanations, Dan just doesn't care. He constantly hammers the message that I'm generating complexity for no reason. This annoys me, a lot.

Management actually takes my defense and say they understand 100% why I make changes and such and even warned Dan several times to be less defensive and negative.

But I'd still like to find a way to get through to him and communicate better.

What can I do to earn the respect of that coworker, or at the very least to establish an effective communication channel?

3
  • Are you in a situation where you need Dan's approval? That is, can you avoid justifying your position and just make the change? Mar 17, 2022 at 17:07
  • @MichaelMcFarlane Not really. I can go ahead and change whatever I need to, but doing so without having him onboard - or at least, aware - seems to yield even more drama.
    – ereOn
    Mar 17, 2022 at 17:12
  • Has Dan made any decisions that survived the scrutiny of new workers. If anything you ever did, was discarded as useless, would you act like Dan did? Mar 20, 2022 at 18:11

3 Answers 3

10

The fundamental problem here is that Dan feels invalidated. Thus, there are two approaches for you to take.

The first is to validate Dan when you talk to him. Find a way to compliment him in any discussion where you must make a change. For instance, in the case above say, "What you implemented is great and effective, but now that I must add a layer of complexity to do this new thing that did not exist when you made this great widget." Since you are very committed to good communication, I suggest reading the book Crucial Conversations.

The second is to cease justifying your changes to Dan. You have the backing of management and the credibility. Instead, communicate details to Dan alongside his boss and project team. Do not argue or criticize, just state the changes and why. Do not respond to Dan's complaints. Let Dan's boss manage Dan's relationship to the team. (I would prefer this myself, but you clearly don't want to give up yet).

1
  • 1
    Thanks for the feedback and advices: much appreciated. I've actually tried #1 a couple of times, but I feel him not recognizing my seniority/value causes any attempt at flattery from me to have the opposite effect. Since I am indeed not ready to give up just yet, I will definitely add that book recommendation to my short-term reading-list. Thanks again!
    – ereOn
    Mar 17, 2022 at 17:39
3

Do be very careful when contriving to 'validate' Dan as suggested; this can easily appear as patronising and insulting - he is unlikely to be fooled by someone who pays lip-service to his opinions, then completely ignores them, so I'd suggest the following approach:

"Dan, I realise this is a difficult situation; you've worked on this for X years, and have built up a wealth of knowledge and experience in this area. However, I've been hired to make some changes, and implement some new techniques that might appear novel to you. Can we discuss this?"

Now comes the (even more) difficult part: you have to negotiate with him over the new methods you are employing - and I don't mean a fake negotiation where you ignore everything he says, because he'll smell that a mile off, but a real negotiation, where you discuss the various options, including some of the 'do nothing' options he might prefer, and reach a suitable compromise. In the end, you have the option of saying "stuff you, I'm doing this anyway", but that must be treated as a last resort, not a desirable approach.

You have presented yourself to us as an expert in the field, but a little humility goes a long way, and maybe Dan has already tried some of the techniques you are proposing, has found problems with them, and by combining your knowledge you can come up with something much better.

However, your working relationship with Dan might already be so bad that this doesn't work. If so, resolving this situation is way above your pay-grade, as it is about the fundamental company structure. Senior management have to be aware of the problem, and they should try to find a way (organisational or financial) for Dan to feel rewarded for his service to the company. If that fails, things will get nasty, and you don't want to get caught in the crossfire between Dan and your employer.

2

Define load tests according to the requirements, ask Dan if he thinks it works and let him carry out the test.

He has the choice to

  • reject the test -> go to the produce manager
  • fake results (not wise)
  • accept the problem and fix it
1
  • 1
    This! I was concerned from the question that lots of the non-functional-requirements (logging, performance) might not actually be defined in the tickets, so an experienced dev "knows" the appropriate level but a less experienced one has to guess, and can easily get it wrong Mar 20, 2022 at 19:11

You must log in to answer this question.

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