Search
Follow me:
Listen on:

Day Two Cloud 087: Inside The World Of A Technical Marketer

Engineers are skeptical about vendor marketing–for justifiable reasons. Marketing language is typically filled with uninformative buzzwords, hype, and exaggerated claims.

Instead of telling you what a product does or how a product works, vendor marketing insists that its hardware is powered by rainbows, the software is written by magic unicorns, and all your IT problems will be solved if you buy it.

But it doesn’t have to be that way. On today’s show we talk with a technical marketer who wants to actually help engineers. His goal, and that of others like him, is to create practitioner-focused collateral that provides concrete information and can help engineers make decisions.

Our guest is Martez Reed, Director of Technical Marketing at Morpheus Data. He makes the case for Technical Marketing Engineers (TMEs) as being on your side.

We discuss:

  • How the audience for technical marketing is different from Web site copy and press releases
  • Creating content for engineers and practitioners
  • Maintaining technical chops as a TME
  • The role of storytelling and aligning messages
  • The content creation process
  • More

Takeaways:

  1. There are openings for TMEs out there–folks who are engineers fit here.
  2. Communication skills are crucial. How do you relay information? Craft emails? Craft presentations for public consumption that aren’t too detailed/tedious? Can you both inform and persuade at the same time?

Show Links:

@GreenReedTech – Martez Reed on Twitter

GreenReedTech.com – Martez’s blog

Martez Reed on LinkedIn

martezr – Martez Reed on GitHub

Transcript:

 

[00:00:11.350] – Ned
Welcome to Day Two Cloud, today’s conversation is all about what does it mean to be a technical marketing person? And we have Martez Reed for Morpheus data, who is the director of technical marketing there, to kind of school us on what that term even means and the process he goes through to create content. What stood out to you, Ethan?

[00:00:32.150] – Ethan
There is so much skepticism out there in the engineering community about marketing, but TME’s are your friend. So when you were evaluating a new product, it’s the TME.

[00:00:41.620] That’s the one if you can find that person to talk to that person is the one who. Yeah, they’ve got a job to do. They’re trying to inform you about a product. And Martez goes into great detail about how he thinks about writing and delivering what he calls collateral out there for engineers to read. But they are also on your side Ned. This is the thing that stuck out to me the most because Martez came from the engineering field and understands the problem that engineers face and is trying to communicate in a way that helps engineers make decisions.

[00:01:16.600] So they’re really yeah, it’s marketing and we’re skeptical. I get that. But still, the TMEs are on our side. That’s what I walked away with.

[00:01:22.790] – Ned
So whether you’re trying to figure out what’s the best way to evaluate a product or you’re thinking about a potential career move yourself. I think you’re really going to enjoy this episode with Martez Reed, the director of technical marketing for Morpheus Data.

[00:01:36.960] Martez Reed, welcome to Day Two Cloud and let’s start out in the intro I mentioned you’re the director of technical marketing at Morpheus and I’m going to go out on a limb and say most folks listening aren’t going to know what that means.

[00:01:50.700] So let’s start there. What is technical marketing?

[00:01:53.940] – Martez
Yeah. So technical marketing for me, the way I think of it is sort of the technical piece of marketing. Put the two together.

[00:02:00.540] You get technical marketing from the standpoint of a software vendor, so Morpheus data is a software vendor. And so you’ve got there’s sort of the traditional marketing of like what is your product, how people use it, how they get value. And then from the practitioner perspective, you go into sort of deeper in the weeds of. Yes, you told me what it is like. How does that work? How does that actually relate to me from a technical standpoint? So that’s what my job is focused on, is how do I take that?

[00:02:27.720] What is Morpheus data and then really translate it to. Yeah, I heard what you are you fit into this category or that category, but what do you actually do from a technical standpoint and how can actually make use of that in my organization.

[00:02:40.620] – Ned
Right. Right. So you’re not writing the ad copy on the website. You’re…

[00:02:46.020] – Martez
Naw.

[00:02:46.020] – Ned
OK.

[00:02:46.710] – Martez
I mean, I’m not I’m not delving into the buzz words and all those things. I’m more so OK as a practitioner. What’s the value of this to you? And so for me, it’s a different audience. Typically, the way I think of the delineation is marketing is been more focused on the CEO, CIO, some of the I.T. director. And then for me, technical marketing is more focused on the the enterprise architect, the practitioner, the engineers, those that are deeper in the weeds for them to understand how the integration actually plays and be able to tie the two together, to be able to tell that full story.

[00:03:21.900] Because as a practitioner, oftentimes you you go to a company’s website, you see the marketing fluff. And it’s like I hear and see all these buzzwords like what does that even mean? And feel like I need somebody to translate that for me. So hopefully I’m that translator.

[00:03:36.780] – Ethan
When you hear the word marketing as an engineer, instantly we all get skeptical and like ehh marketing boo. Because a lot of marketing language is really fluffy and doesn’t mean anything.

[00:03:49.260] But as a technical marketing person, you’re talking to engineers for purposes of really helping them understand what it is that they’re evaluating.

