Content ops stakeholders: Tech stack managers (podcast)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 114 of The Content Strategy Experts podcast, Bill Swallow and Gretyl Kinsey talk about developers and managers of the technical stack as content ops stakeholders.
“Without a gatekeeper, things can go awry very quickly. Other groups can take ownership of a particular piece of the tech stack and then you start to have some issues.”
– Bill Swallow
Related posts:
- Content ops stakeholders: Executives (podcast, part 2)
- Content ops stakeholders: Executives (podcast, part 1)
- Content ops stakeholders: IT (podcast)
Twitter handles:
Transcript:
Gretyl Kinsey: 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 this episode, we continue our series on content ops stakeholders. This time focusing on those who develop and manage the technical stack. Hello and welcome everyone. I’m Gretyl Kinsey.
Bill Swallow: I’m Bill Swallow.
GK: And this is part of our occasional series on stakeholders and content operations projects. So on some of our previous podcast episodes, we’ve discussed a couple of different stakeholders, including IT and executives. And you can find those episodes on scriptorium.com or wherever you get your podcast. This time we’re focusing on the technical stack and the people who develop and manage that. And we want to start out by just talking a little bit about how that’s different from IT, which we’ve covered before.
BS: So IT is in charge of making sure all the systems involved in the content lifecycle work together and with the rest of the company’s technology. Here, we’re talking about the tech stack developers and managers who are more deeper into the weeds of creating the custom plugins, templates and what have you of that publishing system.
GK: So when we talk about the technical stack, some of the things that may be included in that are things like system configuration. So if you have got authoring tools, if you’ve got a content management system of some sort, if you have publishing engines, maybe you’ve got some other connected systems like translation or learning management software, then people managing the technical stack will be responsible for configuration on all of those kinds of things. And as Bill mentioned, there’s also going to be things like style sheet and template creation. And of course, there’s also going to be ongoing support and maintenance.
BS: And your technical stack developers or managers might include any of the following, either an in-house person or a team that you have available to you to develop against the technical stack and to add additional things. It could include outside contractors or consultants who are brought in to do the technical work and then head off and come back again when they’re needed. It could be developers who work for some of your systems vendors who come in and develop against their own system for you, or could be some combination of all of the above.
GK: Yeah. And we’ve discovered in a lot of our projects with clients that, who manages that technical stack often comes down to the industry that you’re in or the type of products you make. It could also be related to things like your company size, your location, or just your general corporate culture. So for example, if you’re the type of company who produces software, you work in high tech, then you might be more likely to have some of those in-house resources for things like developing your custom publishing templates and other parts of your technical stack. Whereas, if you are in a completely different industry, you may be someone who brings that in from the outside, and in some cases we have been a part of that technical stack as the outside contractors or consultants.
BS: Right. And company size does often come into play here as well. If you have a content team of 50, 100 or more people, chances are you probably have the bandwidth and the knowledge in house to be able to take that responsibility on internally.
GK: Yeah, absolutely. So when you are developing a content strategy, what are some of the most important considerations from the perspective of those who work on the technical stack?
BS: So one key consideration to keep in mind regarding the tech stack is to have both the short-term and long-term plans. Even with the long-term plan in place, it’s important to have the short-term ones in there as well. And this includes everything from setting your goals for the tech stack itself, all the way up through the costs and the time it takes to implement. One of the short-term plans that you might have in place is being able to develop a proof of concept within a particular system. So that would be not only selecting the software and the systems involved, but being able to put together your information architecture, your content model, all the way down to how you’re going to produce your outputs. So what are driving the transformations involved to get your raw content out into a published format?
GK: One other thing to mention on the long-term plans in particular is that a big part of that is going to be content governance. And it’s really important to think about where your tech stack fits into that. Because like we mentioned, one of the things that the people involved in the technical stack do is ongoing support and maintenance. So if you think about governing your content lifecycle, it’s not just the content development, but also, how you’re going to govern the maintenance and the changes made to all the different parts of your technical stack over time.
BS: And speaking of maintenance, it’s another key consideration here is that the more you customize your systems in the tech stack, it does mean more maintenance of all of those customizations. So you have to kind of balance the benefits of doing those levels of customization with the costs associated not only with implementing them, but with maintaining them over time.
GK: Yeah. And I think that’s where it’s really important to think about what resources do you actually have available. So we talked about how maybe a larger company or a company that is more tech focused in its industry might be more likely to have some of those in-house technical stack people. And that if you’ve got that available, then maybe you can afford some more of that maintenance cost over time, because you’re going to have more of that continuity if you can do it in house and more of the resources available. Whereas if you don’t have that at your disposal and you are going to be relying more on contractors, then it may not be worth the cost associated with having that higher level of customization.
BS: And regarding those resources, you have to keep scalability in mind. As Gretyl mentioned, do you have the people available to you to do all the work? Do you need to have them stop on a particular project in order to work on the tech stack because something might have broken or something needs attention? Or are they a full-time position within your company and they are eager and ready to jump right in and get their hands dirty? Likewise, there’s a scalability of cost involved. So if you are working with outside resources, you have to keep that in mind that every time you need someone to come in and fix something, you need to be able to budget for that need.
GK: Yeah. And one thing I like to think about with scalability as well, which circles back to that first point we made about your short and long-term plans is that a lot of times when people are coming up with a content strategy, the scalability angle they’re thinking about is how will this grow over time with the growth of the company? So that’s one thing to think about is how does your technical stack grow and change with that? Can it grow? Can it scale? And do you have those resources available? And if you don’t right now, how can you plan for the future to make sure that you do?
BS: And with that in mind, I guess it’s good to ask, what type of collaboration is important between those who are managing or developing the technical stack with other stakeholders?
GK: Yeah. So if you are a content creator, it’s really important to talk to those involved with the technical stack about your delivery channels. So which ones do you need right now? This kind of gets to that short-term planning. Which ones do you need to add later? And that gets into your long-term. And again, how much do they need to be customized? What kinds of delivery are you looking at? What kinds of output formats? How do those need to be styled and formatted? And what is it going to take to get all of that up and running and keep it going in the future?
BS: Right. Because there is a significant difference in the level of effort of being able to include someone within a particular publishing run, let’s say you’re producing content for a new group within the company, it’s very easy to produce their content once it’s in the correct source format into the target delivery formats that you have available. But if they need a brand new system, even if it’s just another portion of the website where you’re potentially publishing content into a slightly different format. So if you’re doing a knowledge base for your content currently, and they want to do something that’s a little more marketing driven or is highly customized for a specific audience, it’s a completely different consideration that you need to keep in mind.
GK: Absolutely. And I also want to point out that when it comes to content creators and technical stack folks collaborating on maybe a new content strategy or a new direction for your content, that often involves a shift in the way that both teams have been working. So it’s really important to keep those discussions going constantly, keep them productive and make sure that you don’t have this separation or siloing off of those two groups, because it’s really, really important that they work together.
BS: Right. And not just work together within a one particular environment, but if they have a separate environment that also can work within your tech stack, you want to be able to keep that in mind as well. So if they are really accustomed to working in a specific tool set, if it somehow splices into the tech stack beautifully, then great. If it doesn’t, then you have a bunch of other considerations to deal with, everything from being able to secure funding for new tools, to secure training and potentially a lot of conversion of their existing content in order to get into that shared environment.
GK: And along those lines, I think if not only you’re a content creator, but also you’re someone in IT, it’s important for those two groups and the technical stack people to have a lot of discussions about the systems that are there to support the content lifecycle. And in particular, if you are choosing any new technologies to be part of that content lifecycle, it’s really, really critical for content creators, for IT people and for your technical stack people to be heavily involved in that decision making process in choosing whatever technology is going to be the best fit for the company, because each group is going to bring in different, but equally important considerations about how that technology needs to work.
BS: And I would say on the management side and the executive side, you want to make sure that you have these conversations with those who are managing the tech stack about the real cost of support. So what types of development efforts take the most time or require the most expertise to complete? Whether outside expertise is also needed in addition to internal expertise. And whether or not you do have additional costs beyond that. So additional tools that may be required to implement a particular thing into the tech stack.
GK: Absolutely. So what are some other things that it’s important to keep in mind regarding the technical stack and the people who work for it?
BS: So I think first and foremost, if your technical stack developers and managers are not in-house resources, then there needs to be a transition plan and some training for any in-house people who would be taking that role on afterwards, whether it’s doing the deep development or just managing the systems and being able to keep an eye on things.
GK: Yeah, absolutely. I think a lot of the projects that Scriptorium has worked on, one of the goals where we try to get companies is if they don’t have those in-house resources at the start, that they train them up over time so that they do have them and can take on their entire content lifecycle eventually. And that does take months or even years to do, especially depending on how much expertise you do or don’t already have.
GK: But that is something to really keep in mind when you first start planning your new content strategy and you get into those earliest phases of getting everything stood up and in place, don’t leave out the training because that is really, really important. And sometimes the training, as Bill said, can often be kind of more of a transition or an ongoing thing. So I know that with some of the projects we’ve worked on, there will be an initial training when you get a tool stood up and then there will be some ongoing sessions, maybe once a week or once a month for the next six months to a year after that, just to make sure that everyone involved knows how to use it and you’re not just kind of turning people loose with this new tool.
BS: Right. And also, in that same line, making sure that there’s plenty of clear documentation about things that authors should and should not be doing with their content or doing with the tech stack specifically. It usually goes back to documentation about the content model and so forth. But there need to be some expectations set that even if the content model allows for a new approach to authoring something, it may not be supported downstream or deeper in the tech stack. And it may have unintended results in the final output.
BS: So being able to identify exactly what people should and should not be doing with regard to the technology and the way it’s set up, because even if you have a tool in your tech stack that can do something very specific, it may not be set up to do that out of the box. And you want to make sure that no one is injecting anything that’s going to break things down the line.
GK: Yeah. And we always say, “Just because you can do something doesn’t mean you should.” So it’s really important, again, to just have that collaboration that we talked about between the content creators and the people who are in charge of managing the technical stack. Making sure that there aren’t these kind of miscommunications and that you don’t have some content creator just saying, “Why don’t we try this because we actually have the technology to support it?” Maybe you do, but maybe it would involve a whole lot more cost than you realize, or maybe it would involve a whole lot more time to get that stood up.
GK: So again, that’s why it’s just really, really important to have those ongoing discussions, to have that documentation and to have a plan so that if you do ever need to change what you’re doing, you do maybe need to add some new thing that you can do in your content or some new delivery channel or output type that you don’t just start adding that ad hoc, but you actually have a plan for that to go through to make sure that it can be supported.
BS: Mm-hmm (affirmative) And likewise, with doing any updates to the technology that’s in your tech stack itself, it may be that a new version of one particular tool or one particular technology comes out. You want to upgrade to the latest and greatest. You need to step back and take a look at the entire ecosystem that you’ve put together and make sure that that one change doesn’t trickle down into multiple problems elsewhere in the tech stack. You need to understand how all of the pieces fit together and where those dependencies are because one small change can equal a lot of change across the entire stack.
GK: Definitely. And I think one really important thing to keep in mind when it comes to managing all those dependencies and when it comes to the idea of content governance and content lifecycle governance that we talked about before is that it’s important to have a single point of contact who is in charge or responsible for all of this. So even if you don’t have that in house, it’s really still important to at least designate someone who can own that process, who can understand how all of the different pieces and parts of your technical stack fit together and who can be the gatekeeper, who can be the person in charge of that level of governance. So they can collect change requests. They can communicate that to all of the stakeholders internally. They can collaborate externally with any of your technical resources that you have contracted out. And they can just be the person who keeps everything running smoothly.
BS: Right. Regardless of whether you’re in-house or external, you do need that in-house person who can keep tabs on things. Because without that gatekeeper, things can go awry very quickly and other groups, other people can, with all good intentions, take ownership of a particular piece of the tech stack and then you start to have some issues, perhaps with some changes that are being made on one side that aren’t being reflected on another side of the tech stack.
GK: Yeah. And we have absolutely seen that happen with some of the companies we’ve worked with where that’s even maybe the reason they brought us in in the first place is because they’ve got this kind of disconnected technical stack and they don’t have that one single point of contact managing everything. So it really, really is critical that you don’t end up in a situation where you’re adding pieces and parts to your technical stack and then resulting in things not working together, not meshing well and not serving your content lifecycle overall. And with that, I think we can go ahead and wrap up this discussion. So thank you so much, Bill.
BS: Thank you.
GK: And thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.
About the author
