Podcasts about heavybit

Joseph Ruscio of Heavybit joins Nick to discuss DeepSeek's Impact on Other LLMs, AI's Effect on Software Engineering, Nvidia's Future, and the Next Wave of Developer-First Companies. In this episode we cover: Impact of AI on Venture Capital and Developer Tools Challenges and Opportunities in Scaling Developer-First Companies Utilizing GitHub and Other Tools for Market Insights Recommendations for Founders and Investors Guest Links: Guest's LinkedIn Company's LinkedIn Company's Website Twitter/X (guest) The host of The Full Ratchet is Nick Moran of New Stack Ventures, a venture capital firm committed to investing in founders outside of the Bay Area. Want to keep up to date with The Full Ratchet? Follow us on social. You can learn more about New Stack Ventures by visiting our LinkedIn and Twitter. Are you a founder looking for your next investor? Visit our free tool VC-Rank and we'll send a list of potential investors right to your inbox!

Produced by Foundersuite (for startups: www.foundersuite.com) and Fundingstack (for VCs: www.fundingstack.com), "How I Raised It" goes behind the scenes with startup founders and investors who have raised capital. This episode is with with Joe Ruscio of Heavybit, a venture capital fund that invests in developer-first startups (many of their portfolio companies make products used by software and technology developers). Learn more at www.heavybit.com. In this episode we talk about what's happening in the software developer tools market, how AI is changing the game, why AI is like having a “weird intern” on your team, how VC is evolving, good and bad reasons to raise capital and more. How I Raised It is produced by Foundersuite, makers of software to raise capital and manage investor relations. Foundersuite's customers have raised over $21 Billion since 2016. If you are a startup, create a free account at www.foundersuite.com. If you are a VC, venture studio or investment banker, check out our new platform, www.fundingstack.com

Enterprises are wrestling with delivering data to fuel their AI efforts, hitting roadblocks around data security and privacy concerns and sifting through use cases and models to put it to work. Too many are making high-stake gambles feeding vast quantities of data into massive models. Jesse Robbins, one of the founders of Chef, a progenitor of the DevOps movement, a builder of the early Internet infrastructure and now partner at Heavybit, joins host Eric Hanselman to look at alternatives to the path that many are taking in pursuit of successful AI projects. In much the same way that DevOps patterns look to shift application development to more smaller, incremental changes with a pipeline that drives continuous improvement, AI projects can work with smaller models and localized datasets to manage risk and iterate faster. It's a pattern that avoids concerns of pushing sensitive data to cloud-based offerings by working locally. Using smaller models reduces infrastructure costs and the need for vast quantities of GPU's. Larger models sizes and data sets create two problems – more computational power and supporting infrastructure is required and more data complicates data provenance, security and ownership issues. Starting smaller and expecting to iterate on the results locally can have multiple benefits. If the data being used never leaves the local confines, security concerns are constrained to local environments. Tools like the open source project Ollama can deliver a choice of models to fit a variety of use cases and infrastructure capacities. Just like DevOps patterns, starting small and iterating quickly can get further faster and with lower risk. More S&P Global Content: Big Picture GenAI report Kubernetes community capitalizes on open source and AI synergies Credits: Host/Author: Eric Hanselman Guests: Jesse Robbins Producer/Editor: Donovan Menard and Odesha Chan Published With Assistance From: Sophie Carr, Feranmi Adeoshun, Kyra Smith Other Resources: The Data Pipeline is the New Secret Sauce Ollama Continue

In this episode, Matt Watson speaks with Joseph Ruscio, a partner at Heavybit, a venture capital firm focused on investing in software development-related companies. They discuss the evolving landscape of venture capital, the unique value niche VC firms provide, and the impact of AI on software development. Joseph shares insights on the challenges developers face, the importance of finding product-market fit, and how AI can enhance developer productivity. They also explore Heavybit's recent investments in AI startups and the future of software development in an AI-driven world. TakeawaysAI is not going to replace developers but will enhance their capabilities.Niche VC firms like Heavybit provide specialized support to early-stage companies.The pressure to integrate AI into products is significant for developers.Finding product-market fit is crucial for startup success.Developers are increasingly seen as the key decision-makers in technology.The cost of software development varies widely across different markets.AI tools can help reduce the toil in software development processes.Investing in specialized AI models is essential for enterprise applications.The landscape of AI investments is rapidly evolving with new startups emerging.Understanding the unique challenges of selling to developers is vital for success. Find Startup Hustle Everywhere:https://gigb.co/l/YEh5 This episode is sponsored by Full Scale:https://fullscale.io/ Find out more about Heavybit here:https://www.heavybit.com Learn more about Joseph Ruscio here:https://www.linkedin.com/in/josephruscio/ Sign up for the Startup Hustle newsletter:https://newsletter.startuphustle.xyz/ Sound Bites"AI is going to make developers more valuable.""The pressure to build AI functionality is real.""Finding product market fit is crucial." Chapters00:00 Introduction to Heavybit and AI in Software Development03:01 The Evolution of Venture Capital and Specialization05:58 The Value of Niche VC Firms09:01 Challenges in Selling to Developers11:48 AI's Impact on Software Development14:46 Investments in AI Companies17:51 The Future of Software Development with AI20:54 The Role of AI in Developer Productivity23:53 Investing in Emerging AI Startups27:08 The Importance of Specialized AI Models30:12 The Landscape of AI Investments33:06 The Economics of Software Development35:54 Conclusion and Future OutlookSee omnystudio.com/listener for privacy information.

Dana Oshiro is a General Partner at Heavybit. Heavybit is a VC that invests exclusively in developer-first startups.What we discuss:One sharp thing. Finding an addressable chunk of a bigger opportunity. Thinking big & smallAre 5 people seriously going to support our migration from DataDog? At Facebook you had a lot of support people/systems you're forgettingFinding the sidedoorStepping up as a founderFear of hitting up the people you respect.Best founders build for themselvesDo founders get better at putting themselves out there?  Speaking in front of people to make change - "there's a new approach. We deserve better!"MovementsDevOps & JamStackDon't try to control the movementJoining into other movementsLinksDana Oshiro https://twitter.com/danaoshiroHeavybit https://heavybit.com/Thanks to Adam DuVander from https://everydeveloper.com/ for introducing us.This episode is sponsored by WorkOS. If you're thinking about selling to enterprise customers, WorkOS can help you add enterprise features like Single Sign On and audit logs.

Avery Pennarun is Co-Founder & CEO of Tailscale, the Wireguard-based VPN that reimagines secure, private networks. Tailscale has raised $115M from investors including Heavybit, Accel, CRV, and Insight. In this episode, we dig into what caused the team to reimagine zero trust security at the networking level, why they focus both on individual developers and large enterprises with a bottoms-up and top-down business model, why they leaned into the VPN comparison, how they create a personal tone for their blog & more!

Dana Oshiro is a general partner at Heavybit, a venture capital fund investing in startups focused on building great developer tools.Dive into topics such as how Dana got into VC, how to open communication with VCs, what to prepare before talking to VCs about raising capital and much more. Hosted by Perry Tiu.Guest links available at: https://perrytiu.com/podcast/natalie-kaminski—Interested being on the show? contact@perrytiu.comSponsorship enquiries: sponsor@perrytiu.comDon't forget to follow the show and leave a review—it's completely free.• Apple Podcasts: https://apple.co/3RASg8x• Spotify: https://spoti.fi/3RBAXEw• Youtube: https://youtube.com/@perrytiuMore Podcast Ruined by a Software Engineer• Website: https://perrytiu.com/podcast• Merch: https://perrytiu.com/shop• RSS Feed: https://perrytiu.com/podcast/rss.xmlFollow Perry Tiu• Twitter: https://twitter.com/perry_tiu• Instagram: https://instagram.com/doctorpoor

In episode 5 of Generationship, Rachel Chalmers shares interviews from Heavybit's 2023 DevGuild: AI Summit on October 19th, 2023. This Open Space unconference brought together a community of 200+ to discuss how AI will change the face of software development. This episode features event highlights and insights from industry experts: Christine Spang of Nylas, Heidi Waterhouse of Sym, Paul Biggar of DarkLang, Raiya Kind of Code and Concept, and Seema Patel of Stifel Venture Banking.

In episode 5 of Generationship, Rachel Chalmers shares interviews from Heavybit's 2023 DevGuild: AI Summit on October 19th, 2023. This Open Space unconference brought together a community of 200+ to discuss how AI will change the face of software development. This episode features event highlights and insights from industry experts: Christine Spang of Nylas, Heidi Waterhouse of Sym, Paul Biggar of DarkLang, Raiya Kind of Code and Concept, and Seema Patel of Stifel Venture Banking.