[00:03:58.300] – Martez
Yeah, and so that’s that’s the way I take it. My job is technical education in a sense, to be able to provide the content for the technical practitioner to understand how our product actually works. Oftentimes you might go to a vendor and in no uncertain terms, they’re trying to sell you a pipe dream of what their product says it’s supposed to do. And oftentimes you have to dig and dig and dig to figure out like, OK, does it actually do what they’re trying to sell me?

[00:04:26.010] And hopefully for me, that goal is I’m going to give you what we do. What we don’t do is not included in there. I’m not going to try to sell you something that we don’t do. I’m going to convey the value of the things that we do.

[00:04:40.240] – Ned
OK, OK. And I know you come from very technical background. We were talking about this, but before the show kicked off, you started working in consulting and I’m sure you started doing something even before that. But when I met you, you were already in the world of consulting and then you moved to Puppet, was that correct?

[00:04:56.610] – Martez
Yep. Moved the puppet where I was actually a Puppet doing technical education.

[00:05:00.390] – Ned
OK

[00:05:00.700] – Martez
So it’s it’s it’s right in my wheelhouse. I’m an individual that loves to share the knowledge that I have, as well as to help individuals learn technology in the sort of the broader IT ecosystem.

[00:05:11.910] – Ned
I think one of my concerns would be moving from a technical practitioner focused role like consulting to something like technical marketing. Suddenly I’m moving away from the keyboard. I’m going to start losing my my technical chops. Are you concerned about that? Do you think that would be the case or is this the sort of situation where you’re still very immersed?

[00:05:31.860] – Martez
So I’m not overly concerned about that. Even as I got sort of later in my career of consulting, it was obviously still very hands on.

[00:05:41.370] But a lot of it was also sort of the architect discussions with customers. You’re setting your whiteboarding, you doing all those things that aren’t you actually physically touching the keys? And in some situations, it is often that more than actually hands on keyboard is how can I best enable the customer to roll out this solution, enable them from a capability standpoint, and that always hands on keyboard. The other thing for me becomes I’m always going to have to be hands on keyboard in some way, especially in technical marketing.

[00:06:09.090] It’s really, in my opinion, relate to the practitioner of it’s hard for me to to showcase you a solution or a capability that I’ve never gotten my hands on and touched, because to me at that point, it feels inauthentic to say, hey, this is what this solution does. This is what the capability is, and I’ve never touched it. In the moment you get past that that surface conversation, it’s like, well, how does this work?

[00:06:33.990] How these two things integrate? And it’s like, well. I don’t really know it’s in the docs type of type of answer, and I never want to give that answer. I always want to feel confident in terms of what the capability is of a solution.

[00:06:48.370] – Ned
Right. Right. Now, one comparison that I’ve heard before of technical marketing is comparing it to something like developer advocates or what used to be called technical evangelist, though I think no one’s using that term anymore. At least it’s been deprecated. How would you compare and contrast technical marketing to someone who’s in a developer advocate role?

[00:07:10.830] – Martez
Yes, I mean, in a lot of ways they’re similar. Depending on the organization. They’re they’re slightly different. Oftn times a developer advocate is more community focused of I’m kind of in the trenches with the community itself of those that are actually using the product. Oftentimes it’s more so related to like open source companies that have an enterprise sort of paid product. And the developer advocate is touching those that are handling or working with the open source version.

[00:07:39.810] – Ned
OK

[00:07:40.260] – Martez
Whereas often on the technical marketing side, it’s we have to educate our customers on the thing that pays the bills. And so we have to have resources there. So, oftentimes that delineation between the two.

[00:07:52.860] – Ned
I think I have a pretty good understanding of what someone in a technical marketing role is going to do. They’re going to create content and tutorials and guides and all that kind of stuff for practitioners to consume when they have questions, when they’re curious about how something works or they want to know more. Now, I’m curious because I create content a lot. I wanted to sort of get into what your process is when you’re going to embark on creating a new piece of content. So let’s start with that. What is your overall process and then maybe we can get into some details?

[00:08:27.420] – Martez
Yeah, absolutely. So my overall process becomes, since I’m director of technical marketing, I align and work for the CMO chief marketing officer. And so for me, there’s always got to be that that collaboration of whether it’s certain topics or certain sort of themes we’re looking to drive in the next month, the next quarter, the next half year, or whatever it might be to make sure that there’s alignment there.

[00:08:53.550] The other thing becomes for me is along those same lines, what’s the story? What story are we trying to tell? And when we talk about alignment, there’s also the aspect of, since I’m not focused on sort of the higher level conversation with the CIOs, the CEOs. It’s what story are we telling there and how can I tie that story all the way down to the practitioner level? So where somebody comes and engages with Morpheus data and says, hey, you’re telling this really great story now, how can I find out more?

[00:09:24.180] And basically it’s you pulling on that thread to say, oh, hey, you know, we’re offering this capability. Oh, great. That sounds really interesting. I want to know more. Where can I find out more? Here’s some architect level content that talks about how you can integrate it with your existing system and capabilities. Perfect. We want to do a POC now. How can we actually sort of dig into the weeds to figure out how to use this for ourselves?

