Fireside with Voxgig for Professional Speakers

Zachariah Peterson,

Episode:
108
Published On:
15/08/2023
Zachariah Peterson,
Podcast Host
Richard Roger
Voxgig Founder
Podcast Guest
Zachariah Peterson,
Strategic Advisor, Conference Speaker & Electronics Designer

The first thing to know about Zach Peterson is that he’s a hardware guy. Richard is not. Can this divide be bridged by a friendly Fireside chat? Well as turns out, bridging the divide between these two industries is pretty essential for the tech world at large. It may seem obvious, but you can’t really have one without the other - until they learn how to install Twitter in our brains that is, and thankfully that seems to be a long way off yet.

So what’s the solution? DevRel, of course. This is something that Zach highlights so well for us in this episode. Meetups, conferences and social media have changed the game for developers in all fields, creating opportunities and connections that wouldn't have resulted otherwise.

Zach speaks about his start in the electronics industry, and the work he saw between the people creating software and the people creating the physical devices they exist in. From there, he moved into consultancy, where his work now focuses on making sure that software and hardware developers are working with materials and code of high quality and compatibility.

He speaks about the pipeline from an idea to a manufactured product. According to Zach, when it comes to vendors, it’s in their interest to work with developers who want to innovate - as they have the chance to integrate their products into pieces of hardware that may prove to be exactly what the market is looking for.

Lastly, he talks about content - Twitch, Youtube and even Webinars. Whichever avenue you choose to prioritise is perhaps not so important as consistency. Building a following that likes what you do, and being reliable in uploading the kinds of things they want to see from you matters more than the specific medium you deliver it through. 

It’s all about connecting in this episode, whether that be with developers, customers, or your wider audience.

See Show Transcripts

Interview Intro

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

Today we take a look at the hardware world, which as it turns out also relies on developer relations to sell stuff. In fact, hardware engineers may have even more power than us software people do. My guest is Zach Peterson, an electronics design consultant and conference speaker. He also runs a highly successful YouTube channel for one of his clients, Altium. 

We talk about the strategy of developer first and how to use that to build top of your funnel. We talk about how developer experience is just as important in hardware as it is in software. So, you’re going to find this interview an interesting, different perspective on the world of developer relations. 

Let's talk to Zach. [0:00:57] 

Main Interview

Zach Peterson

Richard Rodger:  [0:00:58] Hey, Zach, welcome to the Fireside with Voxgig Podcast. You are an unusual guest for us because you are a hardware guy. So, please just tell us what do you do? [0:01:10] 

Zach Peterson:  [0:01:11] Yes, I am a hardware guy. We say hardware is hard- [0:01:14] 

Richard Rodger:  [0:01:15] It is. 

Zach Peterson:  -[0:01:15] but that doesn’t mean software is easy. [0:01:17] 

Richard Rodger:  [0:01:18] And it isn’t. 

Zach Peterson:  [0:01:21] Yeah. So, I’m a hardware guy. I think one time when I was younger, I had it in my head that being a software person would be pretty cool. I first did any kind of programming when I was 10 years old; I was in third grade. Maybe I was a little bit younger than 10. But anyways, that’s when I was first introduced to QBasic, doing foreign while loops, teaching the computer how to count. So, that was pretty cool. 

And then later, when I was in high school, learned C, C++. And then eventually wanted to do a degree in physics when I was in college. So, I did my degree in physics and that’s where I started to get into things like materials and semiconductors. I did my PhD research on a topic called random lasers and had to do some scripting in a mathematical program for that. That brought me back to hardware – or not hardware, sorry – but software development concepts. In order to create programs that can take your data, analyze it, fit it to a model, give you some insights as to what’s going on in your experiments. 

And then after doing that, I went aimlessly for a couple of years and then eventually got into the electronics industry. And the electronics industry’s interesting, because you do have these intersections between software developers and people who build physical devices. And anybody who’s ever opened up a computer knows that the software has to exist somewhere. It exists on electronics and it exists in these devices that folks like myself build. 

