#048: Tech Marketing with Alex Henthorn-Iwane, Part 1

Eric Chou: 0:00

Network Automation Nerds Podcast. Hello and welcome to Network Automation Nerds Podcast, the podcast about network automation, network engineering, python and other technology topics. I'm your host, eric Cho. Today we have a true powerhouse of marketing joining us, alex Henthron Iwani In his own words. He's a multi-exit full-stack B2B marketing executive, technologists and advisors, and he's currently doing fractional CMO work. I have followed a number of Alex's posts, including one he summarized his experience at the recently concluded AutoCon Zero a very interesting experience which I'm literally looking forward to digest more of. I am super excited to have Alex on the show today and I know we'll have a great time talking more about his background, his wealth of knowledge and experience. So let's dive right in. Welcome to the show, alex.

Alex: 0:52

Thanks, thanks for having me, eric, great to be here.

Eric Chou: 0:55

Yeah, I mean you have posted some very interesting posts. In fact, one that was talked about this morning when I was having a conversation with somebody else. They were talking about treating network as pet versus cattle. And I'm ready to talk to somebody who maybe from a marketing perspective, because most of my audience and my colleagues are engineers, but very interesting to hear your thoughts on that.

Alex: 1:23

Yeah, I mean it was one of the concepts that came out in AutoCon and clearly network automation at large is really trying to borrow a lot of concepts from Lean and DevOps and things like that, and one of the major concepts is how do you manage things as herds of cattle, but sort of special pets, and the cloud really does a lot towards that, because when you're dealing with hardware, obviously everything's virtualized and essentially the concept of being disposable. Then you can really do a kind of operation on mass at scale. That has, I think, really eluded networking. And the reason I was interested in this is because I think the analogy only goes so far in terms of addressing some of the hard realities of networking.

Eric Chou: 2:22

And there's some interesting.

Alex: 2:25

I think it's always very important when you're trying to build a movement to have the right sort of scope of ambition. Say, all right, well, it has to be like this, but it's kind of impossible. Then it's just discouraging and you're going to give up.

Alex: 2:42

And I think it's clear that we need to have network engineering move more and more towards programming, automation, systems, thinking, all that, and it's been clear for some time, but there's been a lot of obstacles. So this is just one of those areas that I thought, yeah, well, what are the aspects of networking that are more pet-like and that don't translate into the cattle analogy, so that you just don't develop the wrong expectation. If you're dealing with networks as an engineer, you already know this very viscerally, right? Like if you deal with the fact that, for example, failover or redundancy in most networks is not like, it's not disposability, it's just not. You have two, maybe if you're really lucky, you have three failovers, right, think about uplinks, all that kind of stuff. You're still in a very bespoke level of redundancy.

Alex: 3:48

And that's just an example and then kind of giving thought to, beyond some of the technical aspects, just what has made. What about the economics of networking have made it so. There's a culture of what I call pet whispering, speaking pet languages, which is like OK, I'm trained in vendor acts, and vendor acts without naming names has been very successful in creating an economy of scarcity of skills, which means that there's demand for those people and then they want to pull in vendor acts as equipment and it goes on. But that creates a dynamic of wanting to be a specialist in that particular pet language.

Eric Chou: 4:40

Yeah, yeah, I mean without naming, but they rhyme with San Francisco, but anyways, that's well, I mean Kudos for that dynamic model.

Alex: 4:51

They were very successful and they actually you could say generationally that level elevated networking to really had some cache to the craft right and they branded a craft around their pet language and maybe that was an evolutionary stuff, but it's not going to take us into the future and one of the things I think that is really interesting is that theAUN is closer to the inner equation.

Alex: 5:18

One of the lessons from DevOps was that early vendors really were much less protective. Now it could afford to be because they weren't selling hardware but they were selling, maybe, an automation approach. But the protectiveness around pet languages and pet APIs and the incompleteness of a lot of the interfaces and the uniqueness of the interfaces perpetuates that sort of culture and expectation and that's one of the things I think it has to change, because otherwise what you have is you have a never-ending loop of technical debt and race condition, like if you have a brownfield network, you have a technical debt that extends years back of interfaces that do not have an API and all that or the API is just not very good, and then you have a race condition of new technical try to catch up with the new stuff in terms of automation. That's a really hard thing to overcome. You want the greenfield to be really pristine in terms of its enabling of automation.

