That's the work that leadership should assisting in -- enabling devs to recognize and move into situations where pairing is beneficial, and giving them the scheduling tools and methods to do it successfully. The best a company should be doing is helping devs to recognize the benefits, and when they are activated for a task, and importantly, when they don't exist for other tasks. It's still such a new area, business wise, that I think it's often done very wrong.

I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.

Pairing is optional at my employer.

As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers.

I have also managed people who just like to work together and they're free to pair and unpair on an ad-hoc basis. I don't care, as long as progress is being made.

Edit - I've never "paired" in the way you suggest in a sibling response (assigning a ticket to 2 developers).

>Pairing is optional at my employer.

Is collaboration / pairing part of employee evaluation in any way?

Not directly. If somebody actively avoided paired work, I'd probably ask them about it during a regularly scheduled 1-on-1. And if somebody was doing a spectacular job mentoring/pairing/etc I'd definitely mention it.

That seems pretty reasonable. I'd hate to work at a place that "didn't enforce" something, but had it turn into a 15 pieces of flair type situation.

From my perspective, it’s a great way to mentor and facilitate knowledge transfer. It’s also great for working through coding roadblocks. It’s a useful tool, nothing more. Theres no mandate to use it at the office, it’s up to individual developers to use it appropriately and managers to facilitate it.

In many organisations pairing is encouraged, but not mandated - it means that if developer is stuck with something they ask if someone is available to pair to unblock them. Usually they'll find a person who loves pairing and get things done. In rare cases the PM would tell a developer experienced in the domain, to stop what they are doing and help. That's not too bad provided the interrupted developer gets an extra time added for context switching.

I think in every company, it is encouraged to help someone who is stuck. By "pairing", I mean that a ticket is assigned to a pair, who complete it as a pair. I've never seen a place where some tickets are done by pairs but others, solo. In my experience, if management isn't fully committed to the process of pairing, then they have a hard time understanding how pairing isn't wasting labor.

I see. I tend to avoid organisations that have such culture - I tried this and for me it is too mentally exhausting to constantly be paired with someone.

That's definitely not ideal. Ideally pairing is "authorized" not mandated.