TL; DR:
Good teams can still feel unfamiliar.
Notice the feeling. Investigate the cause.
Seek understanding before pushing for change.
Join me for the live stream (or watch the recording) on Monday, November 9th at 7:00 PM Pacific!
The Team Is Good. Why Don’t I Feel Comfortable?
Have you ever joined a team where everything looked good on paper, but something still felt off?
Nice people. Interesting work. Nobody making your life miserable.
And yet you’re sitting there thinking, “Why don’t I feel like I fit here?”
I came across a question on the ExperiencedDevs subreddit about exactly this. The person described a team that seemed good, but had a very collective approach to solving problems. An issue came up, and everyone jumped in together. That pair-programming or mob-style approach wasn’t how this person preferred to work.
When they asked about it, the response was essentially, “That’s how we do things.”
That doesn’t automatically mean the team is doing something wrong. It also doesn’t mean the person should ignore how they feel. A good team and a comfortable fit aren’t the same thing.
You can check out my full thoughts on this in the video below:
Different Doesn’t Automatically Mean Bad
For a big chunk of my career, I wasn’t joining a well-established engineering team from the outside.
I spent eight years at Magnet Forensics, and I joined when the engineering team was just getting formed. Being there near the beginning meant I could see how our teams and culture evolved. I had opportunities to help shape how we worked.
That doesn’t mean I controlled everything. As the company grew, plenty of things were outside my influence. But there was a familiarity that came from being part of that growth.
Joining Microsoft was different. I’ve worked on two teams there, with great people and interesting work. This isn’t a story about finding a terrible team or needing to escape. It’s about noticing that some ways of working weren’t what I was used to.
One very simple example (just to illustrate the point) is design documents. On my team, there’s an expectation around writing a shorter design document and expanding it into a larger architectural document.
Do I think design documents are bad? No. I see value in them.
Was I used to that approach and that level of expectation? Also no.
Those are different statements. “I’m not used to this” isn’t evidence that “this is a bad process.” But recognizing the difference gives me something more useful to think about than a vague feeling that I don’t quite belong.
Pay Attention to When the Feeling Shows Up
I think awareness is the starting point.
If something feels off, don’t dismiss it just because you can’t immediately explain it. It’s a feeling, not a complete diagnosis. You can take it seriously without deciding that the team is the problem.
So what does that actually look like?
Maybe you notice the feeling during design discussions. Maybe it comes up when everyone jumps into the same problem. Maybe it’s there when a meeting ends and you still don’t understand what the team considers important.
That’s more specific than “I don’t like being here.”
I use a similar idea when helping someone find a development focus in everyday work: start with an experience you can actually examine, rather than forcing yourself to solve a giant abstract question.
Actionable Tip
The next few times you notice that uncomfortable feeling, write down:
What was happening?
What did you expect to happen instead?
What part don’t you understand yet?
You’re not building a case against your team. You’re trying to figure out what you’re reacting to. This is for YOU and so that you can understand yourself better through awareness.
Sometimes You’re Missing Something You Used to Have
Another example for me was moving between teams at Microsoft.
On the Deployment team, our weekly service review included incidents and a strong emphasis on metrics. The goal wasn’t to show numbers just because we had numbers. It was to surface something interesting: an outlier, a trend, or a change worth discussing. The team regularly focused on particular sets of these metrics.
Coming from desktop software, that was new to me. But it made sense, and I got used to it.
When I moved to the Routing Plane team, we also had a weekly service review. Initially, though, I noticed more emphasis on incidents, alerts, and what seemed more general observability. I found that I missed the kind of metrics discussion I’d become accustomed to.
I felt like the outlier wanting more of it.
The meetings evolved over time, and more specific metrics became something we focused on -- and maybe a big part of it was that I was understanding things more clearly myself. But the useful observation wasn’t “this team is bad.” It was “I’m expecting a particular conversation, and I’m not seeing it.”
Sometimes what’s bothering you is a habit you haven’t learned. Other times, it’s something you valued on a previous team that isn’t present on this one.
Either way, you have a better starting point once you can name it.
Ask Why Without Arriving With a Verdict
Once you have something specific, talk about it.
I don’t mean sitting everyone down and announcing that design documents are stupid and you’re changing the process. Or that the way meetings are run is wrong, so therefore we shouldn’t do meetings.
I mean, “Can you help me understand why we do it this way? Here’s what I’m used to, and here’s the part I’m finding difficult.”
That’s a very different conversation.
If bringing it up with the whole team feels awkward, a one-on-one can make room for the individual context. You don’t need a polished solution before asking your manager to help you understand something.
You might find a reason you hadn’t considered. You might also discover that other people have wondered the same thing, but nobody has asked.
And “we’ve always done it this way” is a reason. I just don’t think it’s a particularly strong reason to rule out change. There could be a lesson there or it could just be that it’s time for change.
The goal is to share your perspective and understand theirs. Both matter.
That same distinction shows up in aligning expectations between a learner, mentor, and manager. People can have reasonable intentions and still be working from different assumptions.
Understanding Can Change How You Feel
When I moved from desktop software to the Microsoft deployment team, some of the release processes felt slow to me.
I wanted changes to land so we could move on to the next thing. Why would we deliberately slow that down?
What I needed to understand was the responsibility involved. In that environment, a deployment problem could have a substantial impact. The process included mechanisms intended to make deployments safer, not just obstacles somebody had added for fun.
That context mattered.
It didn’t require me to stop caring about a quick turnaround. It helped me understand why speed wasn’t the only consideration.
And this is the part I don’t want you to miss: you can feel better about a team’s process without changing it.
Not every unfamiliar habit is secretly necessary. Not every uncomfortable feeling disappears once you hear an explanation. But understanding gives you a fairer basis for deciding what to do next.
It also helps separate an actual expectation from an assumption. For example, a manager’s availability doesn’t automatically establish your overtime expectation. If you’re interpreting a visible habit as a rule, that’s worth clarifying rather than quietly treating it as one.
Challenge the Status Quo, Not Your Teammates
I’m encouraging you to challenge things. But challenge doesn’t mean being disruptive or trying to make everyone work exactly like you.
It means asking whether an approach still makes sense. It means offering another perspective and being willing to hear why that perspective may be missing something.
There are a few possible outcomes:
The approach makes sense, and you understand it better.
The team sees an opportunity to try something different.
You understand the reasoning, but the tradeoff still doesn’t fit what you want.
That last one is possible, too. Understanding isn’t the same as agreeing.
If the mismatch remains important, start a career conversation with what you actually want from your work. A preference for how you work is worth discussing without turning it into a claim that everyone else is wrong.
Actionable Tip
Pick one thing that feels off. Ask why it works that way. Explain your experience. If a change seems useful after that conversation, suggest one small experiment and agree on what you’d want to learn.
The goal isn’t to win a debate.
It’s to be part of a team you enjoy, doing work you care about, with people you can work well with. Sometimes that means changing how the team operates. Sometimes it means changing your understanding.
But neither happens if you dismiss the feeling or keep the whole conversation in your head.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
- Blog
- Dev Leader YouTube
- Follow on LinkedIn
- Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!
'Seek understanding before pushing for change' is spot on. Every time I've moved into a new store, the biggest mistake I could have made was assuming what worked with my last team would work here. I spend the first weeks watching how people work before I change anything. Sometimes what feels off is just a different way of doing things.