[00:09:48.900] Even better, we’ve got content that talks about a tutorial or a guide that walks through that that augments the documentation of where the knobs and the bells and whistles that I can turn to to actually walk through sort of that end-to-end flow of from initial engagement or existing customers engagement there all the way down to the actual implementation of the process and the solution. That’s the way I start my process and I think about it, which makes it a little bit different.

[00:10:17.220] Than I’m creating a tutorial on this or tutorial on that, where in some ways it’s a bit of a standalone piece of content that I’m not oftentimes considering all of the the other aspects of how it would tie into a broader story and collaboration with other individuals.

[00:10:34.010] – Ned
Gotcha. So it’s the difference between writing a chapter in a book that needs to be part of a larger, cohesive whole versus writing a short story that doesn’t really have to be attached to anything.

[00:10:42.960] – Martez
Yeah, absolutely. And it’s trying to figure out that that really good synergy to be able to convey that information, as I said, pull on that thread and feel like it goes all the way through as opposed to you get the CEO buzz worthy conversation. And as an architect or an engineer, like it’s sort of falls apart because you can’t find good collateral about what they said.

[00:11:05.400] – Ethan
Would you say you’re trying to break down barriers?

[00:11:08.910] – Martez
I would say possibly in some way. I think it might be a little bit different, kind of the approach that I have, especially kind of in some ways, from what I’ve seen in a lot of situations, from a technical marketing aspect that companies have is mine is very much I gotta align with the story and tell the story all the way through, to avoid it feeling like you gave me a bunch of buzz words and like now I have no clue and now I’ve got to try to dig into it myself and figure out what it really is.

[00:11:39.700] – Ethan
The story aspect is interesting because in my job, I deal with a lot of marketing folks and that is a consistent theme. There’s a beginning, a middle and an end to the story, whatever the story is. And there’s different stories, depending on who you’re communicating with. But being able to get through that story in its entirety seems like a really big deal.

[00:11:59.030] – Martez
Yeah, I mean, it definitely is, because the challenge becomes in this story for me, you’re touching different audiences. It’s not as though you have the story. And like this is the the one persona that’s going to read the story, which oftentimes it becomes much easier if it’s the story is for the CEO, they’re the only ones that’s going to read it. And they understand the nomenclature, the language, all those things. And then we’re done.

[00:12:25.970] – Ned
Right.

[00:12:26.290] – Martez
Well, the challenge becomes, how do I target this audience in this audience and then this audience and this audience, but make it feel like it’s a single theme and and consistency across the story that actually relates to each of those different personas.

[00:12:42.450] – Ned
Right. Right. So you would start with a high level. Here’s the high level problem.

[00:12:46.850] – Martez
This is what it does for your business. Right?

[00:12:49.230] – Ned
Right. And then you work down through the strata of, OK, this is the story at the CEO level, what they want to hear. And then here’s the story at maybe the CIO level, what do they want to hear? What are they worried about? And then the director of infrastructure and then the senior architect or enterprise and then the engineer who’s actually going to be working with thing. Your goal is to have one cohesive story and little dots along the way for each of those people.

[00:13:14.700] – Martez
Yeah, absolutely. Obviously, for those that have been through those various different roles, there’s a different mindset. There’s oftentimes a different focus from a technical standpoint and sometimes a different technical competency along the lines to to understand what’s being conveyed. And so obviously, we’re not giving the CEOs the same information that the engineer is because the CEO probably isn’t going to be deploying or configuring. But who knows?

[00:13:39.050] – Ned
Maybe small enough company, maybe.

[00:13:42.540] – Ethan
So is it is it the same story really then Martez or is it actually kind of different stories to fit the audience?

[00:13:50.180] – Martez
For me, it’s the same story. It’s just different nuances and different details. So it’s one of those things I can I can tell you about this particular product. But what do you want to know? Is how the story starts to evolve, almost kind of the example of perspective of if you’re taking the same object and turning it slightly and then turning it again and turning it again, it’s the same object. It’s just about what your vantage point is in terms of where you want to look and what you want to glean from the particular object.

[00:14:20.820] – Ned
Right. And you even could zoom in on an object and see what it’s made out of its component parts. So, yeah, and in that way, essentially, you’re not going to show the CEO the command line and you’re not going to show the engineer the marketing one pager because they don’t care about that. So I’m curious, we have this idea of a story and I don’t know if you have an example you can use, but how do you get that initial story?

[00:14:44.390] Is that driven by what’s happening at the company, in the marketing team, or is that driven by what the community’s asking for? Like, how does that story get developed before you even create the content?

[00:14:55.280] – Martez
Yeah, there’s definitely a lot of different factors that go into play if it is centered around a feature or capability that we already have. For me, it’s OK. What existing collateral do we have that talks about it, whether it’s from an engineering perspective or architecture perspective or something that C-suite level perspective and then figure out, OK, what are we just missing as part of the story? Are we tying it together well? Let’s say it’s new content of we’re coming out with a new feature, new capability.

[00:15:24.110] How do we position this? It’s that that collaboration with the chief marketing officer to say we have this new capability and then where does it fit within the market of the IT landscape? What are other vendors doing? What are what is the industry talking about in terms of what this capability brings? And so we start to evaluate, OK, how can we position this? Does it need to be targeted more? So this way of business agility doesn’t need to be targeted of IT automation, start to walk through those different scenarios of how we approach that conversation.

