How serious is it that my new teammates didn't show up to a meeting I set up that they agreed to attend?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

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

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.