Everyone in the content industry seems to be trying to define their roles these days. There are a number of new roles and titles being described, and everyone wants to know where to draw the boundaries around them.
Commenting on my recent post on Content Engineering, Jonatan Lundin asked, “So is an information architect a sort of content engineer?” On LinkedIn, Bob Newman protests “I am the Technical Writer – NOT the SME!”. And in the first meeting of the nascent Content Strategy Collective, defining content strategy and content strategy roles was the first thing proposed as a goal for the group.
While this desire for definition is natural — it not only give a sense of security, it really helps when you are asking for money — we can very easily fall into the trap of what we might call the “In Tray” model of job definition.
There is an almost iconic depiction of the typical office job which consists of a person, seated at a desk, with a tray on each side of them, one labeled “IN” and the other labeled “OUT”. The definition of the person’s job is then very clear and easy to define: it is to take the items placed in the IN tray and transform them into items for the OUT tray.
In such a scheme, it might be the job of a technical writer to take the technical spec that the SME places in the IN tray and transform it into a user-readable manual, which they place in their OUT tray. The contents of the writer’s OUT tray might then be transferred to the information architect’s IN tray, whose task would then be to fill their OUT tray with findable, SEO-friendly Web content.
In real life, this model is unrealistic. It might fit well with the management theories of the 50’s or with the union model of work in which a carpenter is not allowed to change a fuse or a plumber to hammer down a protruding nail, for fear of taking work from an electrician or a carpenter respectively. It does not work in a modern company, or in a modern economy.The problem with definitions is that they are, by nature, about boundaries, about the outside edges of things. Come up with a set of job or role definitions and you generally end up with a kind of mosaic in which every tile is separate and cemented in place among the other tiles with no gaps and no overlaps.
Such a pattern looks neat, well defined, and well organized, but in practice it is inefficient and fragile. If any part of the process breaks down, no one can cross roles to solve a problem or fill a gap, and no one sees enough of the overall process to know if it is working efficiently or even if the role they play contributes any value at all.
We would be much better off if we moved away from defining roles by their edges and instead described them by the center of their focus. Most roles in a modern organization are less like a tile in a mosaic and more like the beam of a flashlight. A typical flashlight beam has a small central bright spot and a much broader cone of light with quite fuzzy edges that fade off into the darkness. It often takes several flashlights to adequately illuminate a scene, their central bright spots focussed in different places, but their surrounding cones of light merging with one another to adequately light the whole scene.
So, is an information architect a sort of content engineer? No, content engineering and information architecture have different points of focus. Content engineering is focussed on the content development and delivery process. Information architecture is focussed on the findability of content.
We might apply the insomnia test to finding the core focus on each role: what do the people in each role sit up half the night worrying about. The content strategist, perhaps, sits up worrying about the business value of content, the information architect about whether it can be found, the writer about whether the content is clear, and the content engineer about whether it is being produced efficiently, and whether it takes advantage of the latest delivery technology.
Do their areas of concern overlap? Of course they do. The information architect is not going to be able to maintain findability on a website without understanding and managing the process by which content is created and delivered to the site. The content engineer is not going to be able to engineer an efficient content creation and delivery process without understanding how the content needs to be organized or the business value it is supposed to deliver.
Do these roles overlap with other content roles as well? Certainly they do. The content strategist’s point of focus is to make sure that content delivers the greatest business value. They can’t do this without worrying about whether people can find things in the content, or whether the content development and delivery process is delivering the right content at the right time for the right price.
Similarly, a writer has a focus on creating content that is clear, correct, and useful, but they cannot do this without understanding something of the subject matter, of how the content will be organized, and how the content creates business value. Nor can they work in complete ignorance of the content engineering framework they are working in (though actually it would be better if they needed to know less about it that they have to today).
Thus while the content strategist, the content engineer, the information architect, and the writer all have their specific points of focus, the content strategist’s role also has a broader sphere of concern that includes content engineering, information architecture, and content creation. Each of the other’s similarly includes a wider sphere that covers the focus points of other roles.
The writer, notably, requires some significant degree of overlap with the SME. Merely to place an engineer with no knowledge of the user or of communications with a writer with no knowledge of the subject matter is to invite disaster. Such a pair would lack any of the common ground needed for effective communication or collaboration.
What is needed, right across the communications spectrum, is the collaboration of different roles with distinct areas of focus but overlapping areas of expertise.
However, you don’t always require every specialty in every team. The writer and the information architect should both be capable of doing basic content engineering, for instance. You may not need a dedicated content engineer on every team. Similarly, a writer or an information architect should be capable of doing basic content strategy, and a content strategist of doing decent copy writing.
Nor do we necessarily need the same role definitions or skill sets from one organization to another. Just as many different patterns of light can adequately illuminate a scene, many different sets of roles and responsibilities can work together in different organizations to accomplish the same overall goal. Content jobs are mortar jobs, and they should adapt to fit the nature of the organization in which they exist.
Going too far down the road of strict definition either for content fields or for content roles may only serve to create barriers that prevent people attaining a sufficiently broad set of skills and understanding to collaborate effectively to deliver real business value through content.
Let us focus less, therefore, on drawing strict boundaries around fields and around roles, and concentrate rather on the central focus of each field, and each role, and how they work together with fields and roles with other points of focus, but overlapping spheres of concern.