[00:15:56.360] And then for me, it’s ideally starting at that top level of oftentimes we have the feature, the capability, but we need to bring it all the way back up to the top level to talk about, OK, what’s the beginning of the story that talks to the executive levels of what the value this brings and then start to trickle that down? Because for me, it’s it’s much easier to start there because it’s high level. I don’t have to then take content and collateral that’s deeply technical and try to morph that or convey that in a way that that really drives the business value. And so I’d like to start top down from a content creation perspective.

[00:16:33.560] – Ethan
Do you know before you start composing the story how you want the story to end? And here’s how I mean this some marketing exercises are focused on the end of the story. That is, we’re starting you down a path and at the end there’s a buy or at least a try it and then buy it. Sort of a goal that you’re trying to reach. But you’re technical marketing, that means you’ve got this different audience that you’re trying to reach, the more technical folks, the engineers, where maybe you just want them to be aware of what this thing can do in enough detail, that they can make an informed decision.

[00:17:06.670] Sometimes writing is like that. You take a blog post and sometimes you’re trying to convince someone to do something. Sometimes it’s more like, here’s something I found out. I hope it’s information that’s helpful to you. Good luck. So do you know when you’re composing these stories how it’s going to end?

[00:17:21.880] – Martez
I don’t. Not in terms of the sort of the top level. It’s I would say as you’re starting to evolve the story, you get a sense of where like, oh, hey, you know, we started down this road and there was this really struck a chord in terms of what we were trying to do and trying to convey. And then maybe that ends up getting us to our end goal of OK, at the end. This is how we can really position it from a technical standpoint, because for me, oftentimes the, I don’t want to say the end of the story, but the point where I’m less focused on sort of crafting of the story is when you get into the sort of the ones and the zeroes, the ones and the zeros are the ones and the zeros, there’s not a whole lot of crafting.

[00:18:02.230] There’s not a whole lot of marketing. There’s not a whole lot of fluff that goes in there. And so it’s usually that sort of layer up or the step back of how do I position this from a solution perspective? Are we going to talk about our capability in and of itself? Are we going to focus on how that integrates with a Kubernetes or an infrastructure as code?

[00:18:22.510] Or what are those components in your environment that we can tie that into from a functionality or architecture perspective and then be able to kind of put a bow on this story at that point to say, you know what, this is how you use it in an environment. This is where it really drives that technical value. And then from there, it’s OK. The ones and the zeros. This is how you would actually do it.

[00:18:46.030] – Ned
Yeah. So like the value proposition and then the actual guide on how to do that thing, is there a project you’re currently working on that you could kind of walk us through a little bit of this, this thought process of how it ties into the story and maybe how you started going about crafting it.

[00:19:02.200] – Martez
Yeah, one of the things I can actually talk about I’ve been working on is Morpheus data’s Ansible integration. And so it’s one of those things of how do we convey that from kind of that high level perspective? We have some existing conten and collateral, and so it’s trying to figure out how to tie that in.

[00:19:18.130] That’s sort of in a nutshell. Morpheus data often falls into the bucket of CMP or a cloud management platform, and so leveraged for provisioning of infrastructure.

[00:19:27.670] And so the thing becomes, how do I leverage existing automation tools like an Ansible as part of that solution to provide end-to-end provisioning of workloads? Great. We understand the story. Now, how do I start delving a layer deeper from like an architecture perspective of yes, I understand Ansible. I kind of understand how CMPs work, how can I tie the two together? And that’s where for me, I start to walk through examples of what’s my development workflow as a developer of ansible playbooks, how am I developing Ansible playbooks?

[00:20:01.240] How does that tie into how I can execute those playbooks from Morpheus data? What are the execution methods? One of the really interesting things we have as a platform is being able to execute ansible playbooks through our agent based command bus without relying on SSH or WinRM. How do I start to convey the value of that? To understand that organizations that may not allow SSH or WinRM into a box can still execute ansible playbooks over a secure communication channel, and then we start to delve deeper into the weeds of OK, great. Now how does that actually work from a sort of ones and zeroes perspective?

[00:20:37.870] Kind of. That’s where I start and work through the flow of how do I convey this information to where the listener or the reader understands, obviously the value proposition of what our capability is, as well as how it actually works from a high level architecture perspective.

[00:20:54.970] – Ethan
I got to ask you something that’s got to be a hard thing for you to decide. Where do you draw the line on what you assume a reader knows already? They got to come with a certain level of knowledge to be able to get the story that you’re talking about. Other than that, you’re in a position of trying to educate them on like, well, do I assume they know a lot about Ansible before I get into this story? How do you decide where to where to come in at?

[00:21:19.210] – Martez
I usually level-set on the very basics, like kind of as I just walk through what is Morpheus data, what is a CMP, what is a CMP used for, what is Ansible? Usually I’ll go over like the quick spiel of automation tool, typically leveraged to do this or do that. And so at that point, we start to level set, you may know a lot more about Ansible, you may not really know anything about Ansible. And so hopefully the goal is to to provide that that brief introduction to to not distract, so to speak, those that are much more knowledgeable, but also to make sure everybody knows what exactly we’re talking about, provide that that great foundation.