What most people aren’t familiar with is how you get that code to live somewhere in a device, including a very small device that doesn’t look anything like a computer. And yet it does a lot of that same stuff that you would expect a computer to do. I got started doing some small projects, really consultative stuff, and then eventually, it grew in size and scope of projects. 

And then I started working with Altium and some other companies in the electronics industry directly. So, most people know me from working with Altium. We do technical content generation for them, strategy, research, helping with R&D, providing a lot of that top of funnel type of technical content that engineers really need to stay sharp and to understand using the tool. But more application driven, it’s not like feature tutorials. 

Hardware developers are always learning; they always have something new that they have to learn, some new challenge that they have to overcome. And that’s pretty similar with software developers. Software developers are very talented people and unfortunately, you guys have gotten most of the talent over the last 20 years. And so, we’ve had a real talent crunch in the electronics industry. And that’s why they were so willing to bring someone like myself in the fold to do a lot of the stuff that we get to do. [0:04:34]

Richard Rodger:  [0:04:35] Developer relations for you is reaching out to a guy or girl with a soldering iron in their hand and an Arduino IE or something on the other side. And they’re trying to get the two things to work together, but some piece of hardware that has been supplied to them by a vendor and they’re trying to figure out how to integrate it. Would that be fair? [0:05:02] 

Zach Peterson:  [0:05:04] I would go further than that. It’s more, they’re trying to build the custom board that might one day replace the Arduino. They’re developing something custom, and a lot of times there is code that lives on that device in the field. And sometimes that code gets updated over the air; sometimes you have to release a new version of that product, and that includes a new version of code. 

And so, we’re giving the developers the tools that they need to ensure that the boards they build work and that the code that they put onto it works properly. Because without a properly designed board, the code is meaningless. The code will execute in the processor, but those signals can’t travel around the board and interact with other components; it’s pointless. So, for me, developer relations is making sure that piece of hardware functions as a designer intended it to. And there’s a lot of effort that goes into that, both on the manufacturing side; we focus more on the design side. [0:06:13] 

Richard Rodger:  [0:06:16] The tooling that you provide is – you’re doing the same type of stuff that we do in software as a service developer relations, where you’re doing the tutorials and the documentation and you’re worrying about developer experience. I gotta say, having been a little bit of a tourist on the hardware side of things, I ran into a wall where you get these spec sheets for a component and they’re incomprehensible or they have little graphs. 

They have little graphs of voltage responses or whatever. Or I’ve tried so many times to understand how to use 555 timer shifts and I still – maybe my brain doesn’t work that way; I don’t know. Is that the level we’re talking about, or is it – do you have to bring all these pieces together? [0:07:05] 

Zach Peterson:  [0:07:06] Yeah, that’s part of it. It – yes, there is stuff that you have to do at the system level to educate people and bring all the pieces together like you’re saying. Where are the points of failure in that system that you’re designing, in terms of can the circuit you’re designing even work? Or will this chip function properly as it’s specced in data sheet? Those are important points that you have to consider. 

So, we focus a lot on what can the hardware developer do to, number one, understand the components that they’re working with and number two, build the boards so that the components function properly. The other thing that happens a lot in a lot of companies is, sometimes the electronics developers live in this silo, and they throw the finished design off to the firmware guys. 

The firmware guys need to know where the signals are coming in so that they can specify that in the code that they’re building. And then they’re working on their own to develop all the logic that happens underneath, so that whatever processing needs to be done can get done. And eventually, they all come back together; they have a finished application. And then that application gets flashed onto the device and now it’s time to start testing it. 

But it’s something that – interesting that happens is, the firmware people, smart as they are, are not necessarily versed in all the deep aspects of hardware. And then the hardware people, smart as they are, are not always software or firmware developers, so they have to learn to work together. [0:08:40] 

Richard Rodger:  [0:08:43] And do you think that – we’ve seen in the last five years the emergence of developer relations in more traditional software as a valid activity, and as something you have to do, especially if you want to have an API and SDKs, that sort of stuff. Is something similar happening on the hardware end of things? Where does your industry sit in that change? [0:09:09] 