Eric Chou: 6:37

Yeah, I mean I really know we're going to have a great conversation just by like that past six minutes of our conversation. But I wanted to kind of start out by getting the origin story, because I mean I get exhausted just reading all the titles you've been doing like marketing and technologies and advisors. But how did you get into technology? How did you like a little bit about your origin story? How did you be kind of interesting in all of these?

Alex: 7:07

Well, it was not really on purpose. I mean, when I got to the school I was looking for a job and I landed in a systems integrator and it was one of those kind of things. I don't have an engineering degree. I was a French literature major, nice. Now, one of the things I'll have to say about studying languages it does help you develop stamina for learning other languages, like protocols.

Eric Chou: 7:31

So, because they're languages, and I mean, if I'm not mistaken, I think, the creator of Pearl, larry Wall. He's actually a linguist and musician, and so, yeah, right along that line, right.

Alex: 7:44

Yeah, yeah. So but I stumbled into. You know, I need a job. I've went to work for the system integrator and then it was sort of led me down this path of like, oh, can you learn this, can you learn this, can you learn this?

Alex: 7:57

And all of a sudden I was kind of a technical person you know, designing networks and you know, installing gear and upgrading stuff and all that kind of thing for customers. And then I went onto the vendor side you know was working with networking gear, you know in fairly large companies you know as clients, and then you know, then I was managing some systems engineers and then I kind of made. I had a mentor who said you know, you're kind of a strategic thinker, you should think about getting more into like a corporate job, like product management or something, what's that?

Alex: 8:42

So, I landed a technical marketing job at a startup. I mean, I'm severely aging myself, but this was, like you know, the start of the commercial internet. You know there was a company called Livingston and they made some product called the Portmasters people in the ISP community back then, and you know. So I was working doing stuff and that's where I really got connected to the internet as a technology. You know routing protocols. You know AAA Livingston they invented radias which then turned into diameter and stuff like that Sure.

Alex: 9:23

And so I was in the same room with the people who were writing the you know, the RFCs and all that kind of stuff. So it was. I just got really steeped in a lot of that stuff from that point much more deeply and from there just kind of followed a journey on through you know product management and then eventually kind of made the switch into marketing. And I've always held onto my roots of being technically curious because I think that particularly for people who are doing nerdy things, your head is so full of all that all of that it's hard to then you need, if you want someone you know trying to market your products, you need someone who actually has enough curiosity to figure out what it is really, what's actually special about it technically, what the value is technically and what the value is to actually to the to a business. Right, and that takes some abstraction, but I still stay really technically curious because of that. I actually really like to learn the tech you know, even as a marketer to this day.

Eric Chou: 10:30

Yeah, I mean, I think that's that's very accurate what you talked about on. You got to stay curious because then you know I mean for me being having worked in the corporate world for the last 20-some odd years the most successful people who get into the business, you know, especially for a newcomer, is they're they're offering their service as a gift, right? They have the mindset of, hey, have this awesome thing, I'm curious that, how can it bring value to you? And so put the customer at the center of the of the conversation, right, as opposed to hey, I have this awesome thing, how can I benefit from your dollar or your purse? So I think that that mindset definitely helps in in being a marketer, or technically curious marketer.

Alex: 11:11

Well, at the end of the day, I mean, it's, it's, it's, it's, it's it's, it's it's at the end of the day, I mean, if you think about it and this. This bridges into sort of the. The challenge for network automation is that there's an aspect of it which is all about empathy to the goal right.

Alex: 11:28

You know what's. What's the outcome? Right, that's desired. You know you could call that intent. Right, what's the intent of the and it? And it gets into things like the whole, not maybe even a debate, hopefully anymore but but the reason for a distinguish between automation and orchestration, for example you know, where like okay, automation, you could say.

Alex: 11:51

You could say this is just semantics, but there's an important distinction between saying I'm automating a task or I'm I'm building a process that achieves an outcome where there's some kind of value. And you know I mean the same thing as a marketer, I want to know what is it that? When you get into kind of concepts like jobs to be done, things like that, where it's just what is the, what's the job that needs to get done here, and then, along with that, what's the pain in that trying to get that job done and is there a solution to that?

