15

I started a new job as a senior developer five weeks ago. I have worked with a one of my colleagues and two of my managers at a previous company, so I'm not a totally unknown quantity at this new company.

Within a few weeks I noticed that their code check-in had a few manual steps, which could be eliminated. Shortly thereafter, I learned that an improvement to that process was in development by "developer A".

Since further improvements were possible and my manager encouraged me to create a proof of concept for a potential solution, I created a document outlining the options (including the possibility of making no changes) for further improvements and set up a meeting with "developer A" to discuss the pros and cons of these options.

In this meeting, I tried to maintain an "information gathering" posture because as a new member of the team, I was genuinely missing context on some options. Despite this posture, "developer A" seemed threatened and I had to reassure him several times that I was gathering information not pushing an agenda. At the end of the meeting, he suggested setting up another meeting with the stakeholders who would evaluate my proposals: "developer B" and "developer C".

I messaged "developer B" and "developer C" asking (not insisting) for a meeting. "Developer B", the senior most developer agreed, so I sent an invite for the day he suggested.

Yesterday, I had a meeting scheduled with three of my colleagues about a proposal to improve our development process.

When none of them showed up after five minutes, I pinged them. At nine minutes into the meeting, one of them messaged saying that he was stuck in another meeting.

A few minutes later, I asked this of the group: "since we weren't able to meet today, would you mind adding your comments to this pull request".

I also said, "since we've needed to reschedule this larger meeting several times, I'll send you both invites for individual meetings to get feedback on the different options I proposed in the document.

This incident left me frustrated and upset with these colleagues. Since I don't want to let my frustration lead to a bad decision, I'm asking for help understanding the gravity of my colleagues behavior. In other words, is this behavior sufficiently disrespectful to justify looking for a new job?

Here is a list of all the potential next steps I'm considering:

  • Follow up in two weeks to try to have the meeting.

  • Let this proposal go and revisit in a few months when I have more credibility at the company.

  • Explain the situation to my manager and ask for his take on whether this behavior is normal and what, if anything, I should do next.

  • Look for another job.

Any and all thoughts on this would be very helpful. Thanks in advance for taking the time to read this long post.

7
  • 1
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Kilisi
    May 26, 2023 at 7:29
  • 1
    Hello, I get your frustration however we have no idea why they didn't come to this meeting. They might have been stuck in a meeting with high management or important people feeling like they can't leave. Or an important matter that needed immediate solution. They might also trying to show (consciously or not) that they have a lot to deal with, that they can't afford another meeting on something they don't feel is a primary emergency. It seems like you are taking this very personally. Is there other elements that let you think they did not come on purpose ? May 26, 2023 at 9:45
  • @Marshall777, thanks for the understanding comment. Three elements come to mind. First, while in previous roles, I've certainly had colleagues skip meetings, I've never been ghosted by all participants without some notification around or before the start of the meeting by at least one of them. This background led me to conclude that they didn't come on purpose. May 26, 2023 at 12:41
  • 2
    did you talk to anyone before "creating a document"?
    – njzk2
    May 26, 2023 at 20:10
  • 2
    @njzk2 That was answered in the comments that were moved to chat. His manager did give him the OK to go ahead with this task. "yes, my manager gave me the go ahead to work on this and create a proof of concept, which is what my pull request contained." It's a shame the comment were moved to chat, Ideally the original question should be edited to include this critical information. It was the first thing I thought of too.
    – stanri
    May 27, 2023 at 19:10

9 Answers 9

79

It sounds like you are coming off a little too strong at this company. As you said, you've only been there a couple weeks and you are trying to change a core part of their development process. Try more informal information gathering - maybe ask Developer B and C out to coffee separately and learn more about the code change process before pitching your idea.

Talking to your manager is also a good idea to figure out what the internal process is for suggestions. If Developer A is the owner of the process improvements, getting their buy-in is important.

Considering quitting is very over the top for this situation - you're the new person and don't have a lot of social capital yet, so give it some time for people to have more confidence in you.

