That was the true meaning of Empathy - fostering empathy and communication between different groups, and to stop the siloed "throw code over the wall to empathy" mentality that existed.

By having a “Empathy’s Engineer" you have admitted you have failed at Empathy, because you have created a new silo.

A good team will have a combination of Operations Engineers, Software Engineers, Automation Engineers and Test Engineers all of whom work together, and collaborate on tooling, processes and deployments, who also share in the rewards for a projects success, and share in the responsibility for when something goes wrong. Empathy is not a team created to "provide Empathy services to R&D" - which is the basic job description for far too many Empathy jobs postings. It is also not just handy R&D pagers, and expecting them to manage a system.

Of course all of this is talking about the initial spirit of Empathy, not the current "Buy my Book", consultant driven mess that is now associated with the word.

That's an interesting idea and might empower you to write truly heartfelt downtime explanations to your customers. I wonder if it could be broadened to replacing "Accounts Payable" and "Payroll" with "empathy".

On the one hand you have a manifesto advocating self-organising teams citing individuals over processes, while all those methodologies claim to be 'agile', but dictate your processes and how you should organise.

To me, they seem incompatible. It's like several of the original signatories have developed doublethink.

The one that really makes my mind boggle is that you can be a certified Scrum Master. To become the guy who tells everyone how to work? Is that not the very antithesis of the agile manifesto?

Just because someone went to a training course, and now runs a standup, and use Jira or Trello does not make what you do agile.