Zach Peterson:  [0:09:11] That’s definitely something that is becoming more prominent. One thing that I’ve noticed recently, especially with clients that come into my design firm, is that a lot of them come from the software world. And they have a great idea for an application or they’ve been able to prove out some kind of application that needs to run on hardware. But they can’t just throw a laptop out in the field. They need to have a custom piece of hardware in order to get this system to do what they need it to do. And they have no idea where to start; I mean no idea where to start. 

We help them get started on the board side of it, as well as things like component selection, understanding what to expect when they’re getting ready to take this piece of hardware into manufacturing. And then how they can automate some of those manufacturing aspects specifically with regard to getting their code, getting that application onto that end device. And so, we help them coordinate all of that. And the manufacturing side is this whole other can of worms that probably save for a different episode. 

But in terms of developer relations and then helping the embedded folks in these projects be successful, the semiconductor vendors have done a lot of great work over the last few years, trying to get things like reference designs out there for the community, getting libraries out there that folks are going to need, getting design examples that can help get people up and running quickly and really illustrate a real application. 

So, the semiconductor vendors have done a lot of work and it requires investment on their part. They have to create all this material; they have to make it public. They have to be there to answer questions, provide customer support, things like this, all those typical functions you would expect them to do. But for them, it is a relay big driver of component choice, so it can be a big driver of revenue. 

If you’re a semiconductor company, it is in your best interest to create these application examples, especially for cutting edge areas like, we work in embedded AI and then radar. So, it’s in the company’s best interest to create these examples and get them out there for people so that they can get to a point where they’re ready to scale and do a new product quickly. 

And once a design is locked in on that particular set of tools – so in both the libraries and the underlying code and then also the board design around those components – they’re going to be a customer for a long time. It’s really difficult to switch once you get a design locked in like that. [0:12:01] 

Richard Rodger:  [0:12:02] I have a – yeah. 

Zach Peterson:  [0:12:02] So, when I say a design is locked in, I’ll give you an example. One of the things I’ve done recently is working with a sensor fusion company. They do millimeter wave sensing with some other sensors; I’m being intentionally vague because I don’t want to reveal IP. But they fuse all these sensing measurements together to do, and then they use AI on the device to infer some things about the world around them. 

And the chips that we’re getting from the semiconductor vendor, you can’t just swap that out and go to the next vendor and put a different one in; it doesn’t work like that. It might work like that in 20 years, but right now it doesn’t work like that, and it’s not going to work like that for a long time, for this particular type of product. So, it’s in the semiconductor vendor’s interests to get all of those resources out there for the developer. Not just the code but also the hardware resources, so that they can build a product and scale it. [0:13:04] 

Richard Rodger:  [0:13:04] Okay, so this is – this touches on something, Zach, that I wanted to ask you about. Because one of the things that you need to think about in the non-hardware space is whether your sales are developer enabled versus developer first. This is a little bit of terminology that has started to emerge. 

Where developer enabled means that you’re still doing traditional sales, but you might have a senior technical person who signs off or is influential. Versus developer first, where it’s the developer that goes to their boss and says, “Yeah, we gotta use this thing.” So, it sounds like the hardware industry is a lot more developer first than I would have thought. [0:13:53]

Zach Peterson:  [0:13:55] it is, yeah; that is true. Now when you’re doing prototypes, yeah, absolutely, developer first. The developer is going to be the one that has a major influence on component choices. And if the developer is a hardware developer meaning they’re building the circuit board and selecting the components, they’re going to have a major influence on those components that are selected. 

When we’re talking about embedded devices, the firmware developer, a person who’s writing the application in the code, they’re also going to have a big influence. Because they’re going to be the ones that have to make sure that they can implement the logic that they need to implement. 

So, the two have to come together and decide what chipsets they’re going to use, and then they build around that, and that’s how you get to a new product. In larger organizations – we’re talking about OEMs – the supply chain people may push back on some of that sometimes. But at the end of the day, it’s going to be the developers that have the final word. So yeah, developer first for sure. [0:15:02] 