Michael Isbitski, Director of Cybersecurity Strategy at Sysdig, joins Corey on Screaming in the Cloud to discuss the nuances of an effective cybersecurity strategy. Michael explains that many companies are caught between creating a strategy that's truly secure and one that's merely compliant and within the bounds of cost-effectiveness, and what can be done to help balance the two aims more effectively. Corey and Michael also explore what it means to hire for transferrable skills in the realm of cybersecurity and tech, and Michael reveals that while there's no such thing as a silver-bullet solution for cybersecurity, Sysdig can help bridge many gaps in a company's strategy. About MichaelMike has researched and advised on cybersecurity for over 5 years. He's versed in cloud security, container security, Kubernetes security,  API security, security testing, mobile security, application protection, and secure continuous delivery. He's guided countless organizations globally in their security initiatives and supporting their business.Prior to his research and advisory experience, Mike learned many hard lessons on the front lines of IT with over twenty years of practitioner and leadership experience focused on application security, vulnerability management, enterprise architecture, and systems engineering.Links Referenced: Sysdig: https://sysdig.com/ LinkedIn: https://www.linkedin.com/in/michael-isbitski/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're already managing your network.So what's the benefit? Well, built-in key rotation, the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now - it's free forever for personal use.Corey: Do you wish your developers had less permanent access to AWS? Has the complexity of Amazon's reference architecture for temporary elevated access caused you to sob uncontrollably? With Sym, you can protect your cloud infrastructure with customizable, just-in-time access workflows that can be setup in minutes. By automating the access request lifecycle, Sym helps you reduce the scope of default access while keeping your developers moving quickly. Say goodbye to your cloud access woes with Sym. Go to symops.com/corey to learn more. That's S-Y-M-O-P-S.com/coreyCorey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I periodically find myself in something of a weird spot when it comes to talking about security. I spent a lot of my time in previous lives having to care about it, but the word security was never in my job title. That's who my weekly podcast on the AWS Morning Brief and the accompanying newsletter goes out to: it's people who have to care about security but don't have it as part of their job title. They just want to know what's going on without all of the buzzwords.This promoted guest episode is brought to us by our friends at Sysdig and my guest is Mike Isbitski, Director of Cybersecurity Strategy at Sysdig. Mike, thanks for joining me.Michael: Thanks, Corey. Yeah, it's great to be here.Corey: So, you've been at Sysdig for a little bit, but your history is fascinating to me. You were at Gartner, which on the one hand would lead someone to think, “Oh okay, you talk about this stuff a lot, but might not have been particularly hands-on,” but that's not true. Either. You have a strong background as a practitioner, but not directly security-focused. Is that right?Michael: Yeah. Yeah, that is correct. I can certainly give the short version of the history lesson [laugh]. It is true, yes. As a Gartner analyst, you don't always get as hands-on, certainly talking to practitioners and leaders from all walks of life, different industries, different company sizes, and organization sizes.But yeah, as a Gartner analyst, I was in a different division that was much more technical. So, for me personally, I did actually try to tinker a lot: set up Docker, deploy Kubernetes clusters, all that fun stuff. But yeah, prior to my life, as an analyst, I was a practitioner, a security leader for close to 20 years at Verizon so, saw quite a bit. And actually started as enterprise architect building, kind of, systems and infrastructure to support all of those business needs, then I kind of transitioned over to application security towards the tail end of that career at Verizon.Corey: And one of the things that I find that I enjoy doing is talking with folks in positions like yours, the folks who did not come to the cybersecurity side of the world from a pure strategy advisory sense, but have been hands-on with these things at varying points in our careers, just because otherwise I feel like I'm sort of coming at this from a very different world. When I walk around the RSA show floor, I am consistently confronted by people trying to sell me the same dozen products over and over again with different words and different branding, but it seems like it's all buzzwords aimed from security people who are deep in the weeds to other security people who are deep in the weeds and it's just presumed that everyone knows what they're talking about already. And obviously worse. I'm not here to tell them that they're going about their business wrong, but for smaller companies, SMBs, folks who have to care about security but don't know the vernacular in the same way and don't have sophisticated security apparatus at their companies, it feels like a dense thicket of impenetrable buzzwords.Michael: Yes. Very, very fair assessment, [laugh] I would say. So, I'd say my life as an analyst was a lot of lengthy conversations. I guess a little bit of the secret behind analyst inquiry, I mean, a lot of times, they are hour-long conversations, sometimes multiple sets of them. But yeah, it's very true, right?There's a lot of nuance to how you work with technology and how you build things, but then also how you secure it, it's very hard to, kind of, condense that, you know, hours of conversation and many pages of documentation down into some bite-size nuggets that marketers might run with. So, I try to kind of live in that in-between world where I can kind of explain deep technology problems and business realities, and kind of explain that in more common language to people. Sometimes it's easier said than done when you're speaking it as opposed to writing it. But yeah, that's kind of where I tried to bring my skills and experience.Corey: It's a little counterintuitive to folks coming out from the other side, I suspect. For me, at least the hardest part of getting into the business of cloud cost optimization the way that I do with the Duckbill Group was learning to talk. Where I come from a background of heavy on the engineering and operations side, but being able to talk to business stakeholders who do not particularly care what a Kubernetes might be, is critical. You have to effectively be able to speak to different constituencies, sometimes in the same conversation, without alienating the rest of them. That was the hard part for me.Michael: Yeah, that's absolutely true and I certainly ran into that quite a bit as an enterprise architect at Verizon. There's kind of really need to work to identify, like, what is the business need. And typically, that is talking to the stakeholders, you know, what are they trying to achieve? They might not even know that, right, [laugh] because not everybody is very structured in how they think about the problem you're trying to solve. And then what is their daily workflow?And then you kind of arrive at the technology. I'd say, a common pitfall for anybody, right, Whether you're an engineer or a security practitioner is to kind of start with the technology or the solution and then try to force that on people, right? “Here's your solution to the problem that maybe you didn't know you had.” [laugh]. It kind of should work in reverse, right? What's the actual business need? What's your workflow? And what's the appropriate technology for that, right?Whether it's right-sizing the infrastructure or a particular type of functionality or protection, all those things, right? So, very similar kind of way of approaching the problem. It's just what you're trying to solve but [laugh] I've definitely seen that, kind of, Kubernetes is all the rage, right, or service mesh. Like, everybody needs to start deploying Istio, and you really should be asking the question—Corey: Oh, it's all resume-driven development.Michael: Yep, exactly. Yeah. It's kind of the new kid on the block, right? Let's push out this cool new technology and then problems be damned, right?Corey: I'm only half-kidding on that. I've talked to folks who are not running those types of things and they said that it is a bit of a drag on their being able to attract talent.Michael: Yeah, it's—you know, I mean, it's newer technologies, right, so it can be hard to find them, right, kind of unicorn status. I used to talk quite a bit in advisory calls to find DevOps practitioners that were kind of full-stack. That's tricky.Corey: I always wonder if it's possible to find them, on some level.Michael: Yeah. And it's like, well, can you find them and then when you do find them, can you afford them?Corey: Oh, yeah. What I'm seeing in these other direction, though, is people who are making, you know, sensible technology choices where you actually understand what lives were without turning it into a murder mystery where you need to hire a private investigator to track it down. Those are the companies that are having trouble hiring because it seems that an awful lot of the talent, or at least a significant subset of it, want to have the latest and greatest technologies on their resume on their next stop. Which, I'm not saying they're wrong for doing that, but it is a strange outcome that I wasn't quite predicting.Michael: Yeah. No, it is very true, I definitely see that quite a bit in tech sector. I've run into it myself, even with the amount of experience I have and skills. Yeah, companies sometimes get in a mode where they're looking for very specific skills, potentially even products or technologies, right? And that's not always the best way to go about it.If you understand concepts, right, with technology and systems engineering, that should translate, right? So, it's kind of learning the new syntax, or semantics, working with a framework or a platform or a piece of technology.Corey: One of the reasons that I started the security side of what I do on the newsletter piece, and it caught some people by surprise, but the reason I did it was because I have always found that, more or less, security and cost are closely aligned spiritually, if nothing else. They're reactive problems and they don't, in the general sense, get companies one iota closer to the business outcome they're chasing, but it's something you have to do, like buying fire insurance for the building. You can spend infinite money on those things, but it doesn't advance. It's all on the defensive, reactive side. And you tend to care about these things a lot right after you failed to care about them sufficiently. Does that track at all from your experience?Michael: Yeah. Yeah, absolutely. I'm just kind of flashing back to some war stories at Verizon, right? It was… I'd say very common that, once you've kind of addressed, well, these are the business problems we want to solve for and we're off to the races, right, we're going to build this cool thing. And then you deploy it, right [laugh], and then you forgot to account for backup, right? What's your disaster recovery plan? Do you have logging in place? Are you monitoring the thing effectively? Are your access controls accounted for?All those, kind of, tangential processes, but super-critical, right, when you think about, kind of, production systems, like, they have to be in place. So, it's absolutely true, right, and it's kind of definitely for just general availability, you need to be thinking about these things. And yeah, they almost always translate to that security piece of it as well, right, particularly with all the regulations that organizations are impacted with today. You really need to be thinking about, kind of, all these pieces of the puzzle, not just hey, let's build this thing and get it on running infrastructure and we're done with our work.Corey: A question that I've got for you—because I'm seeing a very definite pattern emerging tied to the overall macro environment, now, where after a ten-year bull run, suddenly a bunch of companies are discovering, holy crap, money means something again, where instead of being able to go out and gets infinite money, more or less, to throw at an AWS bill, suddenly, oh, that's a big number, and we have no idea what's in it. We should care about that. So, almost overnight, we've seen people suddenly caring about their bill. How are you seeing security over the past year or so? Has there been a similar awareness around that or has that not really been tied to the overall macro-cycle?Michael: Very good question, yeah. So unfortunately, security's often an afterthought, right, just like, kind of those things that support availability—probably going to get a little bit better ranking because it's going to support your customers and employees, so you're going to get budget and headcount to support that. Security, usually in the pecking order, is below that, right, which is unfortunate because [laugh] there can be severe repercussions with that, such as privacy impacts, or data breach, right, lost revenue, all kinds of things. But yeah, typically, security has been undercut, right? You're always seeking headcount, you need more budget.So, security teams tend to look to delegate security process out, right? So, you kind of see a lot of DevOps programs, like, can we empower engineers to run some of these processes and tooling, and then security, kind of, becomes the overseer. So, we see a lot of that where can we kind of have people satisfy some of these pieces. But then with respect to, like, security budgets, it is often security tools consolidation because a lot organizations tend to have a lot of things, right? So, security leaders are looking to scale that back, right, so they can work more effectively, but then also cut costs, which is definitely true these days in the current macroeconomic environment.Corey: I'm curious as well, to see what your take is on the interplay between cost and security. And what I mean by that is, I did the numbers once, and if you were to go into an AWS native environment, ignore third-party vendors for a second, just configure all of the AWS security services in your account, so the way that best practices dictate that you should, you're pretty quickly going to end up in a scenario where the cost of that outweighs that of the data breach that you're ostensibly trying to prevent. So—Michael: Yes.Corey: It's an infinite money pit that you can just throw everything into. So, people care about security, but they also care about cost. Plus, let's be very direct here, you can spend all the money on security and still lose. How do companies think about that now?Michael: A lot of leaders will struggle with, are we trying to be compliant or are we trying to be secure? Because those can be very different conversations and solutions to the problem. I mean, ideally, everybody would pursue that perfect model of security, right, enable all the things, but that's not necessarily cost-effective to do that. And so, most organizations and most security teams are going to prioritize their risks, right? So, they'll start to carve out, maybe these are all our internet-facing applications, these are the business-critical ones, so we're going to allocate more security focus to them and security spend, so [maybe we will be turn up 00:13:20] more security services to protect those things and monitor them.Then [laugh], unfortunately, you can end up with a glut of maybe internal applications or non-critical things that just don't get that TLC from security, unfortunately, for security teams, but fortunate for attackers, those things become attack targets, right? So, they don't necessarily care how you've prioritized your controls or your risk. They're going to go for the low-hanging fruit. So, security teams have always struggled with that, but it's very true. Like, in a cloud environment like AWS, yeah, if you start turning everything up, be prepared for a very, very costly cloud expense bill.Corey: Yeah, in my spare time, I'm working on a project that I was originally going to open-source, but I realized if I did it, it would cause nothing but pain and drama for everyone, of enabling a whole bunch of AWS misconfiguration options, given a set of arbitrary credentials, that just effectively try to get the high score on the bill. And it turned out that my early tests were way more successful than anticipated, and instead, I'm just basically treating it as a security vulnerability reporting exercise, just because people don't think about this in quite the same way. And again, it's not that these tools are necessarily overpriced; it's not that they aren't delivering value. It's that in many cases, it is unexpectedly expensive when they bill across dimensions that people are not aware of. And it's one of those everyone's aware of that trap the second time type of situations.It's a hard problem. And I don't know that there's a great way to answer it. I don't think that AWS is doing anything untoward here; I don't think that they're being intentionally malicious around these things, but it's very vast, very complex, and nobody sees all of it.Michael: Very good point, yes. Kind of, cloud complexity and ephemeral nature of cloud resources, but also the cost, right? Like, AWS isn't in the business of providing free service, right? Really, no cloud provider is. They are a business, right, so they want to make money on Cloud consumption.And it's interesting, I remember, like, the first time I started exploring Kubernetes, I did deploy clusters in cloud providers, so you can kind of tinker and see how these things work, right, and they give you some free credits, [a month of credit 00:15:30], to kind of work with this stuff. And, you know, if you spin up a [laugh] Kubernetes cluster with very bare bones, you're going to chew through that probably within a day, right? There's a lot of services in it. And that's even with defaults, which includes things like minimal, if anything, with respect to logging. Which is a problem, right, because then you're going to miss general troubleshooting events, but also actual security events.So, it's not necessarily something that AWS could solve for by turning everything up, right, because they are going to start giving away services. Although I'm starting to see some tide shifts with respect to cybersecurity. The Biden administration just released their cybersecurity strategy that talks about some of this, right? Like, should cloud providers start assuming more of the responsibility and accountability, potentially just turning up logging services? Like, why should those be additional cost to customers, right, because that's really critical to even support basic monitoring and security monitoring so you can report incidents and breaches.Corey: When you look across what customers are doing, you have a different problem than I do. I go in and I say, “Oh, I fixed the horrifying AWS bill.” And then I stop talking and I wait. Because if people [unintelligible 00:16:44] to that, “Ooh, that's a problem for us,” great. We're having a conversation.If they don't, then there's no opportunity for my consulting over in that part of the world. I don't have to sit down and explain to people why their bill is too high or why they wouldn't want it to be they intrinsically know and understand it or they're honestly not fit to be in business if they can't make a strategic evaluation of whether or not their bill is too high for what they're doing. Security is very different, especially given how vast it is and how unbounded the problem space is, relatively speaking. You have to first educate customers in some ways before attempting to sell them something. How do you do that without, I guess, drifting into the world of FUD where, “Here are all the terrible things that could happen. The solution is to pay me.” Which in many cases is honest, but people have an aversion to it.Michael: Yeah. So, that's how I feel [laugh] a lot of my days here at Sysdig. So, I do try to explain, kind of, these problems in general terms as opposed to just how Sysdig can help you solve for it. But you know, in reality, it is larger strategic challenges, right, there's not necessarily going to be one tool that's going to solve all your problems, the silver bullet, right, it's always true. Yes, Sysdig has a platform that can address a lot of cloud security-type issues, like over-permissioning or telling you what are the actual exploitable workloads in your environment, but that's not necessarily going to help you with, you know, if you have a regulator breathing down your neck and wants to know about an incident, how do you actually relay that information to them, right?It's really just going to help surface event data, stitch things together, that now you have to carry that over to that person or figure out within your organization who's handling that. So, there is kind of this larger piece of, you know, governance risk and compliance, and security tooling helps inform a lot of that, but yeah, every organization is, kind of, have to answer to [laugh] those authorities, often within their own organization, but it could also be government authorities.Corey: Part of the challenge as well is that there's—part of it is tooling, absolutely, but an awful lot of it is a people problem where you have these companies in the security space talking about a variety of advanced threats, of deeply sophisticated attackers that are doing incredibly arcane stuff, and then you have the CEO yelling about what they're doing on a phone call in the airport lounge and their password—which is ‘kitty' by the way—is on a Post-It note on their laptop for everyone to see. It feels like it's one of those, get the basic stuff taken care of first, before going down the path to increasingly arcane attacks. There's an awful lot of vectors to wind up attacking an infrastructure, but so much of what we see from data breaches is simply people not securing S3 buckets, as a common example. It's one of those crawl, walk, run types of stories. For what you do, is there a certain level of sophistication that companies need to get to before what you offer starts to bear fruit?Michael: Very good question, right, and I'd start with… right, there's certainly an element of truth that we're lagging behind on some of the security basics, right, or good security hygiene. But it's not as simple as, like, well, you picked a bad password or you left the port exposed, you know? I think certainly security practitioners know this, I'd even put forth that a lot of engineers know it, particularly if they're been trained more recently. There's been a lot of work to promote security awareness, so we know that we should provide IDs and passwords of sufficient strength, don't expose things you shouldn't be doing. But what tends to happen is, like, as you build monitoring systems, they're just extremely complex and distributed.Not to go down the weeds with app designs, with microservices architecture patterns, and containerized architectures, but that is what happens, right, because the days of building some heavyweight system in the confines of a data center in your organization, those things still do happen, but that's not typically how new systems are being architected. So, a lot of the old problems still linger, there's just many more instances of it and it's highly distributed. So it, kind of, the—the problem becomes very amplified very quickly.Corey: That's, I think, on some level, part of the challenge. It's worse in some ways that even the monitoring and observability space where, “All right, we have 15 tools that we're using right now. Why should we talk to yours?” And the answer is often, “Because we want to be number 16.” It's one of those stories where it winds up just adding incremental cost. And by cost, I don't just mean money; I mean complexity on top of these things. So, you folks are, of course, sponsoring this episode, so the least I can do is ask you, where do you folks start and stop? Sysdig: you do a lot of stuff. What's the sweet spot?Michael: Yeah, I mean, there's a few, right, because it is a larger platform. So, I often talk in terms of full lifecycle security, right? And a lot of organizations will split their approaches. We'll talk about shift left, which is really, let's focus very heavily on secure design, let's test all the code and all the artifacts prior to delivering that thing, try to knock out all quality issues, right, for kind of that general IT, but also security problems, which really should be tracked as quality issues, but including those things like vulnerabilities and misconfigs. So, Sysdig absolutely provides that capability that to satisfy that shift left approach.And Sysdig also focuses very heavily on runtime security or the shield right side of the equation. And that's, you know, give me those capabilities that allow me to monitor all types of workloads, whether they're virtual machines, or containers, serverless abstractions like Fargate because I need to know what's going on everywhere. In the event that there is a potential security incident or breach, I need all that information so I can actually know what happened or report that to a regulatory authority.And that's easier said than done, right? Because when you think about containerized environments, they are very ephemeral. A container might spin up a tear down within minutes, right, and if you're not thinking about your forensics and incident response processes, that data is going to be lost [unintelligible 00:23:10] [laugh]. You're kind of shooting yourself in the foot that way. So yeah, Sysdig kind of provides that platform to give you that full range of capabilities throughout the lifecycle.Corey: I think that that is something that is not fully understood in a lot of cases. I remember a very early Sysdig, I don't know if it was a demo or what exactly it was, I remember was the old Heavybit space in San Francisco, where they came out, it was, I believe, based on an open-source project and it was still taking the perspective, isn't this neat? It gives you really in-depth insight into almost a system-call level of what it is the system is doing. “Cool. So, what's the value proposition for this?”It's like, “Well, step one, be an incredibly gifted engineer when it comes to systems internals.” It's like, “Okay, I'll be back in five years. What's step two?” It's like, “We'll figure it out then.” Now, the story has gone up the stack. It originally felt a little bit like it was a solution in search of a problem. Now, I think you have found that problem, you have clearly hit product-market fit. I see you folks in the wild in many of my customer engagements. You are doing something very right. But it was neat watching, like, it's almost for me, I turned around, took my eye off the ball for a few seconds and it went from, “We have no idea of what we're doing” to, “We know exactly what we're doing.” Nice work.Michael: Yeah. Yeah. Thanks, Corey. Yeah, and there's quite a history with Sysdig in the open-source community. So, one of our co-founders, Loris Degioanni, was one of the creators of Wireshark, which some of your listeners may be familiar with.So, Wireshark was a great network traffic inspection and observability tool. It certainly could be used by, you know, just engineers, but also security practitioners. So, I actually used it quite a bit in my days when I would do pen tests. So, a lot of that design philosophy carried over to the Sysdig open source. So, you're absolutely correct.Sysdig open source is all about gathering that sys-call data on what is happening at that low level. But it's just one piece of the puzzle, exactly as you described. The other big piece of open-source that Sysdig does provide is Falco, which is kind of a threat detection and response engine that can act on all of those signals to tell you, well, what is actually happening is this potentially a malicious event? Is somebody trying to compromise the container runtime? Are they trying to launch a suspicious process? So that those pieces are there under the hood, right, and then Sysdig Secure is, kind of, the larger platform of capabilities that provide a lot of the workflow, nice visualizations, all those things you kind of need to operate at scale when you're supporting your systems and security.Corey: One thing that I do find somewhat interesting is there's always an evolution as companies wind up stumbling through the product lifecycle, where originally it starts off as we have an idea around one specific thing. And that's great. And for you folks, it feels like it was security. Then it started changing a little bit, where okay, now we're going to start doing different things. And I am very happy with the fact right now that when I look at your site, you have two offerings and not two dozen, like a number of other companies tend to. You do Sysdig Secure, which is around the security side of the world, and Sysdig Monitor, which is around the observability side of the world. How did that come to be?Michael: Yeah, it's a really good point, right, and it's kind of in the vendor space [laugh], there's also, like, chasing the acronyms. And [audio break 00:26:41] full disclosure, we are guilty of that at times, right, because sometimes practitioners and buyers seek those things. So, you have to kind of say, yeah, we checked that box for CSPM or CWPP. But yeah, it's kind of talking more generally to organizations and how they operate their businesses, like, that's more well-known constructs, right? I need to monitor this thing or I need to get some security. So, lumping into those buckets helps that way, right, and then you turn on those capabilities you need to support your environment, right?Because you might not be going full-bore into a containerized environment, and maybe you're focusing specifically on the runtime pieces and you're going to, kind of, circle back on security testing in your build pipeline. So, you're only going to use some of those features at the moment. So, it is kind of that platform approach to addressing that problem.Corey: Oh, I would agree. I think that one of the challenges I still have around the observability space—which let's remind people, is hipster monitoring; I don't care what other people say. That's what it is—is that it is depressingly tied to a bunch of other things. To this day, the only place to get a holistic view of everything in your AWS account in every region is the bill. That somehow has become an observability tool. And that's ridiculous.On the other side of it, I have had several engagements that inadvertently went from, “We're going to help optimize your cost,” to, “Yay. We found security incidents.” I don't love a lot of these crossover episodes we wind up seeing, but it is the nature of reality where security, observability, and yes, costs all seem to tie together to some sort of unholy triumvirate. So, I guess the big question is when does Sysdig launch a cost product?Michael: Well, we do have one [laugh], specifically for—Corey: [laugh]. Oh, events once again outpace me.Michael: [laugh]. But yeah, I mean, you touched on this a few times in our discussion today, right? There's heavy intersections, right, and the telemetry you need to gather, right, or the log data you need to gather to inform monitoring use cases or security use cases, a lot of the times that telemetry is the same set of data, it's just you're using it for different purposes. So, we actually see this quite commonly where Sysdig customers might pursue, Monitor or Secure, and then they actually find that there's a lot of value-add to look at the other pieces.And it goes both ways, right? They might start with the security use cases and then they find, well, we've over-allocated on our container environments and we're over-provisioning in Kubernetes resources, so all right, that's cool. We can actually reduce costs that could help create more funding to secure more hosts or more workloads in an environment, right? So it's, kind of, show me the things I'm doing wrong on this side of the equation, whether that's general IT security problems and then benefit the other. And yeah, typically we find that because things are so complex, yeah, you're over-permissioning you're over-allocating, it's just very common, rights? Kubernetes, as amazing as it can be or is, it's really difficult to operate that in practice, right? Things can go off the rails very, very quickly.Corey: I really want to thank you for taking time to speak about how you see the industry and the world. If people want to learn more, where's the best place for them to find you?Michael: Yes, thanks, Corey. It's really been great to be here and talk with you about these topics. So, for me personally, you know, I try to visit LinkedIn pretty regularly. Probably not daily but, you know, at least once a week, so please, by all means, if you ever have questions, do contact me. I love talking about this stuff.But then also on Sysdig, sysdig.com, I do author content on there. I speak regularly in all types of event formats. So yeah, you'll find me out there. I have a pretty unique last name. And yeah, that's kind of it. That's the, I'd say the main sources for me at the moment. Don't fall for the other Isbitski; that's actually my brother, who does work for AWS.Corey: [laugh]. That's okay. There's no accounting for family, sometimes.Michael: [laugh].Corey: I kid, I kid. Okay, great company. Great work. Thank you so much for your time. I appreciate it.Michael: Thank you, Corey.Corey: Mike Isbitski, Director of Cybersecurity Strategy at Sysdig. I'm Cloud Economist Corey Quinn and this has been a promoted guest episode brought to us by our friends at Sysdig. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment from your place, which is no doubt expensive, opaque, and insecure, hitting all three points of that triumvirate.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Show Notes: A FFP interview with Guy Podjarny. Guy is a renowned entrepreneur and technologist who currently serves as the co-founder and president at Snyk, a leading cloud-native security company. Guy also hosts of The Secure Developer podcast, and is an O'Reilly author.  Prior to Snyk, Guy Podjarny co-founded Blaze, a groundbreaking web security startup that was later acquired by Akamai Technologies. With over two decades of experience in the software industry, Guy is recognized as a thought leader in the field of application security and has contributed to several open-source projects, including OWASP Top Ten and the Node.js security project. He is also a frequent speaker at industry events and has authored the book "Securing Open Source Libraries" to help developers improve the security of their software. As a passionate advocate for secure software development, Guy is dedicated to empowering developers to write secure code from the start. His mission with Snyk is to democratize security and make it accessible to all developers, regardless of their level of expertise. Under his leadership, Snyk has grown rapidly and become a trusted partner for many of the world's leading companies. Guy's innovative thinking and commitment to building a better, more secure digital world have earned him numerous accolades. Hear Guy Podjarny's perspective on: Heavybit Environment High Standards Functionality vs Security Monetizing Security Explosive Growth Founder Image Humility Culture Unsolved Problems Appreciating Success Celebrating Teams Hiring Leadership Execution Ability Vision & Hustle Assessing Leadership Replacing Executives Retaining Leaders Heads Of X Inflated Titles Links: Guy Podjarny on ⁠Twitter⁠ ⁠Snyk⁠ ⁠The Secure Developer Podcast⁠ Guy Podjarny on ⁠GitHub⁠ We are currently hiring at ⁠Stellate⁠. If you got interested in potentially working with us, please take a look at our ⁠hiring page⁠.