[00:21:59.160] Then from there, it does start to get a little more challenging of how much nuance do you talk about?

[00:22:03.790] – Ned
Hmm. Yeah

[00:22:04.770] – Martez
To me maybe it’s sometimes challenging. As a practitioner who has spent years and years in automation and orchestration, I can go into the deep into the weeds of orchestration.

[00:22:13.080] The difference between automation and orchestration that sometimes people may not understand some of the challenges with orchestration that that really showcase the value of a platform like Morpheus data, but obviously depending upon the content. The goal isn’t to talk about the difference in the nuance between those two. It’s to give you kind of that that bits and pieces of information of value. And either you’ve been down that path and you understand some of the pitfalls and some of the things that I do convey.

[00:22:43.080] You really get like, yes, I really understand the challenge of passing data between two different scripts or two different automation tasks. This is really helpful, or you don’t necessarily grasp it, but you do grasp the higher level of value that says, hey, I can tie things together as part of an end-to-end workflow process to be able to to spin up VMs or instances that are fully configured. And then as I go through the architecture, potentially diagrams and things like that, I also have to avoid those landmines of like I can take you fully deep down in the weeds of like this. You can integrate it with this and you can integrate with that. One of the things that I have been sort of known to do is create sort of these exotic orchestration integrations.

[00:23:29.130] And it’s for just my own personal fun. But I have to realize there’s for a large portion of the audience, they’ll be overwhelmed. And so the goal is not to overwhelm.

[00:23:39.570] – Ned
Yeah

[00:23:40.290] – Martez
That’s kind of the thought process I have.

[00:23:42.270] – Ned
I’ve gone through the same thing when I’m creating content and I’m like I could go two layers deeper on this thing. Like if we really want to expand on something like HashiCorp Vault and I could talk to you about leases and lease IDs and how they’re actually using a key value store underneath and how that’s cool and how the whole basis of vault is key value source. But like that is not pertinent to the thing that I’m probably trying to educate you on.

[00:24:06.750] So I think my driving thing is always what is the actual thing I’m trying to explain or teach. And if that deeper level doesn’t go into service of that primary objective or goal, then I got to leave it out, which is hard.

[00:24:23.610] – Ethan
Well there’s even yet another challenge, though, because the deeper you write tech content, the more likely it is that it’s going to age out. And you’re like trying to maintain this library of documents. I’ve written hundreds of articles over the years, 80 percent of which are probably either useless or would need to be revised to update them since, you know, these articles span over a decade. So Martez has that come into your decision making process as you’re trying to decide what to put in. It’s like if I put it in this, it’s going to change in the next rev, so maybe I’ll just leave it out.

[00:24:55.860] – Martez
In some ways, I’m not overly concerned. Obviously, from an architecture standpoint, the the hope is that it’s a bit more long lasting from a solution to where we’re talking about some of those high level integrations to where maybe a nuance of the data that’s passed from one integration to the next may change in the next version. But overall, the structure of the integration or what’s being talked about doesn’t change much. And the other thing becomes just just needing to understand.

[00:25:25.500] And that’s why I’m often very judicious about what content is created, because content is going to have to be reworked in some form or fashion. If it’s not, then that’s likely a problem with either the software that is being developed or sort of the ecosystem, because IT is going to move and move and move fast. And so there’s going to be change. And so if the assumption is that I’m going to create this this blog post or this solution brief or whatever it might be.

[00:25:54.720] And I’m not going to have to touch it for like three years, like I’m golden. I think. I think you’ve then got a problem there. Either the software is not moving fast enough to where you’re having something that constantly updates or tweaks it. And that’s why you have to, as I said, be judicious about what content you’re creating, because you going to have to update it. And it’s not one of those situations where you just like, hey, let me create all the possible content I can. And then, like, you get to a year later, it’s like, oh, man, I got to update all this content.

[00:26:27.210] – Ethan
You’re in the kubernetes space. It’s like, oh, man, I just wrote this last month. It’s broken already. Oh yeah.

[00:26:33.420] – Martez
That’s that’s just kind of the nature of the beast. And hopefully a lot of it ages well. But you know that a large portion of it is is going to have to be reworked or revamped within a certain period of time.

[00:26:46.180] – Ned
Right. I’ve definitely been on that Sisyphean. Is that the correct term? Climb with with technical documentation when I’ve written it for vendors is. OK, that was right last rev. But now we’ve released one point two of our app and now you have to redo the getting started guide and these six other guides because the process is completely different and like, oh, that’s brutal. But when you do that higher level architecture stuff, that stuff only changes when you have like we’re going from version one to version two, so you don’t have to worry about it quite so often.

[00:27:16.630] You mentioned this concept of, hey, we Morpheus has this ansible integration. And I’m really curious about the one that you talked about, because as someone who’s done consulting projects with heavily regulated companies, they often have a situation where SSH into a machine is verboten. You can’t do that or they have severely limit it. So Ansible wasn’t a good fit, something that was agent based might have been. So is that where you would start with the storytelling is to start with, you’re in a heavily regulated industry talking to the CIO or something and then take it down to the we have a solution that helps you configure your boxes using Ansible.

