The Need for Ubiquitous Language in the Church

I recall the first job title that I made fun of. I was recently out of high school working for a small megachurch in their IT department. One of our staff pastors who had been part of the youth department had recently made the move into "the main office." She would be taking on an emerging role within the organization called "Assimilation Pastor." I remember laughing when I first heard it. My manager did too. "Resistance is futile," we both said. Surely this was a working title that they were still knocking the rough edges off of. But no. Assimilation was the term. Come to find out, this is an all too common job title.

Ultimately, an assimilation pastor (or director), has the primary aim of ensuring that in a large (or mega) church, people find their way onto a volunteer team or into a small group. Studies consistently point to volunteering and small group involvement as key indicators that someone will stay at a given church. So as you get larger (and presumably when your growth outpaces your volunteer capacity), an assimilation pastor is the next best investment.

But is "assimilation" the word that best describes that? It would be out of scope for this piece to explore the development of such a role and the language that developed around it. But the notion of inventing terms – even stretching the semantic range of word to match your role definition – is all too common.

And this is certainly not limited to the church space. Automattic for instance names its technical support people, "Happiness Engineers." The Better Bean company at one time called a marketing specialist, "Brand Champion". And Pacific Light & Hologram (which very likely just did this for keyword stuffing purposes) called an embedded systems developer, "HDL Gunslinger."

And all of this feels like I'm cuing up that George Carlin bit on euphemistic language.

But I believe this is a common foible within megavangelical-style churches. It is a tendency to develop language and messages in complete isolation, and in so doing, they develop and/or employ terms which cause confusion and and lack clarity. In this essay, I'll seek to address the problem of ambiguous and unclear language in churches by suggesting a solution drawn from the software engineering discipline called "ubiquitous language."

Ubiquitous language belongs to a software design approach called domain-driven design. So I will begin by sketching a brief introduction of domain-driven design and describing its value. Don't worry, this won't get technical in areas of software engineering.

We will then explore three major categories within which the lack of ubiquitous language is readily noticed within the church context. The first is in the definition and description of roles¹ and the titles associated with them.

The second is the naming and communication of programs amd ministries. Admittedly, this second category is a well-worn road. We will address this to further demonstrate the problem, and to further demonstrate that this is holistically impactful, not limited to a subset of communication within the church.

The third is a sort of miscellaneous category of general church communication. This will be focused to marketing collateral especially, and target internal and external communication. Think of this category as "those things a church communications director might write."

We will next discuss the impact of this lack of clarity, at the local level, and then zooming out to see its impact at a religion-wide scale. We will then begin to develop a notion for how ubiquitous language might help us solve the problem I have presented.

We will conclude by outlining the ways in which consciously defining, discovering, and adopting ubiquitous language across the three categories outlined above can aid in the church's communication both internally and across the broader Christian tradition.

Footnotes

1. I use the term "role" here as an impermanent approach to the rather murky distinction between a job opening (a vacancy), the collection of roles which make up a "job" (a vacancy that a human occupies within an org), and the distinct set of tasks that are defined as one role. _Mastering the Cube would suggest that the most atomic element of an employee's participation is a task that needs doing. Tasks roll up into roles. Roles into jobs. GitLab has suggested having only two distinctions, "roles" and "vacancies", eschewing the language of "job" altogether. This is a topic that needs further exploration in a separate piece. ↩