Change is hard. But it’s our job.

In May of 2011, I came home from the best conference I’d ever attended, took a deep breath, and decided dammit, I’m gonna blog about content strategy. It was now or never, I figured.

I’m glad I did.

So last week, I took the stage at Confab myself, tackling a topic that’s been on my mind pretty much since I wrote that first post two years ago: How do we get content folks to see their work, their responsibility, as more than just planning for pages and documents? How do we get them interested in, and contributing to, all the challenges and opportunities that new devices and technical capabilities bring?

As our content is increasingly shifted and reshaped for different devices, laid out dynamically, sent to third parties, or combined with other data, I believe we—the people who know the content best and have dedicated our professional lives to making it meaningful, relatable, and helpful—have a responsibility. We must ensure that content—the content that’s mashed with Google Maps, that’s shown as related or personalized, that’s delivered in automated ways of all sorts—is as carefully considered, as natural, as it can possibly be.

We can’t manually control all the different ways our content might be used and seen. We don’t know when our users will want to save our content via Instapaper or Pocket. We don’t even know which devices they’ll be toting around next year.

What we do know is that we’re going to increasingly rely on what I loosely refer to as robots: machines that make decisions on our behalf about how content is displayed, shared, and accessed. And the more we can understand those ‘bots, the more we can help them make choices that feel editorial, considered, human.

Not my job

I spend a lot of time talking to content people—communicators, editors, marketers, strategists—about this need, and when I do, I hear a pretty common refrain.

“I’m not really technical. I deal with the words. What’s an API mashup have to do with me?”

It’s not limited to content specialists, either. I wanted to give a talk about APIs and information architecture recently. The response? “What, do IAs have to do everything now?” You could almost feel the accompanying eye roll.

Please. We’re not martyrs. We’ve spent years learning skills most people don’t have. We’re hired to apply those skills to solve problems and make great things. That’s always been our job.


Thing is, this work isn’t actually difficult because it’s technical.

Sure, maybe you can’t build an algorithm or design a database or launch an API alone. But the underlying concepts aren’t particularly technical at all: we need to define specific, discrete bits of content, label them well, and use them consistently. We need to look at the information we have—or could get from other sources, whether that’s map data or Wikipedia content or biographical information—and figure out how to best turn all that stuff into something useful, helpful, and relevant to our users.

In other words, it’s the same things we’ve been talking about all along: analyzing, organizing, labeling, and consistently styling our content. We’re just applying those skills to a plane that looks a little different.

This work is hard, though. It’s hard because it requires us to see our jobs—and therefore ourselves—differently. It’s hard because change is uncomfortable. And the more stuck in our ways we are, the more getting unstuck will hurt.

But mobile is a disruptive technology—one that is quickly transforming everything about the web. Including our own jobs.

The work of many

I’ve had IAs tell me that business rules have been part of their work for years, so why was I talking about them now? I’ve had database developers start whipping up entity-relationship diagrams before I’ve finished my sentence.

It’s great that so many people are already working on the problems with shifting, sharing, and connecting content across devices and platforms. What’s not so useful is when this turns into a turf war—a way to say, “that’s not your thing; it’s mine.”

When I wrote that first blog post back in 2011, I talked about collaboration—about not just accepting but actually taking delight in the shades of gray between disciplines.

That’s not because I was hoping for some sort of campfire kumbaya moment, though. It’s because I believe no one has a lock on concepts like rules, business cases, metadata, or content structure. Not developers, not IAs, and certainly not content strategists, either.

Adapting to a world where the web may be embedded nearly anywhere, and where content can be viewed and used in a range of different contexts, isn’t a one-person job. It takes understanding users, developing databases, updating content management systems, writing clearly, designing modularly, thinking in systems, and a million other skills.

It is not a phase. It is not a project. It is a fundamental change to the way we make things.

We’ll only be able to embrace that change if we bring people with different specialties together, and give them enough shared vocabulary and understanding to have productive, specific conversations.