[00:27:55.540] – Martez
So I would probably take it up or take it out a level. I would only do a small, let’s say, a blog post about that specific capability. But obviously there’s got to be more to it where it’s great that you told me about this agent based sort of command bus capability, but what is the broader integration look like?

[00:28:15.160] And in a lot of ways, the problem becomes if you’re so deeply tying the thread with that, it becomes that additional piece of collateral or content to where I now have a whole sort of story along the broader ansible integration. And then I also have this sort of subset story of the command bus agent based integration. And now when it comes time to have to update the content, I now have these two totally sort of aligned stories. But it is pieces of content that I now have to maintain sort of in and of themselves.

[00:28:48.730] And you could end up spending a couple of months just making sure both stories are updated as part of the process. What I would do is I would offshoot that as a sort of a one off blog post or a solution capability, solution brief, something like that that aligns with the broader story, but gives you that information about that deeper nuance of what this capability offers.

[00:29:13.100] – Ned
OK, yeah.

[00:29:14.500] – Ethan
So if you do a blog post that you consider that a point in time piece of content that you’re not going to maintain because it’s a blog people know these things age out, as opposed to like a library of white papers that you might be right on top of and making sure they’re current.

[00:29:27.970] – Martez
Yeah, I mean that’s usually the kind of direction I would add is you go with that blog post, people knowing that this is a certain point in time.

[00:29:37.660] And then what you can also do is obviously come back and say, hey, there’s a new blog post talking about the revamped command bus integration or capability to where I’m not updating what’s currently there, but I’m also taking the opportunity to say, hey, there’s something new, look at something new, but also being able to kind of keep that updated in a way that doesn’t require me to go back and update the existing blog post, because for me, it’s challenging.

[00:30:06.040] Like sometimes you go to somebody’s blog and they’re like, oh, this was updated. Such and such date. Like how often are people are really looking for when it was updated, again, if it was originally released. And so that’s why I would create net new content as part of that process.

[00:30:22.150] – Ned
Right. And creating that new content that links back to the older content can help with your SEO. So I mean, there’s a little well extra.

[00:30:28.300] – Martez
A little gaming the system.

[00:30:32.260] – Ned
Yeah, I’m curious. So you’ve decided to create a piece of content, let’s say it’s a blog post, a video, a talk or whatever it is. And you know, the overall story, you kind of know where you’re going with this. How do you start with creating that one piece of content? Do you do you write an outline? You start with like a mission statement, a PR release, or do you just like go for a long walk and just think about it for a while?

[00:30:55.090] – Martez
For me, it’s just kind of diving right into it. Obviously, if it’s a blog post or sort of written piece of collateral content, even with a video there, there’s thought around, OK, kind of know where it fits into the the sort of overall arc of this story. And now I’m jumping right in and starting to work through what that collateral looks like.

[00:31:17.140] Sometimes I’ll outline more often than not my my outline will be the piece of work that I’m actually working on. It’s me going through, writing down my ideas in, oftentimes in the in the format that it will ultimately be published in. But it’s then as I’m going through. OK, this doesn’t make sense. What am I. What am I trying to convey? What am I trying to to touch on as part of the process and then it’s kind of just multiple iterations of that process of tweak, tweak, tweak, tweak, take a step back.

[00:31:49.600] Look at it. Yeah, I don’t know if that’s right. More tweaking and then hopefully within a reasonable amount of time, it actually is published ready.

[00:31:58.330] – Ned
Is there a polishing process where you send it to somebody else to to read through and give you suggestions, or are you your own editor when it comes to those sorts of things?

[00:32:07.270] – Martez
At this point, I’m sort of my own editor. Obviously, it’s looking to the others in the organization for for opinions and thoughts on whether it’s like flow or obviously just technical validation to say, yes, this this is actually technically legit, not you just making stuff up.

[00:32:22.950] – Ethan
Now Martez you used the term collateral a minute ago, and I think we take that to mean you create some artifacts, some object. It’s a blog post, it’s a video, et cetera, like we’ve been talking about. You’ve conceived of it. You’ve brought it to life. Now it’s collateral, something in your library, your arsenal of technical marketing material that you can use. How do you know when that piece of collateral is is successful? Do you have a metrics or where you judge it?

[00:32:50.710] – Martez
So at this point, we’re still developing metrics. We’re a smaller organization. And so, of course, it’s it’s one of the things that how do you how do you track, how do you quantify these various things? But for me, it is kind of, as I said, being able to tell that story.

[00:33:05.410] If we’ve got the arc in the sort of the totality of the story in terms of creation, content creation, that’s successful for me as sort of that initial pass of can somebody ask us about our ansible integration or our terraform integration and get a whole story in a way that feels consistent, feels like it flows really well from sort of top down, because even if I’m an engineer, I may not want to read all the fluff, but can I go through the fluff piece all the way down to the actual sort of ones and zeros and feel like it makes sense, feel like it was tied together, feel like it worked together?

