Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS
John CollinsJohn Collins is a content engineer at Atlassian, where they are well along in their transition from old-fashioned bespoke content models to modern connected content.
Creating and managing content for intelligent content ecosystems requires a fresh approach and a new set of skills.
This new content engineering discipline helps enterprises address the biggest challenges of the digital era: personalization, omnichannel strategy, and localization.
We talked about:
- his work as a content architect and engineer at Atlassian and his background in journalism and technical writing
- the maturing of content professions and the emergence of specialties like content engineering
- Cruce Saunder’s seven disciplines of content engineering: model, metadata, markup, schema, taxonomy, topology, and graph
- the move from bespoke content creation to new kinds of connected content
- how he has helped authors adapt to the new kinds of creativity that decoupled content requires
- the different approaches to content strategy and information architecture necessitated by the emergence of content engineering
- the three trends driving enterprises to decoupled content solutions: personalization, omnichannel strategy, and localization
- the relationship between localization and the technical writing concept of conditionalization
- how modern CMSs permit more robust uses of metadata in content management
- the need for more people with content backgrounds to get into the content engineering field
John’s bio
John Collins is senior content architect on the Content Platform team at Atlassian. Long ago, John was an award-winning community journalist, but he made the move to the software industry more than a decade ago and has extensive experience with technical writing, UX writing, content strategy, content design, and localization. He has spoken internationally, but John is still learning and exploring content, design, and how best to get users the content they need.
Connect with John on social media
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 106. As online content becomes more complex, and as the content itself gets decoupled from its ultimate presentation, new specializations are emerging in the content profession. Content engineering is the new discipline that builds content assets for decoupled content ecosystems. John Collins and his colleagues at Atlassian are adapting their approach to content strategy and information architecture to engineer these new content experiences.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 106 of the Content Strategy Insights podcast. I’m really happy today to have with us, John Collins. John is a Senior Content Architect at Atlassian, the big software publisher. So welcome, John, tell the folks a little bit more about what you do there at Atlassian.
John:
Yeah. So I’m in a new role at the company as Content Architect. I’ve kind of been doing this for a few years under the title of Content Designer, but we’ve made this move, we’re trying to make this more of a practice at Atlassian, of engineering content or architecting content. And trying to build that up as kind of a community of practice, or whatever of those kinds of terms you want to use. I come from a content background, I was actually in journalism years ago, and I was a content designer and technical writer in software for many, many years. And I’ve always been kind of drawn to the underlying systems and structures of the content, and that has morphed into what I am doing today.
Larry:
That’s great. And I love it. Well, I want to say, in terms of the way you contextualized it, that’s such a common pathway into this, and I love that you’ve gone down the more technical part of it. But I think the way we first connected was you did a talk at the UX Writer Conference last winter, where you laid out the content professions. And you had this brilliant diagram of content strategy, content design, content engineering, and content operations. And so you’re obviously very conscious of this, of how the field is laid out. Tell me a little bit more about that journey, and how you plugged yourself into the engineering role.
John:
Yeah. I guess to a certain extent, I think of myself as kind of a big picture thinker, or a systems thinker. And I’ve been doing jobs where I was like, “I know that other people do this. I don’t know who is doing it.” Then I discovered content strategy, and was like, “Oh, well, that’s a lot of what I’m doing.” And then we had the book, Content Design, come out from Sarah Winters, and I was like, “Oh, well, that’s another thing that I’m doing.” And those both really resonated with me, but I was doing a lot of, kind of, systems work, and moving towards single sourcing in help-authoring tools back in the day, as a tech writer. And so content strategy and content design, to me, didn’t quite cover everything there.
John:
And then we started hearing the industry talking about content operations, and I was kind of like, “Oh, aren’t we being pretentious?” And I kind of got… I was very skeptical, and I made a meme, the distracted boyfriend meme, where the boyfriend was content strategy and the former girlfriend was content design. And then content operations was the one that was the new focus. But what that really started me doing was thinking about what was going on. I think content, as a discipline, is maturing, and we’re seeing these specializations come out. And I think the newest, maybe least understood one, is that content engineering. And to me, that’s where my interest has really been, and that entails a lot. And we can go into that, but it’s really those structures, the content models and other related things, that make content happen.
John:
And I think you really have to have all four of those, content design, content strategy, content operations, and content engineering. You have to have all of those before content gets shipped out. Sometimes one person does all those roles, other times you have specializations. There’s… In my diagram, those are represented by circles that overlap, because there is blurriness between, say content operations and content engineering, or between content strategy and content design. And I think many people in smaller companies, or on smaller projects, sit where all four circles overlap, but I’ve gotten myself to a point… I’m in a company that’s growing to the point where the career path of specialization has opened up, and I’m super-interested in that content engineering portion of it.
Larry:
Well, that’s so cool. I mean, it’s great that you got that opportunity, but I think the way you just said that, it’s important for anybody to understand it, because they’re probably doing some of it, whether they call it content engineering or not. Let’s dive a little deeper into that circle, the content engineering circle. What is the scope of engineering, say as opposed to… What distinguishes it from strategy, design, and operations?
John:
Yeah. So in this… To start off, I’ll kind of site Cruce Saunders, of the agency A, or Simple A is the website. He has kind of talked about, I think it’s seven disciplines of content engineering, that I think are helpful to frame it as a discussion. So I’ll just kind of run down what he talks about, and then I might frame it a different way as well, if that’s okay.
John:
But he talks about model. So, that is the content modeling, and I know you’ve had several guests who’ve talked about content modeling recently. Then there’s metadata, and then there’s schema, which relates to metadata. But schema, my quick version of that is, that’s metadata that’s applied on the published side, not on the internal system side, and that’s to help search engines, especially, understand what the content is about. Then there’s markup, which is the super nerdy discussions that you might hear about XML versus JSON, or XHTML, or some other kind of technology. Don’t often have to have discussions at that level, but it does exist as a topic within content engineering. Then there’s taxonomy, which also would relate to metadata, but is kind of a separate, is the way Cruce calls it out.
John:
Then there’s topology, and that’s to have consistent naming and things within the content system, so that authors can find it. And Cruce’s group talks about that as one of the first ways that a company can realize the benefit of a content management system, is consistent naming so you can find and reuse content. And then the last, in his way of talking about it, is graph. And that’s getting into your knowledge graph technologies, and having individual nodes that have very specific, meaningful relationships between each other. One way I’ve described that one is, it’s kind of a way to marry your content and your content system with what you know about a user. And there are other ways to describe it that may be better, but I think that’s one that people are keenly interested in right now, and so that’s one that I’ve found useful to explain, graph.
Larry:
Well, in that last point, I think… Well, I want to circle back to that for sure, but I think there’s… It seems like one of the biggest things here, that’s teasing out engineering as a practice, is the rise of sort of decoupled architectures. And I think a lot of content engineering used to just be configuring your CMS, just taking whatever they gave you. Whereas nowadays, we have to be more proactive about that. Does that mesh with your experience of…
John:
Yeah. Yes, lots of thoughts here. I think a lot of content folks are used to dealing with bespoke content. They’re often very proud of bespoke content and they think that’s where their creativity with content lies. And that’s kind of the old way of doing things, obviously, that doesn’t scale very well. And there’s a new kind of creativity of how you combine bits and pieces of decoupled content, decoupled in the sense of the CMS, but they’re coupled by meaningful relationships, as opposed to where they sit on a page or something like that. And so, if you want to open up scalability, new experiences, you’ve got to get that content out of that paradigm of a page, and that’s pretty tricky.
And I think this may open a door that’s more than we’ll have time for, but I think that a lot of the distaste that people have for their content management systems, or their CMSs, comes from how it’s configured. And that’s often because it’s not been configured from a content-first perspective. And so, you’re kind of beholden to whatever structure an IT department has put in place, or something like that. And so, yeah. I think there’s a lot you could get into there, but I think a good authoring experience is tied to the meaningful structures that you build in your CMS, which are then hand in hand with the capabilities and experiences you can create from that content.
Larry:
Yep. Hey, the way you just said something made me… I’m going to more broadly apply the word decoupled from now on, because you also used it in a way that applies to structured content, and the modular, reusable, structured content that’s also decoupled from the artifact, sort of. So I love that, but when I say decoupled, I first meant the systems.
John:
Yeah. Right.
Larry:
There’s a content system, and there’s a CRM, and whatever else, but I love that. And that kind of circles back to some of the ways you stitch it back together. So in the case of… Well, I guess, I want to stay focused for a minute on the authoring experience, because I think that’s so important. We can talk about the end artifacts, but it’s like, you need to get stuff into your CMS that you can do stuff with later. Have you worked with authors, or author teams, or operations directors, in helping to kind of bring content authors around to this new way of creating?
John:
Yeah. We did a project that’s kind of, officially, just wrapped up in the last few years. Or in the last few months, sorry. It started several years ago, and we were very driven to create an author-friendly experience. It wasn’t, maybe, quite as structured as we wanted it to be. It was migrating out of an old system to a new system. We kind of were in an unstructured world, and you have to make some trade-offs to make that migration happen. So it wasn’t maybe as fully structured as I wanted it to be, but we did a lot of work of understanding what users, authors, were trying to do. That was actually one of our user groups, we were focusing on designing something for those authors. And we had metrics around that for a user experience for the authors, although our sample size was not big enough to completely yield meaningful statistics there. But we did a lot of work where we brought them into design sprints as we designed some of the content model, but also some of the authoring experience.
John:
As much as we might want to separate them out, there’s always, I think, going to be some relationship between the content model and the author experience. And so you’re making trade-offs between what developers can build off of the content model, what authors understand for their authoring experience, and what the content itself needs. So, it’s finding a balance there. And I would say, there’s still things about that project that I wish we had done differently, or I wish we’d been able to spend more time on the author experience. We have mock-ups that we’ve never built against for some of the authoring experience. So there’s always room for improvement, but we did that project specifically with authors as one of our main groups. We’re starting on another project with the framing of content strategy, content design, content ops, and content engineering. We’ve got the content operations group kind of taking the lead on understanding what authors need, and then they’ll feed that into my team, the content engineering, and we’ll work with them to create models and potentially other tooling that meets some of those author needs.
Larry:
Yeah, that’s right. And that kind of gets into, you’ve mentioned modeling a few times now, and you’re reminding me of what Jeff Eaton says about content modeling. That there’s just title-case content modeling, which is can be quickly summarized as, The friends we made along the way. The human part of it, the systems, how it all comes together. And then the lowercase, the sentence-case content modeling, which is more about configuring things for a CMS. And it seems like it’s in the title-case area where we’re modeling content for authors. I think a lot of content modeling to this point has been modeling for the CMS. Tell me more about the increasing attention paid to the authoring experience.
John:
Where to go with that one? I mean, you’ve had employees who, their main role at the company is working in content. And so if you can help them be more efficient, it’s better for everybody, and so I think that’s a big driver for it. This is also, we’ve been those stakeholders for that project that we’ve just wrapped up, they’re content designers, so they’re very much thinking about content, and design, all at the same time. And so if we can deliver something that helps them better meet user needs, that’s going to be great.
And so we have had some folks who really understood writing from a more modular, topic-based kind of approach, that technical writing is kind of originated, but then we had other people who are completely new to those ideas. And so, we’ve had all sorts of training materials, and kind of learning management system kind of courses, that they could take to get up to speed and learn some of that. And we’ve even actually now got permissions. When they get access to the content management system, they start in a training role with limited permissions. They kind of show that they can do some things and then they get more permissions. So, touching on the governance side there. I had some other thoughts that kind of escaped me, so.
Larry:
Well, we’ve got so much to talk about. We can jump back to that if need be. Because you’re also reminding me of, once you’ve modeled something, then you have to build it. You craft the information architecture for it. And that manifests a little bit differently in this increasingly decoupled world too, doesn’t it?
John:
Yeah. There’s a couple things I want to hit on there. One would be, part of what interests me about continent engineering is, I’ve seen a number of smart content strategists come in and try to do some content strategy work. And they haven’t always succeeded, and some of that is because they didn’t maybe understand some of what the content engineering side can do. And I like… Content engineering is like content strategy applied, is maybe one way I’ve described it. That’s where you can show them what’s possible, or you can say, “You don’t have to shoehorn this thing this way. We can build some new structures, and open up some new opportunities.” And so that really excites me, about being able to open that up for the content strategy folks.
John:
But the other thing about content engineering, and kind of those seven disciplines that I went through, I think that a number of those involve information architecture. So it didn’t call out information architecture specifically, but I think as you do the taxonomy, and the content modeling, and some of the other things that it talks about in those seven disciplines, I think that information architecture is happening. And I don’t mean to downplay information architecture, I just think it’s a different way of framing up, but sometimes it’s been tricky for the industry to define, what is information architecture? So I think that if I were placing that as a specialty within the circle of content engineering, I think information architecture is one of those potential specialties, even if it’s not one of those seven disciplines that I listed. The other thing I would say is that the framing… I gave the seven disciplines, the other way I would frame it is maybe from less of a content perspective and more from a knowledge management perspective.
John:
Which I’m only newly exposed to the knowledge management world, so I don’t claim any expertise there, but they talk about ontologies, and taxonomies, mostly. And ontology kind of being the mapping between taxonomies, if I can take a super high-level, super short explanation of it. And then the content model is the manifestation of the ontology and the taxonomy, and that model may live in a content management system, but it may live in other tools. There’s taxonomy management tools, for example. And so that’s another way some of that information architecture work is happening, through those taxonomies and the ontologies. And those are specializations too, that are available if you’re in the right company, in the right role. I know people who are ontologists and taxonomists, etc. And you’ve had some of those as guests on your podcast, so that’s another way to frame the information architecture discussion.
Larry:
Yeah. I’m sort of a budding shade-tree ontologist and I’ve been studying a fair amount. One of the things that seems very promising about it, is that one way to define an ontology is knowledge representation. That when you… It’s like super metadata, is kind of one way I think about it. And I think in this, one of the… I don’t think we’ve used this buzzword yet, but another thing that’s important these days is the ability to personalize user experiences, and to match… And I think about it, especially in terms of content, it’s like you have purposeful content, hopefully if you’ve got strategists around you have content that serves a purpose. And then you have users, and customers, and readers, and visitors, or whoever, whatever you call them, who have an intention about what they want to do with you. And matching that intent with the purpose of the content you have to serve, that seems to me like where knowledge, graphs, and ontological, and other semantic practices can really shine. Have you… Are y’all doing anything in that realm at Atlassian?
John:
I’m just starting to dip my toe in that, personally, it’s definitely an area of interest, for sure. As you mentioned, personalization is a big buzz word. At Atlassian, we’ve got so many products, and so many kind of different configurations of those products. Sometimes it’s hard to provide, for example, help content, or help articles, because we don’t know enough about what your setup is. And if we could know more of that, think of how much more helpful we could be. So, those are kinds of things that are clearly of interest. I’ve got things on my reading list on those topics, and that’s actively something I’m trying to up-skill myself in.
Larry:
Yeah. And all of a sudden, I’m thinking about another buzzword, omnichannel. Because that’s… And it’s not just a buzzword, that’s a real thing that you need to… Because I think something you just said reminded me of this dynamic, that users and customers don’t care where they’re at in their journey. They just want the same… They want the knowledge and the information that they need in that moment, regardless of whether they’re on their phone in a train, or looking at their laptop at home, or interacting with an X Box console, or something like that. How does engineering… I assume you have to have really well engineered content to serve omnichannel distribution needs.
John:
Yeah. I mean, it comes back to that, kind of the decoupled CMS kind of discussion. I would say, for us moving towards a decoupled CMS, there was maybe three drivers, and we’ve kind of hinted at them all so far in our discussion here. It would be personalization, omnichannel, and well, I guess the one we haven’t talked about is localization. And there’s lots of ways we could think about localization. Is that a personalization, or is that some other relationship between the content? And so those are the three drivers that have kind of pushed us towards the decoupled CMS kind of world. And there’s lots of complexity that personalization and localization bring, it’s an exponential kind of effect when you start adding in multiple languages. And then if you have even three, or four, or five variations of something, it gets exponentially harder to manage that content, and understand what’s where, and QA it when it’s got a front end that it’s rendered in. And so all of those things are where everybody seems to be going, and those are what we’re kind of trying to tackle ourselves.
Larry:
Yeah. Does Atlassian have a localization product? Because…
John:
In the years past, we had, like, crowd-sourced products localizations. That was in kind of the pre-cloud era, and we’ve moved more and more towards cloud based offerings, and so we’ve moved away from the crowd-sourced localizations. But we do have products in multiple languages. Some of our web experiences are in multiple languages, others are in fewer. So, we’re not as robust as we want to be there, and some of that was because we didn’t have the backend systems that we really needed to have.
Larry:
Part of the reason I ask about that, is that it seems like in a lot of these problems we’re solving now, are solved problems in the localization world. Like managing different strings for different purposes, in their case localization, or translated content. Anyhow, that’s why I asked about that. But it makes me wonder in the bigger sense where you’ve learned… Because we’re facing what we think are brand new problems, but I’m wondering if any of this has been solved in other areas, or arenas, that you’ve just applied in a new way?
John:
Good question. I mean, my background in tech comes from the tech writing world, and a lot of help authoring tools offer conditionalization capabilities. And so you could have a paragraph that publishes out to three different products, and it swaps out the product name, that’s been core to technical writing tools for some time, and many of those are getting localized as well. And that is… Many of those tools are kind of either HTML based, or some related technology, XML or whatever. And so, it’s pretty easy to transfer those over to a translator and have them translate it. But you start getting into some of the tricks, or difficulties, of giving them context of what this decoupled piece of content is, and that it actually has three variations, and these are what the variations are about. So I think there is some stuff to draw from, from some of those tools, but when you move into the headless CMS world where it’s less content as code, and more content as data, I think that makes it kind of a little bit tricky again.
Larry:
Yeah. Interesting. The way you just said, “Content as data,” because that’s sort of what we’ve got now. The opportunity to treat content, and just the notion of modularizing it and reassembling it later, that’s sort of like computational uses of content. Is that how you kind of lump this all together? This…
John:
Yeah. Well, I mean, lots of people love to talk about metadata, and they may not have a clear picture of what they’re talking about when they talk about metadata, but they all want metadata about their content. And there are segments of the technical writing world who are writing documentation in Markdown, or in XML technologies, and in a sense, that’s just extremely flat text and you don’t have a lot of metadata around it. But when you’re working with some of these other structures like a headless CMS provides, then you can start wrapping it with metadata that helps you have more meaning about what this thing is.
So it’s kind of a philosophical choice of, which direction are you going to go? And then, tying it back into the discussion about graph, at some point you may need to connect that less structured, less metadata world, with a more integrated metadata. And so those are interesting challenges. And there’s tooling, and it’s becoming more and more common, and I’m not expert in all of it, but it’s all stuff on my radar. And if I had all the time in the world, I’d be experimenting with all of it right now.
Larry:
Yeah. I have done some of those experiments and it is fun, but it’s good to stay focused on your job, too. But hey, I can’t believe it, John, we’re already coming up close to time. But I want to leave time at the end. Is there anything last, anything that’s come up in the conversation that you want to elaborate on, or just that’s on your mind about content engineering that you’d like to share with the folks?
John:
Well, I would say, I kind of talked about what drew me to content engineering, and of enabling content strategists to kind of see their strategies realized. Whether you’re a content strategist, or a content designer, or even if you’re in content ops kind of roles, I think that there’s little understanding about content engineering. There’s hunger for it, and we need more people who understand content from a content creator, content designer, content strategist kind of perspective, who are interested in understanding some of the nuts and bolts, and building some of this stuff so that we have… Whether it’s tools within your employer, or commercially available tools that come to market, I think there’s a great need for people with content backgrounds to get into content engineering. And so if things like taxonomy interest you, or content modeling interest you, go hard after those things, and we need more of that kind of people in the content world.
Larry:
You’re also making me wonder, are there any courses, or books, or other resources that you can mention off the top of your head?
John:
Yeah. I mean, the go-to book to me is, Designing Connected Content, by Mike Atherton and Carrie Hane. I literally have had it on my desk for the last several months. It kind of blends content strategy with content engineering, in my viewpoint. They talk about domain modeling as a tool to understand some of the semantic structures of content, so I think that one’s great. I’ve heard Carrie explain it as, “Not a beginner’s book,” and so the book that I think would be a good introduction to that is, Content Everywhere, I believe it is.
Larry:
Yeah. Sara Wachter-Boettcher.
John:
To me, that’s a great introduction. It’s takes some… Similar kind of, not as deep, but it talks content strategy, and a little bit of content engineering at the same time. So I think those two books are great. I’m not too sure of any courses out there right now about these topics, but those books, I heartily recommend to people who are interested.
Larry:
And I would second that recommendation. I love them both. I’d add one to that, actually. Karen McGrane wrote a book way back in 2011, I think, called Content Strategy for Mobile, which was essentially the same terrain, but people were only talking about mobile at the time. So she called it Content Strategy for Mobile. But anyhow, I’ll link to those in the show notes.
John:
One other, too.
Larry:
I’m sorry, John. Yeah.
John:
Yeah. Michael Andrews, I believe. I should’ve had this in my notes, but I’m sorry. He has a book about metadata for web, and that gets very heavily into the topics like schema, and other just metadata strategies, which also lumps in under content engineering, as the way I think of it. So, that’s another very useful book.
Larry:
Yeah. I had him on the podcast a while back, too. I’ll link back to that episode in the… He’s actually got two books out, I think, on metadata for digital publishers. So, yeah, and he’s great. Yeah. He knows his stuff. Well, thanks again. Oh, one last thing, John. What’s the best way for folks to follow you, if they want to connect on social media? Or…
John:
Yeah. I reluctantly got on Twitter years ago when I was attending conferences, and I occasionally do industry related things on Twitter at JRC_Collins. Most active if I am at a conference, and then LinkedIn would be the other one, John Collins. And I’d love it if you want to connect there, if you included a note so I understand why you’re connecting with me. I do have a Medium account, but I’ve kind of been moving away from that towards LinkedIn.
Larry:
Great. Well, thanks so much, John. Super-fun conversation, I really enjoyed it.
John:
I appreciate it. I’ve enjoyed it too.
Leave a Reply