This is a great question.

First, recognize that there are potentially conflicting priorities here. You want:

• To resolve the issue as fast as possible
• To train the other team (who will be slower to resolve the issue)

This means you need to identify first which is most important. Is it a critical issue and any wasted time is super important? Your business needs will drive this. I will assume this is basically a critical issue for the rest of this answer where solving the issue immediately is the highest concern.

Before we talk about communication, though, you need to have a cohesive and organized plan for responding to issues. By that I mean identify a point person or location for each incident. That might be a good thing for your less experienced Seattle team to own - an incident commander from there to effectively organize the response, communicate it, etc.

Once you have a point person they are responsible for organizing the response. If your Seattle team is very inexperienced, you might want to have a backup/shadow type incident commander to work with them.

Communication can only engage both teams if you have a defined plan for response. An ad hoc mass chat ping "stuff broke all hands on deck!" isn't as effective.

What we've found to work is a combination of things, primarily a easily accessible chatroom and a video call. You are correct in identifying that people actively resolving the issue are unlikely to type out massive walls of text. But they can talk in a video call and someone else can type updates (this is an advantage of the incident commander(s) - they aren't actively engaged in fixing the issue).

The primary people to talk in the video call should be those actively resolving the issue. Not bystanders wondering "hey what's the status?" -- that chatter should 100% be directed to the chatroom.

Incidentally video is important too, as faces really help form relationships and trust. What you are basically trying to do is build both those between your teams so try to have video if at all possible.

I would also note that the experienced team will probably feel "it's just easier for us to do this" -- you may have to convince them the benefits of having more people capable of handling support issues or otherwise "bribe" them into believing. This will depend on your company culture, basically.

Have a dedicated Google Hangout so that the Seattle team can watch the Portland team resolve the issue

You want people on both teams to be working together to resolve the issue. How you identify these people is up to you, but you want experienced people as well as inexperienced people on the support/response team actively addressing the issue.

During the issue, try to let the inexperienced team be guided by the experienced team. Even if the experienced people are 100% doing all the problem solving, have the Seattle team actually be doing the responses. People will learn far more from doing than watching. Have the mentor team guide and shepherd the other team, understanding that they can take over if needed (for whatever reason).

Have some of the more junior people be responsible for liasoning with the incident commander (or whoever is "running" the response) to give updates. This has several benefits:

• They have to understand what is going on
• They don't make the busy people solving the issue stop working

By designating "point" and "support" people for your roles (see above in having a process) you provide natural situations where people can learn.

And most importantly, once the issue is resolved, do some sort of after action review to document:

1. What happened
2. Why did that happen
3. What are all the steps the team(s) took to investigate the issue
4. What ultimately solved the issue

If you don't do this, any wisdom and insight from the issue will not be persisted anywhere except the brains of those who were actively addressing the problem. And the next time you will have to learn everything over again.

Doing some sort of review/retro is probably one of the most important parts of this. It's a low stress chance for both the point/backups to discuss and identify how/why/what the experienced team did.

By documenting the issue, your less experienced team can also consume the documentation.