[00:33:43.900] – Ethan
Well, do you have a workshopping process where as you’re composing things, you kind of get into form? I think this is good and then you kick it off to some folks who maybe people that are outside the organization. What do you think of this?

[00:33:56.230] – Martez
Not at this point. That’s actually a really good idea.

[00:33:59.110] – Ethan
I did not just raise my hand.

[00:34:00.580] – Ned
I was going to say, thanks for volunteering, Ethan.

[00:34:04.030] – Martez
I’ll send my collateral right over for you to review.

[00:34:10.840] – Martez
But yeah, it’s definitely a really great insight to be able to to understand, like, where does it resonate with people?

[00:34:18.100] And of course, that’s always one of the biggest challenges of content. You create yourself and kind of go through the process of reviewing yourself or even with a smaller audience of sort of like minded individuals. So you’d be able to say, OK, yeah, this resonates with us. But we also have this additional context of how the product works or what the space is. That is why we actually understand why it clicks. But do or does our audience have that same context of what the problem is or what the market is in terms of how this capability or this component fits?

[00:34:54.130] – Ethan
What you’re saying is you do need some kind of boots on the ground vibe about what’s going on so that you’re addressing people where they’re at, the problems that they’re experiencing, or else your content isn’t going to, quote unquote resonate. They’re not going to feel what you’re writing about because it’s like the way they’re experiencing the problems in the world or are different from where you’re coming from.

[00:35:13.030] – Martez
Yeah, which is actually why one of our inputs to the process is our SEs as well as our professional service engineers, the ones that are sort of day in, day out in front of prospects as well as existing customers to be able to say, okay, you know what, this is what we’re seeing from a challenge perspective, a problem. This is what organizations are looking to get out of the platform like Morpheus data. And then it’s how can we how can we integrate that into the story and tell that story of, yes, this is the problem that we’ve seen dozens or hundreds of customers experiencing.

[00:35:47.410] Now, how can we shine the light on the capability that Morpheus data provides to help solve that problem? So it’s in a lot of ways it ends up being sort of that bidirectional process of, OK, we got this input in from from the field to say this is what we should be creating content around.

[00:36:02.710] OK, now, can we give it back to the SEs for validation, say, based upon what you’ve been hearing and obviously we’re only getting snippets back based upon your hours and hours and hours in front of customers, do you think this resonates with the problem they’re talking about? Yes or no? And then if it’s no, obviously it’s can we rework it again?

[00:36:24.370] – Ethan
Well, so the SEs are customer facing and you can glean information from them. Are you yourself ever customer facing?

[00:36:30.580] – Martez
At times I am. Being able to have that that engagement with customers being brought onto calls and things like that, but obviously it’s it’s certainly not in comparison to the SEs and obviously just the totality of the SEs to be able to glean from a handful of individuals their different territories, their different perspective on on what the problem is and be able to gather that information.

[00:36:55.580] Because if I’m the sort of the single source of what the problem is, then obviously it has my bias, has my thoughts and my views about what the problem is and potentially what the solution is.

[00:37:06.230] – Ned
Especially for startups and smaller companies. It’s imperative that you figure out what customers actually want from your product and deliver that as opposed to what you think they might want. I’ve definitely seen that mistake made several times also by really big companies. But they seem to be able to push through it because they just have all the marketing and enterprise dollars to say, nope, you’re going to do it our way.

[00:37:27.950] – Ethan
Yeah, the bigger companies, they’ll tell you what you want. This is what you want. You’re going to buy it.

[00:37:32.480] – Martez
Well, if they sort of become a conglomerate of mindshare, effectively, that is what you want.

[00:37:39.650] – Ned
That’s right. And then it’s up to smaller companies like a Morpheus data, perhaps to disrupt that lock hold that they have by going, I know you don’t actually want this other thing. Here’s the thing you actually want and you’ve been asking for. So you’re welcome, everybody.

[00:37:55.090] – Martez
Yeah. And it’s it’s definitely always one of those opportunities of a sort of the smaller player to and to be able to experiment with different ideas. As I found, it’s definitely harder for large vendors to to kind of to pivot on certain things, which is why sometimes we see like a small group working on stuff, we see sort of spin outs and and things like that to be able to enable them to move quickly.

[00:38:17.910] – Ned
Right. The last thing I want to ask you about is the size of a piece of content you’re working on, because I’ve struggled with do I write a three thousand, five thousand word blog post that I split into three posts, or do I keep it one post? Do I do a 30 minute long video or do I do a three parter video that I break into 10, like what’s your mental process for how large and long a piece of content should be?

[00:38:42.560] – Martez
You look at your audience and you start to think about what’s their level of investment into that piece of content? And so from like a technical marketing perspective, there’s content that is is focused more so on the prospect than it is on sort of the existing customer. Not to say that the content isn’t going to be for the existing customer as well.

[00:39:03.590] – Ethan
The prospect as a person that isn’t a customer, you’d like to be a customer.

[00:39:07.610] – Martez
Yes

[00:39:07.970] – Ethan
OK

[00:39:08.390] – Martez
Yeah. And so the challenge then becomes how much time are they going to be willing to invest in, let’s say, reading a white paper or reading a solution brief and kind of some of that going to dictate how long it should be. Some of it’s also going to be dictated about for me, just the idea that people aren’t going to want to read a whole lot. And it’s just sort of the world that we live in.