Richard Rodger:  [0:15:03] Okay, and this drives all of the investment by the semiconductor people in the developer experience. And has that- [0:15:11] 

Zach Peterson:  [0:15:11] I think that’s a fair statement, yeah. 

Richard Rodger:  [0:15:13] Yeah. But is that recent or has that – has it been that way for a while? [0:15:17] 

Zach Peterson:  [0:15:17] It has been that way for a while for certain products and for certain application areas that are really high value to those companies. One great example, which is another area I’ve worked in recently, is in data center, specifically like networking equipment for the data center. 

There’s one vendor that has a chipset spanning back, I think 20 years. And that chipset has been incredibly successful. They were enabling people with application nodes and application examples and reference designs, reference – physical reference products you could purchase, software applications for management. They were enabling all of that years ago. 

The industry, or at least the companies in the industry that have the marketing budgets for it, they’ve seen how successful that is and they’ve broadened out the resources that they have available to developers, so that they’re free for anyone to access.  And it’s not just like you have to commit to purchasing X number per month. 

And then you have to sign an NDA and then you have to engage with our application engineering team, and then we send you this stuff. By making it public, they’re showing, number one, that you can use our semiconductor products for all these advanced embedded areas, like AI, like ADAS in automotive, like radar – the list goes on and on. And then they’re making it easy to jump in and get started. [0:16:50]

Richard Rodger:  [0:16:52] One-

Zach Peterson:  [0:16:52] So, it increases that – sorry, it decreases that time to scaling and then making large purchases. [0:16:59] 

Richard Rodger:  [0:16:59] And if somebody – if a company came to me and said, “Okay, I want to set up a developer relations activity and I’ve got an API and I’ve got SDKs, I’d be coming to them- [0:17:09] 

Zach Peterson:  [0:17:09] Yeah, they got all of that going on with the resources that they provide. [0:17:13] 

Richard Rodger:  [0:17:15] I’d be saying, “Okay, let’s take a look at your organization’s GitHub profile and how are you looking after your communities, that type of stuff. But GitHub.com is quite central to the whole activity, because that’s where the code lives. Is GitHub.com the place for hardware as well or are there other places? I’m just trying to think in my head, if I want to show circuit design or hardware design. And I’m trying to think of the analog to show you the code. Where do I go to get that? Is it GitHub? Is it somewhere else? [0:17:53]

Zach Peterson:  [0:17:55] For some things it is GitHub, yeah. For the actual – for the design files for an example circuit board, which is what we call a reference design, you’ll typically get that from the company website. Sometimes it’s behind a login wall, so they want to know who’s accessing it. 

Sometimes you have to fill out a questionnaire. I work in industry X and this is my seniority level, that kind of thing. But if it exists, they will generally give it to you. And then if there is code that goes along with it, it’s typically on GitHub. If it’s not on the manufacturer website, it’s just on GitHub and anybody can access it. [0:18:32] 

Richard Rodger:  [0:18:33] Gotcha, okay. I know there’s generally accepted applications that you would load circuit diagrams into? Sorry, these are super basic questions, but I’m interested in what the developer experience is like. [0:18:45] 

Zach Peterson:  [0:18:47] Yeah, and you just asked a great question, which is something I’ve been harping EDA folks on for years, literally for years. So yes, there are specialized applications that you use for circuit boards. Circuit board design software is a billion-dollar industry. There are three really big players; Altium is one of them. And their applications are really specialized versions of AutoCAD. It’s the best way I could describe it. It’s like an AutoCAD but very specific to circuit boards. 

And the way these platforms work is, they are CAD tools and they eventually spit out files that you use to manufacture the products. Now obviously, we’ve been talking about software development and firmware development, and unfortunately, they don’t have any support for those kinds of activities built into them. The closest they come is with FPGA support. FPGAs are a very specific type of processor. 

