Working outside your area of expertise
Right now I'm working on an Android infrastructure team, which ends up working with a lot of different engineers with different backgrounds. Before this, I did a PhD with a focus on mobile networking - reasonably related to what I do now, but going from academia to non-research industry feels very much like a career change. At some point the topic of working outside your area of expertise came up, which I realize I have a lot of thoughts on.The Myth of Linear Growth
In our society, there's often a sort of a background assumption of linear growth. In college you would move from one year to the next, ideally, and we also had a class ranking of all students, so there would be a #1 student, etc, all the way to the last student. In industry, it's less structured, but you start off as a new grad, and gradually become more senior, maybe moving up some formal system, or maybe not.
Working with people from other technical backgrounds doesn't work with this framework. Maybe I know a fair amount about A, and you know a fair amount about B, but my knowledge of B is that of a complete beginner, and I may not even exactly know what B is, and vice versa.
The most obvious problem, which fortunately I think is fairly rare, is when someone says, "well, you are asking dumb questions about A, so you must be a bad engineer". A more subtle problem though is to think, "well, I don't expect you to know about A, but I'm pretty sure that every engineer uses C, how can you not know that". Or maybe not even consciously think that, but without thinking about it, have a slightly skewed view of the other person's competence. So if you tend to do that, stop.
The more common problem, I think, is when you're worried the other person is doing this.
When I was a new grad student, everyone was afraid to admit they didn't know something. Maybe they should know that? Maybe it reflects badly on them that they don't know that? Then, at one reading group, we were talking about a paper, and a fairly senior professor said, "I have no idea what this is talking about. Does anyone understand this?" Then everyone breathed a sigh of relief and could admit they had no idea what was going on. Then they could learn something.
If you're more senior, especially if you're mentoring someone, it's very useful early on to cheerfully and without shame or apology acknowledge limits to your knowledge. When people don't learn that it's ok to not know things, eventually they might be knowledgeable in their field, but still be as afraid of branching out as they were on their first day.
That's the easier part though - what if it's you who is intimidated?
I would still say - admit when you don't know things, and don't apologize for not knowing things or put yourself down. You'll still sometimes meet toxic people who think that if, say, you are not an expert in the unix command sed you are not a real engineer. This is especially true on the Internet. So while it won't necessarily solve all problems, a good first step is to remind yourself that those people are wrong, and to try and not let them sow doubt in your mind. If engineering skill were tied to domain-specific knowlege, rather than being a general set of skills, we'd all still be using FORTRAN or something.
Relatedly, if you find yourself wanting to switch what field you work in, you’ll probably be surprised to find that even though you have a lot of new things to learn, a lot of the skills you previously developed are still quite applicable, and having to catch up in domain-specific knowledge is not as big a problem as you think.
Another mindset to steer clear of is the idea that your job, field, etc, coincidentally happens to be better than the other ones, particularly ones you work with. In particular, keep in mind that engineering problems that you are not currently working on often sound easier than they actually are. Actually, this principle applies to how people often think about other people's jobs generally.Documentation
This is a much narrower problem, but documentation when working in an unfamiliar area can be especially challenging. Good documentation is hard, and a lot of work. It’s much easier to write ok documentation - documentation that works if you have enough background knowledge in the area, where you mentally fill in the gaps, maybe without thinking about it. You also probably don't have infinite time to perfect your documentation.
So this means two things: first of all, it’s not unusual to have more trouble than usual using documentation from another team. I recommend taking your own set of notes as you figure things out, and save them, even if you don’t think you’ll look at that system again. It might not always make sense to add it to the official documentation, but it can be useful to make it available and findable. This goes in both directions: expect that you might have to help people from other backgrounds more than usual with understanding your documentation.
Also, keep in mind there are only so many Greek mythological figures, etc, so be on the lookout for names for things that mean something totally different to someone else.