Should a content strategist know code? How much geek cred is good for your career? When is it too much?  People have a love-hate relationship with technology even in our industry. Here’s my thoughts on how technical a Content Strategist should be. Some of you may be surprised.

This post was born of a Google Forums Content Strategy discussion (and similar on LinkedIn and Google+) addressing these concepts and sort of got away from me.  Now it’s blog-length and I think an interesting topic.  I struggle with the borderlands between technical and strategic regularly.  I’m especially aware of it in the run up to Content Agility for example as it’s somewhere where Content Strategists, Technical Communicators and Structured CCMS people all get together.  Some think it’s a tech fest because there’s any mention of XML and DITA; others see a separate Content Strategy track and think it’s not for them if they are technical authors. It’s all content, and these worlds are blurring more every day as content delivery becomes more complex and users demand a more seamless experience.

You don’t need to really know much tech at all to follow this post.

Disclaimer

I used to code in my early 20s.  I haven’t written anything in many years and have no real intention of doing so.  This post says why. BUT if you were looking for work and having ‘php’ on your resume got you the job, I have nothing but respect for that.  I’m talking big picture, long-term career-growth here, trying to look from a perspective external to our community.  In a perfect world, more knowledge would always be better.

Not all content tech is equal

I think there’s an important distinction between types of “technologies” that are relevant to CS work.

I feel the two big groups are:

• Programming languages – used to make computer programs
• Mark-up languages – used to mark up content so that computer programs can make better use of it.

The distinction I always make is: Mark-up enables; Programs do.  (Jump to the Post-Script if you want/need further explanation).

Mark-up is a CS core skill

I think that a CS person needs to understand how their content can be better and more powerfully manipulated by programming languages, if they properly enable the process  with mark-up. I don’t think a CS needs to be able to create the programmatic code themselves. You can get a programmer and explain to them what you want and why, and they will build it.  Explain the ‘why’ properly and they’ll complain far less when realising the ‘how’.  For example, if you can understand enough about XSLT to explain why it’s better than Java, that will make your life much easier even if you’re never going to write a line of either.

Programming can be dangerous to your career

I think it’s debatably important not to get into development because of the socio-political backlash in a typical project environment.  Programming is ‘dirty knowledge’.  As I made the transition early in my career from techie to content strategist, I was vividly aware of this idea.  If managers and strategic folk got the sense I was too hands on in my knowledge of ‘techie stuff’, then my cred as a strategic person influencing organisational direction went down.  I was taught that understanding it is ok, doing is not.

In this harsh light, regardless of what we say inside our community, those that employ us (if not directly then a level above or so) will often consider programming to be commoditized geek-stuff with a glass ceiling above those who partake.  This lack of interest/respect means that to keep your emphasis on the strategic side, it’s my belief that it behooves you to keep programming at arm’s length.  We can do it opportunistically, or as a sort of bonus when it adds expected value:  “Hey, I saved everyone a load of trouble with ____ and just threw together a macro/stylesheet.”  Doing it as part of core deliverables makes you a developer of sorts, and could even get you with critical-path programming deliverables on a project plan if you’re not careful.  This is hard to balance against the main CS work as you’ll be one coder among others, but probably one of few, if not the only CS person.

In conclusion, understanding mark-up is vital to understanding what can be done with your content if properly tagged and architected. Making programming part of our brand I think confuses the strategic part of content strategy for others.  Many of whom don’t understand the minutiae of what we do and our value-add in the first place.

My possibly jaded – and not-intended to offend anyone who (quite rightly) takes well-deserved pride in their hard-earned techie skills – two cents.

Post Script – Tech disambiguation

For your interest, here is my explanation of the difference between mark-up and programming languages.  We of course treated these in far greater depth in our book.

• Mark-up languages (HTML, XML, DITA, SGML, SVG, RDF….) are descriptive and semantic metadata that are bound intimately to content.  Mark-up languages exist to mark-up content. I think that the CS’er must understand mark-up languages.  Not just HTML, but the fundamentals that underpin HTML which come from it’s SGML/XML roots.  That is structure and semantics.  They need to understand what the implications are of using mark-up to separate content and presentation (to this day it flabbergasts me how low the penetration of that concept is).  You aren’t really ‘coding’ in my definition, even though you’re adding ‘codes’ like

  to your content.

• Programming languages (C#, javascript, java, xslt, SQL…) are for manipulating data – might be content, but not always.   These are real coding languages and you need vastly different tools and, I think, different skills to master them.  Real manipulation, coding, debugging and app development and general magic happens here.

A marked-up file (HTML, DITA, XML) does nothing.  It just sits there in its DB or file system until an app picks it up and process it in some way.

Note: I left out CSS as a pure presentation language.  I think it’s a very useful, nice-to-have but not a core skill.

PPS: Come to Content Agility 2013!