Ticket in, ticket out. Story points in, story points out. My work is fairly typical to the majority of engineering outfits. That's not to say my work is not exciting, it very much is, but it's got very specific parameters and processes and this has an impact on our professional socialization.
Any social and/or professional conflict I have is also somewhat typical of an engineer in my position. I like to think I've mitigated the majority of it, but it is impossible to avoid conflict wholesale. I work actively to mitigate workplace conflict, with online training, reading, and most effectively: routine career coaching provided by my lovely employer. Individual contributors have a special obligation to mitigate conflict in order to ensure autonomy on their team. The less a people leader is required to intervene on an IC, the smoother a ship runs for both of them.
Still, I'm more at risk of attracting conflict due to my work in ad-hoc workstreams I'm assigned to. These may include a random incident case, a hacked-together gap project or something similar as opposed to my longer product work which has much more easily advertised parameters, acceptance criteria, and timeline. It's a regular topic with my coach, and one thing that we've mutually come to meet on is the interia of engineering work naturally produces conflict.
Not unlike an engineer’s responsibility to control context switching, mental overhead has to be committed to switching from an “engineering” brain to a “social” one, as they’re functionally different.
The best example I'll use of this is transactions. In the normal course of business, we will take JIRA tickets first-in-first-out, scrutinize requests, and prioritize production of resources.
However, "social game" is less of that. Strictly adhering to one message in, one message out or making every request a give-and-take at work will make your work a waking nightmare. Sometimes when responding to an initial message a question will require elaboration and sometimes in responding less is more. Sometimes a colleague needs to feel like they got bailed out by you in order to accept a request from you in the future.
Another more obvious example is process. Professional interaction often does not follow a defined process, and when they do, they vary. I can relate to this because I took a college class on professional interaction and almost none of it held true. However in the normal course of work most productive engineers are borderline confined to process. This is an example of the shift in mentality required to exit engineering work and enter a social interaction.
Anyways, if anyone wants to get a beer just file a ticket.