It's not about the pair

Whilst there are a number of practices that we initially (and almost blindly) follow because we trust that there's a group of fellows that have successfully applied and refined them over time, most should only be followed for as long as they suit you and the team. Not the other way around. This means that you will most probably start with the hard-core version of any XP practice only to find that there are some things that work really well for you and others don't. Some you can adjust, some you can compromise, and maybe some you can even let go of.

It's not about the extremes

The ping-pong technique, for instance, is one of such cases. It works well in clear, well-defined tasks, and it's a good reminder of the driver-navigator dynamics, but it might not work so well for complex exploratory tasks. In that case, it's ok to split up and do some investigation first. Work on spikes together, in parallel or alone. Spikes should be a code sketch of the actual implementation. Discuss spikes together, agree on the best approach for the problem and work on the actual implementation together, if needed.

It's not about writing code

I've found that a good mob discussion on the current team cards, involving the whole team (product manager and designers included) does most of the work. On my team, we usually take some time during or after the daily stand-ups to discuss the implementation of the current tasks/user stories. It's a lot about asking questions first, understanding what the user wants, what the user needs, what we offer at the time and how we can iterate till a generally accepted solution. That usually results in well-defined short cards that make the actual coding much easier and predictable.

It's not about pairing all the time

There are a lot of reasons why you don't (and probably shouldn't) pair all the time. For one, it's not like you can be super productive all day and pairing can really drain your energy. Then there's the issue of synchronizing everyone's schedule: work time, lunchtime, meetings, emails, etc. I also find it useful to work solo on new things I have just learned pairing with more experienced developers. It's a great way to consolidate those learnings and bump on doubts or issues that wouldn't have been raised otherwise. You can then go back to your team and do a pair/mob review together. Explain why and how you did things, ask questions, adjust the code together if needed.

It's about breaking knowledge silos

The benefits of pair programming are not product-exclusive. They should benefit you too, both as a team and individual contributor. That ultimately ends up benefiting the product. If there is something new you'd like to learn and you have a colleague that is experienced on the topic, propose pairing. If you feel that essential knowledge is concentrated in one or a few colleagues, pair with them more often.

It's about communication

All of the refinements to the flow of the team should be decided together. That will require a lot of open and honest communication. I don't think that pair programming works without empathy and a safe emotional work environment - being comfortable with mistakes, sharing ideas, asking questions, being vulnerable - especially if you are in a lower power position. It takes time, energy, and a bit of conflict management here and there. But it's the process of learning more about yourself and your colleagues, sharing responsibilities, mistakes, and wins that makes working together fun and pleasurable.
Wood Zuill said something really simple on a talk on mob programming that for me summarises all these points in one sentence:

' it's not about mob programming, it's about working well together

I'm a great supporter of the 'whatever works for you' philosophy. Iterate. Find out what works for you and your team. Isn't that what agility means?

References:

On pair programming by Birgitta Böckeler and Nina Siessegger
GOTO 2019 • Mob Programming and the Power of Flow • Woody Zuill
HBR - High Performing Teams need psychological safety here's how to create it
The power of vulnerability by Brené Brown