The CTO Show

Okay, welcome to The CTO Show. I am John Graham-Cumming, Cloudflare's CTO, and with me today I have got Josh Butts, who is CTO of Zipf Media Group. Hi, Josh. Hey, John, how you doing? I'm doing very well, thank you. And, you know, it's great to to chat with you. I've talked to quite a few CTOs of different styles of company, but I think Zipf is interesting because it's got quite a portfolio of companies and products in there. Do you want to perhaps just tell us a little bit about Zipf? I bet the name is familiar to a lot of people, but they don't actually know all the things it entails. Yeah, it's a little bit of everything. So Zipf Media Group is a part of Zipf Davis, which is a name that is, you know, an old school publisher that a lot of people have heard of and probably put out a lot of magazines in the past that people were very fond of, especially in the tech space. And Zipf Davis is part of J2 Global, which is our publicly traded parent, which has media services like us and also a bunch of digital facts, cloud services for small business, and kind of a whole other part of the business. So Zipf Media Group is a part of a part of a part, but it's a big part of the company. We do both a bunch of online shopping and e -commerce products in a lot of coupons and deal space. So we have RetailMeNot, we have Offers.com, TechBargains, and then a bunch of platform enablement stuff to power that kind of affiliate commerce. And then we also have a whole other part of it, which is our tech publishing. So we own Mashable. We run that one. We have PCMag, which is a fantastic print brand that is also now a fantastic digital brand with a lot of great history behind it. And those are our big ones. We also, I kind of forgot to mention on the shopping site, we're big in Black Friday. We had a bunch of Black Friday sites, our flagship being BlackFriday.com. So that's another interesting part of the shopping business that means I never get a day off around Thanksgiving. I can imagine that. I can imagine that. So, okay. So how big is your team if you're dealing with this many different properties? So we've got across all of them, I've got something like 150 or 160 people that roll into me. And so my role at Zipf Media Group encompasses product design and engineering. I'm a software engineer by trade. That's what my passion is. And I, through some really great mentorship early on in my career, I kind of became a product enthusiast as well. And so I've got over a hundred engineers distributed across those different brands, and then product teams distributed across them and design teams. So it's kind of like three-legged stool within our product development organization overall. Now, one of the reasons to do this show is because the title CTO means so many different things in different companies. And you're the first person who's talked to me about, specifically about the product management kind of side of things. Tell me a little bit about that. How did you get yourself and your career into the sort of product side of it? And what does it look like within Zipf? Yeah. So I started out as an individual contributor software engineer, but it was a small company. So I came to this media powerhouse through when we sold offers.com to Zipf Davis. That's how I came to the company. And I was effectively employee number one at offers.com, which is in that ecosystem, everybody wears a hundred hats and everybody in a small web startup, everybody's on the product team. That's how you get stuff done. And so I had that kind of like baked into my DNA early on when I was like, I don't know, 22. It was, yeah, you want to build software, but why? And for who? And how should it work? And you need to care about that. And you need to care about how much money it makes and how business works. That is the reason why we do this in the first place. And so that was kind of like just ingrained in me very early on in my career. And so even though my career has been software, it's always been with that lens of the why. Why are we doing it? And how should it work? Not just tell me what to do. And as we acquired companies into this portfolio and Zipf Media Group and as I was one of those companies that got acquired into Zipf Media Group, we've had a bunch of different configurations of that. We've had product and design as one team and vertical and engineering as another one. And they have kind of a friendly adversarial relationship, which I think is true in a lot of companies. But that really wasn't how we wanted it to work. What I really wanted was for not necessarily me, but for someone to be the person that sat on top of all of that and made it feel like it was one team. Because what we saw was when our teams were working the best, it was when we had a small pod of people of two or three engineers and a designer and a product manager, and they had an idea and they could go execute on that. And we wanted to make sure that the team, the overall org structure kind of enabled more of that to happen. Because when you saw it happen, it was really exciting. And we wanted to make sure that there was a way for that to grow and for us to be able to point it out and say, yeah, do more of that. And so I kind of pitched it. I was like, look, let me have all of this. And let me see if we can get this into one cohesive organization where it's not kind of this throw it over the wall mentality. It really, really annoys me and I want to figure out how we get rid of it. And so that's what we've been doing. We've been doing it for three or four years now. And I think it's working. And I think it's something that we are constantly trying to get better at. And the challenge is as different as we get bigger and we have more people and we acquire other companies into the portfolio. You got to reset that every so often and say, that way we were trying to do that, it doesn't scale anymore. What do we do now? Well, there's a whole new thing we got to figure out. And it's not necessarily the best of both worlds. It's maybe a third option that we haven't even thought of yet, but we really want to stick with that product led mentality, even throughout our technology organization. And what about the operational side of it? Because you have that as well under you. I do. Yeah, we have a really solid, I want to say DevOps and I'm going to get someone's going to Slack me later and tell me that was not the appropriate thing to call it. But that's what people understand it to be in 2021. But really solid operations team that has really focused on building out a platform, almost an internal platform as a service. We want all of the fancy Kubernetes and AWS architecture that's built out, not to exist because it's cool, to exist because it works. And really to be able to push that out so that our engineering teams can go ship what they need to ship without having to have this operational gatekeeping. And it's that same, how you keep this big company to have that entrepreneurial lean mentality. And our operations team is focused on delivering that same thing. How do I enable those little clusters of things to happen without me having to get a deployment engineer to go spin everything up and provision it all? And it slows it down. But yeah, the operations team is fantastic. And they really have embraced that. How do I enable all these other smart people to ship stuff without me having to be the gatekeeper? How do you work out where the dividing line is between something that's built by that team and something that's built by the engineering team? Is there a clear cut of like, okay, this is the platform and this is not the platform? How do you do that? It's pretty blurry, I'll be honest with you. I think we have some documentation and some processes that we're working on that put the lines there. But one of the examples I tell from time to time is that we have all this Docker infrastructure and it's super cool and I love working on it. But the infrastructure team built a way for us to ship these applications, containerized out into this infrastructure. And I, as a person who ships things, I don't care how it works. I just know that it will work because they're good at their job. And we, at one point a few years back, shipped a major programming language version bump. And the operations team didn't even know we were doing it. They just called back and said, hey, what did you guys do? All of your resource usage went down. And I was like, yeah, we knew a better, faster version of the language. And that was great for me. It was that we didn't have to bug them. But normally you would think about, oh, you're shipping a major language version change on infrastructure. You need the operations team involved in that. And because of the way they've designed that to enable those teams, we didn't have to. Should we have told them? Probably. But it's kind of fun not to. Well, especially since the surprise was in a good direction, not in a bad way. That's right. That's right. Usually if they call, it's like, hey, what did you guys do? Yeah. What did you do from haywire? Yeah. Presumably it's taken you a while to get to this AWS Kubernetes cloud transformation. Was that done as one big bang? Or did you do sections of change? To say that it was one big bang is not a fair characterization of it. But we have traditionally been probably too bleeding edge for our own good in some cases. But it's fun to be there. So we were full production Docker everything since maybe like late 2014. Before, it was smart to do that. We were doing it. But the cool thing was that it helped us recruit great people. Because that's what people wanted to work on. They wanted to be on the bleeding edge. And so they would come and work for us because we were doing that. And we weren't afraid of it. But even getting to that, it's taken us years and years of investment, both in education and learning for the teams of, okay, well, you told me we're moving everything to Docker, but I don't know Docker. How do I learn it? But also, we didn't move every app on the same day. We did it piece by piece. And then as we acquired Mashable, for example, when we bought Mashable, they were not in Docker, they are now. We didn't start with Kubernetes. We started with a thing called Mesosphere, which was really, really slick at the time, but Kubernetes won out. And so same thing, it took us a long time to get everything fully moved over to Kubernetes. And it wasn't without growing veins, and some downtime and some outages. But I think I'd rather us be closer to the edge and not having to have infrastructure debt than, well, it's working, so let's not touch it. Sometimes you got to do that, but that's not really the way I like to operate. Let's flip back to the CTO role itself a little bit. So what does your day-to-day look like? I presume you're not writing any code, but you're in there. Oh, man, I wish. I wish. I do from time to time, but I get my hand slapped by my team telling me that I can't mess with that stuff, and I'll slow them down, because I'm going to have to put it down and go to a meeting. But no, no, mostly not. I kind of the best way I can describe kind of the overall strategy of it is I have a bunch of really wicked smart people that work for me. And I can give them a PowerPoint presentation of where I'd like us to be going, and they will all go in that direction. But what I feel like my role is, is they'll all go in that direction in parallel lines. They will line up, and they will march in the direction, and they will be headed towards the place where I want them to go. I feel like my job is to take those parallel lines and have them converge on a point. So I can give direction, and people are fantastic about taking us in the east or west at a very high pace. I want us to get to a specific city, and my job is to watch where all these lines are going and kind of nudge them in the right direction so that we all end up at that point where we're supposed to meet up at down the road. Right. And how do you get the organizational structure to be right to that? Because you've got all these different teams and DevOps and companies you're buying. Like, if you have a particular philosophy about that? No, the philosophy is it can't be static, right? Every time I think I've got the best plan in the world, something changes, and we've got to rethink it. And so it's one of those, you know, the only thing that's constant is change, especially in the way that this company works. And I think a lot of people embrace that, right? It means that there's going to be opportunities for people. It's one of the ways that I can enable career growth is that things change, needs change, roles change, and you're not going to get stuck as much as we do. There's opportunities for you if we buy a company or if we decide to pivot a certain business model that we're going to have to change the org to support that. And that's something that I think is one of the ways we can create those opportunities for our people to keep them around and keep them growing as opposed to having them go somewhere else. And so when you're building those teams, is there a particular sort of person you're looking for when you're recruiting into this kind of work? Or is there, you know, is it very opportunistic in terms of who you come across? I think it depends. There's some targeted roles, right? Like if we're looking for data science roles, right? We're looking for a very specific skill set, technology background. I think kind of on our more general, I'll call them full stack engineering teams, we're looking for smart people who get the business, right? That to me, do you understand how we make money and why you're being asked to do this project? And do you have the soft skills, the people skills, so that I can elevate you, right? You start out as a senior engineer that we hire you and, you know, you want to get promoted to be an engineering manager or a principal engineer, however you want to go down that track, right? I look for the people who I know I could send to a meeting without anybody else. And like, they're going to represent the technology needs of the team. And they're going to be a good partner for our business stakeholders. They're going to be able to explain why something's hard to someone who doesn't understand the technology side of it. That's the kind of stuff that I think is the multiplier. And I think the other thing is, I, we can't always do it, but I really like my management to be player coaches. It's not always possible, it doesn't always make sense, but where we can, I like that to be the case. And so we do kind of look for places where we can continue to do that. Let's talk about the last 18 months or so with the pandemic, what had to change in terms of the way in which you were running or managing your team? Man, you know, we, like a lot of other people, I think we, I don't remember when it was, but sometime in March of 2020, we had a practice work from home day. It's like a Friday where it was, everybody must work from home just to make sure that you can, and that you don't have VPN problems or whatever. We never came back. That was a Friday and we didn't go back. I think the thing that I had very much the same experience. There was a Tuesday where I said to my assistant, I'm not sure what's going to go going on. I'm going to go home, see my wife. There's all this stuff going on. I'll see you tomorrow. I didn't come back. That was it. It was, that was the end of that for months. So we had, I think, a unique advantage over, you know, Ziff Davis and Ziff Media Group had traditionally been an in-office culture. It was always flexible, right? There was never a, oh, I need to work from home today because X, fine, who cares? You're good. We don't, there's no problem. But the culture was an office culture. And the thing that I think we had to leg up on was because we were not necessarily a distributed company, but we were a company with lots of offices. We had all of the infrastructure in place already to, you know, we were already daily users of Google Meet to do video calls between offices. The difference was, is instead of it being a conference room in Austin and a conference room in New York, it was, you know, obviously everybody's house, but a lot of the culture of you're going to be managing somebody who's not in the same city as you, and they may not, you may not see them in person for months on end. And you're going to be working with key stakeholders on this project who are in different departments in a different city. We already had that. So a lot of the mechanics were not a problem. Like I think they probably were for other companies and all of the access and remote access, right? We had that kind of already in place. And so I remember getting the phone call, like, what do we need? What problems are we going to have? And I was like, we're going to be good, right? The things on your list are not going to be a problem. There's going to be stuff that nobody anticipated that are going to be problems. And it turns out that like, you know, all day, you know, meetings all day from, you know, 10 different groups, half an hour at a time in person is not nearly as exhausting as doing a video. And, you know, so I think that's that's where the stuff nobody anticipated is that kind of fatigue. But we've been, we've been extremely productive with it. And I, you know, I don't think we're ever going to go back to the way we were. But I think the one thing that we've benefited from is now everybody has that not everybody's going to be sitting next to you, communication style. And so if nothing else, we're going to benefit from that, even when we do go back to our offices. So I totally agree with you. I feel like this is one of the things that changed enormously, which was that when you were in the office, there was this sort of, you could just ask someone and have a quick chat with them. And people got used, there was sort of got used to doing that. And now, with everybody being remote, it was more async. And I know for us, also, it was more of a level playing field. There were two executives at Cloudflare who were remote from San Francisco at the beginning of the pandemic. And we always start dialing into meetings with all the other executives and loads of other people in the organization had the same experience. Now, everyone is a square on the zoom screen. So it's just that that has actually been helpful in a way. Yeah. And I think I don't want to discount the value in that chance conversation that happens, because you happen to overhear someone as you're walking by and like, oh, that's a good idea. Let me tell you what you might want to know about that. That's extremely valuable, but it doesn't scale. And as you get to be a bigger and bigger organization, even if you imagine where you now have seven floors of office space, the person on the first floor might as well be in a different city as the person on the seventh floor. Yeah. Yeah. Yeah. Let's go back to the CTO role. How did you end up with that title? Was that something that you always wanted to be CTO? Or why is it that title and not VP of Engineering? Tell me a little bit about that, because I'm still trying to dig into this idea of what the hell the CTOs do. Uh -huh. Yeah, me too. If you figure it out, let me know. So I was the VP of Engineering for a long time. And I've been the CTO in title for not that long. But in practice, when I got that title, my job didn't really change much. I just had a bunch more people reporting to me doing the same stuff. It wasn't something I was after, necessarily. There's a point where you kind of look at it and say, do you really want the big chair? Or is the second one actually the better job? And I'm a hand raiser, right? Somebody says, hey, does somebody want to do this? I'm going to raise my hand and say, I'll do it. And I probably overcommit as a result of that. But yeah, at some point, and maybe it's been three or four years ago, somebody said, why aren't you doing this? And I said, I don't know. I never thought about it. And then I couldn't stop thinking about it after that. And it was actually, I think, may have been the CTO of J2, asked a question, why aren't you doing this? You should be the one. And I said, well, I never really thought about it. And then I was like, well, I should be the one. I'm going to do that. And really, for me, it was, how much more is there in being just an engineering leader? I love doing that. Love it. And some days, I think I'd rather do that, depending on what's going on. But what's the difference? What's the difference between VP of engineering or SVP of engineering and CTO from your perspective? So the way I viewed it was that as a VP of engineering, I was kind of the final shot caller on a technical decision that nobody else could come down to the answer there was a disagreement on. And it was career growth for teams and programming. Not that kind of programming, but we should do hackathons, and we should have a program, and we should have interns, and how do I build and grow the engineering team? And so I viewed it as we should, as much of a people thing as a technical thing. And to me, the CTO role is much more about where are we going, right? I have a VP of engineering. He's wonderful. He does that stuff that I just listed better than I ever did it. But I try to focus my time on what's in front of us, not what are we doing right now. As much as I can, right? There's always the right now comes calling, and you gotta put a fire out. But to me, it's the vision and strategy of how do I take this giant portfolio of really cool brands, what do we do with them? And since product is a huge part of my day to day now, how do I make them more than the sum of their parts, right? Like that's for me my company, that's part of what my role is, is figuring out how do I not just make it Zip Media Group is the collection of these things, but it's that and more because they're put together. Is there a part of your role which is, like in my role, part of my role is outbound, it's like conferences, speaking to customers, stuff like that. How much is that important in your role in CTM? Not much. It would be cool to do that. I actually used to do a lot more public stuff when I was a director, a senior director, a VP of engineering. I used to travel all over the world speaking at tech conferences. And it was really fun. And somewhere, it was the travel that killed that for me, because I started traveling more for work work and less for fun work. And so I just didn't want to be away that much. But yeah, it's not a huge part of my role. And I think a lot of that is because we have two kinds of customers, which is we're serving two masters all the time. We have the people who consume our content, which is by and free for them to consume. And we have the advertisers and the business partners who help us monetize that content. That's another kind of customer. I don't really have the opportunity to speak to the anonymous customer out on the Internet. I just have to hope we build good products when they come back. And if they keep coming back, I know we're doing a good job. And occasionally, I work with our business customers. But that's not really the core of my role, unless it is a technical thing, which does happen from time to time if there's a, I need to go jump on a sales call because I need to convince them we can do this or something like that. But it doesn't happen often. All right. Listen, as we get into the last few minutes of this, let's flip back to programming. Is there something at work that you would really like to code if you had time? So my pet project that no one else is allowed to touch, I say pull requests are welcome, but I don't really mean it. We have a tool called Drydock, which is ephemeral environments is the word that I think people are using for this, which is the concept of you open a pull request on some software. And in our case, it's often a website and a fully provisioned environment to do UAT for that thing comes up. So it's the website with the full production data set. And at the risk of plugging your products, it is tied to Cloudflare and it's got Cloudflare access in front of it so people can access it, but not the public and all of this good stuff happens automatically. And it's tied to the JIRA tickets. So our stakeholders can go look at that thing they asked for and see if that's what they wanted. And they can play with it in isolation with no other changes, just their one little thing. That to me, it was something that I dreamt up a long time ago and asked someone to build on my engineering team. And then when Docker came around, it became way easier to pull that off. And so we kind of iterated on it. And it's one of those things that I can't imagine working without anymore. It's part of our everyday process. And that's the thing that when I have Friday afternoon, I'm like, how do I have no meetings? I'm working on Dridoc because that's my passion project. That sounds like an extremely useful passion project to have that. It is, right? And that's kind of like somehow it became my passion project because somewhere along the line, at some point in my role before I was a CTO, I decided that I wasn't going to be able to code production features anymore. I just, I couldn't do it. And so I was like, well, if I'm going to still want to code, it's going to have to be on developer experience, right? How do I make my teams more productive? And that's where somehow that became my passion. It's a question of leverage, right? Everything you're doing is about making your teams more successful, whether it's like management structure or schedule or finding people, or in this case, some code. So yeah, makes sense. Yeah. It's one of those things where like every now and then I show it to a new developer, they're like, why aren't we selling this? I was like, if we sold it, it wouldn't be as fun anymore because we'd have to support it. And it'd have to have, it's kind of like that you don't make your hobby, your job. I totally agree. I make little IoT device things for the home and my wife's constantly like, you should commercialize this. And I was like, that's the last thing I want to do. I'd have to support it and have a manual and all this kind of stuff. I like tinkering with it, not trying to make it into a product. Well, listen, Josh, thanks so much for being my guest on the CTO show. It's great to talk to another CTO about what it means, because I'm still trying to work out myself quite what the role means. It seems to vary enormously from company to company. And thanks for taking us through Ziff Media and your setup. Absolutely. Totally enjoyed it. And we'll see you around.