[00:39:30.860] You look at whether it’s social media or sort of different forms of communication. Most people aren’t reading paragraphs and paragraphs and paragraphs of text. So how can I, not say that I’m just going to try to get you the good gold nuggets all the time. But there are certain things that want to be highlighted and make it easier for people to to quickly consume the content and then be able to make that decision of am I willing to invest more time into what the content is or is that enough for me?

[00:40:02.870] – Ethan
There’s that aspect, right? The consideration of the person consuming the content, will they have the time? Will they have the focus, et cetera, to read everything that’s there? But there’s also SEO, Martez, do you think about what to put in a document because of SEO and hoping for discovery and searches and this kind of thing?

[00:40:19.040] – Martez
Yeah, I do. And so for me, for for blog post, it’s it’s trying to sort of hit that SEO magic number. Oftentimes there’s usually never that concern about like, can I write 500 or 600 or 700 words.

[00:40:33.710] It’s I’ve got to make sure I’m not turning this into like a fifteen minute read where the individual has to scroll and scroll and scroll and scroll. And I’ve also thought about the sort of multi part series blog post as well.

[00:40:49.370] The challenge for me becomes following along is in a lot of ways, like if you think about from like a TV show perspective and I don’t know if a lot of people think about it, you have a lot of TV shows nowadays that episodes are really kind of one offs to where like I don’t really have to have watched the previous episode to enjoy and understand what’s going on in this episode.

[00:41:12.530] You have some shows where it’s like you have to have watched the whole first season in order to understand what’s going on in this episode. And so it’s kind of that balance. And that’s in some ways that’s that’s why I tend to shy away from long sort of multi part blog posts.

[00:41:29.870] – Ned
Right, right. You find post number three and you know, you’ve got two other posts to read through. You might just click next. Well, if someone’s interested in getting into the world of technical marketing, I’m curious if you could just sum up some recommendations or things that someone could do to learn more or advance their career towards a role in technical marketing?

[00:41:52.090] – Martez
Yeah, for me, I would say there’s definitely a lot of positions for former practitioners in regards to technical marketing engineering roles. So TMEs as part of the process. The thing that I’ve realized as I’ve gotten further and further into my career is just the ability to be able to communicate is super important.

[00:42:11.540] And one of those things that’s not often really honed and polished from an engineer’s perspective, not to say that all engineers are like people that go into dark corners and just found out code. That’s not that’s indicative of all of us.

[00:42:27.710] – Ned
My corner is very brightly lit.

[00:42:31.190] – Martez
The other thing that does become OK, how can you how can you craft emails? How can you converse with other individuals to be able to convey information and topics? The other thing becomes for me was, I would do, start work on a lot of public speaking.

[00:42:46.970] How can I continue to craft presentations that that don’t feel sort of boring and in super detail focused? I’m not suggesting anything wrong with detail focused, but like if you just slide after slide, I’m just like going over the numbers and the nuance people quickly check out.

[00:43:04.100] And so it’s those things that oftentimes, as engineers we’re already doing that’s part of our day to day jobs and just really focusing in on honing those and understanding. You know what, I’m I’m giving this presentation about a new feature, a new capability or a new product we’re rolling out.

[00:43:21.320] How can I put on the mind of sort of a technical marketing focused role and say, you know what, my goal is not just to inform people about the new feature or capability that we’re bringing to the enterprise, but to also understand that in some ways I need to to understand how can I sell this to people and not so much just like inform you about what the story is.

[00:43:44.570] So kind of you go back to it’s a grammar school where. Well, what’s the difference between an informative essay and a persuasive essay? You kind of have to mix the two and marry the two together in a lot of ways to to start to get into that mindset. I not only need to educate, but I also need to to bubble up the value proposition.

[00:44:03.290] – Ned
And I think that’s important not just for someone in a technical marketing role, but also if you’re just an engineer and you see a product or something that’s going to help you in your day to day, how do you sell that to your boss? How does your boss sell that to their boss? So they’ll actually spend the money to get that thing or get the support for that thing? That’s a good skill to have just in general. Awesome. All right.

[00:44:23.660] Well, Martez, how can people follow you if they want to read all this great content you’re creating or some other stuff that you’re doing around on the Internet?

[00:44:32.700] Yeah, so I’m on Twitter at GreenReedTech. I’m also on LinkedIn Martez Reed. And then I do still a lot of coding on GitHub at MartezR.

[00:44:42.890] – Ned
Awesome. Awesome. Thank you so much. Thank you to Martez Reed for being a guest today on Day Two Cloud. And hey, virtual high fives to you out there for tuning in. If you have suggestions for future shows, we’d love to hear them hit us up on Twitter at Day Two Cloud show. Or you can fill out the form on my fancy website, Ned in the cloud dot com. You know, if you like these engineering oriented shows, maybe you can visit pushers dot net slash subscribe all of our podcasts, newsletters and websites are there. It’s all nerdy content designed for your professional career development until next time. Just remember, cloud is what happens while IT is making other plans.

Episode 87