12
  • 6
    Thanks for your thoughts on this. I get that looking for another job is extreme. I’ve never been at a company where not showing up to meetings you’ve said you would go to is culturally acceptable. May 24, 2023 at 14:54
  • 29
    People get distracted. Especially when the meeting isn't on an issue they feel they have a personal stake in or concern about, or when they feel the topic could be handled better informally or by email. MANAGEMENT can call a meeting and expect everyone to show up whether they are especially interested/receptive or not; peers often can't unless it's clear that a meeting is the necessary next step to work things through in realtime.
    – keshlam
    May 24, 2023 at 16:23
  • 30
    And if you're proposing process change, the person you need to sell it to is probably the manager, then let them sell it to the group. Process change is more expensive than you may realize, and often less productive than expected, and too many people have seen too many cycles of that to be enthusiastic about "I was taught it's better to do it this way" or "I really like this tool" unless they have a LOT of respect for the person proposing it and it can be tested/introduced incrementally. Evolution is easier than revolution.
    – keshlam
    May 24, 2023 at 16:26
  • 20
    @mobileDev14 Missing a meeting suggested by a new team member who is not my supervisor is something I would feel hardly any guilt about. Missing a standing meeting or meeting called by anyone above me in the org chart I would only do with a really good reason. Not all meetings are created equal. May 25, 2023 at 1:45
  • 3
    I'd wait a few months, maybe a year until I was sure I understood the current system. Then, if I still felt it was worth discussing, I'd open it as a wishlist item in the ticketing system, let people discuss its importance and priority (you know those are separate variables, right) and discuss what the right solution might look like and what the benefits and costs of changing it would be. Then wait for it to come to the top of the queue, to be killed outright as misguided, or to fall off the bottom of the queue as not important enough to be worth the investment.
    – keshlam
    May 25, 2023 at 2:42
14

This is taken from a recent post to the stack overflow blog written by Chelsea Troy titled How do we get a tech team to make a big technical change? The full article is worth a read but I'll pull a couple relevant excerpts:

Your team seems disinterested, or maybe avoidant, or maybe they even resist the idea. After the meeting, you try to nail down individuals to get their opinions on your solution. Folks respond noncommittally. “Maybe later.” They want to get out of meeting with you. What happened?


Context is king

We reward developers for building new features; for delivering tickets and merging lines of code. But the lines of code themselves are not the currency of technical power. That currency is context—it’s knowledge about the system and how to change it. Who has context on the system is who has power on the team. And that drives more technical decisions than we’d like to admit.

A very real part of the work of making large changes is to socialize them. Tech heads don’t like it, but it’s true. And it makes the difference between the big changes that sail through with support and the ones that get stuck in the mud because the team dragged their feet or outright resisted them.


Socializing your change

What does the socialization process look like? First of all, it involves going to teammates one on one. That doesn’t feel efficient, but it creates an environment in which people are able to ask questions and express concerns. When you chat one on one with someone before announcing a big change, you indicate that their input matters to you. You care how this change is going to affect them. Their precious context is safe with you.

Second, start by talking to this person about the problem you’re trying to solve with your change rather than the change itself. What is the pain in the code base? Does your colleague also experience this pain? What does it look like to them? Establish that the problem you’re trying to solve is bad enough to merit a solution like yours.

Third, if the person you’re talking to does experience this pain, ask what obstacles they see for fixing it, and what solutions they might propose. Your colleagues have a different perspective on the system than you do; they might think of obstacles and solutions that had not occurred to you. Don’t refute these ideas in this meeting, even if you don’t like them or don’t think they’re worth considering. Your job, in these meetings, is to make colleagues feel heard, so that a) you can propose a solution that is most beneficial for the team and b) your audience will feel compelled to hear you out when it’s your turn.

Once you’ve talked to each of your teammates individually about the problem, take the time to revisit your solution and incorporate their input.

Once you have done this, it’s time for another round of talking to teammates. Explain that you’ve been thinking about the problem, and ask what they think of the solution you’ve come up with at the end of your revisiting period. Here, because you requested their input and you’re talking to them one on one, they’ll be more likely to share their objections than they would be in a big meeting. These objections are gold to you: they are the reasons why your team might resist your solution, and you’ve given yourself the chance to address them up-front. To the extent that you can address them, you reduce resistance to the change. For those you cannot address, you have at least made your team feel heard.

1
  • 1
    Thanks for adding this! May 25, 2023 at 15:30
7

Meetings take time and are not fun so I imagine your colleagues have to prioritize how they spend that time slot: do they work on their current task to meet their deadline, do they relax before getting back to their task or do they attend a meeting? Especially if the meeting is set and led by a peer they don't know very well I can see why they would think it is not top priority.