In other words, it’s one big ol’ gray area. We’re going to have to bump into one another a bit before we figure out how we all fit in.

The hardest part

It’d be one thing if this were just about redefining our roles, but it goes deeper than that. If we want to embrace the flexible, ever-changing nature of the web—if we want to be successful with the digital transformation Jonathan Kahn talks about—then we need to get over the idea that our roles can be fixed, that they are immutable and innately “ours.”

The gray areas aren’t about to disappear. On any given project, in any given circumstance, our roles could—and, most importantly, should—shift. Rather than claim a territory, we have to be a bit more malleable, a bit more comfortable applying our skills even while rolling with the punches.

Because technology’s not going to stop hitting us with new stuff.

This is hard enough at the individual level (comfort zones are, well, comfortable, after all), but it’s even more difficult when we consider what that means for working with or for organizations.

Most organizations—even small ones, even non-corporate ones—are used to clearly demarcated borders, and get more than a little antsy when you start streaming through departmental walls like the Brandenburger Tor just opened and you’re about to bring bananas to the East.

But, as I’m reminded often, “this gig wouldn’t be any fun if it were easy.” That’s true for designing and developing sites that work across browsers and devices, and it’s also true here.

If you’ve embraced this content strategy thing, odds are it wasn’t because it was the easiest way you could find to make a living.

I bet you’re here because you like a challenge.

Today’s challenges extend well beyond the borders of style guides and editorial plans. They run deeper than issues with devices and APIs and content reuse, too. These are problems with organizations that weren’t built for change. They’re problems that will take time—and sweat and probably a few tears—to unravel.

Fixing our content—making it modular and mobile-ready, letting go of old print mindsets, and dealing with dated content management systems—isn’t a cure-all, no. We won’t turn businesses from stuck-in-their-ways factories to podular, connected companies overnight. But what tackling these content challenges will do is get us talking. It’ll get us thinking.

And slowly but surely, it’ll get us unstuck.

3 thoughts on “Change is hard. But it’s our job.

  1. Hi Sara,

    Great blog post – I was nodding my head in a YES motion as I was reading.

    I’ve never been one to say “that’s not my job” – if I have an idea, I will share it. If I see there is a problem, I will look at ways to resolve it. No matter what perceived section of a development it falls under.

    I do feel that content professionals are seen as stepping on others toes though when we move away from only looking at the words on a page (… gah).

    Although this is frustrating, I do think it is up to us all to face such challenges head on and highlight what benefits we can bring to developments.

    You said “I believe no one has a lock on concepts like rules, business cases, metadata, or content structure. Not developers, not IAs, and certainly not content strategists, either.” – I could not agree more.

    I guess it’s just a case of promoting the benefits of collaborative working, sharing ideas and focussing on the end outcome.

    There’s room for us all.

    If people aren’t yet at the stage where they are comfortable moving away from the traditional theory of content professionals being confined to looking only at the words, I would urge them to broaden their minds.

    If people are at that stage, but facing resistance then I would urge them to be confident, optimistic and push for involvement. For the benefit of the projects we are all working on in the digital industry.

    All the best,


    1. Thanks, Rachel. I’ve totally been guilty of stepping on toes in the past, and what I’ve learned from some of those experiences is that there is a tremendous amount to be gained by going into those conversations with a clear idea of what you’re trying to accomplish and why, but not necessarily a solution cemented. One thing that’s great about developers (or designers or IAs or most anyone who’s typically involved in the making of web stuff) is that they’re really into solving problems—that’s often why they got into this work. So if you come with a challenge and an idea, they’re often happy to help you figure out the best way to make it work. If you come to them and just say, “here’s what I want; implement it,” well, you can guess how well that goes over 🙂

      Anyway, us “interlopers”—which might be a content strategist, but could really be anyone who’s interested in being more collaborative and realizes that their job needs to be malleable—will need to continually get better at this part. Part of our job is getting people to be comfortable enough with us that they’ll take the risk to get a bit uncomfortable with their work process.

Leave a reply