I enjoyed the show The Middle. It was about life in “the middle” of the country. I find myself in the middle a lot – not the country, but other places. I am the middle child (and all that encompasses) and for most of my professional life, I have straddled the middle between content and technology.

One side note before we begin. I am a developer. I have been a software developer for 20+ years. It may seem like I’m throwing developers under the bus here or lumping them into one bucket, but I assure you I have the utmost respect for developers. They are often overlooked and misunderstood as much as the content team. So, forgive my blanket statements. In general, I mean the development team and probably really mean the architects.

What does straddling content and technology even mean?

When new applications, websites, and other technical projects kick off (hereafter referred to as “apps” to make things easier), a great deal of planning and resources go into those early stages. However, content management, maintenance and content update processes are often not at the table during those early stages. I have actually heard teams say, “Oh, we don’t care about the content. That’s fill-in-the-blank’s job. We’ll provide a way for them to make edits.” Or, more likely, “Content is messy. We’ll deal with that when we’re done coding.”

I’m here to say that is absolutely the wrong way to approach content on app projects. Even if you, the project manager, product owner, developer, business person, or otherwise think you’ll engage the content team “at some point” in the process, you’re still thinking about it wrong. In my experience, content is not included because opposite sides of the table are making assumptions not in evidence. The development team thinks the business will “handle the content” and the business thinks the developers will update their content – and that they will continue to update the content long after the app has launched, and the team has moved on to another project. Or, worse, the developers DO create a content management process about which the content team was not consulted and expect the business to build a library of “workarounds” to do their job once the app has launched. Don’t fall into this assumption trap.

Content needs to be at the table from the beginning. The representative for content needs to (a) have a strong understanding of the content writing process and (b) have an equally strong, if not stronger, technical understanding of digital content management. Sometimes this can be one person. Often, it’s two – someone who sits solely in the content production world (marketing team, business, etc) and someone who sits in the IT world (web development manager, developer, CMS administrator, etc) and they need to be at the table from the very beginning.

If you design an app without content management in mind – even if you think content is “static,” (a word developers love to use when referring to content that changes weekly if not daily) you are building an app that becomes tech debt day one. Inserting content management after the fact is going to cost you double – if not more – than it would cost you if you had considered content from the beginning – even if you think you are not going to use it day one. Because you will use it – I promise – and having that foundation in place from the beginning is future proofing the app.

How to talk about content on the project

Here is another place not to fall into the assumption trap. Do not assume the business stakeholder on the project represents content. The business stakeholder is probably assuming the development team will be updating and posting their content until the end of time. And the business stakeholder is likely not the person (or team) who actually creates and writes the content. That’s who needs to be at the table. But that might be a big ask and that person probably doesn’t need to be attending daily stand-ups as the project progresses. But that person needs to be represented. And that’s where your technical content person is key. Whether it’s the web development manager or enterprise content management SME – it’s the person who understands the technical needs and can engage the content creators about their specific content needs. That person should be on your daily stand-ups representing content along with the business stakeholder.

The content creator in the business will work with the web development manager or SME to describe how they use the content, plan to use the content and expect to manage the content once the app goes live. As I said earlier, if you build an app with no plan to provide the ability to make content updates on the fly, you have launched an app that is tech debt day one.

Development teams will often rely on a developer who “kinda” knows content management and they end up defining the technical parameters of the project. Don’t fall into this trap either. That’s not to say that developer doesn’t have the skillset to do that, but that developer must talk with the content creators before making any assumptions. Maybe you don’t have a web development manager or a content management SME but you have a developer who knows content. Let that developer engage with the content creation team to fully understand their needs because content creation needs change often and as a result so do their requirements. Working on a content management process 2, 3, 5 years ago doesn’t mean you know how they use content today. Make sure you talk about not only how things are done today, but how they plan to do things in the future. Because they too are probably assuming that they’re getting a new app thus that new app will be designed for future content needs. Is it? Probably not.

What does content representation look like in an Agile environment?

Well. That’s an interesting question and one I will address in my next blog post. In that blog post, I will cover the following topics:

  • Agile methodology applied to the content update process
  • Structure of a story in your content management epic
  • Helping your content partners understand the Agile process

I’m restarting this blog and will do my best to have this posted by next week.


I am a technologist, strategist, software engineer and data nerd who, in my spare time, is also an amateur photographer, animal lover, and low-carb/Keto advocate.

Write A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.