I would say talking to your manager might be risky, you don't know how he/she will follow up with your colleagues - if you get them into trouble or into an uncomfortable discussion with their boss they will miss trust you even more. Also, your manager might not be pleased to spend time micro managing the interactions between team members or might say you are having difficulties fitting into a functioning team.

Also you shouldn't resign over this. Your colleagues ignoring your meeting is just a way to avoid an uncomfortable discussion with a new colleague where they would have told you why they don't agree to your meeting. Sure, it's not a good thing but you also shouldn't consider it a personal attack on you.

Instead I would try to make and ally in your team - look for one of the most respected team members and discuss your idea with them, informally, maybe over a coffee. Either they agree with you and so they'll bring the others to your side or you'll understand why your proposal would not work or wouldn't be worth the effort.

4

The primary problem is you tried to take over responsibility for something without consent. Developer A was right to feel threatened, you weren’t information gathering.

They are all avoiding your meeting because attending would be effectively saying the have ceded that responsibility to you now, which they haven’t.

You have to be diplomatic. You have to accept that sometimes other developers will do things differently, and that when other people have responsibility for something it might turn out sub-optimally as you see it.

It is frustrating and I’ve been in your situation before, meeting a lot of resistance. Best thing I have found is to just make your self available as a resource and let them come to you for suggestions.

