Five Practices of the Well-Rounded Content Management Developer

I’ve long-believed that content management is a special discipline – not readily interchangeable with any other type of software. It’s really a unique collision of people, process, and technology.

Put another way, I’ve always believed in content management as a practice.

If you’re a content management developer – meaning a dev or architect that implements or specializes in CMS as a practice (as opposed as just doing CMS incidentally like any other project) – then here’s a collection of five things I truly believe you need to be able to count among your skills, experience, and practices.

As you read through this, you might pick up on a couple themes. I’ll sum them up at the end.

(Note: the first one is technical; the rest are not, so don’t get your hopes up, code monkey. And if you’re not a developer, please suffer through the first one.)

1. Implement lots of different systems

There are a lot of developers and firms who claim a specialty in content management, but are really just integrators of a single system. I know a lot of them, and they do fantastic things with their chosen platforms.

But, content management isn’t just about platforms, it’s really about patterns, and there are concepts that transcend any platform – things like versioning, approvals, abstraction, delivery, assembly, geography, etc.

There are patterns that you see implemented in completely different ways by different vendors. Some methods of implementation work well, some work poorly, but they all represent perennial problems that content management has been working to solve for decades.

Every implementation you understand gives you one more angle on these problems and concepts. It shines the light a little further into the dark room and blows a little more air into the bubble of your understanding.

Hell, even poor implementations will teach you something. Sometimes they’ll teach you far more than the good implementations, in fact. For years, I worked with a system I loathed, but I know I become a better developer for having experienced it.

Every hobby project is a chance to try out a new CMS and learn from it. Does your church need a website? Don’t implement in your traditional platform – find something else. You may love it, you may hate it and scrap it six months later, but you’ll learn from it.

A few sub-practices here –

1a. Work across coupling paradigms

There are a huge number of developers out there who have never worked with a decoupled system. These fell a bit out of favor years ago, but are on the verge of a comeback.

There are valid reasons for decoupling. You need to understand what they are and what challenges and benefits they bring to a project.

What decoupling also does is give you a much clearer mental model between the concepts of content management and content delivery, which get very muddled in a lot of minds. They are entirely different practices, however, with completely different priorities, processes, and skillsets.

1b. Work across open-source/commercial systems

Open-source CMS and commercial CMS are different in so many ways, but this can be tough to realize unless you’ve implemented both.

The two paradigms have different levels of polish. Open-source systems tend to have more rough edges and concentrate on extensibility and abstract solutions, where commercial systems polish more and hide levels of abstraction.

They often differ in audience too. You’ll find open-source projects that originated with developers and are still made primarily for (and primarily promoted to) developers. Commercial systems tend to have to be palatable far beyond IT, so they’re built to play to a different audience, like the CMO.

1c. Work across technical platforms

If you’re a PHP developer, try a .Net system (maybe Orchard, so you don’t have to learn webforms). If you’re a .Net developer, go see what’s happening in the Python world (which can be tough). If you’re a Java developer, try almost anything else.

Content management is very different across platforms. Java systems tend to be larger and more enterprisey often decoupled. PHP systems tend to be smaller, almost always coupled, and more developer-centric. .Net has many more commercial entries, and they integrate with the larger .Net ecosystem.

Now, on to less technical practices –

2. Contribute content

You need to eat your own dog food and contribute content to some website. You need to live in the holes, suffer through a crappy WYSIWYG editor, get confused by workflow and approvals, and bitch that your content doesn’t look like you intended it to.

In short, you need to learn to hate yourself and developers like you.

There’s a big divide between people on “the content side” – content creators, strategists, information architects, etc. – and “the development side” – the developers who work on their systems. Each one eyes the other somewhat suspiciously, not sure if that side has their best interests as heart.

You need to understand what it’s like on the other side of this divide – what’s it’s like to be frustrated in achieving the ends you want. For full effect, make this happen on a website over which you have no technical control, and are powerless to change.

When you invariably get pissed off, remember that feeling. It will make you a better developer.

3. Participate in the sales process

You need to understand what motivates people to buy and implement content management. What problems do they have that they’re trying to solve? If they’re replacing a system, why? What did it not do that they need?

You need to understand all the stakeholders in a content management project and what’s driving them. Who participates in the process? Who gets a vote? How is the organization justifying the expense? What features are they looking for and how are they comparing systems?