Alex: 12:25

you know that adds value and if there is, then we should build the product to that and then we want to make that clear. That's what marketing is. Is like helping people to understand, sometimes like diagnose their own pain, because maybe they just lived with it for so long, they're just used to it, right. But you say, hey, there's a better way, here it is, and this is what the benefit could be, you know.

Eric Chou: 12:47

Yeah. So I mean you get back to that point about people don't want a three inch you know whole drill. They want the three inch hole, right. So you're talking about that working kind of backwards from their goal and then you know how can we contribute to that goal. So how did you know? So it sounded like you were very much involved with the technical industry. But how was that? How did you get into networking, for example? I know the radias, the triple A's, but you also work for some interesting company that were very specialized in networking.

Alex: 13:19

You could argue, maybe too specialized. I mean, I suppose that there's kind of a blessing and a curse of being really interested in cool tech, right? Because sometimes, like it's so cool that it's too cool Tell us more. You know. So, for example, one of the companies I worked at, which is a company called Packet Design. I'm hoping to work for at least five or six companies in my career that have the word packet in it. All right so far.

Eric Chou: 13:54

Yeah.

Alex: 13:54

Yeah, and the first one was Packet Design and they built a. You know, what we developed was a multi-layer control plane monitoring system and the foundation of that was what they call RAD Analytics, which is basically passively peering with IGPs and you know, and basically getting all the like leg state updates, you know, and then calculating using the same, you know, basically running Dykstra or what you know, running the SPF and calculating the paths, and then do it. You know, you would, you know, set up an adjacency per area, you know, or whatever would choose your equivalent if it's a different protocol. And then you know, because you need the full resolution of the paths, and then it would assemble an end to end of the IGP paths and it also could, you know, peer with BGP and do those. And then, you know, overlay those on the IGP because of course we know BGP relies on the IGP for the internal routing, exits and all that kind of thing.

Alex: 15:05

And then you know static routes and you know LDP, which, yes, of course, files IGP, and then RSVPTE and multicast, and you know, like all this stuff, which was pretty amazing to see how you could create a pretty much real time. Now IGP is truly real time updates because those links, date updates are very, very granular in terms of their timing right. They're pretty much as real time as the routers can make it. So that's. It was incredibly you could replay this stuff, but even with things that where you were scraping or pulling data, fairly short segments, I don't know.

Alex: 15:48

I'm sorry I'm going into way into this, but it's an exciting product because you see, and then they overlaid flow data on it Right, so the entire path state of the network, considering all those layers of functionality and exceptions like static routes and such, you can say, all right, exactly how is traffic flowing through that network? It's amazing insight. You know you have a big network and we mostly work with carriers. You could see exactly how much traffic was on all the links in your network by just collecting at the edges.

Eric Chou: 16:24

Yeah, you know, yeah, I mean I think I think I've looked at packet design. Well, maybe was it when I was at Amazon or whatnot, but but yeah, there's like a lot of values to be gleaned just from the control plane and kind of replay that convergence. Same thing with what you know like Batfish is doing intention net and then to a certain degree Susie Q right, they're all doing kind of these other stuff. But I agree that you know visibility could be gleaned from your just control plane and then you could kind of replay that for you know maybe your post and pre operation or maintenance window validation.

Alex: 17:05

Right. And if you think about, you know, capacity planning and things like that, you know, or right like a pre change, like hey, let's check it to see if this would have any adverse effects in terms of traffic balancing across links or paths and things like that, or you know, edge to edge traffic exit points, all that sort of stuff, there's a lot of interesting things you could do with it that are very practical from a point of view of pre validation, for example.

Eric Chou: 17:33

Yeah, I think the the the big thing that we were looking at was, first of all, you know, like when we're doing maintenance, we want to simulate it right, like what have we not thought about? That would have broken, that would have been broken. And then another was just capacity, capacity planning. I mean, how many people bought Arbor just to just to project, like their, their traffic growth, right? So yeah, those two are definitely big use cases.

Alex: 17:57

Yeah. So I mean there's certainly it was, you know generations of product that did wrinkles of that. And and you know now I mean what are the other companies I worked for was KenTech and they were kind of like the cloud version of the Arbor, right yeah, gale the Arbor, and now obviously moved on and add a lot of other things to it, but that the idea of that you can pull together a huge amount of traffic state and you know, understand what it would do.

