We Can’t Use “In Tray” Definitions for Content Roles

By | 2013/11/18

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.

IN tray

We can’t define content roles by what is going into the IN tray.

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.


A mosaic of distinct job roles may look organized, but roles with such strict boundaries cannot collaborate effectively. Image: By Michael Coghlan from Adelaide, Australia [CC-BY-SA-2.0], via Wikimedia Commons

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.

Each role has a point of focus and a wider circle of interest.

Each role has a point of focus and a wider circle of interest.

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.


12 thoughts on “We Can’t Use “In Tray” Definitions for Content Roles

  1. Ray Gallon

    Hi Mark, what an excellent, clear, explanation! I agree 100%

    You might find it interesting that at the recent EuroIA conference, they have a bowl where any speaker must deposit one euro if they attempt to define Information Architecture! They said, “we leave that to our American colleagues.” 😉

    They also collect a Euro from anyone who says, “it depends.”

    1. Mark Baker Post author

      Thanks for the comment, Ray.

      We need a jar like that to be made mandatory at every tech comm and content strategy conference.

  2. John Garison

    Hi Mark,

    I have long railed against the idea of “In Tray” writers who rely only on what others send them. We have to get out and beat the bushes to find people, specs, working prototypes, use cases and whatever else we can get our mitts on that we can wring good quality input out of. [Talk about ending a sentence with a preposition …]

    Once we have the content, it’s on us to use it to its maximum potential regardless of what hat we are wearing at the time or share it with whoever can use it to do their jobs better and improve the output..

    1. Mark Baker Post author

      Thanks for the comment, John.

      Indeed, and you can’t do any of those things well without a good understanding of the subject matter.

  3. Alex Knappe

    Good one in this series of clarifications, Mark.
    What I’ve been wondering while reading these posts is: Is there already so much specialization in the tech comm field overseas?
    I’m a bit confused, as the guys around here in Europe (or at least in the German speaking part of it) are following a more generalist approach.
    While you devide the jobs into content strategists, content engineers, tech writers and others, we usually get the jobs done by individuals or teams, that build up their expertise in all of those fields. Some are pretty successful in doing that, some not so much.
    If I reflect my own job, I’m covering tech writer, information architect, content engineer and to some degree content strategist and project manager as per your definitions.
    My colleagues at work cover more or less the same fields and so do most of the tech comm people I know.
    I’d even stretch it and say, we’re SMEs for tech comm – with different fields of deep expertise.
    From what I’ve been seeing over the years, only in very large companies there’s a need of differentiation between the jobs.
    It is also something that bothers me already a while. I know of a few tech writers that do exactly that: write documentation, FIFO style, guided by strict DTDs (or guidelines), not looking left or right of their way.
    This ain’t exactly what I do understand as being the job. In my opinion it takes a lot more to be a tech communicator.
    We need to understand the backgrounds of our daily work. We need to know about content strategies, content engineering, information architecture, project management and everything else along the path.
    We need that to produce quality content (information). It is necessary to know _why_ you do stuff like you do it. And therefore it is necessary to be aware of the nuts and bolts that hold the ship together, you are setting under sails.
    I think pioneering is a wonderful analogy for it. You get your mission goal and get the mission done. Cross that river? Do it. If there’s no bridge, build one. Depending on the materials you start with, you may build stable bridges for further passage or one-time-use bridges. You always need to be aware of the possible quality and need to foresee future applications. And you always have limited ressources that have to be used carefully and sparsely.

    1. Mark Baker Post author

      Thanks for the comment Alex,

      I think what is driving the specialization is not so much the size or organization but the size of the information set. On a book-sized project, you can be your own writer, content engineer, information architect, and content strategist. Because books are so loosely connected to each other, the number of books being produced does not make much of a difference to the process by which each individual books is created.

      But the book is about the largest unit of information that one person can take on an individual project. Once we move content online, readers expect it to all work as one. They expect “the documentation” to be a complete and integrated thing, not a set of independent manuals. At that point the scale of the information architecture required is much larger, requires more time and expertise, and it encompasses the work of many writers. That in turn requires a higher level of content engineering, which again is a more complex and elaborate role, requiring more than part time attention, and again covering all the contributing writers.

      The emerging demand for multi-screen delivery and dynamic personalized content also make the tasks of information architecture and content engineering more complex, requiring greater expertise, concentration, and focus.

      And even in the book world, a drive to realize cost savings through techniques like content reuse also up the ante for content engineering, again demanding specialization.

      And, of course, when these functions, which used to be practiced by the book author, are removed and give to specialists, the role of author becomes more specialized too. Many tech writers don’t like this. Tech writing has tended to be the bastion of people who preferred to work alone and own an entire project from beginning to end. (The image you paint of a lonely pioneer hacking a way through the wilderness using only their own two hand speaks exactly to this work-style preference. To have to work cooperatively as one specialist on a team of people from multiple specialties is a very different way of working which many current writers will not relish.

      That does not change the fact that the book model of tech come is dying fast, and so is the model of work that went with it. That does not have to mean that writers become slaves to an aloof DTD writer. That model is, to me, simply poor content engineering. Good content engineering should be about empowering authors to do their best work, but that can only happen with the willing participation of the authors in the content engineering process.

  4. Jonatan Lundin

    Hi Mark,
    You make a good point about the difficulty of using the “in tray” metaphor. To define a role by the “center of their focus” makes much more sense. As you do, I also hate the word “content” when used to describe what we do.

    In Sweden, a role called “Information engineer” has been around for, at least to my knowledge, some 30 years or more. An “Information engineer” role description is not only used in Sweden, but often according to my knowledge a role you often see in ILS (Integrated Logistic Support) environments, such as military and aviation domains.

    I am not sure, but I do believe that an Information engineer does among many things what you refer to as content engineering.

    So who coined “Content engineer”? Why do we need a “Content engineer” when there is already an “Information engineer”? See http://en.wikipedia.org/wiki/Information_engineering. Do you agree that the Wikipedia role description on Information engineer equals your previous post on Content engineering?

    1. Mark Baker Post author

      Thanks for the comment, Jonatan.

      I once headed a department at Nortel called “Information Engineering Methods”, so I can certainly sympathise with the idea of using the term information engineering rather than content engineering. However, per the Wikipedia article you point to, information engineering seems to have a much broader connotation, one focussed on all “information systems” across the enterprise, not simply on what we are constrained to call “content”. It is, in other words, a general IT role.

      IT has never really got content. If they did, we might be able to rely on IT to do our content engineering for us. But they don’t get it. Fundamentally, IT people see the world through RDBMS colored glasses, and if the structures of interest don’t fit the RDBMS model, they treat them as ungovernable and stick them in a blob field.

      Thus we need people who recognize the computability of content beyond the RDBMS model, and the name that is emerging for those folks, whether we like it or not, seems to be “content engineer”.

  5. Dante E. Burgess

    Not really sure why we changed data and information into content, as if it’s something completely different.

    1. Mark Baker

      Thanks for the comment, Dante.

      I think the answer to your question is because data and information are both terms used by IT with a much broader connotation.


Leave a Reply