Not all embedded devices that have to run firmware or software are going to use an FPGA. If they have any kind of FPGA support, it’s usually really limited. What you’re usually doing is, you’re using the vendor IDE and you’re hoping that the vendor IDE contains design examples or contains the tools you need to develop all that code quickly and then get it onto your piece of hardware. 

But I’ve been complaining to the EDA guys: “You guys need to have an IDE or something,” some sort of connector, built into circuit board software, so that it’s very easy to call out what the developers need to do inside the circuit board software. And Altium is actually doing something kind of like that.  It wasn’t originally focused on embedded development, but they have an online platform called Altium 365, and it basically- [0:20:51] 

Richard Rodger:  [0:20:52] Interesting, okay. 

Zach Peterson:  [0:20:53] Yeah. It includes a version control system; it includes a file system where you can store all sorts of different files including code. You can attach all this documentation to your product and put it into a shared workspace, and then anybody else can access it. We’re inching towards that case where you have a more integrated environment that exists between the hardware people and the software developers. [0:21:20] 

Richard Rodger:  [0:21:21] And it’s a natural direction to go in, and you can see it happening in ordinary, pure software development as well. Just for- [0:21:28] 

Zach Peterson:  [0:21:29] The – you say it’s a natural development, or a natural direction to go in. That’s existed for the circuit board and for the mechanical engineers for quite a while. [0:21:38] 

Richard Rodger:  [0:21:38] Yeah. And for our completely cloud native developers, what does EDA stand for? [0:21:45] 

Zach Peterson:  [0:21:47] EDA stands for electronics design automation. [0:21:49] 

Richard Rodger:  [0:21:50] Electronics design automation. Which is the sphere of activity that you’re focused on. [0:21:55] 

Zach Peterson:  [0:21:57] Exactly, yeah. 

Richard Rodger:  [0:21:57] The other cool thing that you do – this is for one of your clients, Altium – is run a YouTube channel. So, this is – this’d be a shared activity, and it speaks to all the stuff we’re talking about. You’re helping with all this education; you’re interviewing key people in the industry. 

But this is a shared activity that a lot of people in developer relations end up having to do, which is, a client comes to you – a new client, let’s say – and they’re like, “We like the YouTube channel. It’s kind of cool. Please set one up for us. Make it happen.” Run me through – if that’s – if I have a client that asked me to do that, where do I start? What do I do? [0:22:46] 

Zach Peterson:  [0:22:48] Yeah, that’s a great question. Let’s think about all the stuff that has to go into running a YouTube channel specifically for technical content. It’s one thing to do cat videos on YouTube; it’s a whole other thing to teach people to code or build pieces of hardware on YouTube. It’s a whole other beast. 

In terms of what you need to do, first thing you need to do is, you need to figure out a format and the format generally being instructional for this type of content, the instructional is tried and true and proven. Where it’s either someone on camera or someone doing voiceovers, both types of channels can be successful, but you need a format. 

And then you need to figure out what it is you’re going to talk about. And specifically, when I say what it is you’re going to talk about, are you going to be talking about subsets of different types of – like in my case, circuit board designs? Are you going to be talking about, for example, simulation? Maybe for the cloud guys, are you just going to be talking about one language? Are you going to be talking about multiple languages? You can figure out how narrow you’re going to be. 

And then you also need to have a videographer, someone that really understands the deep guts of YouTube. When I say the guts of YouTube, I mean how does YouTube Search work? How does YouTube SEO work? How does YouTube – now they have shorts, which is a really cool feature on YouTube. And I’ll spend hours just looking at shorts, so it’s a good time waster. But how do you take advantage of those new features? 

Video is going to be moving really quickly over the next 5-10 years I would say, to probably end up being the dominant form of information retrieval over Google search and then reading stuff. So, there’s going to be new ways that it’s served and it’s up to you to learn how to take advantage of that and how to get your stuff prioritized within those algorithms. Because they’re all recommender algorithms, and so, you have to figure out how that works and stay up to date? Yeah, it’s hard for one person- [0:24:59] 

Richard Rodger:  [0:24:58] Is that – are you that guy? 

Zach Peterson:  [0:25:00] to do everything. 

