Content ops stakeholders: Executives (podcast, part 2)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 110 of The Content Strategy Experts podcast, Alan Pringle and Sarah O’Keefe continue their discussion about executives as important stakeholders in your content operations.
“You need to understand how decisions in your organization are made and where the real power is.”
– Sarah O’Keefe
Related posts:
Twitter handles:
Transcript:
Alan Pringle: 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. This is part two of a two-part podcast.
AP: I’m Alan Pringle. In this episode, Sarah O’Keefe and I continue our discussion about executives as important stakeholders in your content operations. In the previous episode we talked about the importance of business needs. In this episode, we talk about how to effectively communicate with executives. Now, we’ve talked about these business needs, business requirements and how they really affect- basically, I don’t want to put thoughts in the heads of executives but what we talked about is kind of how they think in general, basically from my experience.
AP: I think it’s also worth discussing how to communicate with them. For example, let’s go back to tools for a minute. We’ve already said, don’t talk about all the bells and whistles and the features of the tools, they don’t care about that. I do think one thing they would care about is that you were following the correct company process to select your tools. You are working with your procurement department, you were working with your IT group, you were working with information security folks. Those are also other stakeholders in any kind of project, and a content ops project is no exception. So you need to be sure that you are following the protocols that your company has established for assessing tools, and that you communicate that you are doing that with the executive champion of your project.
Sarah O’Keefe: Yeah. And that’s an interesting one because as an executive, what they are truly paid to do is to assess risk. What is the risk of taking this action? What is the risk of not taking this action? Should I spend this money? What are the implications if I don’t? And what you’re talking about in terms of the tools assessment, and I will say quite frankly, when I hear from a client, we have to go to the enterprise architecture board, that never makes me happy. Because their job, and this is legit, is to minimize the number of tools in the company.
AP: Exactly.
SO: Right? Because the more you have, the more systems you have, the more complicated everything gets and the more expensive it gets. And so the EAB is responsible for saying, “Well, we have these 17 tools already. Why are you telling us you need a specialized tool?”
SO: You need a super special CMS, but we already have three of them. Why can’t you use SharePoint? And then we cry. By the way, crying doesn’t work. Don’t cry. No, never cry. But the executive’s job is to test your argument that no, we are super special and we need a super special set of tools and here’s why. And then they have to make the decision that that argument that you’re making will get better content ops, which will give you all these cool business things, is worth the risk and the cost of introducing another tool or another set of tools or whatever it is that you’re asking for. So it’s not personal. They don’t hate you. They don’t hate your favorite tool, but they don’t like bringing in more complexity and nearly always, that’s what we’re arguing for. We need more stuff. We need another stack because we can’t do this in the generic business tools that you have right now.
AP: Yeah. And those conversations usually are not a one and done sort of thing. It usually takes a lot of time and I hate to use the word education, but I do think there is some of that going on when you’re having these discussions, because you have to explain, like you said, why this particular tool, which may seem like a match to something that already exists, why it is critical for your content ops to have this particular tool.
SO: I have found over the years, that it can be helpful to make the analogy to software developers or product developers if it’s hardware, especially with an engineering, whether software or hardware, manufacturing kind of executive. Essentially your software developers have a bunch of specialized tools to manage code. We are asking for the equivalent for content, right? So it’s not that we’re special and esoteric or anything like that. It’s just that there’s a certain set of tools that help us and that make us more efficient and in which we can do better work just as you have in your software development or in manufacturing, you have CAD systems and you have product lifecycle management, PLM systems, those kinds of things. So I think it’s helpful to just align this with other professional level things that are needed in order to do these jobs well. And of course we swore we wouldn’t talk about tools and here we are. As always.
AP: Yeah, well, let’s shift focus a little bit because politics are always part of a project. That is pretty much the rule of corporate life. At least that’s what I’ve seen in my now, whatever 25 years now, shudder, at Scriptorium. Politics are inevitable. And I think that is especially true when you have executives involved and you have to be very sensitive to them. Let’s wrap up this discussion talking about the importance of politics and why you need to pay attention to those optics.
SO: So two things. We talk about requirements and constraints, right? A requirement is like the system has to do X and a constraint is something like, and also it has to connect to this system, or it must not do this, or it has to run on Linux or something. But a constraint, sometimes there are personal preferences and I really wish I was making this up. We had a project where we went in. They were like, “Oh, and don’t use purple.” Okay. Well sure. But why? “Well, senior exec so and so really hates purple. If you show them anything with purple in it, they will reject the project.” Okay. Well guess what? That’s a constraint.
AP: Yeah.
SO: Absolutely ridiculous, but a constraint. So pay attention to your personal preferences slash constraints of the people that are approving stuff. If they hate PowerPoint and only want a video presentation, or they only want PowerPoint and they don’t want to hear from you, or they only want a white paper making the argument. Okay. Well deliver that, right? So that’s not really politics. That’s more like, how do you pitch to your decision maker? On the political side, there’s so many aspects to this, but basically you need to understand in your organization how decisions are made and where the real power is. So for example, if you have a CEO who’s your nominal decision maker, but on technical questions, they always defer to the CTO. They’re going to let the CTO decide. Then the CTO is your actual decision maker. And that’s who you need to pitch to. That’s who you need to tailor your solution to, to make sure that you’re giving them the information that they need in order to make the decision in the format that they want, et cetera.
SO: So that’s one issue, who’s the actual decision maker and that may be different from who’s on the org chart or you’ve been told, “Oh, so and so is making the decision.” And then you find out that your director of XYZ has a senior technical something who they lean on. And if you can’t convince that person, you’re done.
AP: Yeah. You’re sunk.
SO: Yeah. But they were sitting in the back of the room not talking and you didn’t notice them. And you used blue, which they hate and you didn’t know about because you didn’t pay any attention to them. So that part of it’s really important. And I’m using trivial, ridiculous examples but I will tell you, I have seen these at least once.
AP: Oh yeah. Absolutely.
SO: Usually it’s something more serious than color preferences, but maybe you built a pitch and the person you’re pitching to is color blind and you didn’t think about it. And now you’ve got an ineffective presentation because, well first of all, never do that, but you weren’t paying attention.
AP: You really have to be sure you’re attuned to what is going on. And that really takes some, frankly, detective work and really good observational skills on your part.
SO: Yeah. And it’s one of the hardest challenges that we have as consultants, right? Because we don’t have all that history with the organization. So we tend to lean on the people inside the organization that we’re working with and say, “Well, what do you know about this person?”
AP: Exactly.
SO: And ask those questions. Politically, very often these projects cross organizational boundaries. So for example, if we’re trying to integrate marketing, learning, learning, training, and technical content, then we almost certainly are dealing with two or three C-level executives, right? The marketing executive, the chief marketing officer, maybe there’s a chief learning officer, or maybe that falls under the CIO, or maybe that’s under the chief people person or HR and technical content usually but not always, under some sort of engineering function. Well who makes the decision, right? Those three executives get in a room to talk about this project.
SO: Are they going to do it? Are they going to push back because they don’t like each other? Who pays for it? Who owns the project? Who gets the glory? If those three execs work together well and are a team at the C-level, then things will be great. But what’s far more common is that they all have their own area of responsibility. I’m not saying fiefdom.
AP: I was thinking it though.
SO: Yeah, sorry. So they each have their little fiefdoms, which they rule with an iron fist and a project where you are trying to introduce some sort of enterprise strategy, right? Across those three organizations or more, I mean easily more, but we’ll start with those three. It threatens them because they are giving up control. Oh, we want to introduce an enterprise level taxonomy, an enterprise level terminology. Well, are you telling me that somebody else is going to tell my people how to write? Well, actually, yes because you see, we need all three of those organizations to use the same terminology and the same metadata so that when this content goes to your website or out for delivery, the people consuming it can use it in a consistent way, right? They don’t care about your empire.
AP: So here we are thinking that content silos are the major problem. I think it’s more the fortified castles of each one of these groups. That’s the bigger problem.
SO: Okay. I swear I’m not going to reference Genghis Khan.
AP: We might want to wrap up now. I think we’ve worn this analogy out. Yes.
SO: Yeah. But it is a point, I mean in all seriousness as a chief marketing officer, my job is marketing, right? And all the responsibilities that go with that. So improving engagement among customers and potential customers, outreach, getting new leads, new customers, new this, new that, right? If I’m techcomm, my job is to enable use of the product. So at up at the C-level, we do in fact have different sets of priorities and trying to bring those people into a project that must cross over is really, really difficult because they reasonably are prioritizing what their people need, not always what the overall organization needs. And now I’m going to pick on the CEO, because it’s the job of the CEO to say to these C-level people, “I want you to make this work, work together, make it happen, prioritize the cross department or cross-functional content ops, content strategy and not your individual responsibilities and priorities.”`
AP: That’s a really good point. And I think we can end on that somewhat hopeful note. So thank you very much, Sarah.
SO: Thank you.
AP: 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