Eric Chou: 18:28

Yeah, yeah. So obviously I I really was very focused on the, the front end, yeah. So I mean I think we were at ATEN Networks. You know we're early partners of KenTech and you know we definitely saw how the, the amount of emphasize they have on the front end and making it observability beautiful, and that really appealing, that really appeals to a lot of network engineers and also their bosses.

Alex: 18:55

Right, yeah, I think I mean another company I worked for that did a really good job of the. The elegance of UI was Thousand Eyes right.

Eric Chou: 19:05

Yeah, for sure.

Alex: 19:07

Yeah, because they the the thing that they did, which was interesting, and maybe you know they did a really good job of the, the, the, the, the, the, the, the, the, the, the, the.

Alex: 19:14

All these things are improvements. Everyone wants to argue that everything they've done is brand new, it's never been done before. But incrementally speaking, even just to say, I've got a time slider and I can look at things from the point of view of synthetic transactions and page loads and HTTP, dns paths, bgp, like I can look at all that in one place and I've slide the timer. If I look at a synchronized timer, I can just visually correlate hey, why did we have this? Our latency, our round trip, go crazy for this set of users trying to use our applications. I say, aha, I see that this thing happened on the internet or whatever, or it has nothing to do with the internet and simply there was something happening in our application that affected this. But just even teasing that apart visually really easily was very useful and I think a state of the art of a lot of monitoring has been digestion and presentation for relatively expert consumption and interpretation.

Eric Chou: 20:29

Yeah, I think Thousand Knight did a very good job in having the amount of data points that are hard to get from just the enterprise alone. So for reasonable amount of price they're able to see from outside in what that's been looked at and also extracting value from those data. So those two things are what I see as something that you cannot get from even for a hyperscalar, Even though they are in all the continents outside of maybe the Antarctic Oz, but they still can't get that much visibility from a CDN perspective or from a Thousand Knight's perspective.

Alex: 21:09

Yeah, I mean it's interesting because, well, I mean, hyperscalar networking is really different, because it's not actually traditional. Yeah, yeah, for sure. And all super, super abstracted, and so there's obviously been massive amounts of investment into automation that abstracts everything. Your IPs are not sitting in normal blocks in the same way.

Alex: 21:37

No, there's no IPAM that's telling you which next block that you're going to be able to just take Right it's more of like I mean it's a very crude analogy, but more of like an airline reservation system right, rather than the structured hierarchy that typical networking protocols operate.

Eric Chou: 22:01

Yeah, so it sounds like you have this well-versed background and you're almost reaching your goal of working for what is it? Five companies with that has packing inside, but obviously all of them have tie-ins to automation, as you mentioned. But what were some of the key points that you see as the challenge in telling the story for network automation today?

Alex: 22:26

You know, I think that some of what I find one of the talks that I thought was really interesting was by John Willis. So he came in to give a talk at Autocon about the lessons from DevOps, and one of the things that he talked about is the the way that I would call is sort of like crafting the stories and the iconic images and analogies. Like you know, we talked about the wall of confusion, right when, you know, devs and ops were throwing stuff over the wall of confusion. This separation, this artificial separation, instead of having, you know, an integrated team that Like the Phoenix project.

Eric Chou: 23:14

Well, the first part of the Phoenix project.

Alex: 23:16

Right, and he named that as well. It's like having a canonical book, right, that was very relatable and so. But there was he talked a lot about like, yeah, we came up with these analogies and these pictures and even cartoons and things like that. That helped people kind of grasp the importance of the culture change, because the culture change is arguably the bigger problem, right? You know, one of my reflections, for example, is I was thinking about I can't remember who is the guy from who talked about the Cisco live automation, which is pretty fascinating, yeah, no worries, I'll find the name.

Alex: 24:01

I know who you're talking about and just it's not occurring to me right now, but he used the analogy of like. You know he was kind of making a joke of like not automated is finger driven networking, right, you know, and I thought you know it's a clever little thing. But what strikes me about the storyline of the network, the networking person, if you and this is what you see in historical marketing as well it's where his networking people is, that it's the, you know, sort of the You're going to be blamed. It's a little, I mean, I would say a little bit kind of like, kind of the sort of victim mentality story, being blamed constantly for everything. And you know you're, and it's a very lonely picture, right, you're sitting there up at night typing stuff, answering stuff on your page. You know you're, it's a very lonely picture.