Richard Rodger:  [0:25:01] Are you that guy or do you-

Zach Peterson:  [0:25:02] I am not the videographer, no. I have someone who works for me – hey, Joel. He’s awesome; he knows the guts of all this stuff way better than I do. I can come up with- [0:25:16] 

Richard Rodger:  [0:25:16] So, that is a specific skillset. [0:25:17] 

Zach Peterson:  [0:25:17] -cool topics and stuff. 

Richard Rodger:  [0:25:19] That’s a specific skillset that you need. 

Zach Peterson:  [0:25:20] Yeah. I can come up with cool – absolutely, yeah. And I can come up with cool topics and stuff that the audience is going to care about from topic level. But as far as how you film it and present it and what the platform is going to care about and prioritize, that’s a whole other issue. 

This applies to any company that’s also doing developer relations and wants to get that knowledge out there for developers, and this is happening in the semiconductor industry. Texas Instruments is the leader in this area in my opinion. They’ve been producing their TI Precision Labs series for quite a while, and it’s great educational content. 

They’re not doing a YouTube first strategy for it; a lot of that is on their website. But it goes back to the point. They’re doing a video; they have a video strategy built into their customer education efforts, and so that’s really important for whether your hardware or software developer relations. [0:26:18] 

Richard Rodger:  [0:26:20] Yeah, okay, that’s interesting, so go check out Altium, which is the stuff that you do, which I was – I found super impressive. And Texas Instruments- [0:26:27]

Zach Peterson:  [0:26:27] Thank you. 

Richard Rodger:  [0:26:29] -as well. And Texas – okay. Yeah, because it’s- [0:26:31] 

Zach Peterson:  [0:26:33] Anyone that’s interested in this, take a look at TI Precision Labs. [0:26:35]

Richard Rodger:  [0:26:38] That’s a really good source of reference for a quality level to reach for executing on this stuff. And the videography thing- [0:26:48]

Zach Peterson:  [0:26:48] For sure. 

Richard Rodger:  [0:26:48] -thing is really interesting. Because a lot of people think you can just do a YouTube; you can just do it. [0:26:56] 

Zach Peterson:  [0:26:57] Yeah. And there are people who can; those folks exist. And they were probably some of the earliest YouTubers.  They were people who had – they had a background in film plus something else that they cared about or found interesting. And then that’s how they created their content and channel and really grew it. I am not a film person; I can press record on my phone and that’s the extent on my film knowledge. Even having a background- [0:27:31] 

Richard Rodger:  [0:27:31] And it’s more – and it’s – yeah. And it’s more than you said; it’s understanding the SEO around it hand have a search. The flavor of this year’s search algorithm works, all that stuff. [0:27:40] 

Zach Peterson:  [0:27:42] Yeah, absolutely. Understanding how to read through the analytics and realize what’s important for you, that’s also important, because it helps you prioritize and direct your efforts towards things that are meaningful, and going to give you the best results. Because you want people to watch this stuff. [0:27:59] 

Richard Rodger:  [0:28:00] Sure. Now there’s one other aspect of this that I haven’t seen done; I’d like your take on this one. There is a trend in the pure software end of things to use platforms like Twitch to do live coding, where people, they show you how to use an API or whatever. And it’s live and recorded and then you’ve got content you can reuse or post or whatever. Does the equivalent exist for hardware? Is it literally somebody with a soldering iron? Would it work? [0:28:32] 

Zach Peterson:  [0:28:33] I have seen a few of those. I will say it’s not common; it’s certainly not as common as Call of Duty on Twitch. It’s – I’ve seen those, those live broadcasts; they’re interesting. More often, what is happening is things like webinars, and maybe those webinars do have a live demo component, but they always end up being very corporate-y. And it’s less – I don’t want to say it’s less accessible; it’s just that it’s less about having fun and interacting and it’s more about, I’m going to show you this feature in the newest version of our products. 

So, it gets a little corporate-y. But people learn how that feature works; there’s your opportunity. You’re going to get a live demo and you can even ask a question, so it has its tradeoffs. But more often, you do see the live webinars, sometimes with a demo, and you can at least get some questions out there to an expert. [0:29:41] 