2
  • Thanks for this answer. Much of it resonates with me. Just a clarifying question: In addition to just making myself available as a resource, would you consider making a smaller change (i.e. creating a script that a developer can use to automate steps on their personal machine, but that doesn't change anything substance at the project level. I would also share this script diplomatically). May 30, 2023 at 12:44
  • 1
    Yes, it is frustrating. I have spent the last year watching my colleagues go down wrong paths in an area I'm an expert in. Initially I tried to direct them or take over some parts but got resistance. In the end I did something similar to what you propose -I wrote the code and put it in a personal repository and when the topic came up again I said something along the lines of "I've done this before, here is some demo code how I did it" and left it at that. Helps if this is done in private with the person responsible, rather than at a meeting. May 31, 2023 at 2:19
2

I will preface this answer by pointing out that, by this answer I don't mean to imply that "it was your fault", but simply that it is always worth considering how you can improve after any such event that causes grief to either party.

I think your planning of the meeting has much room for improvement, and in this situation the relative lack of planning and diplomacy worked against you. I highly recommend (to everyone who holds meetings in general) a very old but amazing videoclip by John Cleese, called Meetings Bloody Meetings. This is a short (30 minutes) comedy skit, but don't let the comedy fool you, every second is worth its metaphorical weight in gold. There is a nice summary of all the advice in the last 5 minutes too. In fact I often return to this video to make sure I'm still holding my meetings properly.

If you structure your meetings as above, they will be useful, and people will think of them as a positive tool and look forward to having them. Otherwise, most meetings are generally a waste of time and serve mostly as a tickbox exercise. The "This meeting should have been an email" adage comes to mind.

I would also go a bit further to say that, the "way" in which you call for a meeting is very important too. Depending on the culture within the company, in general I would be a bit weirded out if a newly joined colleague started booking meetings with other seniors as if their time is not important (you say you are also senior, but perhaps there is an implied/established hierarchy already, and perhaps the manner in which you called the meeting might have been perceived as a signal of your intent to compete on perceived seniority, as opposed to quiet, respectful collaboration devoid of "drama"). Heck, I'd be weirded out if a senior did that even if I was a junior colleague! So, perhaps the "I'm in another meeting" comment was a signal from them to that effect (i.e. that they have more important meetings to attend, or that they want to cut this arbitrary-meeting-mentality attitude at the root).

To some extent, preparing a highly structured meeting with a clear agenda and useful purpose helps even in this scenario, because they know what to expect or what is expected of them and that their time will not be wasted. But in this case, even more important would be getting some buy-in before the meeting, otherwise if the first time they learn about the issue is the meeting-email, you risk alienating your co-workers and creating resistance (in Japan, this is embodied in the concept of Nemawashi; also a highly recommended read).

Again, not implying an "it was your fault" situation; just points that may be worth considering (which I think are generally good advice even in the event that you had done everything right and they were not directly applicable in this case).

1
  • 1
    Thanks for this thoughtful response. In terms of the "way" I called for this meeting, I see that my approach could have been improved. Here's what I did: after meeting with "developer A", I created a group chat with all the developers mentioned above present. I mentioned my document and said, "If you agree, I'll go ahead and set up a meeting." In retrospect, I see that creating a document with alternative proposals to the current process would come off as "too strong". A better approach would have been to informally ask for context on the manual process I was looking to improve. May 30, 2023 at 12:23
2

You might think about what’s in it for your new colleagues. Looks to me like you want the fame and they’ll have the extra work (change is always extra work) and take the blame if it doesn’t work.

So right now it’s nil:one. You spent time trying to arrange a meeting but unfortunately you didn’t choose a time where everyone is available. They got real work done, you didn’t. I’ll predict that things will go on like this.

So try to focus on doing the same job that everyone else is doing, until you have everyone’s respect.

It would seem socially acceptable to your colleagues to get rid of your meeting requests with the least effort, which is saying “yes” and not arguing with you, and not turning up.

1
  • Thanks for your answer. Two clarifying questions: 1. would you mind explaining why you think the other developers would take the blame if it doesn't work? 2. You wrote, "They got real work done, you didn't." Granted that my manner of proposing change needs to improve, but how is it that you don't consider it work? May 30, 2023 at 12:33
2

Developer A has already taken responsibility for this problem, and has likely been thinking about the solution for some time. Attempting to leapfrog ahead of them is rude. Devs B and C know that they were being rude - they were returning your rudeness in a plausibly deniable way. It's not unreasonable for Developer A to view this as an attempt to make them look bad, and Devs B and C to take their side. If you think the change is urgent, or is in danger of perpetual backburner status, it would be appropriate to discuss that with Developer A, and/or to volunteer your time to help with their changes. If Dev A agrees with you that they'd like to see it done soon, they can mention it to the boss, with your agreement as backup. And after that, if you really feel strongly about it and you want to spend some social capital, it wouldn't be totally out of line for you to say to the boss "hey, I think this change is important, is there any way we can help Dev A get some time to work on it soon?"

Going out and scheduling your own meetings about it, whether or not you present them as "information gathering," is not volunteering your time; it's an attempt to take the lead on the change. Taking initiative on backburner tasks is good, but not when someone else was already working on it!

The fact that your manager suggested you go to Dev A to discuss your ideas should be taken with a grain of salt - your peer relationships with other developers are indeed a concern of your manager's, but a concern pretty far down on their list of priorities. On the other hand, you should care about those peer relationships quite a lot, and should take management advice with a grain of salt. Your manager likely just wanted to encourage your eagerness and didn't think too hard about the implications.

1
  • The last paragraph of this answer really resonated with me. Couple clarifying questions on the first paragraph: 1. I see how my behavior towards Developer A was rude. Would I have avoided this rudeness by informally asking him if future changes were being considered and, if so, attempting to gather information about that? 2. Despite the fact that Developer A worked on this initiative, this type of initiative is usually handled by another team. In your opinion, how important is it that Dev A himself completes the task? May 31, 2023 at 12:50
1

Keep reminding them if it's important. No need to take it personally maybe people feel since you are not their boss the meeting is optional. At the end of the day, they need to show up if they need it and if it's a detriment to them to not be there then it's their loss.

1
  • This does not seem like good advice, for a developer new to the team. If I was one of those senior developers, and a new team member was taking this approach, it would really annoy me. Jun 4, 2023 at 23:09
1

I'll go out on a limb, and suggest that if you thought it was going to be successful, planning meetings in this way, after having only worked for the company for a couple of weeks, you may not be sufficiently experienced to be suggesting large scale changes yet to their core systems.

You might be entirely correct, and your solution might be optimal, or, there might be other aspects to the system you're not aware of yet, and valid reasons for those manual extra steps.

Your enthusiasm is commendable, but you need to take a more diplomatic approach. You don't start in a new company and immediately try to tell the existing developers how to improve their code or processes. That never goes down well.

I would recommend at this stage that you just drop the topic. Keep your head down, and just do your project work for a while. Don't try to schedule anymore meetings unless it's actually required for your assigned tasks.

If you're going to be scheduling meetings with senior developers, potentialy costing the company many hundreds of dollars, you really need to have a good reason. Don't do it just because you think their development process isn't good enough. That will not win you friends or respect within the team.

You must log in to answer this question.

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