Eric Chou: 24:56

Yeah, very sad.

Alex: 24:58

And sad. It's stressful, sounds horrible, right, but more than anything it struck me as lonely.

Eric Chou: 25:03

Okay.

Alex: 25:04

You know like okay, you're typing on the CLI, there's something you do alone. You have to Like you have all the configs on your laptop, maybe you know you're the. And then a lot of the storyline of what market? You know marketers was like you can be you individually as a network engineer. It can be the hero, right. I mean, how many networking conferences have you gone to where they had like be the hero, right, the superhero?

Eric Chou: 25:28

I believe that was the tagline for many of them.

Alex: 25:31

Right, and because it's a psychological contrast between, like I am sort of being treated like the person in the basement with the pizza slipped under the door, you know, just, you know, keep typing and get that, make sure that network doesn't go down, but that's. You know, for example, the culture changes to say like okay, well, in a lot of the talks you were like this is a team. They didn't say it in this way, but you know the way I was. This is a team sport, right, and if you're automating, you're doing systems work and systems thinking. And how do we solve things at scale with repeatability? That's a team sport. It's no longer the lonely, you know sort of mistreated. You know networking hero who is the specialist in vendor X pet language. It's a team sport. Developing automation, developing orchestration, you know aiming for business kind of intent, right, you can't do that all by yourself.

Eric Chou: 26:32

Yeah, but how do you tell that story though? What is the you know, or have you found a successful way of telling people that, hey, get out of that basement. You know there's no longer something you throw over the wall to operations team is, you know, getting into more of a system level mindset?

Alex: 26:51

I think I mean this is something I've just started to think of. I mean this, is this even just this sort of team sport analogy? I think I think there's something about coming up with these analogies and these pictures that they have to be simple enough, and that's why I kind of like the team sport analogy, because I and it's not to say that aren't networking teams, but it wasn't. I mean, a lot of times it was like people doing their thing on you know, task taking, tickets doing, you know, and. But if you look at the way that the folks, particularly who are giving talks, who are leaders, you know, a lot of what they've talked about is like okay, we won't leave anyone behind, we're doing these sessions, we're learning together and we're developing these things together. There's an emphasis on sharing.

Alex: 27:41

So I think even something as simple and has got to be sort of simple you know, team sport versus, you know, sort of lonely adventure, lonely CLI type right is kind of there there. There have to be some simple, powerful analogies to help kind of say like, if you're not, if if you're not working like this, you probably are not in the right heading, the right direction, you're not where you belong right, where you were really belong is is doing things this way and it's going to be so much better for you as for everyone and, by the way, that's the only way to get out of the dungeon. So I mean, maybe it's just like pictures and analogies and things like that. So it's something that I I really took to heart of to think about. Like what are, what are those impactful analogies that would really help? And sometimes they just come out and talks and such.

Alex: 28:42

But so hopefully over time the community can really develop those things. We can develop analogous things that are the network engineering community's own thing and not just sort of not just sort of, you know, borrowed, slightly repurposed versions of older DevOps themes and only because I think there needs to be pride of ownership, the concepts right, and if you have that, then people will sign on. If it just feels like this is a retread, it's just not that it doesn't inspire any imagination or ambition. So I don't know. It's kind of what I think of, at least.

Eric Chou: 29:24

I mean, I think that's true and especially if you do the right analogy that drives through people, that people remember they could be the advocate at the table, right? Because most of the time when, like you and I, certainly not at the table when this engineer X after conference X goes back to the team and they try to advocate network automation versus lonely CLI engineer, as you would say, that they have to come up with something that is more of internal. So the analogies are easier to be internalized and they could identify with it and they could be the advocate for you for that message, right. So I think that's definitely a good point to make.

Alex: 30:05

I think the other thing that is a challenge and why this has to be have some thought given to it, is one of the things that enabled DevOps to happen and for that that was an external force and function was cloud. So the shift to cloud was there was its own economics and business benefits right, opex versus CAPEX, and ease of change and stuff like that Reducing maintenance. You do not have to deal with software upgrades, updates, all that sort of cycle overhead and the ability to theoretically at least turn it on and turn it off. Yeah, but this has never get turned off, but you still get billed by it, by the way.