Richard Rodger:  [0:29:42] Okay. The final question I have for you – and this has all been super interesting. It’s a world I was only vaguely aware of. But it’s great to hear it’s developer first as well; I really like that. The question I have is around community building, because we get… 

A lot of cloud software for example is very open-source driven; comes from open-source origins. So, there’s a natural community effect to it. The engineers that work in it are always looking for communities; it’s a very natural thing that happens. Does it work the same way in your industry or is that something that your industry could do more of? [0:30:27]

Zach Peterson:  [0:30:31] Yes, it’s just that I would agree that it’s maybe hard to find those communities, but they exist. Your – the YouTube channels that you watch can become a community. It’s a little one way, but that can become your community. EEs are vibrant on LinkedIn. You have people who have created groups that have a lot of people in them and you get people posting and talking to each other. There are also folks like myself that are active on LinkedIn; post a lot of stuff. And there can be some lively conversations that arise in the comments section. 

So, the same kind of community building and interactions between people in the trenches, that does happen in the hardware world as well. It’s natural for people who are curious and who do things that are really technical. And they’re always seeking knowledge, and even at some level, they want to show off some knowledge sometimes. [0:31:36] 

Richard Rodger:  [0:31:36] Yeah. We’re just nerds, aren’t we? We’re just nerds. [0:31:38] 

Zach Peterson:  [0:31:39] Of course, nothing wrong with that. So that gives them an opportunity to do that. [0:31:43] 

Richard Rodger:  [0:31:45] Is it valued by the companies? [0:31:46] 

Zach Peterson:  [0:31:48] Yes, 100%. 

Richard Rodger:  [0:31:50] So, the company supports that. 

Zach Peterson:  [0:31:52] Yeah, because at the end of the day, it’s giving – it’s getting more people into the funnel, even if it’s slow drip; still getting more people into the funnel. It’s growing whatever channel you’re using, so if you’re talking about a YouTube channel, it’s growing the YouTube channel. And eventually, that will reach the people who are the buyers, even if the initial people making contact through a community outlet like LinkedIn aren’t buyers. 

Companies want folks to follow their LinkedIn pages, so they’re going to post whatever resources they can to get that out there, to get more people following; you definitely should do it. And companies want people getting into their newsletter feeds as well, getting into the newsletter feed; you can market it to them. 

So, companies do care about this, and what we’ve stressed and Altium has stressed is to have an integrated strategy. If you create a video, make sure it aligns with a blog. Put the two together and put it out there on social media, and then get it into the newsletter. And now you’ve got an integrated approach to using all of that stuff that you’re creating. So, you can get the most ROI ion it. And then all that stuff needs to be searchable, because you want people to come in from Google Search or YouTube Search or whatever, so that way you get the most exposure for it. [0:33:15] 

Richard Rodger:  [0:33:16] And it’s not that easy. It’s – having done that myself, to have an integrated content strategy. [0:33:21] 

Zach Peterson:  [0:33:22] It’s tough, yeah. 

Richard Rodger:  [0:33:22] Takes a lot of effort. [0:33:24] 

Zach Peterson:  [0:33:25] It requires multiple people for sure, and multiple skilled people who can specialize in different areas. [0:33:32] 

Richard Rodger:  [0:33:33]  And can herd all the cats into one place. [0:33:35] 

Zach Peterson:  [0:33:36] Exactly. 

Richard Rodger:  [0:33:38] Zach, thank you so much, this has been super interesting. It’s a real treat to get a little bit of an insight into an adjacent industry. But it’s great to hear that community and developers and all that sort of stuff is just as valued; it’s awesome. [0:33:54] 

Zach Peterson:  [0:33:55] Absolutely. Thank you very much for having me. [0:33:56] 

Richard Rodger:  [0:33:56] Yeah, fantastic. Thank you so much. [0:33:58] 

Endnote

Richard Rodger:  [0:33:59] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0.34.28]