In this episode, Rob sits down with the DevOps “party starter” himself, Jesse Robbins, to discuss the current state of software delivery. Is DevOps really dead, or are we simply witnessing a maturing model as organizations grow and evolve? Tune it to hear Jesse's valuable take on where he sees the industry moving and the potential complexities on the horizon.Download the 2023 State of Software Delivery Report here: circleci.com/resources/2023-state-of-software-delivery/For more information on platform engineering, visit: circleci.com/blog/platform-engineering-devops-at-scale/Have someone you'd like to hear on the podcast, let us know on Twitter @CircleCI! 

About AlyssAlyss Noland is the head of Developer Relations Relations and Product Marketing at Common Room, an intelligent community-led growth platform. She previously led product marketing for Developer Experience at GitHub where she focused on open source community investment and helping engineering teams find success through development metrics and developer-focused research. She's been working in tech since 2012 in various roles from Sales Engineering and Developer Advocacy to Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce, as well as being an advisor at Heavybit. Links Referenced: Common Room: https://www.commonroom.io/ Heavybit: https://www.heavybit.com/ Twitter: https://twitter.com/PreciselyAlyss Twitch: https://www.twitch.tv/PreciselyAlyss TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're managing your network.So what's the benefit? You'll get built-in key rotation, the ability to manage permissions as code, connectivity between two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security. Try Tailscale now - it's free forever for personal use forever.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I often wonder how to start these conversations, but sometimes it's just handed to me and I don't even have to do a whole lot of work. My guest today is Alyss Noland, who's the Head of Developer Relations Relations and Product Marketing at Common Room. Alyss, thank you for joining me.Alyss: Thanks for having me, Corey. I'm really excited to be here.Corey: So, developer relations relations. It feels like an abstraction that has been forced to be built on top of another abstraction that has gotten too complicated, so as best I can tell, you are walking around as a human equivalent of Kubernetes.Alyss: Oh, gosh, I would really hope not to be a human equivalent of Kubernetes. I think that would make me an octopus. But—Corey: Yeah, “What did you say about me?” Yeah.Alyss: [laugh].Corey: “I didn't come here to be insulted, Quinn.” Yeah.Alyss: No, like listen, I love octopodes. Which [tattoo 00:01:24] is which? So, developer relations relations. Yes, it's an abstraction on an abstraction. A really critical level, it is how do I relate? Can I relate to people that are in the developer relations profession at large?We are at the point at which this is a somewhat poorly-defined area that is continuing to grow. And there's a lot of debates in that space and so I'm really excited to be at an organization that will give me a platform to try and move the industry forward.Corey: Your relatively recent career history is honestly fascinating to me. You spent about a year and a half as a senior developer advocate at Box. And as anyone who's ever tried it knows, it's very hard to beat Box [beatboxing noises]. But you tried and went to GitHub, in which case, you basically transitioned pretty quickly from a Senior Product Marketing Manager to Director of Product Marketing, where you were the go-to-market lead for GitHub Copilot.Alyss: Yeah, that was a really interesting project to be on. I started off at the technical preview back in 2021, launching that too—it ended up being with about a little over a million, two million folks in technical preview. And it's fairly new to the market. There was nothing else—or at the time, there had been nothing else that was using a descendant of GPT-3. There was nothing else using a descendant of GPT-3 to generate suggestions for code to—there were a couple that were using GPT-2, but the amount of language coverage they had was a little bit limited, what they were suggesting was a little bit limited.And it's hard to say, like, highlight of my career, but at that point in time, I would say probably, highlight of my career to be able to work on something with that opportunity for impact.Corey: As someone who was in the technical preview and now tried to be a paying customer of it, but I can't because of my open-source work, it wound up giving it to me for free. I found it to be absolutely transformative. And I know I'm going to get letters and I don't even slightly care because it's not, “I'm going to tab-complete my application.” If a tool can do that, your application is probably not that complex. No, for me, what I find incredibly valuable is the ability to tab-complete through obnoxious boilerplate. CloudFormation, I am not subtweeting you; I am calling you out directly. You are wordy and obnoxious. Fix yourself.And especially in languages that I don't deal with day-to-day—because I'm not a full-time developer—I forget certain parameters or argument order or things like that and being able to effectively tab-complete is awesome for that use case. It's not doing my job; it's automating the crappy part of my job. And I absolutely love it for that.Alyss: Yeah, and was really interesting working on a common portion of product marketing work is that we build messaging houses. We try to identify where's the value to the user, to the organization at large, depending on, like, who it is we're trying to sell to, how does that ladder up from, like, an IoT to a manager. And so, one of the things that I got really excited about as we started to see it—and there's some great work that Dr. Eirini Kallaimvakou has published that I would definitely refer to if you're interested in diving deeper into it—is the way in which Copilot and this, like, ability to improve the boilerplate experience, improve the boring shit—automate the boring shit, if you will—is about developer satisfaction. It's not about making you build your commits faster or about having more lines of code that you like get deployed out; it's about making your jobs suck less.Corey: Well, if you spent, what was it roughly two years, give or take, at GitHub between your various roles—and yes, I'm going to pronounce it ‘GIF-ub' because that's my brand of obnoxious, so I'm going to go for it—you went to Common Room. Let's begin there. What does Common Room do, exactly?Alyss: So, Common Room is an intelligent community-led growth platform. And there's a few things kind of packed into that really short description, but the idea is that we've seen all of these product-lead grows businesses. But at a critical point, and something we've seen at GitHub, which is a product-led growth company, it's something that we've seen at Atlassian, Asana, you name half a dozen different, like, SaaS companies, self-hosted software, open-source, community is at the heart of it. And so, how do you nurture that community? How do you measure that community? How do you prove that the work that you're doing is valuable?And that's what Common Room is setting out to do. And so, when I saw—like, they're not the only person or organization in the market that's doing this, but I think they're doing it exceptionally well, and with really great goals in mind. And so, I'm enthused to try and facilitate that investment in community for more organizations.Corey: One of the challenges that I have seen of products in the community space is it tended, historically, to go in really, I guess I'll call them uncomfortable directions. In the before times, I used to host dinner parties near constantly here, and someone confide into me once—after, you know, six beers or so, because that's when people get the excitingly honest—they mentioned that, “Yeah, I'm supposed to wind up putting these dinners into Salesforce”—or whatever the hell it was—“To track the contacts we have with influencers in this space.” And that made me feel so profoundly uncomfortable. It's, you're invited here to spend time with my friends and my family. You're meeting my kids, it's, yeah, this is just a go-to-market motion and you can [BLEEP] on out of here and never come back.And I did not get that sense to be clear and I'm told the company wound up canceling that horrifying program, but it does feel like it's very easy to turn an authentic relationship into something that feels remarkably sleazy. That said, Common Room has been around for a while and I have yet to hear a single accusation that you folks have come within a thousand miles of doing that. How do you avoid the trap?Alyss: It's a slippery slope, and I can't say that Common Room creates any kind of like enforcement or silos or prevents organizations from falling into this trap. Fundamentally, the way in which community can be abused, the way in which these relationships can be taken advantage of, at least from the perception of the parties that initially built the relationship, is to take the context out of them, to take the empathy out of them, take the people out of them. And so, that is fundamentally left to the organization's principles, it's left to how much authority does community have within the business relative to a sales team. And so first, being able to elevate community in such a way to show that they are having that impact already without having to turn the community into a prospect pool is, I think, one of the critical first steps, and it's something that we've been able to break through initially by connecting things like Slack, Discord, Twitter to show, here's all these people talking about you, here's all the things that they're saying, here's the sentiment analysis, and also, now we're going to push that into Salesforce. So, you can see that this started out in community and it was fostered there. Now, you can see the ROI, you don't need to go hitting up our community contacts to try and sell to them because we're doing it on your behalf in a very real way.Corey: Part of the challenge, I think, is that—and you've talked to me about this in previous conversations we've had—that so much of community is distilled down to a sales motion, which let's be direct, it kind of sucks at, in some levels, because it's okay, great, I'm here to talk to you about how community works. Well, in the AWS community, for example, the reason that formed and is as broad and fast as it is because AWS's documentation is Byzantine and there's a sort of shared suffering that we all get to commiserate over. And whenever AWS tries to take, “Ownership,” quote-unquote, of its community, right, that doesn't actually work that way. They have community watering holes, but to my understanding, the largest AWS-centric Slack team is the Open Guide to AWS's Slack team, which now has, at last count, 15,000 people in it. I'm lucky enough to be the community lead for that project.But it was pre-existing before I got there and it's great to be able to go and talk to people who are using these things. It doesn't feel like it is owned, run, or controlled—because it's not—by AWS themselves. It's clear from the way that your product has evolved, that you feel similarly around that where it's about being aware of the community rather than controlling the community. And that's important.Alyss: Absolutely. And one of the ways in which we, like, highlight this as soon as you're in the product, is being able to show community responsiveness and then what percentage of those responses are coming from my team members. And frankly, as someone who's previously set strategy for developer relations teams, for developer communities, what I want to see is community members responding to each other, community members knowing what's the right place to look, what's the right answer, how am I ensuring that they have the resources that they need, the answers that they need. Because at the end of the day, I can't scale one-to-one; no one can. And so, the community being able to support itself is at the heart of the definition of community.Corey: One of the other problems that I've seen historically, and I'll call it the Chef problem because Chef had an incredibly strong community, and as someone who is deep in the configuration management space myself, but never use Chef, it was the one that I avoided for a variety of reasons at the time, it was phenomenal. I wound up going to ChefConf, despite not being a Chef user, just to spend time with some of the great people that were involved. The blunder that they made before they were acquired into irrelevance by progress—and to be fair, the industry changed direction toward immutable infrastructure in ways that were hard to foresee—but the problem is, they made was hiring their entire community. And it doesn't sound like that would be a bad thing, but suddenly, everyone who was talking about the product had a Chef email address, and that hits very differently.Alyss: It does. And it goes back to that point of trying to maintain those authentic relationships. And if we're to step outside of tech, I have a background prior to tech in the video game industry, and that was a similar problem. Nearly every single community-made application, extension ends up getting acquired by some organization, like Curse, and then piped full of ads, or the person that you thought you could ask or to see build some other better experience of version control software, or a Git client ends up getting consumed into a large business and then the project never sees the light of day. And frankly, that's not how you run community in my estimation.My estimation is, if the community is doing things better than you are, take notes. Product management, pay attention. That's something that is another aspect of doing developer relations is about checking in with those teams, about showing them evidence. And like, it so often ends up being qualitative in a way that doesn't change people's minds or their feelings, where people want to see quantitative numbers in order to say, “Oh, this is the business justification. Like, this is the ROI. This proves that this is the thing we should invest in.” And frankly, no. Like, sometimes it is a little bit more about stepping back and letting the organic empathy and participation happen without having to own it.Corey: There's a sense, I think that a lot of companies feel the need to own every conversation that happens around them, their product, et cetera, and you can't. You just can't, unless—to be direct—your company is failing. Just because if no one's talking about you, then great, you're the only ones talking about you. And you can see this from time to time and it's depressing as hell when you have people who work for a company all tweeting the same cookie-cutter statement, and they get zero interaction except from a bot account. It's sad.Alyss: Yeah. And I've unfortunately seen this more times than I can count in community Slacks where people just, like, copy-paste whatever marketing handed to them, and I would be shocked if they got any engagement at all. Because that's… cool. What do I know about you? Why do I care about this event? Have you personalized it to me?And yeah, you don't want the organization to be the only one talking about you. If you are then you've already failed in this, you know, product-led growth motion. You've kind of—if we want to get into the murky water of NPS, like, nobody's going and telling their friends about your product [laugh]. And the thing that's so valuable is the authentic voice. It's the, “I'm excited to talk about this and I like it enough to tell you what I like about it.” I like it enough to tell you about this use case that might never seen the light of day, but because we're having a conversation between ourselves, it can all be personalized. It can all be about what's going on between us and about our shared experiences. And that is ten times more powerful than most Twitter-promoted ads you'll ever see.Corey: So, I want to unpack a little bit about not developer relations as such, but developer relations relations because I can mostly understand—badly—what product marketing is, but developer relations relations—or as you'd like to call it developer relations squared—that's something new. I've always called DevRel to be devrelopers, and people get annoyed enough at that. What is that newfound layer of abstraction on top of it?Alyss: Well, there's several things that I'm going to end up—and I say end up; I'm six weeks into the role, so I have a lot of high hopes for where I hope this goes. And one of those is things, like, we don't have a very shared understanding and shared definition of what developer advocacy even is, what is developer relations? Does developer marketing belong under that umbrella? How should organizations approach developer relations? How should they value it? Where should it, you know, belong in terms of business strategy?And there's an opportunity for a company whose business it is to elevate this industry, this career path, if you will, where we can spend the time, we can spend the money to say, here's what success looks like. We've interviewed all these groups, we've talked with the leaders in this space that are making it their jobs to think about this. Here's a set of group-developed recommendations for how the industry should mature. Or here's an open-source set of job descriptions and requirements. And like, let's get to some level of shared understanding.So, as an example of, kind of, where I'm leading to with all of this, and some of the challenges that developer relations faces is the State of Developer Relations report that just came out. There's a significant number of people that are coming into developer advocate, developer relations roles for the first time, they have one to two years of experience, they're coming into programs that have been around for one to two years, and so what does that tell you? That tells you you're bringing in people with no experience to try to establish brand new programs, that they're being asked to by their business, and they don't have the vocabulary, the tools, the frameworks in which to establish that for themselves. And so, they're going to be swayed by, you know, the tides of business, by the influences of their leadership without having their own pre-built notions. And so, how do we give them that equipment and how do we elevate the practice?Corey: Cloud native just means you've got more components or microservices than anyone (even a mythical 10x engineer) can keep track of. With OpsLevel, you can build a catalog in minutes and forget needing that mythical 10x engineer. Now, you'll have a 10x service catalog to accompany your 10x service count. Visit OpsLevel.com to learn how easy it is to build and manage your service catalog. Connect to your git provider and you're off to the races with service import, repo ownership, tech docs, and more. Corey: It feels like so much of the DevRel discourse has turned into, one, we define it by what is not, and two, it doesn't matter how you're measuring it, you're measuring it wrong. I feel like that is, I guess we'll call it counterproductive, for lack of a better descriptor. It feels like there's such a short-sighted perspective on all of this, but at the same time, you've absolutely got to find ways to articulate the value of DevRel slash community to the business otherwise, it turns into a really uncomfortable moment when, okay, time to cut costs. Why should we keep your function over a different function? If there's not a revenue or upside or time to market or some form of value story tied to that, that the business can understand that isn't just touchy-feely, it's a very difficult path forward from there. How do you see it?Alyss: I agree with you and I've, frankly, run into this problem several times in my career, and every time I've been a developer advocate. It's, you know—and where I've found the most success is not in saying, “Here's exactly the numbers that I'm going to be constantly looking at. I'm going to try to produce this many pieces of content, or I'm absolutely not speaking at events. And that's not my job. Or I'm not writing code. That's not my job.”It's about understanding what is driving the business forward. Who do I need participation and buy-in from and where am I hoping to go? Like, what does a year out from this look like? What does three years out from this look like? At Box, we do not want to be the API governance standard. That is not our job. That's not where we sit within engineering.That's frankly, if you really want to get into it, internal developer advocacy because it can influence the impact on the community. It is not the core focus and there are probably people better equipped and better educated on the core application. Big commerce, platform ecosystem, platform flywheel developers are fundamentally a part of continuing to grow the business and how do I go make that point to sales, how do I go make that point to partners, how do I go make that point to customer success, so that I can build a function that has more than one person. And so, I think to kind of bring it back to the larger question, that is where I see our greatest challenge is that we haven't given ourselves the vocabulary or the framework to understand the level of complexity that DevRel has become in being across so many industries, and being in B2B, and being in business to developer, and being in business to consumer. No one size fits all and we need to stop trying to treat it as though it can be.Corey: I think that there is a, how to put it, a problem in terms of how Twitter views a lot of these things. Someone wound up finally distilling it down for me in relatively recent times with a very resonant quote, which was simply put, that Twitter is not where you go for nuance. Twitter is where you go to be righteous. And I realized, oh, my God, that describes a good 80% of the things I've put up there. Like when I talk about how when companies do this thing to their staff and it's crappy, I am not necessarily for a nuanced debate, although of course there's always nuance and edge cases in the rest.As a counterpoint, whenever I wind up talking about things on Twitter and speak in generalities, I get a whole bunch of people pushing back with a, “Well, what about this edge case? That renders your entire point invalid.” And, ugh, not really. It feels like one of the casualties of the pandemic has been a sense of community in a sense of humans relating to other humans. I think we're all tired of the Zoom calls from hell I got to see you a couple of weeks before this recording at Monktoberfest in Portland, Maine, and oh, my God, dealing with people face to face, it was so much richer, at least from my perspective, compared to everything that we've been able to do during the pandemic. Am I alone on that? Are you seeing this across the board? Where companies are talking about this?Alyss: I will say with confidence, you're not alone in this. Whether or not companies are talking about it is also across the board. How rich are those understandings? How rich are those conversations? Because trying to step back as a brand is not really a way.Like, having nuance, being real, been community members, like that's not a way in which I think companies can participate in a way that feels truly authentic. That's why you need faces. That's why you need people. That's why you need folks whose job it is to do this. But in terms of things are lost, like, Twitter is not the right place to be having these conversations. It's not the right place in which to necessarily relate to people, absolutely.When you get distilled down all of your interactions into oh, I've got a notification. Oh, I have a checkmark, and so I have, like, better moderation tools. Oh, like, I made a statement and I don't want to hear a solution for it. We get all of these, uncurated experiences that are so dissatisfying that it does make us miss being around people who can read body language, that can understand my immediate relationship to them in spaces that we choose to be in, whereas Twitter is this big panopticon where we can just get yelled at and yell at each other. And it loves to amplify those conversations far more than any of the touchy-feely, good news success stories.Corey: When you take a look across the entire landscape of managing DevRel programs and ensuring that companies are receiving value for it, and—by which I mean, nurturing the long-term health of communities because yes, I am much more interested in that than I am in next quarter's numbers, how do you see that evolving, particularly with the recent economic recession or correction or drawback or everything's on fire, depending upon who it is you talk to? How do you see that evolving?Alyss: It goes back to what I said earlier about, I can speak in generalities, there will be specifics to various organizations, but at a fundamental part, like, I'll kind of take a step back and maybe make some very strong statements about what I think DevRel is, in a regard, which is, without documentation, without support, you don't have a product. And if you don't have folks going out and understanding what it is your customers need, and especially when those customers are maybe all the time or sometimes developers, and understanding what it is that they're saying and truly how having empathy for what's going on in their day-to-day, what task are they trying to complete, how relevant is this to them, if you don't invest in that, when that happens, you've lost the plot. And so, in those instances, unfortunately, that's a conversation with leadership team. Your leadership doesn't fundamentally understand the value and maybe it's worth it to make the argument in favor of to illustrate that without this feedback loop, without this investment in the educational journey of developers, without the investment in what is going on in our product, and where have we allowed ourselves to remain ignorant of what is happening in the day-to-day of our users. We need those folks.Product managers are in sprints, they're in standups. They're doing, like, strategic planning and their yearly planning. We need a group who is rewarded to care about this but also is innately driven to do so as well. And that's not something that you can make. And it's not something that we otherwise see. It's part of why we have such an absence in good developer marketing is because marketers aren't paid well enough to ever have learned the skills to be developers, and so there's no skills transfer.Corey: One last topic that I want to get into something you've only been doing for a short while, but you've become an advisor at Heavybit, which is a VC firm. How did that come about and what do you do?Alyss: So currently, I—I'll do the super-high level. What I do right now is I host office hours with seed startups and Series A that are in the dev tool space. And we generally talk about developer relations, a little bit in developer marketing go-to-market strategies. And it's super enriching for me because I love hearing about different experiences and problems and, like, areas of practice. But it was really interesting, and a little bit of a make-your-own-luck-and-opportunity type deal.Where I live in Austin, Texas; I do not live in the Bay Area, I don't have all those connections, I've been a bit distant from it. And I saw someone who had accepted a role that I had interviewed for, end up in some of their content. And I was like, “They're doing a great job. They definitely deserve to be there, but I also had similar qualifications, so why should I also be there?” And I found someone, his name's Tim, on LinkedIn, who runs their events. And I reached out and I said, “Hey, Tim, how would you like a new advisor?” And so, Tim responded back and we—Corey: Knock knock. Who's there? It's me.Alyss: Yeah, exactly. It's—and it was just, I want this thing to happen. How do I make it happen? I ask.Corey: And what does it day-to-day that look like? How much time does it take? What do you do exactly?Alyss: Yeah. I mean, right now, it's about five hours every quarter. So, I spend anywhere between 30 minutes to an hour with various organizations that are a part of Heavybit's portfolio, talking with them through their motion to go general availability, or they want to start participating in events, or they want to discover what are the right events for them to—or, like, DevOpsDays, should we participate in that? Should we hire a DevRel person? Should we hire a product marketing person? Just helping them sort wheat from chaff in terms of, like, how to proceed.And so, it's relatively, for me, lightweight. And Heavybit also gives us the opportunity to contribute back in blog posts, participate in podcasts and be able to have some of those richer conversations. So, I have a set of bookmarks, so there's over 100, bookmarks long, that is fully curated across several different categories. That was my first blog post was diving into a few of those where I think are critical areas of developer relations. What are some of the conversations on DevRel metrics? How do I think about setting a DevRel strategy for the first time? How do I do my first DevRel hire? And so, I wouldn't even call it a second job. It's more of a getting to, again, enrich my own experience, see a wider variety of different problems in this space and expand my own understanding.Corey: I really want to thank you for being so generous with your time. If people want to learn more about what you're up to, how you view the world, and basically just come along for the ride as you continue to demonstrate a side of tech that I don't think we get to see very often, where can they find you?Alyss: I am@PreciselyAlyss on Twitter, as well as Twitch. Aside from that, I would not recommend looking for me.Corey: Excellent. Always a good decision. I will put links to that in the [show notes 00:30:00]. Thank you so much for your time. I appreciate it.Alyss: Thanks, Corey.Corey: Alyss Noland, Head of Developer Relations Relations and Product Marketing at Common Room. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment belittling community and letting the rest of us know by observation just why you've been thrown out of every community to which you've ever been a part.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Omri Gazitt is Co-Founder & CEO of Aserto, the open source enterprise-grade authorization-as-a-service platform. Their open source toolchain includes projects such as Open Policy Agent and their platform was built to be enterprise-ready incredibly fast. Aserto has raised over $5M from investors including Heavybit and Costanoa Ventures. In this episode, we discuss the importance of market education on a new capability (ie when would a user look for you in their journey), category creation, tracking success, and learnings for other open source founders!