Read RFPs. Yes, I know, many of them are horrible. But read them even if you don’t intend to respond, because they’ll usually tell you what an organization wants out of their content platform. Learn to read between the lines – what’s the question behind the question? If the organization is proposing a solution, what is the problem they’re really trying to solve but perhaps can’t articulate? What patterns do you see over and over?

Participate in sales demos. Watch how a successful salesman demonstrates the product. How does this match up with what you think its strengths are? How do prospects react to it? What features go over well in demos that you think are frivolous? What features fall flat but that you think are critical?

Content management projects don’t begin in a vacuum. There’s always a hole that someone is trying to fill. Understand what drives these projects will help you implement them better.

4. Keep an eye on the industry

Business can be boring, but keep watching broader industry trends, because they can tell you a lot about how content management is treated in organizations, how it’s selected, and how it evolves in the marketplace.

In the last few years, for example, we saw a huge shift away from core management and into marketing functionality (things that happen after you press the “publish” button). This signaled a shift away from the repository, and that vendors felt most of the ground had been broken on this side. This is something worth knowing.

A few years ago, Salesforce announced a new content management initiative. I remember thinking, “Why would Salesforce want to get into content management?” (I blogged as much, in fact.) But the more I read about it, the more I understood their motivation and how CMS and CRM were weaving together. This has altered my view of both industries ever since.

What are Forrester and Gartner saying? It’s easy to write them off as being out of touch, but people listen to what they say. If you don’t know what the Magic Quadrant is or who is in it, find out. You don’t have to agree with them, but know that lots of organizations eat up everything they say.

You need to know who Real Story Group and the Digital Clarity Group are. Follow their blogs, and read their releases. Know what they’re talking about, and continually ask yourself how it impacts you and how you might apply it to your projects.

The larger content management industry affects you in ways you may not immediately understand, but know you’re operating in a relatively small market with strong currents. Vendors move in packs. Make sure you have at least some idea of the directions they’re moving in.

5. Go to at least one non-technical content-focused conference

I remember one of the first conferences I went too – Intranets 2001. I was a freshly-minted development manager for the intranet of a bank. I was super-excited to talk to people about databases and servers and stuff.

Except no one was talking about that.

Instead, it was a bunch of “content people” and “business people” talking about things like workflow, and user adoption, and training issues, and support contracts. No one was talking about code. In fact, code was an afterthought.

These people were talking about outcomes. They didn’t know the technical details were achieved, and they didn’t care. That wasn’t their concern. They just wanted an outcome, and, frankly, the developer was a commodity meant to get them that outcome. I wasn’t the hero, after all.

You need to experience this. You need to spend time listening to people who don’t care about your code or your architecture or your technical elegance. You need to hear them rage against their development team. You need to hear the frustration in their voice when they explain why their project failed and who they blame this on.

Go to Confab and listen to Kristina Halvorson summarize all the things you’re going to hear while you’re there (PDF)…and then hear all those things said a hundred times over two days. You need to get inside a group of content creators after they’ve had a few drinks and find out what they like, what they don’t, and what things are important to them.

Go to Gilbane and go to the analyst panels. Find out what they think are the broader trends of the industry. Go to case study presentations where a business stakeholder walks you through their project from beginning to end. What they remember from a project is probably vastly different than what a developer remembers from it. Go to vendor demos and see what features they’re pushing. In all cases, pay attention to how the audience reacts. What they like and don’t like can tell you a lot.

So…what are the themes here? Empathy and perspective.

• You need to empathize with your users. You need to understand their motivations and frustrations. Your code is a means to an end. Specifically, their end, not yours. You work in service of them, not the other way around and it’s easy to lose sight of this if you don’t get exposed to them enough. (I’ve personally spent a lot of time hanging out with content strategists in the last year. I am a far, far better developer because of it.)

• You need a broader perspective than just what you do every day. There is a world outside of Drupal or WordPress or Sitecore or whatever system you spend all your time working in. Step back far enough to bump up against the boundaries of your industry. Even exposure to an aspect of content management you never use will give you a new angle on things you do every day.

These are things I just don’t see enough of in this industry.

As CMS developers, we don’t truly understand or care enough about our users’ problems, and we play around too much in our own little sphere of happiness without enough perspective of the bigger picture – too often, all we have are hammers, so every problem looks like a nail.

We need to stop this.