Alex: 30:53

Yeah, so that actually really helped people, because the cloud created herds of cattle to be herded. So if you could use that forcing function as like well, this is the new way to do it for cloud. With networking, you don't get that same luxury. It's like oh, guess what? We're still buying a box with ports on it. Right right right, it's not. Hasn't magically just disappeared into a gauzy sort of thing in the sky.

Eric Chou: 31:32

Yeah, I mean, I see that analogy. So, instead of saying this is this beautiful thing that you spend hundreds and thousands of dollars, that you cater and you unbox and you spend all these effort, rack and stack in, if you were to be in the cloud analogy, it's something that you spin up, you use that and then you just composed right after. So we need to move, like networking, toward that kind of analogy.

Alex: 31:55

Again, your pet versus cattle story, but the thing is you don't get the air cover of that landscape changing, like if the CIO and the CEO you know like everything's going to the cloud, then you can kind of ride the tail coats of that thing. Well, and to do that, we have to do it the way those cloud people do it, which is DevOps and this, et cetera, et cetera. And this is the way to do it because this is the way it works. It's totally different. So you don't get the air cover networking because you're still saying, hey, could you sign this purchase order for you know X dollars to buy these new boxes that we have, stores and HQs and whatever data centers. It looks very much the same. So that's one of the challenges, I think.

Eric Chou: 32:42

Yeah, I mean, I also think that's where the polarization that I see is happening is for a company who are all committed to the cloud at least majority to the cloud that they have one set of mindsets and they're all guaranteed toward that and it's easier to deliver that automation message to them. And there's also, like the company who's maybe the biggest in their industry but they still have 1.5 network engineers and the 0.5 like have to deal with Windows machines and, you know, poor provisioning right. So I think that's kind of the polarization that I see and the challenge is the same story cannot be told to two different groups.

Alex: 33:18

Yeah, yeah for sure. Because if you think about a purely digital business, right, I mean, in a lot of cases there's no, you know. I mean, once you get to a certain size, you probably need, you probably need you probably, and you're running a big net service, you probably should have your own edge and all that you know. But let's say before that all you need is sort of like a cloud provider and you know, pick a CDN service and you know a few other things, DNS provider, it's all like out there, you don't have to do anything. So you all, you're focusing on software anyway and there's a direct tie to the value Because it's, you know, whereas the companies that have factories and you know, offices and retail and all that sort of real world stuff, they still have to plug boxes in those places, right.

Alex: 34:10

They still have to deal with those that long tail of Brownfield deployed equipment, right, and yeah, so they have a different reality they're dealing with and they don't. There's no one who thinks networking is fundamentally changing for us and it doesn't count if you're using a network as a service subscription model, that doesn't. That's just a payment method, right, it's not a technology culture changer. You know what I mean, and it's fine in an executive suite like oh look, you know, magically, cloud provider X has, you know, replaced all of our actual hardware routers in our stores and warehouses and factories.

Eric Chou: 34:53

That's not happening, right, yeah. So I mean, yeah, I mean this is probably like a good place to kind of take a pause and the breathe. I mean we talked about your background. How did you get into marketing, technical marketing, as well as some of the challenges that you know to delivery that network automation message to people. So next week we're gonna, you know, dive right into it, maybe bring some specifics, some recommendations, and so stay tuned for our next session. So, alex, where can people follow you and find some of your work? What are the best places? On social? Maybe some other places?

Alex: 35:28

I'm really primarily active on LinkedIn. I have the benefit of having a probably globally unique name, so find me thanks to hyphenating with my wife's last name. Nice, yeah, you can find me there.

Eric Chou: 35:43

Okay, great, and we'll include all these in the show notes. And thanks again for being here today and we'll continue our conversation next week.

Alex: 35:51

That's great. Thanks a lot for having me.

Eric Chou: 35:53

Cool. Thanks for listening to Network Animation Earth's podcast today. Find us at Apple Podcasts, google Podcasts, spotify and all the other major podcast platforms. Until next time. Bye-bye, then. Us.