Full transcript of content strategy pitfalls: silos podcast
Sarah O’Keefe: Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way.
In episode 26, we continue our series on content strategy pitfalls. What are the dangers that the intrepid content strategist must avoid as she navigates a complex project. In this episode, we’ll focus on the issue of silos.
SO: Hi everyone, I’m Sarah O’Keefe, I’m here with Alan Pringle.
Alan Pringle: Hey there.
SO: And Bill Swallow.
Bill Swallow: Hello.
SO: And we wanted to talk today about silos and why content silos in particular are a problem when you’re working through a content strategy project. So Alan, I’ll start with you, what is a content silo or a silo in the content world?
AP: A silo in the content world is, for example, when you have one department writing their content in their own system in one place and then you—or one system I should say, it doesn’t necessarily limit it to geography although that can play into it—and then you have another department writing their own content in another complete separate system. So, in some cases they may be writing material that is close to the same or should be the same, yet they’re maintaining that information in two entirely separate systems.
SO: So that sounds silly and why does it happen?
AP: Bill?
BS: Why… Thank you, Alan!
AP: You’re welcome!
BS: There’s a few different reasons why content silos come to be. In some cases, it’s just a typical break in how different departments choose to work and what the different departments responsibilities are. So, they may start out as completely separate and then grow to realize that there might be some need to share information. But they started out as separate entities that really didn’t talk to each other much. Another could be especially in larger companies, so you could have different cost centers. So, everyone has their own budget, everyone has their own spend and in order to work with another department in many large companies, you see this transactional silo happening as well. Where they need to actually purchase time from one other department if they need to work with that department. And then of course you just have the operational break.
SO: So, if you have those cost centers then it discourages people from working together because there are weird cost implications?
BS: It could, and those come about from various reasons. It doesn’t hinder them from working because you really have to spend money to do really anything in a company that large with that big of a scope. But they have to be able to track their time accordingly even on internal stuff, they end up having a bill for something.
SO: So those sound like, I don’t know about valid but at least common sort of structural and business reasons that you run into this. Are there any other common problems that cause silos that are maybe a little less appropriate?
AP: Well, I can think of one and it’s like, “My stuff is special and better than yours, therefore, I must maintaining on my own in my own special precious system.”
SO: My stuff is special.
BS: The fiefdoms.
AP: Right, exactly. Everybody has this … Pride and ownership is one thing, overthinking how special you are is completely something separate, and a lot of that attitude does fuel these silos, unfortunately.
SO: So you get the empire-building and the-
AP: Exactly.
SO: I’m not putting my stuff in your system because that implies that you’re more organized than I am and I’m somehow subordinate to your thing and that’s just not going to happen.
AP: Right.
SO: Okay. I guess the big picture question… So, we understand what silos are and why they happen, and the big picture question—Alan—is, are silos bad?
AP: Yes and no. There is not a pat answer for this. We’re going to be the horrible consultant people. It depends because it does. I can think of very valid cases to have silos. For example, when you have content contributors who may be volunteers, for example, they are not tied into your publishing system, your content management system, whatever it may be. They’re there not because they have publishing expertise, they are there because they have expertise in whatever subject matter you are writing about.
So, if they are going to basically share their brain with you, if you get content in word and you have to maintain this little word infrastructure for them so everything is in Word processing files, Microsoft Word or maybe even Excel, whatever. And then you have to somehow draw it into your system to connect them, there to me is a legitimate reason to have a silo. You have got like a sub-process over here and must maintain some of that content in more standard ubiquitous tools, because that’s what your content contributors know how to use.
SO: You need those sort of professional level tools to actually get the content out the door-
AP: Exactly.
SO: … and do all the things you need to do. Bill, are silos bad?
BS: As a general rule, no, but they can be. And I think we got to look at it from two different points of view. There’s the technological point of view where they could be bad, they might not be bad but it could be based on just historical needs, and each group has moved in a different direction. The only way I think you can really look at silos being a really bad thing is if you do have, again, that fiefdom mentality. Like, this is my domain, I’m going to do things my way and I’m not going to interact with other groups or they can use whatever I give them and it’s up to them to make it work. That type of mentality really is what I think mostly leads toward the negative connotation around silos.
AP: And I think a case in particular where it can be negative is when you have mergers and acquisitions, and then you end up with two, three or more departments who essentially were doing the same thing and, say you’ve got product A and product B are now together in one company yet they have their own arms for marketing, for documentation, for support, whatever else. And they are probably all using separate systems in each one of those groupings. There’s when you do have to start thinking about… This is a case where I think you do have to legitimately say, is this wise to have this split.
Basically, what you’re doing is maintaining two companies even though you’ve got one company now, because you’ve got two tracks of systems for all of these different important arms of your company, and I do think you can run into problems with silos there that are quite negative.
BS: You can. When you do have a situation like that, especially if you’re looking at an equal size acquisition or something that’s comparable. Where you have one company that’s maybe acquiring another one that is roughly about the same size, you run into that situation where you really do have to assess all of that from top to bottom across every group. So even the silos would have silos. From organization A and organization B, the marketing group would have their two silos, the techcomms group would have their silos, the tech support group would have their silos and all different tech and all different, whatnot.
But if a company approaches these acquisitions where they … If they aren’t doing a direct consumption of that other company and saying, “no we’re just going to roll you into what we have.” But if they’re going to sit back and look and say okay let’s take a look at these systems again, I think it’s important to do that across the board and really start seeing where this stuff can start marrying up where it makes sense to.
AP: And it gets super political and sometimes unpleasant.
BS: Oh, yes.
SO: Alan, you had a good example of a case where the sort of tools mismatch requires silos. Essentially, it requires a point where you sort of convert things over from system A to system B because you’ll never get everybody into the same integrated system because they have different requirements. And then the sort of M&A approach… these companies have merged, they now have two different systems that do the same thing and they need to start sharing content. That’s why they merged the company, was to merge the products. So, at that point you really have to look at the question of how are we going to bring this stuff together and make it all work in a single system, because over the long run it doesn’t make a lot of sense for the two legacy product content groups from Company A and Company B to keep separate systems.
I mean, you’ve got to bring them together over time. So, that’s one kind of leave it as is and one bust the silos and make them go away. Now, in the mergers… Actually, not in the merger scenario but we’ve talked kind of about combining let’s say two techcomm or two marketing or two tech support groups, what about the scenario of a marketing content and a product content or technical content silo, what do you do with those? Do you combine them, do you somehow connect them, what does that look like?
BS: I’m going to go back to “it depends.” I mean, it really does. How much reuse and how much need for reuse is there between those two groups and exactly how… What makes sense for your company’s culture and your systems, what makes sense to do? Does it make sense to combine the groups into one and have a single shared repository? Does it make sense to have the two groups continue to work separately but together at the same time towards the same goal and maybe have some kind of a shared infrastructure that allows them to share content across? So, even though they have two different repositories, maybe they have a common way of sharing information across them.
AP: I think this also plays into a blog post you wrote a week or two ago, Sarah. And we’ll be sure to include that in the show notes, it’s on shared pipes. Basically, you can have different ways of creating information but they can… You have basically a middle system that translates it all to make it common and there are ways to do that where you can still… It’s almost like you can kind of sort of maintain those silos but there is middleware, if you will, for lack of a better word, that lets things be shared. So, that definitely plays into that and the technology there is getting better and better as far as creating these middleware systems that help translate everything.
SO: Is there a cost component that we have to worry about with silos or non-silos? I mean, what does cost angle look like when you start thinking about that?
AP: Well, immediately I start thinking about the IT departments screaming and raising holy heck because they’re going to if they have to maintain two and three different systems that do the same thing. And this is particularly true in a case of a merger when you’ve got two systems that do essentially the same thing. That’s when they want to say, we don’t need to be maintaining two systems. So, there’s a cost component involved in the licensing and the support of some tools, content management systems, whatever it may be there, that’s one component you have to look at.
BS: We did touch upon that in the last podcast we did when we talked about tools and IT’s reluctance usually to green-light yet another content management system even though it might be something completely different than what’s in use five, six, seven other times around the organization.
AP: That is their job in their defense, by the way.
BS: It is. I mean, it’s their job to maintain it. Even if it’s a SaaS solution, they still have to be involved. There’s still data transfer that happens there and they still have to monitor the health of this application.
SO: All other things being equal, fewer systems equals less cost, lower cost.
BS: Maybe.
SO: Maybe, yeah. What’s the “but”?
BS: Well, the “but” is the duplication of labor, the duplication of content, the manual… Is the cost of yet another system or is the cost of a different system going to reduce costs elsewhere in managing that content and developing that content.
SO: If we have the option of having four systems, let’s say each of which is purpose-built for a particular thing and does that particular thing perfectly for each of those four groups versus saying, “No, we’re getting rid of three of them, so everybody: one system to rule them all.” And it’s going to be great and it’s great for IT because one system, but three of the four groups have requirements that are not really met very well by that system.
This brings us right back around to where we started, which is that when people say, “I don’t want to be in your system,” what they really mean is… Well, maybe they mean because empire but it’s also likely that what they actually mean is, “well, your system is great for you and yes, if my content wearing your system, it would be very easy for us to share content but you know what, I don’t work that way. That system is great for what you do but it’s not great what for what I do and I don’t really want to have to make my team change how they do stuff.” And that’s legitimate.
AP: What ties into the whole idea of content strategy, you look at your business and strategic requirements, and sometimes you may have very specific requirements for certain kinds of content that will not be addressed by one particular process. Another cost that we haven’t really talked about is if you are going to consolidate systems and people have to move to other systems, you have got change management issues to address, you have got training to address and some other issues. Because you’ve got to tread very carefully here because you’re going to… People are going to be unhappy if they have to go into it usually, usually.
SO: Always.
AP: Yeah. So you’ve got to account for that. There is a human cost, you may lose people in this transition and there is also the actual cost of doing the training. You can’t just throw people out these new systems and say, do it. It doesn’t work like that realistically.
BS: Also, the time and money it takes to move content over from one system to another.
AP: Right. Conversion, things like that.
SO: We claim that our favorite answer is, “it depends,” but it seems that our favorite answer is actually, “what’s the business case?”
AP: Yes.
BS: Really, yeah.
SO: That’s really what we’re saying is, okay, well if we need to combine these things down and put everybody in one system or in fewer systems, IT is going to be happy, it’s less complex from a management administration point of view because you have fewer systems, but there are other costs associated with that such as… I mean, the temporary ones like productivity hits and training and conversion…
BS: We HOPE that productivity hits are going to be temporary.
SO: Yeah. In the bad scenario, the productivity hit is permanent because I’ve just stuck an instructional designer in a content management system that is designed for tech support. I mean, that does happen and it’s not a good thing. So, you’ve got those kinds of issues and… Is it fair to say that most of these systems are really purpose-built for a particular departmental kind of thing like their techcomm versus marketing versus tech support versus training versus sales proposals?
BS: I think there’s some systems that branch, they cover more than one need. But every single system that’s out there, regardless of whether its content management system, a document management system, a component content management system, whatever. They all have particular strengths that they lean toward. I mean, that’s why we have so many of them out there because they do… All these systems really do at least 70 if not a heck of a lot more percent of the work that all the other ones do. They all do the same thing and they all do it fairly well.
It’s when you get down into the nitty gritty of, okay, what does this one shine at, what does this other one shine at. That’s the make or break there. You can’t look at like, “this system, this system, these three systems all do the same 85% of the stuff, so it really doesn’t matter which one we pick.” Well, no. It really comes down to what do you need and which one does that the best. You have to make a sacrifice somewhere else but you always look for that core benefit. What is the greatest core benefit you can get.
AP: I do think a lot of the companies that are focusing on content solutions, you’re seeing much more now THEM referencing silos in their marketing content and the presentations they’re making it industry events. And their products are starting to reflect this mentality where it could consume different types of content. There’s definitely a push there and I think these products are still kind of maybe not completely in a mature phase yet, but things are moving that way and we’ll see if it ends up just being lip service or this is an actual movement that’s going to happen.
BS: Right. Because being able to consume different content types is the … I mean, that’s the inconsequential part. What really it comes down to is what does the workflow look like, does it meet every single groups particular workflow needs. What does the storage and retrieval look like, what does the data access look like, what does the interoperability look like so being able to talk to other systems. It really comes down to what is the core need. So it may be in some cases where we talk about silos and technology silos. If, for example, techcomm and marcom have two very different content management systems, it’s not necessarily to say … “Well, they both do content management, so it really doesn’t matter which one we choose.” It’s being able to look at it and say, “what is the primary driver for being able to share information? Do we need to consolidate down to one or do we stay with two and we build a bridge?”
SO: And I think that may be a good place to leave it. Is that interoperability, it’s not so much are you siloed and do you have multiple systems, it’s can the different pieces of information be moved, transferred, converted, transferred from one system to the other. Because it’s sort of like, it’s not do you have a silo, it’s can you connect that silo or not. I mean, eliminate it is certainly one solution but if you can’t eliminate it for whatever reason, can you get the content from point A to point B without huge amounts of manual labor.
So, I guess in talking about silos and pitfalls, it’s not so much get rid of all the silos, it’s consider getting rid of all the silos but also look at how you can possibly connect the silos and make sure that, that’s going to work. I think I’ll leave it there, that’s a good summary place to leave it.
So, with that, thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, please visit scriptorium.com or check the show notes for relevant links.