Avery Pennarun launched his first successful startup in college. He is now on his second tech startup, and investors have been more than eager to help fund it. The venture, Tailscale has attracted funding from top-tier investors like Accel, Heavybit, Insight Partners, and Uncork Capital.

Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments. Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses. Ephemeral Environments (https://ephemeralenvironments.io/) Shipyard (https://shipyard.build/) Follow Benjie on LinkedIn (https://www.linkedin.com/in/bueller/). Follow Shipyard on Twitter (https://twitter.com/shipyardbuild), LinkedIn (https://www.linkedin.com/company/shipyardbuild/), or GitHub (https://github.com/shipyard). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me. BENJIE: Thanks for having me. CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does? BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up. CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist? BENJIE: That's a great question. I actually am also a developer; that's my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility. I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion. Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself. CHAD: [laughs] BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again. So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess." And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars. And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from. CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it. Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that? BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things. One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments. And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem. But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –- CHAD: There's the obvious DNS outages. BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders' ability to get their hands on features earlier, find problems, and then get those back to developers. And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect. CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah. BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on? CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging. BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases. CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production? BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component. But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen. CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem? BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --? CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting. BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments. Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that. CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way. BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help. CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes? BENJIE: So this is quite a controversial topic. CHAD: [laughs] BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let's just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments. So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing. The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it. CHAD: [laughs] BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore. CHAD: [laughs] BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it. Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments. CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that. BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going. And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard? BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion. You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there. But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that. And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea. CHAD: [laughs] Yeah, you have to queue the Inception music. BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about. CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app. BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway. CHAD: [laughs] That's a good PSA for people. BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it. And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team. CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy? BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing. But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging. But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot. And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out. I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch. CHAD: It did help. So you recommend people have a pitch. BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch? CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it. BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive. The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works. You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet. I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things. And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world. CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank? BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever. CHAD: [laughs] BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever. CHAD: [laughs] BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that. CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business? BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end. CHAD: While you were doing that, you supported yourselves from the consulting revenue. BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful. CHAD: And how did you decide how much money you should be seeking to raise? BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision. But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round? Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there. CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were? BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful. So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority. CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this." BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling. Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us. And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful. One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up. CHAD: [laughs] BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this. CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right? BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things. The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses. And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that. And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes. CHAD: [laughs] BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about. CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that? BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing. CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right? BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running. But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that. Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape. CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Benjie De Groot.

In episode 23 of Venture Confidential, Heavybit's Jesse Robbins interviews Jonathan Heiliger of Vertex Ventures on counseling founders and making big infrastructure bets.

In episode 44 of The Secure Developer, Guy Podjarny sits down with guest host Simon Maple of Snyk to reflect back on the numerous guests he's had on the show throughout 2019, and the many security lessons and insights shared along the way. The post Ep. #44, Year in Review with Guy Podjarny appeared first on Heavybit.

In episode 43 of The Secure Developer, Guy joins Stu Hirst, Principle Cloud Security Engineer at Just Eat. They discuss Stu's journey into cloud security, avoiding burnout, cultivating better hiring practices, and the importance of failing fast. The post Ep. #43, Combatting Security Burnout with Stu Hirst of Just Eat appeared first on Heavybit.

In episode 42 of The Secure Developer, Guy speaks with Kate Whalen, a security engineer at The Guardian, to discuss news media security and advocating security across many teams within a large organization. The post Ep. #42, News Media Security with Kate Whalen of The Guardian appeared first on Heavybit.

In episode 41 of The Secure Developer, Guy talks with Sara Dunnack, a security engineer at InVision. They discuss methods for improving communication between DevSecOps, AppSec, and Engineering teams within an organization. The post Ep. #41, Optimizing Team Communication with Sara Dunnack of InVision appeared first on Heavybit.

In episode 40 of The Secure Developer, Guy speaks with Brian Sodano, Director of Engineering at Liberty Mutual Insurance. They unpack what happens to security when a company goes through a large-scale digital transformation, and ruminate on the future of the security industry. The post Ep. #40, Large-Scale Digital Transformation with Brian Sodano of Liberty Mutual appeared first on Heavybit.

In episode 39 of The Secure Developer, Guy is joined by Mohan Yelnadu, Head of AppSec at Prudential. They discuss Mohan's journey from pen tester to DevSecOps consultant, security threat modeling, and his 6 principles of continuous security. The post Ep. #39, Build, Break, and Defend with Mohan Yelnadu of Prudential appeared first on Heavybit.

In episode 38 of The Secure Developer, Guy speaks with Andy Ellis, CSO of Akamai. They discuss streamlining customer assurance, the role of an incidents coordinator, and the value of transparency between a security company and their associates. The post Ep. #38, You Own It, You Secure It with Andy Ellis of Akamai appeared first on Heavybit.

In episode 37 of The Secure Developer, Guy speaks with James Kaplan of McKinsey & Co. James describes his journey into the telecommunications industry, and how many longstanding companies must reevaluate security practices when going through a digital transformation. The post Ep. #37, Security Transformation with James Kaplan of McKinsey & Company appeared first on Heavybit.

In episode 36 of The Secure Developer, Guy is joined by Peter Oehlert of Smartsheet. They discuss holistic security approaches, understanding various categories of risk, and how the different teams in a large organization can work together to improve security. The post Ep. #36, Holistic Security with Peter Oehlert of Smartsheet appeared first on Heavybit.

In episode 35 of The Secure Developer, Guy is joined by Robert C. Seacord of NCC Group, who champions the continued practice of coding security in C and C++, and offers practical advantages to using various programming languages in the Agile era. The post Ep. #35, Secure Coding in C/C++ with Robert C. Seacord of NCC Group appeared first on Heavybit.

In episode 34 of The Secure Developer, Guy speaks with Siren Hofvander of Cybercom about her enlightening journey from the digital medical space to running a secure developer consulting team, as well as her empathy-driven ethos in the one-size-fits-all security world. The post Ep. #34, Positive Security with Siren Hofvander of Cybercom appeared first on Heavybit.

In episode 33 of The Secure Developer, Guy is joined by Leif Dreizler and Eric Ellett of Segment. They discuss motivating security teams, the importance of investing time in your business relationships, and the longterm rewards of proper security training. The post Ep. #33, Engineering Teams with Leif Dreizler and Eric Ellett of Segment appeared first on Heavybit.

In episode 32 of The Secure Developer, Duncan Godfrey from Auth0 speaks with Guy about his journey into security. Duncan also shares great insights into staying secure and compliant in a fast moving environment. The post Ep. #32, Security and Compliance with Duncan Godfrey of Auth0 appeared first on Heavybit.

In episode 31 of The Secure Developer, Guy is joined by Tanya Janca, Cloud Advocate at Microsoft. Tanya shares insights, from her early days leading software teams for the Canadian government, to evangelizing software security at Microsoft. The post Ep. #31, Evangelizing Security with Tanya Janca of Microsoft appeared first on Heavybit.

In episode 30 of The Secure Developer, Guy speaks with Justin Somaini, a security industry leader and Founder of Somaini LLC. They discuss how security theory has changed over the past 25 years, and how AppSec can be improved by educating the developer community. The post Ep. #30, Improving Security Culture with Justin Somaini appeared first on Heavybit.

In episode 29 of The Secure Developer, Guy sits down with Liran Tal, Developer Advocate at Snyk, to discuss the state of open source, Docker security, and developer infrastructure. The post Ep. #29, The State of Open Source & Docker Security appeared first on Heavybit.

In episode 28 of The Secure Developer, Guy is joined by Jason Chan of Netflix to discuss simplifying the security process for software developers, as well as some of the open source projects Netflix has shared with the community. The post Ep. #28, Developer Empathy with Jason Chan of Netflix appeared first on Heavybit.

In episode 27 of The Secure Developer, Guy is joined by Jeff McAffer, director of Microsoft's Open Source Programs Office, who shares his insights on how to keep open source projects sustainable and secure for the whole community. The post Ep. #27, Open Source Security with Jeff McAffer of Microsoft appeared first on Heavybit.

In episode 26 of The Secure Developer, Guy is joined by Jim Manico, founder of Manicode Security, to discuss insights from his long career as a security educator, and to explore the importance of developer training in application security. The post Ep. #26, Security Education with Jim Manico appeared first on Heavybit.

In episode 25 of The Secure Developer, Guy meets with Simon Bennett, VP Product at Bitnami, to discuss golden images, image layering, and how Bitnami helps accelerate application delivery across multiple clouds. The post Ep. #25, Golden Images with Simon Bennett of Bitnami appeared first on Heavybit.

In episode 24 of The Secure Developer, Guy is joined by Omer Levi Hevroni, DevSecOps Engineer at Soluto, to discuss application security, OWASP, security ‘mavens,' and more. The post Ep. #24, Application Security with Omer Levi Hevroni appeared first on Heavybit.

In episode 23 of The Secure Developer, Guy speaks with Zach Powers, CISO of One Medical, to discuss the evolution of security at One Medical, what he looks for when hiring for his team, and why automation is a must. The post Ep. #23, Automation with One Medical's Zach Powers appeared first on Heavybit.

In episode 22 of The Secure Developer, Guy meets with Stina Ehrensvärd, founder and CEO of Yubico, to explore how hardware solutions like YubiKey can be an effective approach to authentication and security. The post Ep. #22, Authentication with Yubico's Stina Ehrensvärd appeared first on Heavybit.

In episode 21 of The Secure Developer, Guy meets with Julie Tsai, Cybersecurity Leader and DevSecOps Practitioner, to discuss ways to manage secure systems and bridge the gap between security and DevOps. The post Ep. #21, Managing Security with Cybersecurity Leader and DevSecOps Practitioner Julie Tsai appeared first on Heavybit.

In episode 20 of The Secure Developer, Guy speaks to Dan Cornell, CTO of Denim Group, the developer security firm behind ThreadFix, a vulnerability resolution platform. The post Ep. #20, Using ThreadFix with Dan Cornell of Denim Group appeared first on Heavybit.

In episode 19 of The Secure Developer, Guy meets with Allison Miller to discuss the ways technology and security have intersected throughout her career. The post Ep. #19, Measuring Security with Allison Miller appeared first on Heavybit.

In episode 18 of The Secure Developer, Guy meets with Marten Mickos, CEO of HackerOne, a platform for vulnerability coordination and a bug bounty program that helps developers test and build more secure systems. The post Ep. #18, Collaborative Security with HackerOne's Marten Mickos appeared first on Heavybit.

In episode 17 of The Secure Developer, Guy meets up with Adrian Colyer, Venture Partner at Accel and author of The Morning Paper, a daily recap of academic articles in computer science. The pair investigates how researchers are discovering new side-channel attacks and vulnerabilities that look, at first glance, like they're out of a science fiction or spy novel. The post Ep. #17, Security Research with The Morning Paper's Adrian Colyer appeared first on Heavybit.

In episode 16 of The Secure Developer, Guy is joined by Masha Sedova, co-founder of Elevate Security, to discuss how training for employees (even developers) can help companies stay one step ahead of the pack when it comes to preventing a breach. The post Ep. #16, Security Training with Elevate's Masha Sedova appeared first on Heavybit.

In episode 15 of The Secure Developer, Guy is joined by James Governor, Analyst and Co-founder of RedMonk, a developer-focused industry analyst firm. The pair discusses multiple ways that companies can be incentivized, and how they can incentivize others, to invest in and improve security. The post Ep. #15, Enterprise Security with RedMonk's James Governor appeared first on Heavybit.

In the latest episode of The Secure Developer, Guy is joined by Geoff Belknap, Chief Security Officer at Slack. Geoff discusses what drew him into security and reveals why it's critical for security teams to be recognized as a full-fledged member of engineering. He explains why it makes sense for companies to develop a track record of transparency and actively encourage community participation through bug bounty programs. Geoff also concludes that companies should encourage basic security hygiene rather than seek a silver bullet that does not exist. The post Ep. #14, How Slack Stays Secure During Hyper Growth appeared first on Heavybit.

In the latest episode of The Secure Developer, Guy is joined by Shaun Gordon, Chief Security Officer at New Relic. Shaun tells us how he got into a career in security and explains how the role of security has evolved at New Relic. He reveals their philosophy of adapting security processes to fit the way developers do their job and emphasizes the importance of exception alerts, scorecards, and automation to support a rapidly scaling organization. The post Ep. #13, How New Relic Does Security appeared first on Heavybit.

In the latest episode of The Secure Developer, Guy is joined by Molly Crowther from Pivotal. Molly discusses her role in managing security at Cloud Foundry, an open source cloud platform on which developers can build, deploy and run applications. She explains their security triage and CVE process and reveals some of the challenges of working within the large ecosystem of diverse companies that make up the Cloud Foundry Foundation. Molly also talks about how she fulfills her role of wearing many hats as a representative of both Pivotal and the open source foundation. The post Ep. #12, Keeping Cloud Foundry Secure appeared first on Heavybit.