Podcasts about devopsdays

  • 90PODCASTS
  • 278EPISODES
  • 40mAVG DURATION
  • 1MONTHLY NEW EPISODE
  • Apr 22, 2025LATEST

POPULARITY

20172018201920202021202220232024


Best podcasts about devopsdays

Latest podcast episodes about devopsdays

Kodsnack
Kodsnack 639 - Ingen presentation är den andra lik, med Daniel Raniz Raneland

Kodsnack

Play Episode Listen Later Apr 22, 2025 57:26


Fredrik snackar med Daniel Raniz Raneland om att skapa och hålla presentationer. Ämnen finns överallt bara man börjar se dem, och man ska inte göra det svårt för sig. Att berätta hur man själv lärt sig något blir en alldeles utmärkt presentation. Skulle du kunna skriva en bloggpost om något? Då kan du också göra en presentation av det, du behöver bara anpassa formen lite. En presentation behöver vara lite mer av en resa och ge lite mer av en kontext. Du vet inte vilken kunskap du sitter på som är vardagsmat för dig men ett guldkorn för någon annan! Våga hålla en presentation! Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Raniz Factor10 Besöket i Varberg - då avsnitt 609 spelades in Softhouse Raniz blogg Jfokus TDD Kodkata Parprogrammering Sessionize Seecfp - mejllista Devoxx We are developers Berlin Raniz Øredevpresentation 2024 - Pipeline patterns and antipatterns Swetugg Slidev - koda dina presentationer i Markdown, HTML, och CSS Mermaid Magic code Stöd oss på Ko-fi! En version av Raniz Java på AWS lambda-presentation Papercall Martin Fowler Myconf - konferens i Varberg i maj Devopsdays i Zürich NDC Titlar Myndig på mjukvaruutveckling Vad gör ni här? Jag skriver abstrakt Alldeles för höga förväntningar En väldigt bra struktur En chans att dra sig ur Slutsatsen i början Prata väldigt fort istället 22 minuter inspelat material Ingen presentation är den andra lik En konferens i födelsedagspresent Broar som leder vidare

LowOpsCast
[VIDEO] #22 Episódio DevOps, Automação e Comunidade com Levi Leopoldino Alves (Levinux)

LowOpsCast

Play Episode Listen Later Mar 7, 2025 90:34


LowOpsCast
[AUDIO] #22 Episódio DevOps, Automação e Comunidade com Levi Leopoldino Alves (Levinux)

LowOpsCast

Play Episode Listen Later Mar 7, 2025 90:34


The IaC Podcast
Behind the Sessions of DevOpsDays TLV

The IaC Podcast

Play Episode Listen Later Nov 28, 2024 26:20


Join Omry Hay, Co-founder and CTO of env0, as he hosts a special episode of The IaC Podcast from DevOpsDays Tel Aviv. Hear his conversations with guests about IaC trends, key lessons, and what's next for the DevOps community!Thank you to our amazing guests for this DevOpsDays edition:Roi Ravhon - Co-founder & CEO at FinOut‍Shiran Melamed - DevOps Group Lead at JFrog‍Baruch Sagodursky - Developer Relations & DPE Advocacy at Gradle‍Yishai Beeri - CTO at LinearB‍Shem Magnezi - Co-Founder & CTO at Wilco‍ Avishai Ish-Shalom‍

Unveiled: GovCon Stories
From Chaos to Clarity: Mastering Leadership in Government Contracting

Unveiled: GovCon Stories

Play Episode Listen Later Oct 9, 2024 43:54


Imagine this: You're fresh into government contracting, stepping into a small business as a new managing partner. The stakes are high. Not only are you navigating a whole new market, but you also have the pressure of enabling a company's growth on your shoulders. Sound overwhelming? You bet! But it's also where the magic happens.And here's the exciting part: it's not just about surviving those early hurdles. It's about thriving in them—supporting growth of a company through new territory, quickly driving success, and building something with untapped potential. This is more than just a story of business management; it's about creating breakthroughs that have a lasting impact. So, whether you're an entrepreneur, a business leader, or just curious about how innovation can change the game, we're about to dive into the insights that can help you lead boldly and think differently. Are you ready to lead boldly? Let's get into it!Guest Bio:Seni Aguiar is the Chief Operating Officer at Digital Charter, Inc. (DCIT), where she has played a pivotal role in securing Prime contracts and driving operational excellence for nearly three years. A PMP-certified professional with over a decade of experience in government contracting and IT services, Seni is recognized for her versatile leadership across business operations, HR, business development, and marketing. She is known for streamlining processes and fostering innovation within the organization.Seni was honored as a DCA Power Woman in GovCon for her contributions to the industry and has shared her expertise at events such as DevOps Days and CodeCamp, where she highlights networking strategies and the power of LinkedIn in advancing professional careers. As a lead organizer for the DevOps Days Tampa Bay Conference for three consecutive years, she has helped bring together tech leaders and enthusiasts from across the country.Outside of work, Seni is an avid reader and is taking professional voice lessons to perfect her car karaoke skills. She and her husband live in Florida with their three energetic boys, whose activities—ranging from sunrise surf sessions and soccer tournaments to band performances—keep them constantly on the move. With her unique blend of professional and personal accomplishments, Seni is a leader who inspires those around her by balancing career success with a vibrant, family-focused life.Call(s) to Action:Help spread the word about Unveiled: GovCon Stories: https://shows.acast.com/unveiled-govcon-storiesDo you want to be a guest or recommend a topic that you would like to learn or hear about on the podcast? Let us know through our guest feedback and registration form.Links:Digital Charter Website: https://digitalcharter.com/ Digital Charter LinkedIn: https://www.linkedin.com/company/digitalcharter Seni Aguiar Linkedin: https://www.linkedin.com/in/seniaguiar/ Hosted on Acast. See acast.com/privacy for more information.

The IaC Podcast
Chef to Pulumi - Exploring IaC Tools with Matty Stratton

The IaC Podcast

Play Episode Listen Later Sep 30, 2024 26:56


How did Chef and Puppet shape the early days of Infrastructure as Code? Join Matty Stratton as he shares his experiences with these foundational tools and how they paved the way for modern IaC practices. We explore the power of open-source solutions and how they've transformed DevOps workflows.Matty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and a global organizer of the DevOpsDays set of conferences.Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide.

Software Defined Talk
Episode 486: Platform Engineering vs. DevOps

Software Defined Talk

Play Episode Listen Later Sep 27, 2024 55:49


This week, we discuss the intersection of DevOps and Platform Engineering, the latest WordPress drama, and some M&A tips for Intel. Plus, a few recommendations on using iPhone mirroring. Watch the YouTube Live Recording of Episode (https://www.youtube.com/watch?v=SGxrtrRWtvc) 486 (https://www.youtube.com/watch?v=SGxrtrRWtvc) Runner-up Titles I'm out of nuts, time to podcast System Settings Security, it never ends Fancy Sysadmins Providing needles for your balloons Batman's not real What's the opposite of a taboo DevOps is not the tooling Software gets old Release the turbo button Rundown ‎Windows App (https://apps.apple.com/us/app/windows-app/id1295203466?mt=12) PlatformDays vs. DevOpsDays Has DevOps been "worth it" to you? (https://www.reddit.com/r/devops/comments/1f5srog/has_devops_been_worth_it_to_you/) R (https://newsletter.cote.io/p/how-devops-can-come-back-from-the)enaming a few DevOpsDays (https://newsletter.cote.io/p/how-devops-can-come-back-from-the) t (https://newsletter.cote.io/p/how-devops-can-come-back-from-the)o PlatformDays (https://newsletter.cote.io/p/how-devops-can-come-back-from-the). Tossed Salads And Scrumbled Eggs (https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-eggs/) Digital Transformation Gone Wrong How Sonos Botched an App and Infuriated Its Customers (https://www.bloomberg.com/opinion/articles/2024-09-23/how-sonos-botched-an-app-and-infuriated-its-customers) FAA air traffic control modernization efforts are a mess (https://www.theregister.com/2024/09/24/us_air_traffic_control_system_upgrade/) Apple Apple launches iPhone 16 with Apple Intelligence (https://finance.yahoo.com/news/apple-launches-iphone-16-with-apple-intelligence-183724722.html) Apple removes Control-click option for skipping Gatekeeper in macOS Sequoia (https://appleinsider.com/articles/24/08/06/apple-removes-control-click-option-for-skipping-gatekeeper-in-macos-sequoia) Intel Qualcomm Approached Intel About a Takeover in Recent Days (https://www.wsj.com/business/deals/qualcomm-approached-intel-about-a-takeover-in-recent-days-fa114f9d) Intel launches new AI chips as takeover rumors swirl (https://finance.yahoo.com/news/intel-launches-new-ai-chips-as-takeover-rumors-swirl-153749461.html) Wordpress Drama Matt Mullenweg calls WP Engine a 'cancer to WordPress' and urges community to switch providers (https://techcrunch.com/2024/09/22/matt-mullenweg-calls-wp-engine-a-cancer-to-wordpress-and-urges-community-to-switch-providers/) Matt Mullenweg needs to step down from WordPress.org leadership ASAP (https://notes.ghed.in/posts/2024/matt-mullenweg-wp-engine-debacle/) WordCamp US & Ecosystem Thinking (https://ma.tt/2024/09/ecosystem-thinking/) WP Engine responds (https://wpengine.com/wp-content/uploads/2024/09/Cease-and-Desist-Letter-to-Automattic-and-Request-to-Preserve-Documents-Sent.pdf) Relevant to your Interests IBM quietly axing thousands of jobs, source claims (https://www.theregister.com/2024/09/18/ibm_job_cuts/) Comment on #1262 Health of Linkerd project (https://github.com/cncf/toc/issues/1262#issuecomment-2357919000) Starbucks New CEO on Return to Office: ‘We're All Adults Here' (https://www.bloomberg.com/news/articles/2024-09-19/starbucks-new-ceo-on-return-to-office-we-re-all-adults-here) Yaak Is Now Open Source (https://yaak.app/blog/now-open-source) OpenAI to Decide Which Backers to Let Into $6.5 Billion Funding (https://www.bloomberg.com/news/articles/2024-09-19/openai-to-decide-which-backers-to-let-into-6-5-billion-funding?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axiosprorata&stream=top) Google rolls out automatic passkey syncing via Password Manager (https://techcrunch.com/2024/09/19/google-rolls-out-automatic-passkey-syncing-via-password-manager/) A Leader in 2024 Gartner Magic Quadrant for Container Management (https://cloud.google.com/blog/products/containers-kubernetes/a-leader-in-2024-gartner-magic-quadrant-for-container-management/) Companies Like to Pit Internal Teams Against Each Other. Bad Idea. (https://www.wsj.com/lifestyle/workplace/competition-companies-employees-9099a425) Microsoft has announced new efforts to improve its cybersecurity systems (https://www.neowin.net/news/microsoft-has-announced-new-efforts-to-improve-its-cybersecurity-systems/) Oracle Sees $104 Billion Sales in Fiscal 2029 on Cloud Expansion (https://www.bloomberg.com/news/articles/2024-09-12/oracle-sees-104-billion-sales-in-fiscal-2029-on-cloud-expansion) Oracle Runs OCI Clones At Rival AWS, Google, And Azure Clouds (https://www.nextplatform.com/2024/09/10/oracle-runs-oci-clones-at-rival-aws-google-and-azure-clouds/) Oracle and Amazon Web Services Announce Strategic Partnership (https://www.oracle.com/news/announcement/ocw24-oracle-and-amazon-web-services-announce-strategic-partnership-2024-09-09/) John Mulaney got paid $2M to show up to Dreamforce and say this (https://softwaredefinedtalk.slack.com/archives/C04EK1VBK/p1727125631774399) The Cloud is Darker and More Full of Terrors (https://www.chrisfarris.com/post/sect2024/?ck_subscriber_id=1141233388) Kaspersky deletes itself, installs UltraAV antivirus without warning (https://www.bleepingcomputer.com/news/security/kaspersky-deletes-itself-installs-ultraav-antivirus-without-warning/) IBM AI simply not up to the job of replacing staff (https://www.theregister.com/2024/09/24/ibm_layoffs_ai_talent/) More Americans – especially young adults – are regularly getting news on TikTok (https://www.pewresearch.org/short-reads/2024/09/17/more-americans-regularly-get-news-on-tiktok-especially-young-adults/) Meta Unveils 'Orion' Augmented Reality Glasses (https://www.macrumors.com/2024/09/25/meta-augmented-reality-glasses/) Google Rehired Noam Shazeer With Major Payout, (https://uk.finance.yahoo.com/news/google-rehired-noam-shazeer-major-141808501.html) Congress grills CrowdStrike about multibillion-dollar July outage (https://www.washingtonpost.com/technology/2024/09/24/congress-grills-crowdstrike-about-multibillion-dollar-july-outage/) Wiz In Talks to Sell Shares at Valuation as High as $20 Billion (https://www.bloomberg.com/news/articles/2024-09-24/cyber-firm-wiz-in-talks-to-sell-shares-at-20-billion-valuation) Google files Brussels complaint against Microsoft cloud business (https://archive.ph/VtRiP) Marques Brownlee says ‘I hear you' after fans criticize his new wallpaper app (https://www.theverge.com/2024/9/24/24253023/mkbhd-panels-wallpaper-app-response-criticism) Progress update on Microsoft's Secure Future Initiative (https://www.microsoft.com/en-us/security/blog/2024/09/23/securing-our-future-september-2024-progress-update-on-microsofts-secure-future-initiative-sfi/?ref=runtime.news) OpenAI rolls out Advanced Voice Mode with more voices and a new look (https://techcrunch.com/2024/09/24/openai-rolls-out-advanced-voice-mode-with-more-voices-and-a-new-look/) Intel launches new AI chips as takeover rumors swirl (https://finance.yahoo.com/news/intel-launches-new-ai-chips-as-takeover-rumors-swirl-153749461.html) Dozens of Fortune 100 companies have unwittingly hired North Korean IT workers, according to report (https://therecord.media/major-us-companies-unwittingly-hire-north-korean-remote-it-workers) Nonsense Grocery chains are bigger than ever. See who runs the stores near you. (https://www.washingtonpost.com/business/interactive/2024/grocery-store-owners-map-kroger-albertsons-merger/?utm_campaign=wp_post_most&utm_medium=email&utm_source=newsletter&wpisrc=nl_most&carta-url=https%3A%2F%2Fs2.washingtonpost.com%2Fcar-ln-tr%2F3f166c7%2F66f2df1965e56477aea35218%2F5ed96de79bbc0f3a78a62db3%2F8%2F54%2F66f2df1965e56477aea35218) Conferences Cloud Foundry Day EU (https://events.linuxfoundation.org/cloud-foundry-day-europe/), Karlsruhe, GER, Oct 9, 2024, 20% off with code CFEU24VMW. VMware Explore Barcelona (https://www.vmware.com/explore/eu), Nov 4-7, 2024. Coté speaking. SREday Amsterdam (https://sreday.com/2024-amsterdam/), Nov 21, 2024. Coté speaking (https://sreday.com/2024-amsterdam/Michael_Cote_VMwarePivotal_We_Fear_Change), 20% off with code SRE20DAY. DevOpsDayLA (https://www.socallinuxexpo.org/scale/22x/events/devopsday-la) at SCALE22x (https://www.socallinuxexpo.org/scale/22x), March 6-9, 2025, discount code DEVOP SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: Use Magnifier on your iPhone or iPad (https://support.apple.com/en-us/105102) Matt: Ghosts (https://www.imdb.com/title/tt8594324/) Coté: The Modern Myths (https://press.uchicago.edu/ucp/books/book/chicago/M/bo52584433.html). Photo Credits Header (https://unsplash.com/photos/a-black-and-white-photo-of-a-pattern-_QcLpud-gD0) Artwork (https://unsplash.com/photos/person-typing-on-silver-laptop-computer-ANGrwTKxjlk)

The Cloud Gambit
Navigating Community, Open Source, and Brazilian Jiu-Jitsu with Tim Banks

The Cloud Gambit

Play Episode Listen Later Sep 24, 2024 59:52 Transcription Available


Send us a textIn this episode, we dive deep into the multifaceted world of Tim Banks, a Staff Solutions Architect at Caylent. Tim shares his remarkable journey from the US Marine Corps to becoming a prominent voice in the tech community. We explore the parallels between his experiences in tech, Brazilian Jiu-Jitsu, and community building, uncovering valuable insights on personal growth, professional development, and the state of open source. Whether you're a seasoned tech professional, a community organizer, or someone looking to break into the industry, this episode offers valuable insights on navigating the complex landscape of technology, community, and personal growth.Where to Find Tim BanksTwitter: https://x.com/elchefeLinkedIn: https://www.linkedin.com/in/timjb/GitHub: https://github.com/timbanksYouTube: https://www.youtube.com/@elchefenegroTikTok: https://www.tiktok.com/@timbanks71Blog: https://tim-banks.ghost.io/Show LinksCaylent: https://caylent.com/CNCF: https://www.cncf.io/Apache Software Foundation: https://www.apache.org/DevOpsDays: https://devopsdays.org/Elastic License Change: https://www.elastic.co/blog/elastic-license-v2OpenSearch (Amazon's Elasticsearch Fork): https://opensearch.org/Follow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambit

The IaC Podcast
From DevOps Days to Platform Engineering with Patrick Debois

The IaC Podcast

Play Episode Listen Later Sep 10, 2024 24:29


What does the future hold for DevOps and platform engineering? Patrick Debois, the creator of DevOps Days, shares his thoughts on the evolution of DevOps practices. From the emergence of AI-driven automation to the challenges of building effective internal platforms, this episode covers the key trends and developments shaping the industry. Learn about the skills and strategies that will be crucial for the next generation of professionals.Patrick Debois is a versatile technologist with a breadth of experience across Dev, Sec, and Ops. Known for his aptitude in harnessing emerging ideas , he skillfully guides teams and advises businesses ranging from startups to enterprises in their journey. Recognized as a trusted ally among dev, sec, ops communities, and beyond, he is currently immersing himself in the world of AI & Machine Learning continuously pushing the boundaries of his technical expertise.

Voice of the DBA
A Lack of Architecture and Planning

Voice of the DBA

Play Episode Listen Later Aug 18, 2024 2:36


A few weeks ago, I was sitting in the audience, waiting for my turn to speak at DevOps Days in Minneapolis. Just before me, Xe Iaso delivered a funny and thought-provoking talk on building a social network on a whiteboard. It was very well done and had me feeling nervous about following that session. The talk is a bit of a satirical look at an interview Xe had for a company that tried to get them to derive an architecture for a large distributed system. It was interesting to hear Xe note that often we have architecture diagrams of what we'd like to have, but never an explanation of how we implement a large system, especially one that has to grow as our workload grows. Read the rest of A Lack of Architecture and Planning

NerdCast
Nerd na Cloud 6 - Aprendendo com a comunidade no DevOpsDays

NerdCast

Play Episode Listen Later May 31, 2024 42:54


Neste sexto episódio do Nerd na Cloud, vamos falar sobre a nova forma de trabalho dos DevOps e como foi o evento DevOpsDays com a presença da Magalu Cloud. MAGALU CLOUD Saiba mais sobre o DevOpsDays: https://jovemnerd.page.link/Magalu_Cloud_Dev_Ops_Days Clique e saiba mais sobre o Magalu Cloud: https://jovemnerd.page.link/Magalu_Cloud_Nerd_Na_Cloud_6 Seja um parceiro do Magalu Cloud: https://jovemnerd.page.link/Magalu_Cloud_Parcerias_6 ARTE DA VITRINE: Randall Random EDIÇÃO COMPLETA POR RADIOFOBIA PODCAST E MULTIMÍDIA Mande suas críticas, elogios, sugestões e caneladas para nerdcast@jovemnerd.com.br

NerdCast
NerdCast 934 - Gambiarras Extremas e Criativas da Cultura Maker

NerdCast

Play Episode Listen Later May 31, 2024 112:43


Quem nunca fez um submarino em casa? No NerdCast de hoje, vamos falar tudo sobre a Cultura Maker e como foi a evolução do Do It Yourself! Baixe a versão Wallpaper da vitrine AMAZON PODCASTS Baixe agora mesmo o aplicativo do Amazon Music e ouça gratuitamente o Podcast Caso Bizarro com episódio extra exclusivo. Um podcast de horror com comédia, histórias bizarras que aconteceram no mundo ou casos enviados por ouvintes. O episódio extra sai toda quarta-feira, não perca! https://jovemnerd.page.link/Amazon_Music_Caso_Bizarro_NerdCast  MAGALU CLOUD Saiba mais sobre o DevOpsDays: https://jovemnerd.page.link/Magalu_Cloud_DevOpsDay_NerdCast Ouça o Nerd na Cloud de hoje: https://jovemnerd.page.link/Nerd_Na_Cloud_DevOpsDay Conheça o Magalu Cloud: https://jovemnerd.page.link/Magalu_Cloud_NerdCast_6 Seja parceiro do Magalu Cloud: https://jovemnerd.page.link/Magalu_Cloud_Parcerias_NerdCast_6 MAGALU CARREIRAS  Faça parte do time Magalu: https://jovemnerd.page.link/Conheca_Magalu_Carreiras SOCIEDADE DA VIRTUDE  Assista a 1ª Temporada completa: https://jovemnerd.page.link/Sociedade_da_Virtude CONFIRA OS OUTROS CANAIS DO JOVEM NERD  E-MAILS Mande suas críticas, elogios, sugestões e caneladas para nerdcast@jovemnerd.com.br APP JOVEM NERD: Google Play Store |  Apple App Store PARTE DA VITRINE: Randall Random EDIÇÃO COMPLETA POR RADIOFOBIA PODCAS T E MULTIMÍDIA

Cabeça de Lab
COMUNIDADES SOBRE KUBERNETES

Cabeça de Lab

Play Episode Listen Later May 23, 2024 57:32


Neste episódio, discutiremos a importância das comunidades sobre Kubernetes e dos eventos de tecnologia, tanto nacionais quanto internacionais, e como eles fomentam a inovação e a troca de conhecimento. Falaremos de eventos como o KubeCon, DevOpsDays, Kubernetes Community Days, entre outros, que são fundamentais para a evolução contínua das tecnologias de código aberto e para a disseminação das melhores práticas entre profissionais de todo o mundo. Curtiu? Aperte o play e venha conosco explorar o fascinante mundo das comunidades de tecnologia! E olha só o spoiler: você conhecerá um pouco mais sobre a Magalu Cloud. Edição completa por Rádiofobia Podcast e Multimídia: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://radiofobia.com.br/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ --- Nos siga no Twitter e no Instagram: @luizalabs @cabecadelab Dúvidas, cabeçadas e sugestões, mande e-mail para o ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠cabecadelab@luizalabs.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ou uma DM no Instagram Participantes: ERIVALDO LOPES | https://www.linkedin.com/in/erivaldolopes/ YOHAN RODRIGUES | ⁠https://www.linkedin.com/in/yohan-rodrigues/

Open at Intel
Nerdy About Networks

Open at Intel

Play Episode Listen Later Jan 24, 2024 26:04


Fen Aldrich, a Developer Advocate with Equinix, talks about their open source partner program and giving back to the open source community. Fen highlights collaborative relationships they've established with key projects, serving as a testing ground and leveraging their surplus of hardware and network resources. We discussed that appreciating the human aspect of tech is crucial, as all technical systems ultimately depend on human innovation and interaction. We also nerd out a bit about the basics of networking and the technology underneath the magic we all take for granted. 00:00 Introduction 02:57 Deep Dive into Networking Basics 09:33 Exploring the Importance of Corporate Open Source Contributions 19:54 Understanding the Interconnectedness in Open Source Guest: Fen Aldrich is a Developer Advocate at Equinix Metal and an organizer for DevOpsDays events in the northeast US. Passionate about Resilience Engineering and Mental Health in the tech industry, they believe that every technology problem is ultimately, when you get right down to it, a people challenge. Find their work at speaking.crayzeigh.com, and connect on twitter @crayzeigh or mastodon @crayzeigh@hachyderm.io

Kubernetes Bytes
DevOpsDays Boston - Helping developers be more productive in a multi-cloud world

Kubernetes Bytes

Play Episode Listen Later Oct 25, 2023 35:02


In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Michael o'leary and Ibett A to talk about how developers can build multi-cloud secure architectures using Kubernetes and the principles of Shift Left and DevSecOps. Check out the KubernetesBytes website: https://www.kubernetesbytes.com/ Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytes Ads: Ready to shop better hydration, use "kubernetesbytes" to save 20% off anything you order.Timestamps: 00:00 Interview with Michael o'leary 18:50 Interview with Ibett AShow links: Boston Kubernetes Meetup - https://www.meetup.com/boston-kubernetes-meetup/

Kubernetes Bytes
DevOpsDays Boston - Platform Engineering and Internal Developer Platforms

Kubernetes Bytes

Play Episode Listen Later Oct 25, 2023 31:12


In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Alexandre Pauwels and Kevin Scheunemann at DevOps Days Boston to talk all about IDPs and Platform Engineering. The discussion focuses on how organizations can build IDPs from open source tools and the how DevOps, SRE and Platform Engineering teams work together. Check out the KubernetesBytes website: https://www.kubernetesbytes.com/ Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytesAds: Ready to shop better hydration, use "kubernetesbytes" to save 20% off anything you order.Timestamps: 00:00 Interview with Alexandre Pauwels 16:00 Interview with Kevin ScheunemannShow links: https://bitmantle.com/

Kubernetes Bytes
DevOpsDays Boston - Real value of community

Kubernetes Bytes

Play Episode Listen Later Oct 25, 2023 42:41


In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Paul Bruce and Don Luchini - the organizers of DevOpsdays Boston and talk about the value of community, what DevOps means to them and how the event has evolved over the years. Listen in to learn more about what to expect when you attend one of these events or meetups in the future, and the guests also share their perspective around DevOps, Kubernetes and Platform Engineering Check out the KubernetesBytes website: https://www.kubernetesbytes.com/ Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytes Ads: Ready to shop better hydration, use "kubernetesbytes" to save 20% off anything you order. Try Nom Nom today, go to https://trynom.com/kubernetesbytes and get 50% off your first order plus free shipping.Timestamps: 00:00 Interview with Paul Bruce 22:25 Interview with Don LuchiniJoin the DevOpsDays Boston slack - https://bostondevops.github.io/

The Cloudcast
DevOps, OSS Communities & WASM in the Public Cloud

The Cloudcast

Play Episode Listen Later May 31, 2023 52:10


Bridget Kromhout (@bridgetkromhout, Principal PM @Azure) & Ralph Squillace (@ralph_squillace, Principal PM @Azure) talk about DevOps, Public Cloud involvement with OSS communities, CNCF, WASM and OSS Communities. SHOW: 724CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:Datadog Synthetic Monitoring: Frontend and Backend Modern MonitoringEnsure frontend issues don't impair user experience by detecting user-facing issues with API and browser tests with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt. CloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSHOW NOTES:Open Source on AzureArrested DevOps PodcastDevOps DaysWeb Assembly, Docker, Containerd, and Kubernetes (YouTube)Microsoft Open SourceRevive WG-LTS · Issue #7259 · kubernetes/community · GitHubKubernetes 1.23: Dual-stack IPv4/IPv6 Networking Reaches GA  Develop serverless WebAssembly apps with Spin | Fermyon • Experience the next wave of cloud computing. GitHub - jpetazzo/container.training: Slides and code samples for training, tutorials, and workshops about Docker, containers, and Kubernetes.xkcd: Dependency Topic 1 - Bridget, welcome back! It's been over 7 years since you were last on the show! Ralph, welcome to the show! Topic 2 - Bridget, let's talk about your journey. You were involved with Arrested DevOps Podcast & DevOps Days.  Your career has changed a bit from the Developer Advocate path into the PM side. Tell us a little bit about that.Topic 3 -  For those that aren't familiar, tell everyone about OSS @ Azure. How does Azure work with the Linux Foundation and the CNCF?Topic 4 - Ralph, let's talk about Web Assembly a bit. How did you get involved? How does Web Assembly fit into the bigger Azure architecture? How does it compare to Azure Functions?Topic 5 - We last talked about WASM probably in the summer last year. Momentum appears to have picked up dramatically judging by interest at recent KubeCon events. From your perspective, how has the space evolved and changed in the last 12 months?Topic 6 - How is Web Assembly different from the past promises of PaaS? What are some of the unique capabilities and use-cases that have evolved?FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Screaming in the Cloud
Combining Community and Company Employees with Matty Stratton

Screaming in the Cloud

Play Episode Listen Later Mar 16, 2023 40:08


Matty Stratton, Director of Developer Relations at Aiven, joins Corey on Screaming in the Cloud for a friendly debate on whether or not company employees can still be considered community members. Corey says no, but opens up his position to the slings and arrows of Matty in an entertaining change of pace. Matty explains why he feels company employees can still be considered community members, and also explores how that should be done in a way that is transparent and helpful to everyone in the community. Matty and Corey also explore the benefits and drawbacks of talented community members becoming employees.About MattyMatty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and a global organizer of the DevOpsDays set of conferences.Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Links Referenced: Aiven: https://aiven.io/ Twitter: https://twitter.com/mattstratton Mastodon: hackyderm.io/@mattstratton LinkedIn: https://www.linkedin.com/in/mattstratton/ 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: This episode is brought to us in part by our friends at Min.ioWith more than 1.1 billion docker pulls - Most of which were not due to an unfortunate loop mistake, like the kind I like to make - and more than 37 thousand github stars, (which are admittedly harder to get wrong), MinIO has become the industry standard alternative to S3. It runs everywhere  - public clouds, private clouds, Kubernetes distributions, baremetal, raspberry's pi, colocations - even in AWS Local Zones. The reason people like it comes down to its simplicity, scalability, enterprise features and best in class throughput. Software-defined and capable of running on almost any hardware you can imagine and some you probably can't, MinIO can handle everything you can throw at it - and AWS has imagined a lot of things - from datalakes to databases.Don't take their word for it though - check it out at www.min.io and see for yourself. That's www.min.io Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined today by returning guest, my friend and yours, Matty Stratton, Director of Developer Relations at Aiven. Matty, it's been a hot second. How are you?Matty: It has been a while, but been pretty good. We have to come back to something that just occurred to me when we think about the different things we've talked about. There was a point of contention about prior art of the Corey Quinn face and photos. I don't know if you saw that discourse; we may have to have a conversation. There may be some absent—Corey: I did not see—Matty: Okay.Corey: —discourse, but I also would accept freely that I am not the first person to ever come up with the idea of opening my mouth and looking ridiculous for a photograph either.Matty: That's fair, but the thing that I think was funny—and if you don't mind, I'll just go ahead and throw this out here—is that I didn't put this two and two together. So, I posted a picture on Twitter a week or so ago that was primarily to show off the fact—it was a picture of me in 1993, and the point was that my jeans were French-rolled and were pegged. But in the photo, I am doing kind of the Corey Quinn face and so people said, “Oh, is this prior art?” And I said—you know what? I actually just remembered and I've never thought about this before, but one of my friends in high school, for his senior year ID he took a picture—his picture looks like, you know, that kind of, you know, three-quarters turn with the mouth opening going, “Ah,” you know?And he loved that picture—number one, he loved that picture so much that this guy carried his senior year high school ID in his wallet until we were like 25 because it was his favorite picture of himself. But every photo—and I saw this from looking through my yearbook of my friend Jay when we are seniors, he's doing the Corey Quinn face. And he is anecdotally part of the DevOps community, now a little bit too, and I haven't pointed this out to him. But people were saying that, you know, mine was prior art on yours, I said, “Actually, I was emulating yet someone else.”Corey: I will tell you the actual story of how it started. It was at re:Invent, I want to say 2018 or so, and what happened was is someone, they were a big fan of the newsletter—sort of the start of re:Invent—they said, “Hey, can I get a selfie with you?” And I figured, sure, why not. And the problem I had is I've always looked bad in photographs. And okay, great, so if I'm going to have a photo taken of me, that's going to be ridiculous, why not as a lark, go ahead and do this for fun during the course of re:Invent this year?So, whenever I did that I just slapped—if someone asked for a selfie—I'd slap the big happy open mouth smile on my face. And people thought, “Oh, my God, this is amazing.” And I don't know that it was necessarily worth that level of enthusiasm, but okay. I'll take it. I'm not here to tell people they're wrong when they enjoy a joke that I'm putting out there.And it just sort of stuck. And I think the peak of it that I don't think I'm ever going to be able to beat is I actually managed to pull that expression on my driver's license.Matty: Wow.Corey: Yeah.Matty: That's—Corey: They don't have a sense of humor that they are aware of at the DMV.Matty: No, they really don't. And having been to the San Francisco DMV and knowing how long it takes to get in there, like, that was a bit of a risk on your part because if they decided to change their mind, you wouldn't be able to come back for another four months [laugh].Corey: It amused me to do it, so why not? What else was I going to do? I brought my iPad with me, it has cellular on it, so I just can work remotely from there. It was either that or working in my home office again, and frankly, at the height of the pandemic, I could use the break.Matty: Yes [laugh]. That's saying something when the break you can use is going to the DMV.Corey: Right.Matty: That's a little bit where we were, where we at. I think just real quick thinking about that because there's a lot to be said with that kind of idea of making a—whether it's silly or not, but having a common, especially if you do a lot of photos, do a lot of things, you don't have to think about, like, how do I look? I mean, you have to think about—you know, you can just say I just know what I do. Because if you think about it, it's about cultivating your smile, cultivating your look for your photos, and just sort of having a way so you don't—you just know what to do every time. I guess that's a, you know, maybe a model tip or something. I don't know. But you might be onto something.Corey: I joke that my entire family motto is never be the most uncomfortable person in the room. And there's something to be said for it where if you're going to present a certain way, make it your own. Find a way to at least stand out. If nothing else, it's a bit different. Most people don't do that.Remember, we've all got made fun of, generally women—for some reason—back about 15 years ago or so for duck face, where in all the pictures you're making duck face. And well, there are reasons why that is a flattering way to present your face. But if there's one thing we love as a society, it's telling women they're doing something wrong.Matty: Yeah.Corey: So yeah, there's a whole bunch of ways you're supposed to take selfies or whatnot. Honestly, I'm in no way shape or form pretty enough or young enough to care about any of them. At this point, it's what I do when someone busts out a camera and that's the end of it. Now, am I the only person to do this? Absolutely not. Do I take ownership of it? No. Someone else wants to do it, they need give no credit. The idea probably didn't come from me.Matty: And to be fair, if I'm little bit taking the mickey there or whatever about prior art, it was more than I thought it was funny because I had not even—it was this thing where it was like, this is a good friend of mine, probably some of that I've been friends with longer than anyone in my whole life, and it was a core part [laugh] of his personality when we were 18 and 19, and it just d—I just never direct—like, made that connection. And then it happened to me and went “Oh, my God. Jason and Corey did the same thing.” [laugh]. It was—Corey: No, it feels like parallel evolution.Matty: Yeah, yeah. It was more of me never having connected those dots. And again, you're making that face for your DMV photo amused you, me talking about this for the last three minutes on a podcast amused me. So.Corey: And let's also be realistic here. How many ways are there to hold your face during a selfie that is distinguishable and worthy of comment? Usually, it's like okay, well, he has this weird sardonic half-smile with an eyebrow ar—no. His mouth was wide open. We're gonna go with that.Matty: You know, there's a little—I want to kind of—because I think there's actually quite a bit to the lesson from any of this because I think about—follow me here; maybe I'll get to the right place—like me and karaoke. No one would ever accuse me of being a talented singer, right? I'm not going to sing well in a way where people are going to be moved by my talent. So instead, I have to go a different direction. I have to go funny.But what it boils down to is I can only do—I do karaoke well when it's a song where I can feel like I'm doing an impression of the singer. So, for example, the B-52s. I do a very good impression of Fred Schneider. So, I can sing a B-52 song all day long. I actually could do better with Pearl Jam than I should be able to with my terrible voice because I'm doing an Eddie Vedder impression.So, what I'm getting at is you're sort of taking this thing where you're saying, okay, to your point, you said, “Hey,”—and your words, not mine—[where 00:07:09] somebody say, “The picture is not going to be of me looking like blue steel runway model, so I might as well look goofy.” You know? And take it that way and be funny with it. And also, every time, it's the same way, so I think it's a matter of kind of owning the conversation, you know, and saying, how do you accentuate the thing that you can do. I don't know. There's something about DevOps, somehow in there.Corey: So, I am in that uncomfortable place right now between having finalized a blog post slash podcast that's going out in two days from this recording. So, it will go out before you and I have this discussion publicly, but it's also too late for me to change any of it,m so I figured I will open myself up to the slings and arrows of you, more or less. And you haven't read this thing yet, which is even better, so you're now going to be angry about an imperfect representation of what I said in writing. But the short version is this: if you work for a company as their employee, then you are no longer a part of that company's community, as it were. And yes, that's nuanced and it's an overbroad statement and there are a bunch of ways that you could poke holes in it, but I'm curious to get your take on the overall positioning of it.Matty: So, at face value, I would vehemently disagree with that statement. And by that is, that I have spent years of my life tilting at the opposite windmill, which is just because you work at this company, doesn't mean you do not participate in the community and should not consider yourself a part of the community, first and foremost. That will, again, like everything else, it depends. It depends on a lot of things and I hope we can kind of explore that a little bit because just as much as I would take umbrage if you will, or whatnot, with the statement that if you work at the company, you stop being part of the community, I would also have an issue with, you're just automatically part of the community, right? Because these things take effort.And I feel like I've been as a devreloper, or whatever, Corey—how do you say it?Corey: Yep. No, you're right on. Devreloper.Matty: As a—or I would say, as a DevRel, although people on Twitter are angry about using the word DevRel to discuss—like saying, “I'm a DevRel.” “DevRel is a department.” It's a DevOps engineer thing again, except actually—it's, like, actually wrong. But anyway, you kind of run into this, like for example—I'm going to not name names here—but, like, to say, you know, Twitter for Pets, the—what do you—by the way, Corey, what are you going to do now for your made-up company when what Twitter is not fun for this anymore? You can't have Twitter for Pets anymore.Corey: I know I'm going to have to come up with a new joke. I don't quite know what to do with myself.Matty: This is really hard. While we will pretend Twitter for Pets is still around a little bit, even though its API is getting shut down.Corey: Exactly.Matty: So okay, so we're over here at Twitter for Pets, Inc. And we've got our—Corey: Twitter for Bees, because you know it'll at least have an APIary.Matty: Yeah. Ha. We have our team of devrelopers and community managers and stuff and community engineers that work at Twitter for Pets, and we have all of our software engineers and different people. And a lot of times the assumption—and now we're going to have Twitter for Pets community something, right? We have our community, we have our area, our place that we interact, whether it's in person, it's virtual, whether it's an event, whether it's our Discord or Discourse or Slack or whatever [doodlee 00:10:33] thing we're doing these days, and a lot of times, all those engineers and people whose title does not have the word ‘community' on it are like, “Oh, good. Well, we have people that do that.”So, number one, no because now we have people whose priority is it; like, we have more intentionality. So, if I work on the community team, if I'm a dev advocate or something like that, my priority is communicating and advocating to and for that community. But it's like a little bit of the, you know, the office space, I take the requirements from the [unintelligible 00:11:07] to people, you I give them to the engineers. I've got people—so like, you shouldn't have to have a go-between, right? And there's actually quite a bit of place.So, I think, this sort of assumption that you're not part of it and you have no responsibility towards that community, first of all, you're missing a lot as a person because that's just how you end up with people building a thing they don't understand.Corey: Oh, I think you have tremendous responsibility to the community, but whether you're a part of it and having responsibility to it or not aligned in my mind.Matty: So… maybe let's take a second and what do you mean by being a part of it?Corey: Right. Where very often I'll see a certain, I don't know, very large cloud provider will have an open-source project. Great, so you go and look at the open-source project and the only people with commit access are people who work at that company. That is an easy-to-make-fun-of example of this. Another is when the people who are in a community and talking about how they perceive things and putting out content about how they've interacted with various aspects of it start to work there, you see areas where it starts to call its authenticity into question.AWS is another great example of this. As someone in the community, I can talk about how I would build something on top of AWS, but then move this thing on to Fastly instead of CloudFront because CloudFront is terrible. If you work there, you're not going to be able to say the same thing. So, even if you're not being effusive with praise, there are certain guardrails and constraints that keep you from saying what you might otherwise, just based upon the sheer self-interest that comes from the company whose product or service you're talking about is also signing your paycheck and choosing to continue to do so.Matty: And I think even less about it because that's where your paycheck is coming. It's also just a—there's a gravitational pull towards those solutions because that's just what you're spending your day with, right? You know—Corey: Yeah. And you also don't want to start and admit even to yourself, in some cases, that okay, this aspect of what our company does is terrible, so companies—people shouldn't use it. You want to sort of ignore that, on some level, psychologically because that dissonance becomes harmful.Matty: Yeah. And I think there's—so again, this is where things get nuanced and get to levels. Because if you have the right amount of psychological safety in your organization, the organization understands what it's about to that. Because even people whose job is to be a community person should be able to say, “Hey, this is my actual opinion on this. And it might be contrary to the go-to-market where that comes in.”But it's hard, especially when it gets filtered through multiple layers and now you've got a CEO who doesn't understand that nuance who goes, “Wait, why was Corey on some podcast saying that the Twitter for Pets API is not everything it could possibly be?” So, I do think—I will say this—I do think that organizations and leadership are understanding this more than they might have in the past, so we are maybe putting on ourselves this belief that we can't be as fully honest, but even if it's not about hiding the warts, even if it's just a matter of also, you're just like, hey, chances are—plus also to be quite frank, if I work at the company, I probably have access to way more shit than I would have to pay for or do whatever and I know the right way. But here's the trick, and I won't even say it's a dogfooding thing, but if you are not learning and thinking about things the way that your users do—and I will even say that that's where—it is the users, which are the community, that community or the people that use your product or are connected to it, they don't use it; they may be anecdotal—or not anecdotally, maybe tangentially connected. I will give an example. And there was a place I was working where it was very clear, like, we had a way to you know, do open-source contributions back of a type of a provider plug-in, whatever you want to call it and I worked at the company and I could barely figure out how to follow the instructions.Because it made a lot of sense to someone who built that software all day long and knew the build patterns, knew all that stuff. So, if you were an engineer at this company, “Well, yeah, of course. You just do this.” And anybody who puts the—connects the dots, this has gotten better—and this was understood relatively quickly as, “Oh, this is the problem. Let's fix it.” So, the thing is, the reason why I bring this up is because it's not something anybody does intentionally because you don't know what you don't know. And—Corey: Oh, I'm not accusing anyone of being a nefarious actor in any of this. I also wonder if part of this is comes from your background as being heavily involved in the Chef community as a Chef employee and as part of the community around that, which is inherently focused on an open-source product that a company has been built around, whereas my primary interaction with community these days is the AWS community, where it doesn't matter whether you're large or small, you are not getting much, if anything, for free from AWS; you're all their customers and you don't really have input into how something gets built, beyond begging nicely.Matty: That's definitely true. And I think we saw that and there was things, when we look at, like, how community, kind of, evolved or just sort of happened at Chef and why we can't recreate it the same way is there was a certain inflection point of the industry and the burgeoning DevOps movement, and there wasn't—you know, so a lot of that was there. But one of the big problems, too, is, as Corey said, everybody—I shouldn't say every, but I've from the A—all the way up to AWS to your smaller startups will have this problem of where you end up hiring in—whether you want to or not—all of your champions and advocates and your really strong community members, and then that ends up happening. So, number one, that's going to happen. So frankly, if you don't push towards this idea, you're actually going to have people not want to come work because you should be able to be still the member that you were before.And the other thing is that at certain size, like, at the size of a hyperscaler, or, you know, a Microsoft—well, anybody—well Microsofts not a hyperscaler, but you know what I'm saying. Like, very, very large organization, your community folks are not necessarily the ones doing that hiring away. And as much as they might—you know, and again, I may be the running the community champion program at Microsoft and see that you want—you know, but that Joe Schmo is getting hired over into engineering. Like, I'm not going to hire Joe because it hurts me, but I can't say you can't, you know? It's so this is a problem at the large size.And at the smaller size, when you're growing that community, it happens, too, because it's really exciting. When there's a place that you're part of that community, especially when there's a strong feel, like going to work for the mothership, so to speak is, like, awesome. So again, to give an example, I was a member of the Chef community, I was a user, a community person well, before, you know, I went and, you know, had a paycheck coming out of that Seattle office. And it was, like, the coolest thing in the world to get a job offer from Ch—like, I was like, “Oh, my God. I get to actually go work there now.” Right?And when I was at Pulumi, there quite a few people I could think of who I knew through the community who then get jobs at Pulumi and we're so excited, and I imagine still excited, you know? I mean, that was awesome to do. So, it's hard because when you get really excited about a technology, then being able to say, “Wait, I can work on this all the time?” That sounds awesome, right? So like, you're going to have that happen.So, I think what you have to do is rather than prevent it from happening because number one, like, you don't want to actually prevent that from happening because those people will actually be really great additions to your organization in lots of ways. Also, you're not going to stop it from happening, right? I mean, it's also just a silly way to do it. All you're going to do is piss people off, and say, like, “Hey, you're not allowed to work here because we need you in the community.” Then they're going to be like, “Great. Well, guess what I'm not a part of anymore now, jerk?” Right? You know [laugh] I mean so—Corey: Exactly.Matty: Your [unintelligible 00:18:50] stops me. So, that doesn't work. But I think to your point, you talked about, like, okay, if you have a, ostensibly this a community project, but all the maintainers are from one—are from your company, you know? Or so I'm going to point to an example of, we had—you know, this was at Pulumi, we had a Champions program called Puluminaries, and then there's something similar to like Vox Populi, but it was kind of the community that was not run by Pulumi Inc. In that case.Now, we helped fund it and helped get it started, but there was there were rules about the, you know, the membership of the leadership, steering committee or board or whatever it was called, there was a hard limit on the number of people that could be Pulumi employees who were on that board. And it actually, as I recall when I was leaving—I imagine this is not—[unintelligible 00:19:41] does sometimes have to adjust a couple of things because maybe those board members become employees and now you have to say, you can't do that anymore or we have to take someone down. But the goal was to actually, you know, basically have—you know, Pulumi Corp wanted to have a voice on that board because if for no other reason, they were funding it, but it was just one voice. It wasn't even a majority voice. And that's a hard sell in a lot of places too because you lose control over that.There's things I know with, uh—when I think about, like, running meetup communities, like, we might be—well I mean, this is not a big secret, I mean because it's been announced, but we're—you know, Aiven is helping bootstrap a bunch of data infrastructure meetups around the world. But they're not Aiven meetups. Now, we're starting them because they have to start, but pretty much our approach is, as soon as this is running and there's people, whether they work here, work with us or not, they can take it, right? Like, if that's go—you know? And being able to do that can be really hard because you have to relinquish the control of your community.And I think you don't have to relinquish a hundred percent of that control because you're helping facilitate it because if it doesn't already have its own thing—to make sure that things like code of conduct and funding of it, and there's things that come along with the okay, we as an organization, as a company that has dollars and euros is going to do stuff for this, but it's not ours. And that's the thing to remember is that your community does not belong to you, the company. You are there to facilitate it, you are there to empower it, you're there to force-multiply it, to help protect it. And yeah, you will probably slurp a whole bunch of value out of it, so this is not magnanimous, but if you want it to actually be a place it's going to work, it kind of has to be what it wants to be. But by the same token, you can't just sort of sit there and be like, “I'm going to wait for this community grow up around me without anything”—you know.So, that's why you do have to start one if there is quote-unquote—maybe if there's no shape to one. But yeah, I think that's… it is different when it's something that feels a little—I don't even want to say that it's about being open-source. It's a little bit about it less of it being a SaaS or a service, or if it's something that you—I don't know.Corey: This episode is sponsored in part by Honeycomb. I'm not going to dance around the problem. Your. Engineers. Are. Burned. Out. They're tired from pagers waking them up at 2 am for something that could have waited until after their morning coffee. Ring Ring, Who's There? It's Nagios, the original call of duty! They're fed up with relying on two or three different “monitoring tools” that still require them to manually trudge through logs to decipher what might be wrong. Simply put, there's a better way. Observability tools like Honeycomb (and very little else becau se they do admittedly set the bar) show you the patterns and outliers of how users experience your code in complex and unpredictable environments so you can spend less time firefighting and more time innovating. It's great for your business, great for your engineers, and, most importantly, great for your customers. Try FREE today at honeycomb.io/screaminginthecloud. That's honeycomb.io/screaminginthecloud.Corey: Yeah, I think you're onto something here. I think another aspect where I found it be annoying is when companies view their community as, let's hire them all. And I don't think it ever starts that way. I think that it starts as, well these are people who are super-passionate about this, and they have great ideas and they were great to work with. Could we hire them?And the answer is, “Oh, wait. You can give me money for this thing I've been doing basically for free? Yeah, sure, why not?” And that's great in the individual cases. The problem is, at some point, you start to see scenarios where it feels like, if not everyone, then a significant vocal majority of the community starts to work there.Matty: I think less often than you might think is it done strategically or on purpose. There have been exceptions to that. There's one really clear one where it feels like a certain company a few years ago, hired up all the usual suspects of the DevOps community. All of a sudden, you're like, oh, a dozen people all went to go work at this place all at once. And the fun thing is, I remember feeling a little bit—got my nose a little out of joint because I was not the hiring mana—like, I knew the people.I was like, “Well, why didn't you ask me?” And they said, “Actually, you are more important to us not working here.” Now, that might have just been a way to sell my dude-in-tech ego or not, but whether or not that was actually true for me or not, that is a thing where you say you know, your folks—but I do think that particular example of, like, okay, I'm this, that company, and I'm going to go hire up all the usual suspects, I think that's less. I think a lot of times when you see communities hire up those people, it's not done on purpose and in fact, it's probably not something they actually wanted to do in mass that way. But it happens because people who are passionate about your product, it's like I said before, it actually seems pretty cool to go work on it as your main thing.But I can think of places I've been where we had, you know—again, same thing, we had a Pulumi—we had someone who was probably our strongest, loudest, most vocal community member, and you know, I really wanted to get this person to come join us and that was sort of one of the conversations. Nobody ever said, “We won't offer this person a job if they're great.” Like, that's the thing. I think that's actually kind of would be shitty to be like, “You're a very qualified individual, but you're more important to me out in the community so I'm not going to make your job offer.” But it was like, Ooh, that's the, you know—it'd be super cool to have this person but also, not that that should be part of our calculus of decision, but then you just say, what do you do to mitigate that?Because what I'm concerned about is people hearing this the wrong way and saying, “There's this very qualified individual who wants to come work on my team at my company, but they're also really important to our community and it will hurt our community if they come work here, so sorry, person, we're not going to give you an opportunity to have an awesome job.” Like, that's also thinking about the people involved, too. But I know having talked to folks that lots of these different large organizations that have this problem, generally, those community folks, especially at those places, they don't want this [laugh] happening. They get frustrated by it. So, I mean, I'll tell you, it's you know, the—AWS is one of them, right?They're very excited about a lot of the programs and cool people coming from community builders and stuff and Heroes, you know. On one hand, it's incredibly awesome to have a Hero come work at AWS, but it hurts, right, because now they're not external anymore.Corey: And you stop being a Hero in that case, as well.Matty: Yeah. You do, yeah.Corey: Of course, they also lose the status if they go to one of their major competitors. So like, let me get this straight. You can't be a Hero if you work for AWS or one of its competitors. And okay, how are there any Heroes left at all at some point? And the answer is, they bound it via size and a relatively small list of companies. But okay.Matty: So, thinking back to your point about saying, okay, so if you work at the company, you lose some authenticity, some impartiality, some, you know… I think, rather than just saying, “Well, you're not part”—because that also, honestly, my concern is that your blog post is now going to be ammunition for all the people who don't want to act as members of the community for the company they work for now. They're going to say, well, Corey told me I don't have to. So, like I said, I've been spending the last few years tilting at the opposite windmill, which is getting people that are not on the community team to take part in community summits and discourse and things like that, like, you know, for that's—so I think the thing is, rather than saying, “Well, you can't,” or, “You aren't,” it's like, “Well, what do you do to mitigate those things?”Corey: Yeah, it's a weird thing because taking AWS as the example that I've been beating up on a lot, the vast majority of their employees don't know the community exists in any meaningful sense. Which, no fault to them. The company has so many different things, no one keeps up with at all. But it's kind of nuts to realize that there are huge communities of people out there using a thing you have built and you do not know that those users exist and talk to each other in a particular watering hole. And you of course, as a result, have no presence there. I think that's the wrong direction, too. But—Matty: Mm-hm.Corey: Observing the community and being part of the community, I think there's a difference. Are you a biologist or are you a gorilla?Matty: Okay, but [sigh] I guess that's sort of the difference, too which—and it's hard, it's very hard to not just observe. Because I think that actually even taking the mentality of, “I am here to be Jane Goodall, Dr. Jane Goodall, and observe you while I live amongst you, but I'm not going to actually”—although maybe I'm probably doing disservice—I'm remembering my Goodall is… she was actually more involved. May be a bad example.Corey: Yeah. So, that analogy does fall apart a little bit.Matty: It does fall apart a little bit—Corey: Yeah.Matty: But it's you kind of am I sitting there taking field notes or am I actually engaging with you? Because there is a difference. Even if your main reason for being there is just purely to—I mean, this is not the Prime Directive. It's not Star Trek, right? You're not going to like, hold—you don't need to hold—I mean, do you have to hold yourself aloof and say, “I don't participate in this conversation; I'm just here to take notes?”I think that's very non-genuine at that point. That's over-rotating the other way. But I think it's a matter of in those spaces—I think there's two things. I think you have to have a way to be identified as you are an employee because that's just disclosure.Corey: Oh, I'm not suggesting by any stretch of the imagination, people work somewhere but not admit that they work somewhere when talking about the company. That's called fraud.Matty: Right. No, no, and I don't think it's even—but I'm saying beyond just, if it's not, if you're a cop, you have to tell me, right?Corey: [laugh].Matty: It's like, it's not—if asked, I will tell you I work at AWS. It's like in that place, it should say, “I am an AWS em—” like, I should be badged that way, just so it's clear. I think that's actually helpful in two ways. It's also helpful because it says like, okay, maybe you have a connection you can get for me somehow. Like, you might actually have some different insight or a way to chase something that, you know, it's not necessarily just about disclosure; it's also helpful to know.But I think within those spaces, that disclosure—or not disclosure, but being an employee does not offer you any more authority. And part of that is just having to be very clear about how you're constructing that community, right? And that's sort of the way that I think about it is, like, when we did the Pulumi Community Summit about a year ago, right? It was an online, you know, thing we did, and the timing was such that we didn't have a whole lot of Pulumi engineers were able to join, but when we—and it's hard to say we're going to sit in an open space together and everybody is the same here because people also—here's the difference. You say you want this authority? People will want that authority from the people that work at the company and they will always go to them and say, like, “Well, you should have this answer. Can you tell me about this? Can you do this?”So, it's actually hard on both cases to have that two-way conversation unless you set the rules of that space such as, “Okay, I work at Aiven, but when I'm in this space, short of code of conduct or whatever, if I have to be doing that thing, I have no more authority on this than anyone else.” I'm in this space as the same way everyone else's. You can't let that be assumed.Corey: Oh, and big companies do. It's always someone else's… there's someone else's department. Like, at some level, it feels like when you work in one of those enormous orgs, it's your remit is six inches wide.Matty: Well, right. Right. So, I think it's like your authority exists only so far as it's helpful to somebody. If I'm in a space as an Aivener, I'm there just as Matty the person. But I will say I work at Aiven, so if you're like, “God, I wish that I knew who was the person to ask about this replication issue,” and then I can be like, “Aha, I actually have backchannel. Let me help you with that.” But if I can say, “You know what? This is what I think about Kafka and I think why this is whatever,” like, you can—my opinion carries just as much weight as anybody else's, so to speak. Or—Corey: Yeah. You know, it's also weird. Again, community is such a broad and diverse term, I find myself in scenarios where I will observe and talk to people inside AWS about things, but I never want to come across as gloating somehow, that oh, I know, internal people that talk to you about this and you don't. Like, that's never how I want to come across. And I also, I never see the full picture; it's impossible for me to, so I never make commitments on behalf of other people. That's a good way to get in trouble.Matty: It is. And I think in the case of, like, someone like you who's, you know, got the connections you have or whatever, it's less likely for that to be something that you would advertise for a couple of reasons. Like, nobody should be advertising to gloat, but also, part of my remit as a member of a community team is to actually help people. Like, you're doing it because you want to or because it serves you in a different way. Like, that is literally my job.So like, it shouldn't be, like—like, because same thing, if you offer up your connections, now you are taking on some work to do that. Someone who works at the company, like, yes, you should be taking on that work because this is what we do. We're already getting paid for it, you know, so to speak, so I think that's the—Corey: Yeah.Matty: —maybe a nuance, but—Corey: Every once in a while, I'll check my Twitter spam graveyard, [unintelligible 00:32:01] people asking me technical questions months ago about various things regarding AWS and whatnot. And that's all well and good; the problem I have with it is that I'm not a support vector. I don't represent for the company or work for them. Now, if I worked there, I'd feel obligated to make sure this gets handed to the right person. And that's important.The other part of it, though, is okay, now that that's been done and handed off, like do I shepherd it through the process? Eh. I don't want people to get used to asking people in DMs because again, I consider myself to be a nice guy, but if I'm some nefarious jerk, then I could lead them down a very dark path where I suddenly have access to their accounts. And oh, yeah, go ahead and sign up for this thing and I'll take over their computer or convince them to pay me in iTunes gift cards or something like that. No, no, no. Have those conversations in public or through official channels, just because I don't, I don't think you want to wind up in that scenario.Matty: So, my concern as well, with sort of taking the tack of you are just an observer of the community, not a part of it is, that actually can reinforce some pretty bad behavior from an organization towards how they treat the community. One of the things that bothers me—if we're going to go on a different rant about devrelopers like myself—is I like to say that, you know, we pride ourselves as DevRels as being very empathetic and all this stuff, but very happy to shit all over people that work in sales or marketing, based on their job title, right? And I'm like, “Wow, that's great,” right? We're painting with this broad brush. Whereas in reality, we're not separate from.And so, the thing is, when you treat your community as something separate from you, you are treating it as something separate from you. And then it becomes a lot easier also, to not treat them like people and treat them as just a bunch of numbers and treat them as something to have value extracted from rather than it—this is actually a bunch of humans, right? And if I'm part of that, then I'm in the same Dunbar number a little bit, right? I'm in the same monkey sphere as those people because me, I'm—whoever; I'm the CTO or whatever, but I'm part of this community, just like Joe Smith over there in Paducah, you know, who's just building things for the first time. We're all humans together, and it helps to not treat it as the sort of amorphous blob of value to be extracted.So, I think that's… I think all of the examples you've been giving and those are all valid concerns and things to watch out for, the broad brush if you're not part of the community if you work there, my concern is that that leads towards exacerbating already existing bad behavior. You don't have to convince most of the people that the community is separate from them. That's what I'm sort of getting at. I feel like in this work, we've been spending so much time to try to get people to realize they should be acting like part of their larger community—and also, Corey, I know you well enough to know that, you know, sensationalism to make a point [laugh] works to get somebody to join—Corey: I have my moments.Matty: Yeah, yeah, yeah. I mean, there's I think… I'll put it this way. I'm very interested to see the reaction, the response that comes out in, well now, for us a couple of days, for you the listener, a while ago [laugh] when that hits because I think it is a, I don't want to say it's controversial, but I think it's something that has a lot of, um… put it this way, anything that's simple and black and white is not good for discussion.Corey: It's nuanced. And I know that whenever I wrote in 1200 words is not going to be as nuanced of the conversation we just had, either, so I'm sure people will have opinions on it. That'd be fun. It'd be a good excuse for me to listen.Matty: Exactly [laugh]. And then we'll have to remember to go back and find—I'll have to do a little Twitter search for the dates.Corey: We'll have to do another discussion on this, if anything interesting comes out of it.Matty: Actually, that would be funny. That would be—we could do a little recap.Corey: It would. I want to thank you so much for being so generous with your time. Where can people find you if they want to learn more?Matty: Well, [sigh] for the moment, [sigh] who knows what will be the case when this comes out, but you can still find me on Twitter at @mattstratton. I'm also at hackie-derm dot io—sorry, hackyderm.io. I keep wanting to say hackie-derm, but hackyderm actually works better anyway and it's funnier. But [hackyderm.io/@mattstratton](https://hackyderm.io/@mattstratton) is my Mastodon. LinkedIn; I'm. Around there. I need to play more at that. You will—also again, I don't know when this is coming out, so you won't tell you—you don't find me out traveling as much as you might have before, but DevOpsDays Chicago is coming up August 9th and 10th in Chicago, so at the time of listening to this, I'm sure our program will have been posted. But please come and join us. It will be our ninth time of hosting a DevOpsDay Chicago. And I have decided I'm sticking around for ten, so next year will be my last DevOpsDay that I'm running. So, this is the penultimate. And we always know that the penultimate is the best.Corey: Absolutely. Thanks again for your time. It's appreciated. Matty Stratton, Director of Developer Relations at Aiven. 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 comment talking about how I completely missed the whole point of this community and failing to disclose that you are in fact one of the producers of the show.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.

Screaming in the Cloud
The Evolution of DevRel with Jeremy Meiss

Screaming in the Cloud

Play Episode Listen Later Feb 2, 2023 30:12


About JeremyJeremy is the Director of DevRel & Community at CircleCI, formerly at Solace, Auth0, and XDA. He is active in the DevRel Community, and is a co-creator of DevOpsPartyGames.com. A lover of all things coffee, community, open source, and tech, he is also house-broken, and (generally) plays well with others.Links Referenced: CircleCI: https://circleci.com/ DevOps Party Games: https://devopspartygames.com/ Twitter: Iamjerdog LinkedIn: https://www.linkedin.com/in/jeremymeiss/ 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: 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 generally try to have people that I know in the ecosystem on this show from time to time, but somehow today's guest has never made it onto the show. And honestly, I have no excuse other than that, I guess I just like being contrary about it. Jeremy Meiss is the Director of DevRel and Community at CircleCI. Jeremy, thank you for finally getting on the show.Jeremy: Hey, you know what? I woke up months and months ago hoping I would be able to join and never have, so I appreciate you finally, you know, getting that celestial kick in the ass.Corey: I love the fact that this is what you lie awake at night worrying about. As all people should. So, let's get into it. You have been at CircleCI in their DevRel org—heading their DevRel org—for approximately 20 years, but in real-time and non-tech company timeframes, three years. But it feels like 20. How's that been? It's been an interesting three years, I'll say that much with the plague o'er the land.Jeremy: Yes, absolutely. No, it was definitely a time to join. I joined two weeks before the world went to shit, or shittier than it already was. And yeah, it's been a ride. Definitely see how everything's changed, but it's also been one that I couldn't be happier where I'm at and seeing the company grow.Corey: I've got to level with you. For the longest time, I kept encountering CircleCI in the same timeframes and context, as I did Travis CI. They both have CI in the name and I sort of got stuck on that. And telling one of the companies apart from the other was super tricky at the time. Now, it's way easier because Travis CI got acquired and then promptly imploded.Security issues that they tried to hide left and right, everyone I knew there long since vanished, and at this point, it is borderline negligence from my point of view to wind up using them in production. So oh, yeah, CircleCI, that's the one that's not trash. I don't know that you necessarily want to put that on a billboard somewhere, but that's my mental shortcut for it.Jeremy: You know, I'm not going to disagree with that. I think, you know, it had its place, I think there's probably only one or two companies nowadays actually propping it up as a business, and I think even they are actively trying to get out of it. So yeah, not going to argue there.Corey: I have been on record previously as talking about CI/CD—Continuous Integration slash Continuous Deployment—or for those who have not gone tumbling down that rabbit hole, the idea that when you push a commit to a particular branch on Git—or those who have not gotten to that point, push the button, suddenly code winds up deploying to different environments, occasionally production, sometimes staging, sometimes development, sometimes by accident—and there are a bunch of options in that space. AWS has a bunch of services under their CodeStar suite: CodeBuild, CodeDeploy, CodePipeline, and that's basically there as a marketing exercise by CI/CD companies that are effective because after having attempted to set those things up with the native offerings, you go scrambling to something else, anything else. GitHub Actions has also been heavily in that space because it's low friction to integrate, it's already there in GitHub, and that's awesome in some ways, terrible in others. But CircleCI has persistently been something that I see in a lot of different environments, both the open-source world, as well as among my clients, where they are using you folks to go from developer laptops to production safely and sanely.Jeremy: Absolutely, yeah. And I think that's one thing for us is, there's a niche of—you know, you can start if you're into AWS or you're into Google, or you're in—any of those big ecosystems, you can certainly use what they have, but those are always, like, add-on things, they're always like an afterthought of, “Oh, we're going to go add this,” or, “We're going to go add that.” And so, I think you adequately described it of, you know, once you start hitting scale, you're eventually going to start to want to use something, and I think that's where we generally fit in that space of, you know, you can start, but now you're going to eventually end up here and use best-in-class. I spent years Auth0 in the identity space, and it was the same kind of boat is that, you know, sure you can start with hopefully not rolling your own, but eventually you're going to end up wanting to use something best-in-class that does everything that you want it to do and does it right.Corey: The thing that just completely blows my mind is how much for all these companies, no matter who they are and how I talk to them, everyone talks about their CI/CD flow with almost a sense of embarrassment. And back in the days when I was running production environments, we use Jenkins as sort of a go-to answer for this. And that was always a giant screaming exemption to the infrastructure-as-code approach because you could configure it via the dashboard and the web interface and it would write that out as XML files. So, you wound up with bespoke thing lots of folks could interact with in different ways, and oh, by the way, it has access into development, staging, and production. Surely, there will be no disasters that happened as a result of this.And that felt terrible. And now we've gotten into a place where most folks are not doing that anymore, at least with the folks that I talk to, but I'm still amazed by how few best practices around a lot of this stuff has really emerged. Every time I see a CI/CD pipeline, it feels like it is a reimplementation locally of solving a global problem. You're the director of DevRel and have been for a few years now. Why haven't you fixed this yet?Jeremy: Primarily because I'm still stuck on the fact you mentioned, pushing a button and getting to XML. That just kind of stuck me there and sent me back that I can't come up with a solution at this point.Corey: Yeah, it's the way that you solve the gap—the schism as it were—between JSON and YAML. “Cool, we're going to use XML.” And everyone's like, “Oh, God, not that.” It's like, “Cool, now you're going to settle your differences or I'm going to implement other things, too.”Jeremy: That's right, yeah. I mean, then we're going to go use some bespoke company's own way of doing IAC. No, I think there's an element here where—I mean, it goes back to still using best-in-class. I think Hudson, which eventually became Jenkins, after you know, Cisco—was it Cisco? No, it was Sun—after Sun, you know, got their hands all over it, it was the thing. It's kind of, well, we're just going to spin this up and do it ourselves.But as the industry changes, we do more and more things on the cloud and we do it primarily because we're relocating the things that we don't want to have to manage ourselves with all of the overhead and all of the other stuff. We're going to go spit it over to the cloud for that. And so, I think there's been this shift in the industry that they still do, like you said, look at their pipelines with a little bit of embarrassment [laugh], I think, yeah. I chuckle when I think about that, but there is a piece where more and more people are recognizing that there is a better way and that you can—you don't have to look at your pipelines as this thing you hate and you can start to look at what better options there are than something you have to host yourself.Corey: What I'm wondering about now, though, because you've been fairly active in the space for a long time, which is a polite way of saying you have opinions—and you should hear the capital O and ‘Opinions' when I say it that way—let's fight about DevRel. What does DevRel mean to you? Or as I refer to it, ‘devrelopers?'Jeremy: Uh, devrelopers. Yes. You know, not to take from the standard DevOps answer, but I think it depends.Corey: That's the standard lawyer answer to anything up to and including, is it legal for me to murder someone? And it's also the senior consultant answer, to anything, too, because it turns out the world is baked and nuanced and doesn't lend itself to being resolved in 280 characters or less. That's what threads are for.Jeremy: Right [laugh]. Trademark. That is ultimately the answer, I think, with DevRel. For me, it is depending on what your company is trying to do. You ultimately want to start with building relationships with your developers because they're the ones using your product, and if you can get them excited about what they're doing with your product—or get excited about your product with what they're doing—then you have something to stand on.But you also have to have a product fit. You have to actually know what the hell your product is doing and is it going to integrate with whatever your developers want. And so, DevRel kind of stands in that gap that says, “Okay, here's what the community wants,” and advocates for the community, and then you have—it's going to advocate for the company back to the community. And hopefully, at the end of the day, they all shake hands. But also I've been around enough to recognize that there comes that point where you either a have to say, “Hey, our product for that thing is probably not the best thing for what you're trying to do. Here, you should maybe start at this other point.”And also understanding to take that even, to the next step to finish up the answer, like, my biggest piece now is all the fights that we have constantly around DevRel in the space of what is it and what is it not, DevRel is marketing. DevRel is sales. DevRel is product. And each of those, if you're not doing those things as a member of the company, you're not doing your job. Everybody in the company is the product. Everybody in the company is sales. Everybody in the company is marketing.Corey: Not everyone in the company realizes this, but I agree—Jeremy: Yes.Corey: Wholeheartedly.Jeremy: Yes. And so, that's where it's like yes, DevRel is marketing. Yes, it is sales. Because if you're not out there, spreading whatever the news is about your product and you're not actually, you know, showing people how to use it and making things easier for people, you're not going to have a job. And too often, these companies that—or too often I think a lot of DevRel teams find themselves in places where they're the first that get dropped when the company goes through things because sometimes it is just the fact that the company has not figured out what they really want, but also, sometimes it's the team hasn't really figured out how to position themselves inside the business.Corey: One of the biggest, I'll call it challenges that I see in the DevRel space comes down to defining what it is, first and foremost. I think that it is collectively a mistake for an awful lot of practitioners of developer relations, to wind up saying first and foremost that we're not marketing. Well, what is it that you believe that marketing is? In fact, I'll take it a step beyond that. I think that marketing is inherently the only place in most companies where we know that doing these things leads to good results, but it's very difficult to attribute or define that value, so how do we make sure that we're not first up on the chopping block?That has been marketing's entire existence. It's, you know that doing a whole bunch of things in marketing will go well for you, but as the old chestnut says, half your marketing budget is wasted and you'll go broke figuring out which half it is.Jeremy: Yeah. And whenever you have to make cuts, generally, they always, you know, always come to the marketing teams because hey, they're the ones spending, you know, millions of dollars a quarter on ads, or whatever it is. And so yeah, marketing has, in many ways figured this out. They're also the team that spends the most money in a company. So, I don't really know where to go with that isn't completely off the rails, but it is the reality. Like, that's where things happen, and they are the most in touch with what the direction of the company is going to ultimately be received as, and how it's going to be spoken about. And DevRel has great opportunities there.Corey: I find that when people are particularly militant about not liking sales or marketing or any other business function out there, one of the ways to get through them is to ask, “Great. In your own words, describe to me what you believe that department does. What is that?” And people will talk about marketing in a bunch of tropes—or sales in a bunch of tropes—where it is the worst examples of that.It's, “Terrific, great. Do you want me to wind up describing what you do as an engineer—in many cases—in the most toxic stereotype of Uber and 2015-style engineer I can come up with?” I think, in most cases if we're having a conversation and I haven't ended it by now, you would be horrified by that descriptor. Yeah. Not every salesperson is the skeezy used car salesman trying to trick you into something awful. Actual selling comes down to how do we wind up taking your pain away. One of my lines is, “I'm a consultant. You have problems and money. I will take both.”Jeremy: That's right [laugh]. Yeah, that's right.Corey: If you don't have a painful problem, I have nothing to sell you and all I'm doing is wasting my breath trying.Jeremy: Yeah, exactly. And that's where—I'll say it two ways—the difference between good marketing teams are, is understanding that pain point of the people that they're trying to sell to. And it's also a difference between, like, good and bad, even, DevRel teams is understanding what are the challenges that your users are having you're trying to express to, you're trying to fix? Figure that out because if you can't figure that out, then you or your marketing team are probably soon to be on the block and they're going to bring someone else in.Corey: I'm going to fight you a little bit, I suspect, in that a line I've heard is that, “Oh, DevRel is part of product because we are the voice of the community back into the development cycle of what product is building.” And the reason that I question that is I think that it glosses over an awful lot of what makes product competent as a department and not just a function done by other people. It's, “Oh, you're part of the product. Well, great. How much formal training have you had as part of your job on conducting user research and interviews with users and the rest?”And the answer invariably rounds to zero and, okay, in other words, you're just giving feedback in a drive-by fashion that not structured in any way and your product people are polite enough not to call you out on it. And that's when the fighting and slapping begins.Jeremy: Yeah. I don't think we're going to disagree too much there. I think one of the challenges, though, is for the very reason you just mentioned, that the product teams tend to hear your product sucks. And we've heard all the people telling us that, like, people in the community say that, they hear that so much and they've been so conditioned to it that it just rolls off their back, like, “Okay, whatever.” So, for DevRel teams, even if you're in product, which we can come back to that, regardless of where you're at, like, bringing any type of feedback you bring should have a person, a name associated with it with, like, Corey at Duckbill Group hates this product.Corey: Uh-oh [laugh]. Whenever my name is tied to feedback, it never goes well for me, but that will teach me eventually, ideally, to keep my mouth shut.Jeremy: Yeah. Well, how's that working for you?Corey: I'll let you know if it ever happens.Jeremy: Good. But once you start making the feedback like an actual person, it changes the conversation. Because now it's like, oh, it's not this nebulous, like, thing I can not listen to. It's now oh, it's actually a person at a specific company. So, that's one of the challenges in working with product that you have to overcome.When I think about DevRel in product, while I don't think that's a great spot for it, I think DevRel is an extension of product. That's part of where that, like, the big developer experience craze comes from, and why it is a valuable place for DevRel to be able to have input into is because you tend to be the closest to the people actually using the product. So, you have a lot of opportunities and a big surface area to have some impact.Corey: This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months, deploying passwordless on any tricky old app, and achieving business resilience with always-on identity, all from one lightweight and flexible platform.Want to see it in action? Share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of AirPods Pro. Don't miss out, visit Strata.io/ScreamingCloud. That's Strata dot io slash ScreamingCloud.Corey: I think that that is a deceptively nuanced statement. One of the things I learned from an earlier episode I had with Dr. Christina Maslach, is contributors to occupational burnout, so much of it really distills down—using [unintelligible 00:16:35] crappy layman's terms—to a lack of, I guess what I'm going to call relevance or a lack—a feeling like you are not significant to what the company is actually doing in any meaningful way. And I will confess to having had a number of those challenges in my career when I was working in production environments because, yeah, I kept the servers up and the applications up, but if you really think about it, one of the benefits of working in the system space—or the production engineers base, or DevOps, or platform engineering, or don't even start with me these days—is that what you do conveys almost seamlessly from company to company. Like, the same reason that I can do what I do now, I don't care what your company does, necessarily, I just know that the AWS bill is a bounded problem space and I can reason about it almost regardless of what you do.And if I'm keeping the site up, okay, it doesn't matter if we're streaming movies or selling widgets or doing anything, just so long as I don't find that it contradicts my own values. And that's great, but it also is isolating because you feel like you're not really relevant to the direction of what the company actually does. It's, “Okay, so what does this company do?” “We make rubber bands,” and well, I'm not really a rubber band connoisseur, but I could make sure that the website stays up. But it just feels like there's a disconnect element happening.Jeremy: That is real. It is very real. And one of the ways that I tried to kind of combat that, and I help my team kind of really try and keep this in mind, is we try to meet as much as possible with the people that are actually doing the direction, whether it be product marketing, or whether it's in product managers, or it's even, you know, in engineering is have some regular conversations with what we do as a company. How are we going to fit with that in what we do and what we say and all of our objectives, and making sure that everything we do ties to something that helps other teams and that fits within the business and where it's going so that we grow our understanding of what the company is trying to do so that we don't kind of feel like a ship that's without a sail and just floating wherever things go.Corey: On some level, I am curious as to what you're seeing as we navigate this—I don't know if it's a recession,' I don't know if it's a correction; I'm not sure what to call it—but my gut tells me that a lot of things that were aimed at, let's call it developer quality of life, they were something of a necessity in the unprecedented bull market that we've seen for the last decade at some point because most companies cannot afford to compete with the giant tech company compensation packages, so you have to instead talk about quality of life and what work-life balance looks like, and here's why all of the tools and processes here won't drive you to madness. And now it feels like, “Oh, we don't actually have to invest in a lot of those things, just because oh yeah, like, the benefits here are you're still going to be employed next week. So, how about that?” And I don't think that's a particularly healthy way to interact with people—it's certainly not how I do—but it does seem that worrying about keeping developers absolutely thrilled with every aspect of their jobs has taken something of a backseat during the downturn.Jeremy: I don't know. I feel like developer satisfaction is still an important piece, even though, you know, we have a changing market. And as you described, if you're not happy with the tool you're using, you're not going to be as productive than using the tool or using—you know, whether it's an actual developer productivity tool, or it's even just the fact that you might need two monitors, you're not going to be as productive if you're not enjoying what you're doing. So, there is a piece of it, I think, the companies are recognizing that there are some tools that do ultimately benefit and there's some things that they can say, we're not going to invest in that area right now. We're good with where we're at.Corey: On some level, being able to say, “No, we're not going to invest in that right now,” is the right decision. It is challenging, in some cases, to wind up talking to some team members in some orgs, who do not have the context that is required to understand why that decision is being made. Because without context, it looks like, “Mmm, no. I'm just canceling Christmas for you personally this year. Sorry, doesn't it suck to be you? [singing] Dut, dut.” And that is very rarely how executives make decisions, except apparently if they're Elon Musk.Jeremy: Right. Well, the [Muskrat 00:21:23] can, you know, sink any company—Corey: [laugh].Jeremy: — and get away with it. And that's one thing I've really been happy with where I'm at now, is you have a leadership team that says, “Hey, here's where things are, and here's what it looks like. And here's how we're all contributing to where we're going, and here's the decisions we're going to make, and here's how—” they're very open with what's going on. And it's not a surprise to anybody that the economic time means that we maybe can't go to 65 events next year. Like, that's just reality.But at the end of the day, we still have to go and do a job and help grow the company. So, how can we do that more efficiently? Which means that we—it leaves it better to try and figure that out than to be so nebulous, with like, “Yep, nope. You can't go do that.” That's where true leadership comes to is, like, laying it out there, and just, you know, getting people alongside with you.Corey: How do you see DevRel evolving? Because I think we had a giant evolution over the past few years. Because suddenly, the old vision of DevRel—at least in some quarters, which I admit I fell a little too deeply into—was, I'm going to go to all the conferences and give all of the talks, even though most of them are not related to the core of what I do. And maybe that's a viable strategy; maybe it's not. I think it depends on what your business does.And I don't disagree with the assertion that going and doing something in public can have excellent downstream effects, even if the connection is not obvious. But suddenly, we weren't able to do that, and people were forced to almost reinvent how a lot of that works. Now, that the world is, for better or worse, starting to open up again, how do you see it evolving? Are we going right back to a different DevOps days in a different city every week?Jeremy: I think it's a lot more strategic now. I think generally, there is less mountains of money that you can pull from to go and do whatever the hell you want. You have to be more strategic. I said that a few times. Like, there's looking at it and making sure, like, yeah, it would be great to go and, you know, get in front of 50,000 people this quarter or this year, whatever you want to do, but is that really going to move the bottom line for us? Is that really going to help the business, or is that just helping your Delta miles?What is really the best bang for the buck? So, I think DevRel as it evolves, in the next few years, has to come to a good recognition moment of we need to be a little bit more prescriptive in how we do things within our company and not so willy-nilly return to you know, what we generally used to get away with. That means you're going to see a lot more people have to be held to account within their companies of, is what you're doing actually match up to our business goal here? How does that fit? And having to explain more of that, and that's, I think, for some people will be easy. Some people are going to have to stretch that muscle, and others are going to be in a real tough pickle.Corey: One last topic I want to get into with you is devopspartygames.com, an online more or less DevOps, quote-unquote, “Personality” assortment of folks who wind up playing online games. I was invited once and promptly never invited back ever again. So first, was it something I said—obviously—and two what is that and how—is that still going in this post-pandemic-ish era?Jeremy: I like how you answered your own question first; that way I don't have to answer it. The second one, the way it came about was just, you know, Matty and I had started missing that interaction that we would tend to have in person. And so, one of the ways we started realizing is we play these, you know, Jackbox games, and why can't we just do this with DevOps tech prompts? So, that's kind of how it kicked off. We started playing around doing it for fun and then I was like, “You know, we should—we could do this as a big, big deal for foreseeable future.”Where's that now is, we actually have not done one online for—what is it? So probably, like, eight, nine months, primarily because it's harder and harder to do so as everybody [laugh]—we're now doing a little bit more travel, and it's hard to do those—as you know, doing podcasts, it takes a lot of work. It's not an easy kind of thing. And so, we've kind of put that on pause. But we actually did our first in-person DevOps Party Games at DevOpsDays Chicago recently, and that was a big hit, I think, and opportunity to kind of take what we're doing virtually, and the fun and excitement that we generally would have—relatively half-drunk—to actually doing it actually in-person at an event. And in the different—like, just as giving talks in person was a different level of interaction with the crowd, the same thing is doing it in person. So, it was just kind of a fun thing and an opportunity maybe to continue to do it in person.Corey: I think we all got a hell of a lot better very quickly at speaking to cameras instead of audiences and the rest. It also forced us to be more focused because the camera gives you nothing in a way that the audience absolutely does.Jeremy: They say make love to the camera, but it doesn't work anyways.Corey: I really want to thank you for spending as much time as you have talking to me. If people want to learn more about who you are and what you're up to, where should they go?Jeremy: Well, for the foreseeable future, or at least what we can guess, you can find me on the Twitters at @Iamjerdog. You can find me there or you can find me at, you know, LinkedIn, at jeremymeiss, LinkedIn. And you know, probably come into your local DevOpsDays or other conference as well.Corey: Of course. And we will, of course, put links to that in the show notes.Jeremy: Excellent.Corey: Thank you so much for being so generous with your time. It is always appreciated. And I do love talking with you.Jeremy: And I appreciate it, Corey. It was great beyond, finally. I won't hold it against you anymore.Corey: Jeremy Meiss, Director of DevRel at CircleCI. 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, irritated comment talking about how CI/CD is nonsense and the correct way to deploy to production is via the tried-and-true method of copying and pasting.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.

Getup Kubicast
#113 | Platform Engineering - O debate

Getup Kubicast

Play Episode Listen Later Jan 19, 2023 76:33


O Kubicast reuniu uma turma muito experiente para discutir sobre Platform Engineering. Seria o termo um cargo novo, uma área emergente, uma maneira de implementar DevOps ou um assunto do hype? E se for para ter uma plataforma, vale só aquela que você constrói? Quanto à autonomia dos Devs, o que a plataforma deveria ou não controlar? Ainda, o quanto a plataforma está atualizada para atender à demanda dos Devs? Por fim, a galera deu também a sua opinião sobre qual seria a plataforma dos sonhos!Os LINKS de alguns assuntos comentados no programa seguem abaixo:DevOps Days: https://devopsdays.org/ Team Topologies livro do Matthew Skelton Tweet do Kelsey HighTower “Plataforma é muito legal, desde que eu mesmo construa a minha!”: https://twitter.com/kelseyhightower/status/851935087532945409Palestra do Edson Yanaga - Solucionando Problemas de Microsserviços com Service Mesh: Istio e Envoy: https://www.youtube.com/watch?v=AWpsmh47pIkKubicast #59 com Bruno Rocha da Creditas: https://open.spotify.com/episode/0nCFotKAfaVVdMn9GOMUOp?si=DDnxVRa-T7q-BEWym7zfjAKubicast #93 com pessoal do Tsuru: https://open.spotify.com/episode/0psox8YUTyduqJxghZePZf?si=S-ZiSBYKS3GwKpdGs9z4BwOs PARTICIPANTES do episódio são Felipe Rocha, Nicolas Takashi, Rafael Schettino, Ricardo Castro, Sergio Soares, André Ferreira.O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e outras tecnologias cloud native que trazem performance, automação e resiliência para infraestrutura de TI. Os episódios do podcast estão em getup.io, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.

Screaming in the Cloud
Defining and Nurturing a Self-Supporting Community with Alyss Noland

Screaming in the Cloud

Play Episode Listen Later Jan 17, 2023 33:48


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.

Screaming in the Cloud
Holiday Replay Edition - Inside the Mind of a DevOps Novelist with Gene Kim

Screaming in the Cloud

Play Episode Listen Later Dec 29, 2022 30:49


About GeneGene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.Links: The Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Unicorn Project: https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/B0812C82T9 The DevOps Enterprise Summit: https://events.itrevolution.com/ @RealGeneKim TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by a man who needs no introduction but gets one anyway. Gene Kim, most famously known for writing The Phoenix Project, but now the Wall Street Journal best-selling author of The Unicorn Project, six years later. Gene, welcome to the show.Gene Kim: Corey so great to be on. I was just mentioning before how delightful it is to be on the other side of the podcast. And it's so much smaller in here than I had thought it would be.Corey Quinn: Excellent. It's always nice to wind up finally meeting people whose work was seminal and foundational. Once upon a time, when I was a young, angry Unix systems administrator—because it's not like there's a second type of Unix administrator—[laughing] The Phoenix Project was one of those texts that was transformational, as far as changing the way I tended to view a lot of what I was working on and gave a glimpse into what could have been a realistic outcome for the world, or the company I was at, but somehow was simultaneously uplifting and incredibly depressing all at the same time. Now, The Unicorn Project does that exact same thing only aimed at developers instead of traditional crusty ops folks.Gene Kim: [laughing] Yeah, yeah. Very much so. Yeah, The Phoenix Project was very much aimed at ops leadership. So, Bill Palmer, the protagonist of that book was the VP of Operations at Parts Unlimited, and the protagonist in The Unicorn Project is Maxine Chambers, Senior Architect, and Developer, and I love the fact that it's told in the same timeline as The Phoenix Project, and in the first scene, she is unfairly blamed for causing the payroll outage and is exiled to The Phoenix Project, where she recoils in existential horror and then finds that she can't do anything herself. She can't do a build, she can't run her own tests. She can't, God forbid, do her own deploys. And I just love the opening third of the book where it really does paint that tundra that many developers find themselves in where they're just caught in decades of built-up technical debt, unable to do even the simplest things independently, let alone be able to independently develop tests or create value for customers. So, it was fun, very much fun, to revisit the Parts Unlimited universe.Corey Quinn: What I found that was fun about—there are few things in there I want to unpack. The first is that it really was the, shall we say, retelling of the same story in, quote/unquote, “the same timeframe”, but these books were written six years apart.Gene Kim: Yeah, and by the way, I want to first acknowledge all the help that you gave me during the editing process. Some of your comments are just so spot on with exactly the feedback I needed at the time and led to the most significant lift to jam a whole bunch of changes in it right before it got turned over to production. Yeah, so The Phoenix Project is told, quote, “in the present day,” and in the same way, The Unicorn Project is also told—takes place in the present day. In fact, they even start, plus or minus, on the same day. And there is a little bit of suspension of disbelief needed, just because there are certain things that are in the common vernacular, very much in zeitgeist now, that weren't six years ago, like “digital disruption”, even things like Uber and Lyft that feature prominently in the book that were just never mentioned in The Phoenix Project, but yeah, I think it was the story very much told in the same vein as like Ender's Shadow, where it takes place in the same timeline, but from a different perspective.Corey Quinn: So, something else that—again, I understand it's an allegory, and trying to tell an allegorical story while also working it into the form of a fictional work is incredibly complicated. That's something that I don't think people can really appreciate until they've tried to do something like it. But I still found myself, at various times, reading through the book and wondering, asking myself questions that, I guess, say more about me than they do about anyone else. But it's, “Wow, she's at a company that is pretty much scapegoating her and blaming her for all of us. Why isn't she quitting? Why isn't she screaming at people? Why isn't she punching the boss right in their stupid, condescending face and storming out of the office?” And I'm wondering how much of that is my own challenges as far as how life goes, as well as how much of it is just there for, I guess, narrative devices. It needed to wind up being someone who would not storm out when push came to shove.Gene Kim: But yeah, I think she actually does the last of the third thing that you mentioned where she does slam the sheet of paper down and say, “Man, you said the outage is caused by a technical failure and a human error, and now you're telling me I'm the human error?” And just cannot believe that she's been put in that position. Yeah, so thanks to your feedback and the others, she actually does shop her resume around. And starts putting out feelers, because this is no longer feeling like the great place to work that attracted her, eight years prior. The reality is for most people, is that it's sometimes difficult to get a new job overnight, even if you want to. But I think that Maxine stays because she believes in the mission. She takes a great deal of pride of what she's created over the years, and I think like most great brands, they do create a sense of mission and there's a deep sense of the customers they serve. And, there's something very satisfying about the work to her. And yeah, I think she is very much, for a couple of weeks, very much always thinking about, she won't be here for long, one way or another, but by the time she stumbles into the rebellion, the crazy group of misfits, the ragtag bunch of misfits, who are trying to find better ways of working and willing to break whatever rules it takes to take over the very ancient powerful order, she falls in love with a group. She found a group of kindred spirits who very much, like her, believe that developer productivity is one of the most important things that we can do as an organization. So, by the time that she looks up with that group, I mean, I think she's all thoughts of leaving are gone.Corey Quinn: Right. And the idea of, if you stick around, you can theoretically change things for the better is extraordinarily compelling. The challenge I've seen is that as I navigate the world, I've met a number of very gifted employees who, frankly wind up demonstrating that same level of loyalty and same kind of loyalty to companies that are absolutely not worthy of them. So my question has always been, when do I stick around versus when do I leave? I'm very far on the bailout as early as humanly possible side of that spectrum. It's why I'm a great consultant but an absolutely terrible employee.Gene Kim: [laughing] Well, so we were honored to have you at the DevOps Enterprise Summit. And you've probably seen that The Unicorn Project book is really dedicated to the achievements of the DevOps Enterprise community. It's certainly inspired by and dedicated to their efforts. And I think what was so inspirational to me were all these courageous leaders who are—they know what the mission is. I mean, they viscerally understand what the mission is and understand that the ways of working aren't working so well and are doing whatever they can to create better ways of working that are safer, faster, and happier. And I think what is so magnificent about so many of their journeys is that their organization in response says, “Thank you. That's amazing. Can we put you in a position of even more authority that will allow you to even make a more material, more impactful contribution to the organization?” And so it's been my observation, having run the conference for, now, six years, going on seven years is that this is a population that is being out promoted—has been promoted at a rate far higher than the population at large. And so for me, that's just an incredible story of grit and determination. And so yeah, where does grit and determination becomes sort of blind loyalty? That's ultimately self-punishing? That's a deep question that I've never really studied. But I certainly do understand that there is a time when no amount of perseverance and grit will get from here to there, and that's a fact.Corey Quinn: I think that it's a really interesting narrative, just to see it, how it tends to evolve, but also, I guess, for lack of a better term, and please don't hold this against me, it seems in many ways to speak to a very academic perspective, and I don't mean that as an insult. Now, the real interesting question is why I would think, well—why would accusing someone of being academic ever be considered as an insult, but my academic career was fascinating. It feels like it aligns very well with The Five Ideals, which is something that you have been talking about significantly for a long time. And in an academic setting that seems to make sense, but I don't see it thought of or spoken of in the same way on the ground. So first, can you start off by giving us an intro to what The Five Ideals are, and I guess maybe disambiguate the theory from the practice?Gene Kim: Oh for sure, yeah. So The Five Ideals are— oh, let's go back one step. So The Phoenix Project had The Three Ways, which were the principles for which you can derive all the observed DevOps practices from and The Four Types of Work. And so in The Five Ideals I used the concept of The Five Ideals and they are—the first—Corey Quinn: And the next version of The Nine whatever you call them at that point, I'm sure. It's a geometric progression.Gene Kim: Right or actually, isn't it the pri—oh, no. four isn't, four isn't prime. Yeah, yeah, I don't know. So, The Five Ideals is a nice small number and it was just really meant to verbalize things that I thought were very important, things I just gravitate towards. One is Locality and Simplicity. And briefly, that's just, to what degree can teams do what they need to do independently without having to coordinate, communicate, prioritize, sequence, marshal, deconflict, with scores of other teams. The Second Ideal is what I think the outcomes are when you have that, which is Focus, Flow and Joy. And so, Dr. Mihaly Csikszentmihalyi, he describes flow as a state when we are so engrossed in the work we love that we lose track of time and even sense of self. And that's been very much my experience, coding ever since I learned Clojure, this functional programming language. Third Ideal is Improvement of Daily Work, which shows up in The Phoenix Project to say that improvement daily work is even more important than daily work itself. Fourth Ideal is Psychological Safety, which shows up in the State of DevOps Report, but showed up prominently in Google's Project Oxygen, and even in the Toyota production process where clearly it has to be—in order for someone to pull the andon cord that potentially stops the assembly line, you have to have an environment where it's psychologically safe to do so. And then Fifth Ideal is Customer Focus, really focus on core competencies that create enduring, durable business value that customers are willing to pay for, versus context, which is everything else. And yeah, to answer your question, Where did it come from? Why do I think it is important? Why do I focus on that? For me, it's really coming from the State of DevOps Report, that I did with Dr. Nicole Forsgren and Jez Humble. And so, beyond all the numbers and the metrics and the technical practices and the architectural practices and the cultural norms, for me, what that really tells the story of is of The Five Ideals, as to what one of them is very much a need for architecture that allows teams to work independently, having a higher predictor of even, continuous delivery. I love that. And that from the individual perspective, the ideal being, that allows us to focus on the work we want to do to help achieve the mission with a sense of flow and joy. And then really elevating the notion that greatness isn't free, we need to improve daily work, we have to make it psychologically safe to talk about problems. And then the last one really being, can we really unflinchingly look at the work we do on an everyday basis and ask, what the customers care about it? And if customers don't care about it, can we question whether that work really should be done or not. So that's where for me, it's really meant to speak to some more visceral emotions that were concretized and validated through the State of DevOps Report. But these notions I am just very attracted to.Corey Quinn: I like the idea of it. The question, of course, is always how to put these into daily practice. How do you take these from an idealized—well, let's not call it a textbook, but something very similar to that—and apply it to the I guess, uncontrolled chaos that is the day-to-day life of an awful lot of people in their daily jobs.Gene Kim: Yeah. Right. So, the protagonist is Maxine and her role in the story, in the beginning, is just to recognize what not great looks like. She's lived and created greatness for all of her career. And then she gets exiled to this terrible Phoenix project that chews up developers and spits them out and they leave these husks of people they used to be. And so, she's not doing a lot of problem-solving. Instead, it's this recoiling from the inability for people to do builds or do their own tests or be able to do work without having to open up 20 different tickets or not being able to do their own deploys. She just recoil from this spending five days watching people do code merges, and for me, I'm hoping that what this will do, and after people read the book, will see this all around them, hopefully, will have a similar kind of recoiling reaction where they say, “Oh my gosh, this is terrible. I should feel as bad about this as Maxine does, and then maybe even find my fellow rebels and see if we can create a pocket of greatness that can become like the sublimation event in Dr. Thomas Kuhn's book, The Structure of Scientific Revolutions.” Create that kernel of greatness, of which then greatness then finds itself surrounded by even more greatness.Corey Quinn: What I always found to be fascinating about your work is how you wind up tying so many different concepts together in ways you wouldn't necessarily expect. For example, when I was reviewing one of your manuscripts before this went to print, you did reject one of my suggestions, which was just, retitle the entire thing. Instead of calling it The Unicorn Project. Instead, call it Gene Kim's Love Letter to Functional Programming. So what is up with that?Gene Kim: Yeah, to put that into context, for 25 years or more, I've self-identified as an ops person. The Phoenix Project was really an ops book. And that was despite getting my graduate degree in compiler design and high-speed networking in 1995. And the reason why I gravitated towards ops, because that was my observation, that that's where the saves were made. It was ops who saved the customer from horrendous, terrible developers who just kept on putting things into production that would then blow up and take everyone with it. It was ops protecting us from the bad adversaries who were trying to steal data because security people were so ineffective. But four years ago, I learned a functional programming language called Clojure and, without a doubt, it reintroduced the joy of coding back into my life and now, in a good month, I spend half the time—in the ideal—writing, half the time hanging out with the best in the game, of which I would consider this to be a part of, and then 20% of time coding. And I find for the first time in my career, in over 30 years of coding, I can write something for years on end, without it collapsing in on itself, like a house of cards. And that is an amazing feeling, to say that maybe it wasn't my inability, or my lack of experience, or my lack of sensibilities, but maybe it was just that I was sort of using the wrong tool to think with. That comes from the French philosopher Claude Lévi-Strauss. He said of certain things, “Is it a good tool to think with?” And I just find functional programming is such a better tool to think with, that notions like composability, like immutability, what I find so exciting is that these things aren't just for programming languages. And some other programming languages that follow the same vein are, OCaml, Lisp, ML, Elixir, Haskell. These all languages that are sort of popularizing functional programming, but what I find so exciting is that we see it in infrastructure and operations, too. So Docker is fundamentally immutable. So if you want to change a container, we have to make a new one. Kubernetes composes these containers together at the level of system of systems. Kafka is amazing because it usually reveals the desire to have this immutable data model where you can't change the past. Version control is immutable. So, I think it's no surprise that as our systems get more and more complex and distributed, we're relying on things like immutability, just to make it so that we can reason about them. So, it is something I love addressing in the book, and it's something I decided to double down on after you mentioned it. I'm just saying, all kidding aside is this a book for—Corey Quinn: Oh good, I got to make it worse. Always excited when that happens.Gene Kim: Yeah, I mean, your suggestion really brought to the forefront a very critical decision, which was, is this a book for technology leaders, or even business leaders, or is this a book developers? And, after a lot of soul searching, I decided no, this is a book for developers, because I think the sensibilities that we need to instill and the awareness we need to create these things around are the developers and then you just hope and pray that the book will be good enough that if enough engineers like it, then engineering leaders will like it. And if enough engineering leaders like it, then maybe some business leaders will read it as well. So that's something I'm eagerly seeing what will happen as the weeks, months, and years go by. Corey Quinn: This episode is sponsored in part by DataStax. The NoSQL event of the year is DataStax Accelerate in San Diego this May from the 11th through the 13th. I've given a talk previously called the myth of multi-cloud, and it's time for me to revisit that with... A sequel! Which is funny given that it's a NoSQL conference, but there you have it. To learn more, visit datastax.com that's D-A-T-A-S-T-A-X.com and I hope to see you in San Diego. This May.Corey Quinn: One thing that I always admired about your writing is that you can start off trying to make a point about one particular aspect of things. And along the way you tie in so many different things, and the functional programming is just one aspect of this. At some point, by the end of it, I half expected you to just pick a fight over vi versus Emacs, just for the sheer joy you get in effectively drawing interesting and, I guess, shall we say, the right level of conflict into it, where it seems very clear that what you're talking about is something thing that has the potential to be transformative and by throwing things like that in you're, on some level, roping people in who otherwise wouldn't weigh in at all. But it's really neat to watch once you have people's attention, just almost in spite of what they want, you teach them something. I don't know if that's a fair accusation or not, but it's very much I'm left with the sense that what you're doing has definite impact and reverberations throughout larger industries.Gene Kim: Yeah, I hope so. In fact, just to reveal this kind of insecurity is, there's an author I've read a lot of and she actually read this blog post that she wrote about the worst novel to write, and she called it The Yeomans Tour of the Starship Enterprise. And she says, “The book begins like this: it's a Yeoman on the Starship Enterprise, and all he does is admire the dilithium crystals, and the phaser, and talk about the specifications of the engine room.” And I sometimes worry that that's what I've done in The Unicorn Project, but hopefully—I did want to have that technical detail there and share some things that I love about technology and the things I hate about technology, like YAML files, and integrate that into the narrative because I think it is important. And I would like to think that people reading it appreciate things like our mutual distaste of YAML files, that we've all struggled trying to escape spaces and file names inside of make files. I mean, these are the things that are puzzles we have to solve, but they're so far removed from the business problem we're trying to solve that really, the purpose of that was trying to show the mistake of solving puzzles in our daily work instead of solving real problems.Corey Quinn: One thing that I found was really a one-two punch, for me at least, was first I read and give feedback on the book and then relatively quickly thereafter, I found myself at my first DevOps Enterprise Summit, and I feel like on some level, I may have been misinterpreted when I was doing my live-tweeting/shitposting-with-style during a lot of the opening keynotes, and the rest, where I was focusing on how different of a conference it was. Unlike a typical DevOps Days or big cloud event, it wasn't a whole bunch of relatively recent software startups. There were serious institutions coming out to have conversations. We're talking USAA, we're talking to US Air Force, we're talking large banks, we're talking companies that have a 200-year history, where you don't get to just throw everything away and start over. These are companies that by and large, have, in many ways, felt excluded to some extent, from the modern discussions of, well, we're going to write some stuff late at night, and by the following morning, it's in production. You don't get to do that when you're a 200-year-old insurance company. And I feel like that was on some level interpreted as me making fun of startups for quote/unquote, “not being serious,” which was never my intention. It's just this was a different conversation series for a different audience who has vastly different constraints. And I found it incredibly compelling and I intend to go back.Gene Kim: Well, that's wonderful. And, in fact, we have plans for you, Mr. Quinn.Corey Quinn: Uh-oh.Gene Kim: Yeah. I think when I say I admire the DevOps Enterprise community. I mean that I'm just so many different dimensions. The fact that these, leaders and—it's not leaders just in terms of seniority on the organization chart—these are people who are leading technology efforts to survive and win in the marketplace. In organizations that have been around sometimes for centuries, Barclays Bank was founded in the year 1634. That predates the invention of paper cash. HMRC, the UK version of the IRS was founded in the year 1200. And, so there's probably no code that goes that far back, but there's certainly values and—Corey Quinn: Well, you'd like to hope not. Gene Kim: Yeah, right. You never know. But there are certainly values and traditions and maybe even processes that go back centuries. And so that's what's helped these organizations be successful. And here are a next generation of leaders, trying to make sure that these organizations see another century of greatness. So I think that's, in my mind, deeply admirable.Corey Quinn: Very much so. And my only concern was, I was just hoping that people didn't misinterpret my snark and sarcasm as aimed at, “Oh, look at these crappy—these companies are real companies and all those crappy SAS companies are just flashes in the pan.” No, I don't believe that members of the Fortune 500 are flash in the pan companies, with a couple notable exceptions who I will not name now, because I might want some of them on this podcast someday. The concern that I have is that everyone's work is valuable. Everyone's work is important. And what I'm seeing historically, and something that you've nailed, is a certain lack of stories that apply to some of those organizations that are, for lack of a better term, ossified into their current process model, where they there's no clear path for them to break into, quote/unquote, “doing the DevOps.”Gene Kim: Yeah. And the business frame and the imperative for it is incredible. Tesla is now offering auto insurance bundled into the car. Banks are now having to compete with Apple. I mean, it is just breathtaking to see how competitive the marketplaces and the need to understand the customer and deliver value to them quickly and to be able to experiment and innovate and out-innovate the competition. I don't think there's any business leader on the planet who doesn't understand that software is eating the world and they have to that any level of investment they do involves software at some level. And so the question is, for them, is how do they get educated enough to invest and manage and lead competently? So, to me it really is like the sleeping giant awakening. And it's my genuine belief is that the next 50 years, as much value as the tech giants have created: Facebook, Amazon, Netflix, Google, Microsoft, they've generated trillions of dollars of economic value. When we can get eighteen million developers, as productive as an engineer at a tech giant is, that will generate tens of trillions of dollars of economic value per year. And so, when you generate that much economic activity, all problems become solvable, you look at climate change, you take a look at the disparity between rich and poor. All things can be fixed when you significantly change the economic economy in this way. So, I'm extremely hopeful and I know that the need for things like DevOps are urgent and important.Corey Quinn: I guess that that's probably the best way of framing this. So you wrote one version that was aimed at operators back in 2013, this one was aimed at developers, and effectively retails and clarifies an awful lot of the same points. As a historical ops person, I didn't feel left behind by The Unicorn Project, despite not being its target market. So I guess the question on everyone's mind, are you planning on doing a third iteration, and if so, for what demographic?Gene Kim: Yeah, nothing at this point, but there is one thing that I'm interested in which is the role of business leaders. And Sarah is an interesting villain. One of my favorite pieces of feedback during the review process was, “I didn't think I could ever hate Sarah more. And yet, I did find her even to be more loathsome than before.” She's actually based on a real person, someone that I worked with.Corey Quinn: That's the best part, is these characters are relatable enough that everyone can map people they know onto various aspects of them, but can't ever disclose the entire list in public because that apparently has career consequences.Gene Kim: That's right. Yes, I will not say who the character is based on but there's, in the last scene of the book that went to print, Sarah has an interesting interaction with Maxine, where they meet for lunch. And, I think the line was, “And it wasn't what Maxine had thought, and she's actually looking forward to the next meeting.” I think that leaves room for it. So one of the things I want to do with some friends and colleagues is just understand, why does Sarah act the way she does? I think we've all worked with someone like her. And there are some that are genuinely bad actors, but I think a lot of them are doing something, based on genuine, real motives. And it would be fun, I thought, to do something with Elizabeth Henderson, who we decided to start having a conversation like, what does she read? What is her background? What is she good at? What does her resume look like? And what caused her to—who in technology treated her so badly that she treats technology so badly? And why does she behave the way she does? And so I think she reads a lot of strategy books. I think she is not a great people manager, I think she maybe has come from the mergers and acquisition route that viewed people as fungible. And yeah, I think she is definitely a creature of economics, was lured by an external investor, about how good it can be if you can extract value out of the company, squeeze every bit of—sweat every asset and sell the company for parts. So I would just love to have a better understanding of, when people say they work with someone like a Sarah, is there a commonality to that? And can we better understand Sarah so that we can both work with her and also, compete better against her, in our own organizations?Corey Quinn: I think that's probably a question best left for people to figure out on their own, in a circumstance where I can't possibly be blamed for it.Gene Kim: [laughing].That can be arranged, Mr. Quinn.Corey Quinn: All right. Well, if people want to learn more about your thoughts, ideas, feelings around these things, or of course to buy the book, where can they find you?Gene Kim: If you're interested in the ideas that are in The Unicorn Project, I would point you to all of the freely available videos on YouTube. Just Google DevOps Enterprise Summit and anything that's on the plenary stage are specifically chosen stories that very much informed The Unicorn Project. And the best way to reach me is probably on Twitter. I'm @RealGeneKim on Twitter, and feel free to just @ mention me, or DM me. Happy to be reached out in whatever way you can find me. Corey Quinn: You know where the hate mail goes then. Gene, thank you so much for taking the time to speak with me, I appreciate it.Gene Kim: And Corey, likewise, and again, thank you so much for your unflinching feedback on the book and I hope you see your fingerprints all over it and I'm just so delighted with the way it came out. So thanks to you, Corey. Corey Quinn: As soon as my signed copy shows up, you'll be the first to know.Gene Kim: Consider it done. Corey Quinn: Excellent, excellent. That's the trick, is to ask people for something in a scenario in which they cannot possibly say no. Gene Kim, multiple award-winning CTO, researcher, and author. Pick up his new book, The Wall Street Journal best-selling The Unicorn Project. 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 Apple Podcasts. If you hated this podcast, please leave a five-star review on Apple Podcasts and leave a compelling comment.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

Coffee and Open Source
Matty Stratton

Coffee and Open Source

Play Episode Listen Later Nov 1, 2022 61:20


Matty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences. Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL. He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. You can follow Matty on Social Media https://twitter.com/mattstratton https://matty.wtf/ Also take a look at some other links from Matty https://www.arresteddevops.com/ https://devopsdays.org/ PLEASE SUBSCRIBE TO THE PODCAST - Spotify: http://isaacl.dev/podcast-spotify - Apple Podcasts: http://isaacl.dev/podcast-apple - Google Podcasts: http://isaacl.dev/podcast-google - RSS: http://isaacl.dev/podcast-rss You can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.com/ Coffee and Open Source is hosted by Isaac Levin (https://twitter.com/isaacrlevin) --- Support this podcast: https://podcasters.spotify.com/pod/show/coffeandopensource/support

PurePerformance
How to fail at Serverless (without even trying) with Kam Lasater

PurePerformance

Play Episode Listen Later Oct 24, 2022 48:33


Serverless and other emerging technologies hide the complexity of the underlying runtimes from developers. This is great for productivity but can make it really hard when troubleshooting behavior that needs deeper insight into those runtimes, platforms or frameworks.In this episode we hear from Kam Lasater, Founder of Cyclic Software. Kam has run into several walls while he was implementing solutions from scratch using Serverless technologies as well as other popular cloud services. He recently presented a handful of those scenarios at DevOpsDays Boston 2022.Tune in and learn from Kam as he walks us through two of those challenges he covered during his DevOpsDays talk. If you want to learn more make sure to watch the full talk on YouTube: https://www.youtube.com/watch?v=xB9vsSl93mE If you want to learn more from or about Kam check out the following links:YouTube video from DevOpsDays Boston: https://www.youtube.com/watch?v=xB9vsSl93mECyclic Website: https://www.cyclic.sh/Cyclic Blog: https://www.cyclic.sh/blog/Twitter: https://twitter.com/seekayelPersonal Website: https://kamlasater.com/LinkedIn: https://www.linkedin.com/in/kamlasater/

The Cloudcast
Did we get Digital Transformation wrong?

The Cloudcast

Play Episode Listen Later Sep 18, 2022 29:21


Digital transformation has seen a number of success stories, but it's not always clear that it followed a DevOps Days pattern. Let's explore what works and maybe doesn't work.SHOW: 652CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:CloudZero - Cloud Cost Intelligence for Engineering TeamsCDN77 - Content Delivery Network Optimized for Video85% of users stop watching a video because of stalling and rebuffering. Rely on CDN77 to deliver a seamless online experience to your audience. Ask for a free trial with no duration or traffic limits.SHOW NOTES:Japan's digital minister has "declared war" on floppy disks and other retro tech used by the country's bureaucrats.IRS Reaches Milestone on Paper Return Backlog FedNow℠ Service instant payments in July 2023Amazon's API MandateGartner Bi-Modal ITCloud Adoption will fail with the skills gap (Gartner)There is no talent shortage (Andrew Clay Shafer)DIGITAL TRANSFORMATION WAS SUPPOSED TO BE THE FOUNDATION FOR DEVOPSDevs don't want to do OpsBlameless Post-Mortems don't seem to be commonHybrid Cloud didn't really materialize into real applications BUT HOW MUCH OF IT ACTUALLY WORKED OUT?Do we need more top-down leadership to make it happen?Do we need the annoying person to keep everyone on-track? Do we need more mandates declaring old technology dead? FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

AWS Developers Podcast
Episode 044 - The Evolution of DevOps with Matty Stratton - Part 2

AWS Developers Podcast

Play Episode Listen Later Jul 8, 2022 18:04


In part two, Dave and Emily continue their chat with Matty Stratton. If you missed it, please listen to part one of this conversation in Episode 043. Matt is a Staff Developer Advocate at Pulumi, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences. He is a well-known international speaker and brings over 20 years of IT Operations experience. Matt recants the early days of DevOps, shares more tech history, and offers an exciting look at what is yet to come for the industry. Matt on Twitter: https://twitter.com/mattstratton Emily on Twitter: https://twitter.com/editingemily Dave on Twitter: https://twitter.com/thedavedev Matt's Website: https://matty.wtf/ Matt's Podcast – Arrested DevOps: https://www.arresteddevops.com Matt on Twitch – DevOps Party Games: https://www.twitch.tv/devopspartygames Matt on LinkedIn: https://www.linkedin.com/in/mattstratton/ Matt's Presentations and Upcoming Speaking Events: https://speaking.mattstratton.com/ Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud

AWS Developers Podcast
Episode 043 - The Evolution of DevOps with Matty Stratton

AWS Developers Podcast

Play Episode Listen Later Jun 27, 2022 24:43


In this episode, Dave and Emily chat with Matty Stratton. Matt is a Staff Developer Advocate at Pulumi, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences. He is a well-known international speaker and brings over 20 years of IT Operations experience. Matt walk through his journey to the cloud, the early days of DevOps, the creation of DevOps days, and thought stuff on the current state of DevOps. Matt on Twitter: https://twitter.com/mattstratton Emily on Twitter: https://twitter.com/editingemily Dave on Twitter: https://twitter.com/thedavedev Matt's Website: https://matty.wtf/ Matt's Podcast – Arrested DevOps: https://www.arresteddevops.com Matt on Twitch – DevOps Party Games: https://www.twitch.tv/devopspartygames Matt on LinkedIn: https://www.linkedin.com/in/mattstratton/ Matt's Upcoming Speaking Events: https://speaking.mattstratton.com/ Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud

evolution devops it operations devopsdays arrested devops matty stratton
Screaming in the Cloud
Conveying Authenticity in Marketing with Sharone Zitzman

Screaming in the Cloud

Play Episode Listen Later Jun 2, 2022 32:16


About SharoneI'm Sharone Zitzman, a marketing technologist and open source community builder, who likes to work with engineering teams that are building products that developers love. Having built both the DevOps Israel and Cloud Native Israel communities from the ground up, today I spend my time finding the places where technology and people intersect and ensuring that this is an excellent experience. You can find my talks, articles, and employment experience at rtfmplease.dev. Find me on Twitter or Github as @shar1z.Links Referenced: Personal Twitter: https://twitter.com/shar1z Website: https://rtfmplease.dev LinkedIn: https://www.linkedin.com/in/sharonez/ @TLVCommunity: https://twitter.com/TLVcommunity @DevOpsDaysTLV: https://twitter.com/devopsdaystlv 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: DoorDash had a problem as their cloud native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, competence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud/C-H-R-O-N-O-S-P-H-E-R-E.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance. To learn more visit: snark.cloud/deployandgoCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I have been remiss by not having today's guest on years ago because back before I started this ridiculous nonsense that, well, whatever it is you'd call what I do for a living, I did other things instead. I did the DevOps, which means I was sad all the time. And the thing that I enjoyed was the chance to go and speak on conference stages. One of those stages, early on in my speaking career, was at DevOpsDays Tel Aviv.My guest today is Sharone Zitzman, who was an organizer of DevOpsDays Tel Aviv, who started convincing me to come back. And today is in fact, in the strong tradition here of making up your own job titles in ways that make people smile, she is the Chief Manual Reader at RTFM Please Ltd. Sharone, thank you for joining me.Sharone: Thank you for having me, Corey. Israelis love the name of my company, but Americans think it has a lot of moxie and chutzpah. [laugh].Corey: It seems a little direct and aggressive. It's like, oh, good, you are familiar with how this is going to go. There's something to be said for telling people what you do on the tin upfront. I've never been a big fan of trying to hide that. I mean, the first iteration of my company was the Quinn Advisory Group because I thought, you know, let's make it look boring and sedate and like I can talk to finance people. And yeah, that didn't last more than ten seconds of people talking to me.Also, in hindsight, the logo of a big stylized Q. Yeah, I would have had to change that anyway, for the whole QAnon nonsense because I don't want to be mistaken for that particular brand of nuts.Sharone: Yeah, I decided to do away with the whole formalities and upfront, just go straight [laugh]. For the core of who we are, Corey; you are very similar in that. So, yes. Being a dev first company, I thought the developers would appreciate such a title and name for my company. And I have to give a shout out here to Avishai Ish-Shalom, who's my friend from the community who you also know from the DevOpsDays community.Corey: Oh, yeah @nukemberg on Twitter—Sharone: Yes exactly.Corey: For those who are not familiar.Sharone: [laugh]. Yep. He coined the name.Corey: The problem that I found is that people when they start companies or they manage their careers, they don't bias for the things that they're really good at. And it took me a long time to realize this, I finally discovered, “Ah, what am I the best at? That's right, getting myself fired for my personality, so why don't I build a business where that stops being a liability?” So, I started my own company. And I can tell this heroic retcon of what happened, but no, it's because I had nowhere else to go at that point.And would you hire me? Think about this for a minute. You, on the other hand, had options. You are someone with a storied history in community building, in marketing to developers without that either coming across as insincere or that marked condescending accent that so many companies love to have of, “Oh, you're a developer. Let me look at you and get down on my hands and knees like we're going camping and tell a story in ways that actively and passively insult you.”No, you have always gotten that pitch-perfect. The world was your oyster. And for some godforsaken reason, you looked around and decided, “Ah, I'm going to go out independently because you know what I love? Worrying.” Because let's face it, running your own company is an exercise in finding new and exciting things to worry about that 20 minutes ago, you didn't know existed. I say this from my own personal experience. Why would you ever do such a thing?Sharone: [laugh]. That's a great question. It was a long one, but a good one. And I do a thing where I hit the mic a lot because I also have. I can't control my hand motions.Corey: I too speak with my hands. It's fine.Sharone: [laugh]. Yeah, so it's interesting because I wanted to be independent for a really long time. And I wasn't sure, you know, if it was something that I could do if I was a responsible enough adult to even run my own company, if I could make it work, if I could find the business, et cetera. And I left the job in December 2020, and it was the first time that I hadn't figured out what I was doing next yet. And I wanted to take some time off.And then immediately, like, maybe a week after I started to get a lot of, like, kind of people reaching out. And I started to interview places and I started to look into possibly being a co-founder at places and I started to look at all these different options. And then just, I was like, “Well…. This is an opportunity, right? Maybe I should finally—that thing that's gnawing at the back of my head to see if, like, you know if I should go for this dream that I've always wanted, maybe now I can just POC it and see if, you know, it'll work.”And it just, like, kind of exploded on me. It was like there was so much demand, like, I just put a little, like, signal out to the world that this is something that I'm interested in doing, and everyone was like, “Ahh, I need that.” [laugh]. I wanted to take a quarter off and I signed my first clients already on February 1st, which was, like, a month after. I left in December and that—it was crazy. And since then, I've been in business. So, yeah. So, and since then, it's also been a really crazy ride; I got to discover some really exciting companies. So.Corey: How did you get into this? I found myself doing marketing-adjacent work almost entirely by accident. I started the newsletter and this podcast, and I was talking to sponsors periodically and they'd come back with, “Here's the thing we want you to talk about in the sponsor read.” And it's, “Okay, you want to give people a URL to go to that has four sub-directories and entire UTM code… okay, have you considered, I don't know, not?” And because so much of what they were talking about did not resonate.Because I have the engineering background, and it was, I don't understand what your company does and you're spending all your time talking about you instead of my painful problem. Because as your target market, I don't give the slightest of shits about you, I care about my problem, so tell me how you're going to solve my problem and suddenly I'm all ears. Spend the whole time talking about you, and I could not possibly care less and I'll fast-forward through the nonsense. That was my path to it. How did you get into it?Sharone: How did I get into it? It's interesting. So, I started my journey in typical marketing, enterprise B2B marketing. And then at GigaSpaces, we kickstarted the open-source project Cloudify, and that's when I found myself leading this project as the open-source community team leader, building, kind of, the community from the ground floor. And I discovered a whole new world of, like, how to build experience into your marketing, kind of making it really experiential and making sure that everyone has a really, really easy and frictionless way of using your product, and that the product—putting the product at the center and letting it speak for itself. And then you discover this whole new world of marketing where it's—and today, you know, it has more of a name and a title, PLG, and people—it has a whole methodology and practice, but then it was like we were—Corey: PLG? I'm unfamiliar with the acronym. I thought tech was bad for acronyms.Sharone: Right? [laugh]. So, product-led growth. But then, you know, like, kind of wasn't solidified yet. And so, a lot of what we were doing was making sure that developers had a really great experience with the product then it kind of sold itself and marketed itself.And then you understood what they wanted to hear and how they wanted to consume the product and how they wanted it to be and to learn about it and to kind of educate themselves and get into it. And so, a lot of the things that I learned in the context of marketing was very guerilla, right, from the ground up and kind of getting in front of people and in the way they wanted to consume it. And that taught me a lot about how developers consume technology, the different channels that they're involved in, and the different tools that they need in order to succeed, and the different, you know, all the peripheral experience, that makes marketing really, really great. And it's not about what you're selling to somebody; it's making your product shine and making the experience shine, making them ensure that it's a really, really easy and frictionless experience. You know, I like how [Donald Bacon 00:08:00] says it; he calls it, like, mean time to hello world, and that to me is the best kind of marketing, right? When you enable people to succeed very, very quickly.Corey: Yeah, there's something to be said for the ring of authenticity and the rest. Periodically I'll promote guest episodes on this, where it's a sponsored episode where people get up and they talk about what they're working on. And they're like, “Great. So, here's the sales pitch I want to give,” and it's no you won't because first, it won't work. And secondly, I'm sorry, whether it's a promoted episode or not, I will not publish something that isn't good because I have a reputation to uphold here.And people run into challenges an awful lot when they're trying to effectively tell their story. If you have a startup that was founded by an engineer, for example, as so many of these technical startups were, the engineer is often so deeply and profoundly in love with this problem space and the solution and the rest, but if they talk about that, no one cares about the how. I mean, I fix AWS bills, and people don't care—as a general rule—how I do that at all if they're in my target market. They don't care if it's through clever optimization, amazing tooling, doing it on-site, or taking hostages in Seattle. They care about their outcome much more than they ever do about the how.The only people who care about the how are engineers who very often are going to want to build it themselves, or work for you, or start a competitor. And it doesn't resonate in quite the same way. It's weird because all these companies are in slightly different spaces; all of them tend to do slightly different things—or very different things—but so many of the challenges that I see in the way that they're articulating what they do to customers rhymes with one another.Sharone: Yeah. So, I agree completely that developers will talk often about how it works. How it works. How does it work under the hood? What are the bits and bytes, you know?Like, nobody cares about how it works. People care about how will this make my life better, right? How will this improve my life? How will this change my life? [laugh]. As an operations engineer, if I'm, you know, crunching through logs, how will this tool change that? What my days look like? What will my on-call rotation look like? What will—you know, how are you changing my life for the better?So, I think that that's the question. When you learn how to crystallize the answer to that question and you hit it right on the mark—you know, and it takes a long time to understand the market, and to understand the buying persona, and t—and there's so much that you have to do in the background, and so much research you have to do to understand who is that person that needs to have that question answered? But once you do and you crystallize that answer, it lands. And that's the fun part about marketing, really trying to understand the person who's going to consume your product and how you can help them understand that you will make their life better.Corey: Back when I was starting out as a consultant myself, I would tell stories that I had seen in the AWS billing environment, and I occasionally had clients reach out to me, “Hey, why don't you tell our story in public?” It's, “Because that wasn't your story. That was something I saw on six different accounts in the same month. It is something that everyone is feeling.” It's, people think that you're talking about them.So, with that particular mindset on this, without naming specific companies, what themes are you seeing emerging? What are companies getting wrong when they are attempting and failing to market effectively to developers?Sharone: So, exactly what we're talking about in terms of the product pitch, in that they're talking at developers from this kind of marketing speak and this business language that, you know, developers often—you know, unless a company does a really, really good job of translating, kind of, the business value—which they should do, by the way—to engineers, but oftentimes, it's a little bit far from them in the chain, and so it's very hard for them to understand the business fluff. If you talk to them in bits and bytes of this is what my day-to-day developer workflow looks like and if we do these things, it'll cut down the time that I'm working on these things, it'll make these things easier, it'll help streamline whatever processes that are difficult, remove these bottlenecks, and help them understand, like I said, how it improves their life.But the things that I've seen breakdown is also in the authenticity, right? So obviously, the world is built on a lot of the same gimmicks and it's just a matter of whether you're doing it right or not, right? So, there's so much content out there and webcasts and webinars, and I don't know what and podcasts and whatever it is, but a lot of the time, people, their most valuable asset is their time. And if you end up wasting their time, without it being, like, really deeply valuable—if you're going to write content, make sure that there is a valuable takeaway; if you're going to create a webinar, make sure that somebody learned something. That if they're investing their time to join your marketing activities, make sure that they come away with something meaningful and then they'll really appreciate you.And it's the same idea behind the whole DevOpsDays movement with the law of mobility and open spaces that people if they find value, they'll join this open space and they'll participate meaningfully and they'll be a part of your event, and they'll come back to your event from year to year. But if you're not going to provide that tangible value that somebody takes away, and it's like, okay, well, I can practically apply this in my specific tech stack without using your tool, without having to have this very deterministic or specific kind of tech stack that they're talking about. You want to give people something—or even if it is, but even how to do it with or without, or giving them, like, kind of practical tools to try it. Or if there's an open-source project that they can check out first, or some kind of lean utility that gives them a good indication of the value that this will give them, that's a lot more valuable, I think. And practically understandable to somebody who wants to eventually consume your product or use your products.Corey: The way that I see things, at least in the past couple of years, the pandemic has sharpened an awful lot of the messaging that needs to happen. Because in most environments, you're sitting at a DevOpsDays in the front row or whatnot, and it's time for the sponsor talks and someone gets up and starts babbling and wasting your time, most people are not going to get up and leave. Okay, they will in Israel, but in most places, they're not going to get up and leave, whereas in pandemic land, it's you are one tab away from something I actually want—Sharone: Exactly.Corey: To be doing, so if you become even slightly boring, it's not going to go well. So, you have to be on message, you have to be on point or no one cares. People are like, “Oh, well what if we say the wrong thing and people wind up yelling about us on Twitter?” It's like unless it is for something horrifying, you should be so lucky because people are then talking about you. The failure mode isn't that people don't like your product, it's no one talks about it.Sharone: Yeah. No such thing as bad publicity [crosstalk 00:14:32] [laugh]—Corey: Oh, there very much is such a thing is bad publicity. Like, “I could be tweeting about your product most days,” is apparently a version of that, according to some folks. But it's a hard problem to solve for. And one of the things that continually surprises me is the things I'm still learning about this entire industry. The reason that people sponsor this show—and the rates they pay, to be direct—have little bearing to the actual size of the audience—as best we can tell; lies, damn lies, and podcast statistics; if you're listening to this, let me know. I'd love to know if anyone listens to this nonsense—but when you see all of that coming out, why are we able to charge the rates that we do?It's because the long-term value of someone who is going to buy a long-term subscription or wind up rolling out something like ChaosSearch or whatnot that is going to be a fundamental tenet of their product, one prospect becoming a customer pays for anything, I can sell a company, it will sponsor—they can pay me to sponsor for the next ten years, as opposed to the typical mass-market audience where well, I'm here to sling Casper mattresses today or something. It's a different audience and there's a different perception there. People are starting to figure out the value of—in an age where tracking is getting harder and harder to do and attribution will drive you nuts, instead of go where your audience is. Go where the people who care about the problem that you have and will experience that problem are going to hang out. And it always is wild to me to see companies missing out on that.It's, “Okay, so you're going to do a $25 million billboard ad in spotted in airports around the world talking about your company… but looking at your billboard, it makes no sense. I don't understand what it's there for.” Even as a brand awareness play, it fails because your logo is tiny in the corner or something. It's you spent that much money on ads, and maybe a buck on messaging because it seems like with all that attention you just bought, you had nothing worthwhile to say. That's the cardinal sin to me at least.Sharone: Yeah. One thing that I found—and back to our community circuit and things that we've done historically—but that's one thing that, you know, as a person comes from community, I've seen so much value, even from the smaller events. I mean, today, like with Covid and the pandemic and everything has changed all the equilibrium and the way things are happening. But some meetups are getting smaller, face-to-face events are getting smaller, but I've had people telling me that even from small, 30 to 40 people events, they'll go up and they'll do a talk and great, okay, a talk; everybody does talks, but it's like, kind of, the hallway track or the networking that you do after the talk and you actually talk to real users and hear their real problems and you tap into the real community. And some people will tell me like, I had four concrete leads from a 30-person meet up just because they didn't even know that this was a real challenge, or they didn't know that there was a tool that solves this problem, or they didn't understand that this can actually be achieved today.Or there's so many interesting technologies and emerging technologies. I'm privileged to be able to be at the forefront of that and discover it all, and I if I could, I would drop names of all of the awesome companies that work for me, that I work with, and just give them a shout out. But really, there's so many amazing companies doing, like, developer metrics, and all kinds of troubleshooting and failure analysis that's, like, deeply intelligent—and you're going to love this one: I have a Git replacement client apropos to your closing keynote of DevOpsDays 2015—and tapping into the communities and tapping into the real users.And sometimes, you know, it's just a matter of really understanding how developers are working, what processes look like, what workflows look like, what teams look like, and being able to architect your products and things around real use cases. And that you can only discover by really getting in front of actual users, or potential users, and learning from them and feedback loops, and that's the little core behind DevRel and developer advocacy is really understanding your actual users and your consumers, and encouraging them to you know, give you feedback and try things, and beta programs and a million things that are a lot more experiential today that help you understand what your users need, eventually, and how to actually architect that into your products. And that's the important part in terms of marketing. And it's a whole different marketing set. It's a whole different skill set. It's not talking at people, it's actually… ingesting and understanding and hearing and implementing and bringing it into your products.Corey: And it takes time. And you have to make yourself synonymous with a painful problem. And those problems are invariably very point-in-time specific. I don't give a crap about log aggregation today, but in two weeks from now, when I'm trying to chase down 18 different Lambdas function trying to figure out what the hell's broken this week, I suddenly will care very much about log aggregation. Who was that company that's in that space that's doing interesting things? And maybe it's Cribl, for example; they do a lot of stuff in that space and they've been a good sponsor. Great.I start thinking about those things in that light because it is—when I started having these problems, it sticks in your head and it resonates. And there's value and validity to that, but you're never going to be able to attribute that either, which is where people often lose their minds. Because for anything even slightly complicated—you're going to be selling things to big bank—great, good on you. Most of those customers are not going to go and spin up a trial in the dead of night. They're going to hear about you somewhere and think, “Ohh, this is interesting.”They're going to talk about a meeting, they're going to get approval, and at that point, you have long since lost any tracking opportunity there. So, the problem is that by saying it like this, as someone who is a publisher, let's be very clear here, it sounds like you're trying to justify your entire business model. I feel like that half the time, but I've been reassured by people who are experts in doing these things, like, oh, yeah, we have data on this; it's working. So, the alternative is either I accept that they're right or I sit here and arrogantly presume I know more about marketing than people who've devoted their entire careers to it. I'm not that bold. I am a white guy in tech, but not that much.Sharone: Yeah, I mean, the DevRel measurement problem is a known problem. We have people like [unintelligible 00:20:21] who have written about it. We have [Sarah Drasner 00:20:23], we have a million people that have written really, really great content about how do you really measure DevRel and the quality. And one of the things that I liked, Philipp Krenn, the dev advocate at Elastic once said in one of his talks that, you know, “If you're measuring your developer advocates on leads, you're a marketing organization. If you're measuring them on revenue, you're a sales organization. It's about reach, engagement, and awareness, and a lot of things that it's much, much harder to measure.”And I can say that, like, once upon a time, I used to try and attribute it at Cloudify. Like, I remember thinking, like, “Okay, maybe I could really track this back to, you know, the first touch that I actually had with this user.” It's really, really difficult, but I do remember, like, when we used to go out into the events and we were really active in the OpenStack community, in the DevOps community, and many other things, and I remember, like, even after events, like, you get all those lead gen emails. All I would say now is, like, “Hey, if you missed us at the booth, you know, and you want still want a t-shirt, you know, reach out and I'll ship it to you.” And some of those eventually, after we continued the relationship, and we, you know, when we were friends and community friends, six months later, when they moved to their next role at their next job, they were like, “Oh, now I have an opportunity to use Cloudify and I'm going to check it out.”And it's very long relationship that you have to cultivate. It has to be, you know, mutual. You have to be, you have to give be giving something and eventually is going to come back to you. Good deeds come back to you. So, I—that's my credo, by the way, good deeds come back to you. I believe in that and I try to live by that.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: So, I have one last question for you and it is pointed and the reason I buried it this deep in the episode is so that if I open with it, I will get letters and I'm hoping to get fewer of them. But I met you, again, at DevOpsDays Tel Aviv, and it was glorious. And then you said, “This is fun. Come help me organize it next year.”And I, like an idiot said, “Sure, that sounds awesome because I love going to conferences and it's great. So, what's involved?” “Oh, a whole bunch of meetings.” “Okay, great.” “And planning”—things I'm terrible at—“Okay.” And then the big day finally arrives where, “Great, when do we get to get on stage and tell a story?” Like, “That's the neat part. We don't.” So, I have to ask, given that it is all behind-the-scenes work that is fairly thankless unless you really screw it up because then it's very visible, what is the point of being so involved in the community?Sharone: Wow, that's a big question, Corey.Corey: It really is.Sharone: [laugh].Corey: Because you've been involved in community for a long time and you're very good at it.Sharone: It's true. It's true. Appreciate it, thank you. So, for me, first of all, I enjoy, kind of, the people aspect of it, absolutely. And that people aspect of it actually has played out in so many different ways.Corey: Oh, you mean great people, and also me.Sharone: [laugh]. Particularly you, Corey, and we will bring you back. [laugh]. And we will make sure you chop wood and carry water because eventually it'll fill your soul, you'll see. [laugh] one of the things that really I have had the privilege and honor, and having come out of, like, kind of all my community work is really the network I've built and the people that I've met.And I've learned so much and I've grown so much, but I've also had the opportunity to connect people, connect things that you wouldn't imagine, un—seemingly-related things. So, there are so many friends of mine that have grown up with me in this community, it's been already ten years now, and a lot of folks have now been going on to new adventures and are looking to kickstart their new startup and I can connect them to this investor, I can connect them to this other person who is maybe a good, you know, partner for their startup, and hiring opportunities, and something—I've had this, like, privilege of kind of being able to connect Israel to the outer world and other things and the global kind of community, and also bring really intelligent folks into the community. And this has just created this amazing flywheel of opportunity that I'm really happy to be at the center of. And I think I've grown as a person, I think our community has grown, has learned, and there's a lot of value in that, I think, yeah. We got to meet wonderful folks like you, Corey. [laugh].Corey: It has its moments. Again, you're one of those rarities in that it's almost become a trope in VC land where VCs always like, “How may I be useful?” And it's this self-serving transparent thing. Every single time you have deigned to introduce me to someone, it's been a productive conversation and I'm always glad I took the meeting. That is no small thing.A lot of people say, “I'm good at community,” which is sort of cover for, “I'm not good at anything,” but in your case, it—Sharone: [laugh]. [I'm an entrepreneur 00:24:48].—Corey: Is very much not true. Oh, yeah. I'm a big believer that ‘entrepreneur' and ‘hero' and other terms like that are things people call you; you don't call yourself that. It always feels weird for, “Oh, he's an entrepreneur.” It's like, that's a pretty lofty word for shitposting, but okay, we'll roll with it.It doesn't work that way. You've clearly invested long-term in a building reputation for yourself by building a name for yourself in the space, and I know that whenever you reach out to me as a result, you are not there to waste my time or shill some bullshit. It is always something that is going to, even if I don't love every aspect of it or agree with the core of the message you're sending, great, it is never not going to be worth my time, which is why I'm so glad I got the chance to talk to you this show.Sharone: I appreciate that. It's something that I really believe in, I don't want to waste people's time and I really only will connect folks or only really will reach out to someone if I do think that there's something meaningful for both sides. It's never only what's in it for me, also. I also want to make sure that there's something in it for the other person and it's something that makes sense and it's meaningful for both sides. I've had the opportunity of meeting such interesting folks, and sometimes it's just like, “You must meet. [laugh]. You will love each other.” You will have so much to do together or it's so much collaboration opportunity.And so yeah, I really am that type of person. And I'll even say from a personal perspective, you know, I know a lot of people, and I've even been asked from the flip side, “Okay, is this a toxic manager? Or is this a, you know, a good hire? Is this”—and I tried to provide really authentic input so people make the right decisions, or make, you know, the right contacts, or make—and that's something I really value. And I managed to build trust with a lot of really great folks—Corey: And also me—Sharone: —and it's come back to me, also. And—[laugh] and particularly you, again. [laugh].Corey: If people want to learn more about how you see the world and the space and otherwise bask in your wisdom, where's the best place to find you?Sharone: So, I'm on Twitter as @shar1z, which is SharoneZ. Basically, everyone thinks it's such a smart, or I don't know what, like, or an esoteric screen name. And I'm like, no, it's just my name, I just—the O-N-E is… the one. [laugh].So yes, shar1z on Twitter, but also my website, rtfmplease.dev, you can reach out, there's a contact form there. You can find me on the web anywhere—LinkedIn. Reach out, I answer almost all my DMs when I can. It's very rare that I don't answer DMs. Maybe there'll be a slight lag, but I do. And I really do like when folks reach out to me. I do like it when people try and make contact.Corey: And you can also be found, of course, wherever find DevOps products are sold, on stage apparently.Sharone: [laugh]. The DevOps community, that's right. @TLVCommunity, @DevOpsDaysTLV—don't out me. All those are—yes, those are also handles that I run on Twitter, it's true.Corey: Excellent.Sharone: So, when you see them all retweeting the same tweet, yes, it's happening within same five minutes, it's me.Corey: Oh, that would have made it way easier to go viral. My God, I should have just thought of that earlier.Sharone: [laugh].Corey: Thank you so much for your time. I appreciate it.Sharone: Thank you, Corey, for having me. It's been a privilege and honor being on your show and I really do think that you are doing wonderful things in the cloud space. You're teaching us, and we're all learning, and you—keep up the good work.Corey: Well, thank you. I appreciate that.Sharone: I also want to add that on proposed marketing and whatever, I do actually listen to all of your openings of all of your shows because they're not fluffy and I like that you do, like, kind of a deep explanation, a deep technical explanation of what your sponsoring product does, and it gives a lot more insight into why is this important. So, I think you're doing that right. So, anybody who's sponsoring this show, listen. Corey knows what he's doing.Corey: Well, thank you. I appreciate that. Yay, “I know what I'm doing.” That one's going in the testimonial kit. My God.Sharone: [laugh]. That's the name of this episode, “Corey knows what he's doing.”Corey: We're going to roll with it, you know. No take-backsies. Sharone Zitzman, Chief Manual Reader at RTFM Please. 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 of your podcast platform of choice, or if it's on the YouTubes smash the like and subscribe buttons, whereas if you've hated this show, exact same thing—five-star review wherever you happen to find it, smash both the buttons—but also leave an insulting comment telling me that I'm completely wrong which then devolves into an 18-page diatribe about exactly how your nonsense, bullshit product is built and works.Sharone: [laugh].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.

InSecurity
Mike Fraser: Developers... Adapt or DIE!

InSecurity

Play Episode Listen Later May 18, 2022 72:59


    How can we make a better mousetrap if the designers of and the materials that go into the contemporary mousetraps aren't good enough to keep pace with the current mouse?   Adapt or perish… now as ever, is nature's inexorable imperative  --HG Wells   It is not the strongest species that survie, nor the most intelligent… but the ones most responsive to change  --Charles Darwin   You improvise! You adapt! You overcome!  -- Gunnery Sgt Tom Highway; Heartbreak Ridge   All due respect to the United States Air Force   Do you know what SecDevOps is? Do you know how when or why the concept applies to cybersecurity and the world at large? What if I told you that there are people out there who personify the definition of what we identify as SecDevOps.   Well… I gotta guy…   On today's episode, Matt Stephenson welcomes Mike Fraser, VP of DevSecOps at Sophos. We take a look at the role that developers can and must play in the world of cybersecurity. These aren't the folks building the security building... the are the ones making the bricks and hammers used to construct that building. How important are the materials used to construct the very infrastructure of an entire industry? Tune in and find out...   About Mike Fraser Mike Fraser is Vice President of DevSecOps at Sophos. Previously, he was co-founder, CEO and chief architect at Refactr (acquired by Sophos in 2021) where he spearheaded the creation of a DevSecOps automation platform that bridges the gap between DevOps and cybersecurity.   Mike is a regular speaker at numerous industry events, including Hashiconf, Hashitalks, KubeSec, various Microsoft events, RedHat AnsibleFest, DevOps Days, and All Day DevOps.   He has also published several feature articles including on TechCrunch, RSA 365, and DevOps.com.   In addition to his Sophos role, Mike helps advise other veteran-led software startups. While leading Refactr, Mike earned a bachelor's degree in application development from North Seattle College and has a master's degree in computer science from Seattle University.   He is also, and it is clearly stated on his CV, the World's Coolest Dad   About Matt Stephenson My name is Matt Stephenson (@packmatt73) and I have hosted podcasts, videos and live events all over the world which put me with experts on every corner of the cybersecurity landscape. pm73media is my first solo endeavor. On this platform and others to come, I will continue to expand upon the tradition we started with the Insecurity podcast as I seek out the leading minds in the tech industry and beyond. I am always looking for fun people who may break things every now and again.   In 20 years in the ecosystem of Data Protection and Cybersecurity I have toured the world extolling the virtues of Artificial Intelligence and Machine Learning and how, when applied to information security, these technologies can wrong-foot the bad guys.   Whether in person, live virtual events or podcasting, I get to interview interesting people doing interesting things all over the world of technology and the extended world of hacking. Sometimes, that means hacking elections or the coffee supply chain... other times that means social manipulation or the sovereign wealth fund of a national economy.   Wherever I go, my job is all about talking with the people who build, manage or wreck the systems that we have put in place to make the world go round...   If you tuned in to any of my previous podcasts, there's great news…! pm73media is here! I will be bringing the same kind of energy and array of guests you know and love. Best part? We're still at the same spot. You can find it at Spotify, Apple, Amazon Music & Audible as well as GooglePlay, Gaana, Himalaya, I Heart Radio and wherever you get your podcasts!   Make sure you Subscribe, Rate and Review!

PurePerformance
When DevOps, SRE and Keptn go on a road-trip

PurePerformance

Play Episode Listen Later May 2, 2022 35:23


The world is slowly moving back to having on-site meetings and conferences – such as DevOpsDays in Raleigh, NC where Andi presented on “Oh Keptn, my Keptn”.Besides presenting Andi also visited several organizations on his road trip through North Carolina and Texas. Listen in and learn what the adoption challenges of DevOps & SRE are, how to define good SLOs (Service Level Objectives) and how to explain the difference between containers and microservices. Also check out the following links Brian and Andi discussed:State of SRE Report: https://www.dynatrace.com/info/sre-report/DevOpsDays Raleigh: https://devopsdays.org/events/2022-raleigh/program/andreas-grabner SLOConf: https://www.sloconf.com/WTFisSRE: https://www.cloud-native-sre.wtf/Keptn: https://www.keptn.sh

Screaming in the Cloud
Allowing Aspiration to Lead with Tom Totenberg

Screaming in the Cloud

Play Episode Listen Later Apr 21, 2022 41:50


About TomTom enjoys being a bridge between people and technology. When he's not thinking about ways to make enterprise demos less boring, Tom enjoys spending time with his wife and dogs, reading, and gaming with friends.Links Referenced: LaunchDarkly: https://launchdarkly.com Heidi Waterhouse Twitter: https://twitter.com/wiredferret 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: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is brought to us by our friends at LaunchDarkly. And it's always interesting when there's a promoted guest episode because they generally tend to send someone who has a story to tell in different ways.Sometimes they send me customers of theirs. Other times they send me executives. And for this episode, they have sent me Tom Totenberg, who's a senior solutions engineer at LaunchDarkly. Tom, thank you for drawing the short straw. It's appreciated.Tom: [laugh]. Anytime. Thank you so much for having me, Corey.Corey: So, you're a senior solutions engineer, which in many different companies is interpreted differently, but one of the recurring themes tends to pop up is often that is a different way of saying sales engineer because if you say sales, everyone hisses and recoils when you enter the conversation. Is that your experience or do you see your role radically differently?Tom: Well, I used to be one of those people who did recoil when I heard the word sales. I was raised in a family where you didn't talk about finances, you know? That's considered to be faux pas, and when you hear the word sales, you immediately think of a car lot. But what I came to realize is that, especially when we talk about cloud software or any sort of community where you start to run into the same people at conferences over and over and over again, turns out the good salespeople are the ones who actually try to form relationships and try to solve problems. And I realized that oh, I like to work with those people. It's pretty exciting. It's nice to be aspirational about what people can do and bring in the technical chops to see if you can actually make it happen. So, that's where I fit in.Corey: The way that I've always approached it has been rather different. Because before I got into tech, I worked in sales a bunch of times and coming up from the—I guess, clawing your way up doing telesales was a polite way of describing—back in the days before there were strong regulations against it, calling people at dinner to sell them credit cards. And what's worse is I was surprisingly effective at it for a kid who, like, you grew up in a family where we didn't talk about money. And it's easy to judge an industry by its worst examples. Another one of these would be recruiting, for example.When everyone talks about how terrible third-party recruiters are because they're referring to the ridiculous spray-and-pray model of just blasting out emails to everything that hold still long enough that meets a keyword. And yeah, I've also met some recruiters that are transformative as far as the conversations you have with them go. But some of that with sales. It's, “Oh, well, you can't be any fun to talk to because I had a really bad experience buying a used car once and my credit was in the toilet.”Tom: Yeah, exactly. And you know, I have a similar experience with recruiters coming to LaunchDarkly. So, not even talking about the product; I was a skeptic, I was happy where I was, but then as I started talking to more and more people here, I'm assuming you've read the book Accelerate; you probably had a hand in influencing part of it.Corey: I can neither confirm nor deny because stealing glory is something I only do very intentionally.Tom: Oh okay, excellent. Well, I will intentionally let you have some of that glory for you then. But as I was reading that book, it reminded me again of part of why I joined LaunchDarkly. I was a skeptic, and they convinced me through everyone that I talked to just what a nice place it is, and the great culture, it's safe to fail, it's safe to try stuff and build stuff. And then if it fails, that's okay. This is the place where that can happen, and we want to be able to continue to grow and try something new.That's again, getting back to the solutions engineer, sales engineer part of it, how can we effectively convey this message and teach people about what it is that we do—LaunchDarkly or not—in a way that makes them excited to see the possibilities of it? So yeah, it's really great when you get to work with those type of people, and it absolutely shouldn't be influenced by the worst of them. Sometimes you need to find the right ones to give you a chance and get in the door to start having those conversations so you can make good decisions on your own, not just try to buy whatever someone's—whatever their initiative is or whatever their priority is, right?Corey: Once upon a time when I first discovered LaunchDarkly, it was pretty easy to describe what you folks did. Feature flags. For longtime listeners of the show, and I mean very longtime listeners of the show, your colleague Heidi Waterhouse was guest number one. So, I've been talking to you folks about a variety of different things in a variety of different ways. But yeah, “LaunchDarkly. Oh, you do feature flags.”And over time that message has changed somewhat into something I have a little bit of difficulty to be perfectly honest with you in pinning down. At the moment we're recording this, if I pull up launchdarkly.com, it says, “Fundamentally change how you deliver software. Innovate faster, deploy fearlessly, and make each release a masterpiece.”And I look at the last release I pushed out, which wound up basically fixing a couple of typos there, and it's like, “Well, shit. Is it going to make me sign my work because I'm kind of embarrassed by a lot of it.” So, it's aspirational, I get it, but it also somehow [occludes 00:05:32] a little bit of meaning. What is it you'd say it is you do here.Tom: Oh, Office Space. Wonderful. Good reference. And also, to take about 30 seconds back, Heidi Waterhouse, what a wonderful human. wiredferret on Twitter. Please, please go look her up. She's got just always such wonderful things to say. So—Corey: If you don't like Heidi Waterhouse, it is a near certainty it is because you've not yet met her. She's wonderful.Tom: Exactly. Yes, she is. So, what is it we'd say we do here? Well, when people think about feature flags—or at this point now, ‘feature management,' which is a broader scope—that's the term that we're using now, it's really talking about that last bit of software delivery, the last mile, the last leg, whatever your—you know, when you're pushing the button, and it's going to production. So, you know, a feature flag, if you ask someone five or ten years ago, they might say, oh, it's a fancy if statement controlled by a config file or controlled by a database.But with a sort of modern architecture, with global delivery, instant response time or fraction of a second response time, it's a lot more fundamental than that. That's why the word fundamental is there: Because it comes down to psychological safety. It comes down to feeling good about your life every day. So, whether it is that you're fixing a couple typos, or if you're radically changing some backend functionality, and trying out some new sort of search algorithm, a new API route that you're not sure if it's going to work at scale, honestly, you shouldn't have to stay up at night, you shouldn't have to think about deploying on a weekend because you should be able to deploy half-baked code to production safely, you should be able to do all of that. And that's honestly what we're all about.Now, there's some extra elements to it: Feedback loops, experimentation, metrics to make sure that your releases are doing well and doing what you anticipated that they would do, but really, that's what it comes down to is just feeling good about your work and making sure that if there is a fire, it's a small fire, and the entire audience isn't going to get part of the splash zone, right? We're making it just a little safer. Does that answer your question? Is that what you're getting at? Or am I still just speaking in the lingo?Corey: That gets it a lot closer. One of the breakthrough moments—of course I picked it up from one of Heidi's talks—is feature flag seems like a front end developer thing, yadda, yadda, yadda. And she said historically, yeah, in some ways, in some cases, that's how it started. But think about it this way. Think about separating out configuration from your deploy process. And what would that mean? What would that entail?And I look at my current things that I have put out there, and there is no staging environment, my feature branches main, and what would that change? In my case, basically nothing. But that's okay. Because I'm an irresponsible lunatic who should not be allowed near anything expensive, which is why I'm better at stateless things because I know better than to take my aura near things like databases.Tom: Yeah. So, I don't know how old you are Corey. But back—Corey: I'm in my mid-30s, which—Tom: Hey—Corey: —enrages my spouse who's slightly older. Because I'm turning 40 in July, but it's like, during the pandemic, as it has for many of us, the middle has expanded.Tom: There you go. Right. Exa—[laugh] exactly. Can neither confirm nor deny. You can only see me from about the mid-torso up, so, you know, you're not going to see whether I've expanded.But when we were in school doing group projects, we didn't have Google Docs. We couldn't see what other people were working on. You'd say, “Hey, we've got to write this paper. Corey, you take the first section, I'll take the second section, and we'll go and write and we'll try to squish it back together afterward.” And it's always a huge pain in the ass, right? It's terrible. Nobody likes group projects.And so the old method of Gitflow, where we're creating these feature branches and trying to squish them back later, and you work on that, and you work on this thing, and we can't see what each other are doing, it all comes down to context switching. It is time away from work that you care about, time away from exciting or productive work that you actually get to see what you're doing and put it into production, try it out. Nobody wants to deal with all the extra administrative overhead. And so yeah, for you, when you've got your own trunk-based development—you know, it's all just main—that's okay. When we're talking about teams of 40, 50, 100, 1000 suddenly becomes a really big deal if you were to start to split off and get away from trunk-based development because there's so much extra work that goes into trying to squish all that work back together, right? So, nobody wants to do all the extra stuff that surrounds getting software out there.Corey: It's toil. It feels consistently like it is never standardized so you always have to wind up rolling your own CI/CD thing for whatever it is. And forget between jobs; between different repositories and building things out, it's, “Oh, great. I get to reinvent the wheel some more.” It's frustrating.Tom: [laugh]. It's either that or find somebody else's wheel that they put together and see if you can figure out where all those spokes lead off to. “Is this secure? I don't know.”Corey: How much stuff do you have running in your personal stuff that has more or less been copied around for a decade or so? During the pandemic, I finally decided, all right, you know what I'm doing? That's right, being productive. We should fix that. I'm going to go ahead and redo my shell config—my zshrc—from scratch because, you know, 15 years of technical debt later, a lot of the things I used to really need it to do don't really apply anymore.Let's make it prettier, and let's make it faster. And that was great and all, but just looking through it, it was almost like going back in time for weird shell aliases that I don't need anymore. It's, well, that was super handy when I ran a Ruby production environment, but I haven't done that in seven years, and I haven't been in this specific scenario that one existed for since 2011. So maybe, maybe I can turn that one off.Tom: Yeah, maybe. Maybe we can get rid of that one. I mean, when's the last time you ran npm install on something you were going to try out here and paid attention to the warnings that came up afterward? “Hey, this one's deprecated. That one's deprecated.” Well, let's see if it works first, and then we'll worry about that later.Corey: Exactly. Security problems? Whatever. It's a Lambda function. What do I care?Tom: Yeah, it's fine. [laugh]. Exactly. Yeah. So, a lot of this is hypothetical for someone in my position, too, because I didn't ever get formal training as a software developer. I can copy and paste from Stack Overflow with the best of them and there's all sorts of resources out there, but really the people that we're talking to are the ones who actually live that day in, day out.And so I try to step into their shoes and try to feel that pain. But it's tough. Like, you have to be able to speak both languages and try to relate to people to see what are they actually running into, and is that something that we can help with? I don't know.Corey: The way that I tend to think about these things—and maybe it's accurate, and maybe it's not—it's just, no one shows up hoping to do a terrible job at work today, but we are constrained by a whole bunch of things that are imposed upon us. In some of the more mature environments, some of that is processes there for damn good reasons. “Well, why can't I just push everything I come up with to production?” “It's because we're a bank, genius. How about you think a little bit before you open your mouth?”Other times, it's because well, I have to go and fight with the CI/CD system, and I'm just going to go ahead and patch this one-line change into production. Better processes, better structure have made that a lot more… they've made it a lot easier to be able to do things the right way. But I would say we're nowhere near its final form, yet. There's so much yak-shaving that has to go into building out anything that it's frustrating, on some level, just all of the stuff you have to do, just to get the scaffolding in place to write nonsense. I mean, back when they announced Lambda functions it was, “In the future, the only code you'll write is business logic.”Yeah, well, I use a crap-ton of Lambda here and it feels like most of the code I write is gluing all of the weird formats and interchanges together in different APIs. Not a lot of business logic in that; and awful lot of JSON finickiness.Tom: Yeah, I'm with you. And especially at scale, I still have a hard time wrapping my mind around how all of that extra translation is possibly going to give the same sort of performance and same sort of long-term usability, as opposed to something that just natively speaks the same language end-to-end. So yeah, I agree, there's still some evolution, some standardization that still needs to happen because otherwise we're going to end up with a lot of cruft at various points in the code to, just like you said, translate and make sure we're speaking the same language.Getting back to process though, I spent a good chunk of my career working with companies that are, I would say, a little more conservative, and talking to things like automotive companies, or medical device manufacturers. Very security-conscious, compliant places. And so agile is a four-letter word for them, right, [laugh] where we're going faster automatically means we're being dangerous because what would the change control board say? And so there's absolutely a mental shift that needs to happen on the business side. And developers are fighting this cultural battle, just to try to say, hey, it's better if we can make small iterative changes, there is less risk if we can make small, more iterative changes, and convincing people who have never been exposed to software or know the ins and outs of what it takes to get something from my laptop to the cloud or production or you know, wherever, then that's a battle that needs to be fought before you can even start thinking about the tooling. Living in the Midwest, there's still a lot of people having that conversation.Corey: So, you are clearly deep in the weeds of building and deploying things into production. You're clearly deep into the world of explaining various solutions to different folks, and clearly you have the obvious background for this. You majored in music. Specifically, you got a master's in it. So, other than the obvious parallel of you continue to sing for your supper, how do you get from there to here?Tom: Luck and [laugh]. Natural curiosity. Corey, right now you are sitting on the desk that is also housing my PC gaming computer, right? I've been building computers just to play video games since I was a teenager. And that natural curiosity really came in handy because when I—like many people—realize that oh, no, the career choice that I made when I was 18 ended up being not the career choice that I wanted to pursue for the rest of my life, you have to be able to make a pivot, right, and start to apply some of the knowledge that you got towards some other industries.So, like many folks who are now solutions engineers, there's no degree for solutions engineering, you can't go to school for it; everyone comes from somewhere else. And so in my case, that just happened to be music theory, which was all pedagogy and teaching and breaking down big complex pieces of music into one node at a time, doing analysis, figuring out what's going on underneath the hood. And all of those are transferable skills that go over to software, right? You open up some giant wall of spaghetti code and you have to start following the path and breaking it down because every piece is easy one note at a time, every bit of code—in theory—is easy one line at a time, or one function at a time, one variable at a time. You can continue to break it down further and further, right?So, it's all just taking the transferable skills that you may not see how they get transferred, but then bringing them over to share your unique perspective, because of your background, to wherever it is you're going. In my case, it was tech support, then training, and then solutions engineering.Corey: There's a lot to be said for blending different disciplines. I think that there was, uh, the naughts at least, and possibly into the teens, there was a bias for hiring people who look alike. And no, I'm not referring to the folks who are the white dudes you and I clearly present as but the people with a similar background of, “Oh, you went to these specific schools”—as long as they're Stanford—“And you majored in a narrow list of things”—as long as they're all computer science. And then you wind up going into the following type of role because this is the pedigree we expect and everything, soup to nuts, is aligned around that background and experience. Where you would find people who would be working in the industry for ten years, and they would bomb the interview because it turns out that most of us don't spend our days implementing quicksort on whiteboards or doing other algorithmic-based problems.We're mostly pushing pixels around a screen hoping to make ourselves slightly happier than we were. Here we are. And that becomes a strange world; it becomes a really, really weird moment, and I don't know what the answer is for fixing any of that.Tom: Yeah, well, if you're not already familiar with a quote, you should be, which is that—and I'm going to paraphrase here—but, “Diverse backgrounds lead to diversity in thought,” right? And that presents additional opportunities, additional angles to solve whatever problems you're encountering. And so you're right, you know, we shouldn't be looking for people who have the specific background that we are looking for. How it's described in Accelerate? Can you tell that I read it recently?Which we should be looking for capabilities, right? Are you capable? Do you have the capacity to do the problem-solving, the logic? And of course, some education or experience to prove that, but are you the sort of person who will be able to tackle this challenge? It doesn't matter, right, if you've handled that specific thing before because if you've handled that specific thing before, you're probably going to implement it the same way, again, even if that's not the appropriate solution, this time.So, scrap that and say, let's find the right people, let's find people who can come up with creative solutions to the problems that we're facing. Think about ways to approach it that haven't been done before. Of course don't throw out everything with the—you know, the bathwater out with a baby or whatever that is, but come in with some fresh perspectives and get it done.Corey: I really wish that there was more of an acceptance for that. I think we're getting there. I really do, but it takes time. And it does pay dividends. I mean, that's something I want to talk to you about.I love the sound of my own voice. I wouldn't have two podcasts if I didn't. The counterargument, though, is that there's an awful lot of things that get, you know, challenging, especially when, unlike in a conference setting, it's most people consider it rude to get up and walk out halfway through. When we're talking and presenting information to people during a pandemic situation, well, that changes a lot. What do you do to retain people's interest?Tom: Sure. So, Covid really did a number on anyone who needs to present information or teach. I mean, just ask the millions of elementary, middle school, and high schoolers out there, even the college kids. Everyone who's still getting their education suddenly had to switch to remote learning.Same thing in the professional world. If you are doing trainings, if you're doing implementation, if you're doing demos, if you're trying to convey information to a new audience, it is so easy to get distracted at the computer. I know this firsthand. I'm one of those people where if I'm sitting in an airport lobby and there's a TV on my eyes are glued to that screen. That's me. I have a hard time looking away.And the same thing happens to anyone who's on the receiving end of any sort of information sharing, right? You got Slack blowing you up, you've got email that's pinging you, and that's bound to be more interesting than whatever the person on the screen is saying. And so I felt that very acutely in my job. And there's a couple of good strategies around it, right, which is, we need to be able to make things interactive. We shouldn't be monologuing like I am doing to you right now, Corey.We shouldn't be [laugh] just going off on tangents that are completely irrelevant to whoever's listening. And there's ways to make it more interactive. I don't know if you are familiar, or how much you've watched Twitch, but in my mind, the same sorts of techniques, the same sorts of interactivity that Twitch streamers are doing, we should absolutely be bringing that to the business world. If they can keep the attention of 12-year-olds for hours at a time, why can we not capture the attention of business professionals for an hour-long meeting, right? There's all sorts of techniques and learnings that we can do there.Corey: The problem I keep running into is, if you go stumbling down that pathway into the Twitch streaming model, I found it awkward the few experiments I've made with it because unless I have a whole presentation ready to go and I'm monologuing the whole time, the interactive part with the delay built in and a lot of ‘um' and ‘ah' and waiting and not really knowing how it's going to play out and going seat of the pants, it gets a little challenging in some respects.Tom: Yeah, that's fair. Sometimes it can be challenging. It's risky, but it's also higher reward. Because if you are monologuing the entire time, who's to say that halfway through the content that you are presenting is content that they want to actually hear, right? Obviously, we need to start from some sort of fundamental place and set the stage, say this is the agenda, but at some point, we need to get feedback—similar to software development—we need to know if the direction that we're going is the direction they also want to go.Otherwise, we start diverging at minute 10 and by minute 60, we have presented nothing at all that they actually want to see or want to learn about. So, it's so critical to get that sort of feedback and be able to incorporate it in some way, right? Whether that way is something that you're prepared to directly address. Or if it's something that says, “Hey, we're not on the same page. Let's make sure this is actually a good use of time instead of [laugh] me pretending and listening to myself talk and not taking you into account.” That's critical, right? And that is just as important, even if it feels worse in the moment.Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they're calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS marketplace if you'd prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: From where I sit, one of the many, many, many problems confronting us is that there's this belief that everyone is like we are. I think that's something fundamental, where we all learn in different ways. I have never been, for example—this sounds heretical sitting here saying it, but why not—I'm not a big podcast person; I don't listen to them very often, just because it's such a different way of consuming information. I think there are strong accessibility reasons for there to be transcripts of podcasts. That's why every 300-and-however-many-odd episodes that this one winds up being the sequence in, every single one of them has a transcript attached to it done by a human.And there's a reason for that. Not just the accessibility wins which are obvious, but the fact that I can absorb that information way more quickly if I need to review something, or consume that. And I assume other people are like me, they're not. Other people prefer to listen to things than to read them, or to watch a video instead of listening, or to build something themselves, or to go through a formal curriculum in order to learn something. I mean, I'm sitting here with an eighth-grade education, myself. I take a different view to how I go about learning things.And it works for me, but assuming that other people learn the same way that I do will be awesome for a small minority of people and disastrous for everyone else. So, maybe—just a thought here—we shouldn't pattern society after what works for me.Tom: Absolutely. There is a multiple intelligence theory out there, something they teach you when you're going to be a teacher, which is that people learn in different ways. You don't judge a fish by its ability to climb a tree. We all learn in different ways and getting back to what we were talking about presenting effectively, there needs to be multiple approaches to how those people can consume information. I know we're not recording video, but for everyone listening to this, I am waving my hands all over the place because I am a highly visual learner, but you must be able to accept that other people are relying more on the auditory experience, other people need to be able to read that—like you said with the accessibility—or even get their hands on it and interact with it in some way.Whether that is Ctrl-F-ing your way through the transcript—or Command-F I'm sorry, Mac users [laugh]; I am also on a Mac—but we need to make sure that the information is ready to be consumed in some way that allows people to be successful. It's ridiculous to think that everyone is wired to be able to sit in front of a computer or in a little cubicle for eight hours a day, five days a week, and be able to retain concentration and productivity that entire time. Absolutely not. We should be recording everything, allowing people to come back and consume it in small chunks, consume it in different formats, consume it in the way that is most effective to them. And the onus for that is on the person presenting, it is not on the consumer.Corey: I make it a point to make what I am doing accessible to the people I am trying to reach, not to me. And sometimes I'm slacking, for example, we're not recording video today, so whenever it looks like I'm not paying attention to you and staring off to the side, like, oh, God, he's boring. No. I have the same thing mirrored on both of my screens; I just prefer to look at the thing that is large and easy to read, rather than the teleprompter, which is a nine-inch screen that is about four feet in front of my face. It's one of those easier for me type of things.On video, it looks completely off, so I don't do it, but I'm oh good, I get to take the luxury of not having to be presentable on camera in quite the same way. But when I'm doing a video scenario, I absolutely make it a point to not do that because it is off-putting to the people I'm trying to reach. In this case, I'm not trying to reach you; I already have. This is a promoted guest episode you're trying to reach the audience, and I believe from what I can tell, you're succeeding, so please keep at it.Tom: Oh, you bet. Well, thank you. You know this already, but this is the very first podcast I've ever been a guest on. So, thank you also for making it such a welcoming place. For what it's worth, I was not offended and didn't think you weren't listening. Obviously, we're having a great time here.But yeah, it's something that especially in the software space, people need to be aware of because everyone's job is—[laugh]. Whether you like it or not, here's a controversial statement: Everyone's job is sales. Are you selling your good ideas for your product, to your boss, to your product manager? Are you able to communicate with marketing to effectively say, “Hey, this is what, in tech support, I'm seeing. This is what people are coming to me with. This is what they care about.”You are always selling your own performance to your boss, to your customers, to other departments where you work, to your spouse, to everybody you interact with. We're all selling ourselves all the time. And all of that is really just communication. It's really just making sure you're able to meet people where they are and, effectively, bridge your point of view with theirs to make sure that we're on the same page and, you know, we're able to communicate well. That's so especially important now that we're all remote.Corey: Just so you don't think this is too friendly of a place, let's go ahead and finish out the episode with a personal attack. Before you wound up working at LaunchDarkly. You were at Perforce. What's up with that? I mean, that seems like an awfully big company to cater to its single customer, who is of course J. Paul Reed.Tom: [laugh]. Yeah. Well, Perforce is a wonderful place. I have nothing but love for Perforce, but it is a very different landscape than LaunchDarkly, certainly. When I joined Perforce, I was supporting product called Helix ALM, which, they're still headquartered—Perforce is headquartered here in Minneapolis. I just saw some Perforce folks last week. It truly is a great place, and it is the place that introduced me to so many DevOps concepts.But that's a fair statement. Perforce has been around for a while. It has grown by acquisition over the past several years, and they are putting together new offerings by mixing old offerings together in a way that satisfies more modern needs, things like virtual production, and game development, and trying to package this up in a way that you can then have a game development environment in a box, right? So, there's a lot of things to be said for that, but it very much is a different landscape than a smaller cloud-native company. Which it's its own learning curve, let me tell you, but truly, yeah, to your Perforce, there's a lot more complexity to the products themselves because they've been around for a little bit longer.Solid, solid products, but there's a lot going on there. And it's a lot harder to learn them right upfront. As opposed to something like LaunchDarkly, which seems simple on the surface and you can get started with some of the easy concepts in implementation in, like, an hour, but then as you start digging deeper, whoof, suddenly, there's a lot more complexity hidden underneath the surface than just in terms of how this is set up, and some of those edge cases.Corey: I have to say for the backstory, for those who are unfamiliar, is I live about four miles away from J. Paul Reed, who is a known entity in reliability engineering, in the DevOps space, has been for a long time. So, to meet him, of course I had to fly to Israel. And he was keynoting DevOpsDays Tel Aviv. And I had not encountered him before, and it was this is awesome, I loved his talk, it was fun.And then I gave a talk a little while later called, “Terrible Ideas in Git.” And he's sitting there just glaring at me, holding his water bottle that is a branded Perforce thing, and it's like, “Do you work there?” He's like, “No. I just love Perforce.” It's like, “Congratulations. Having used it, I think you might be the only one.”I kid. I kid. It was great and a lot of different things. It was not quite what I needed when I needed it to but that's okay. It's gotten better and everyone else is not me, as we've discussed; people have different use cases. And that started a very long-running joke that J. Paul Reed is the entirety of the Perforce customer base.Tom: [laugh]. Yeah. And to your point, there's definitely use cases—you're talking about Perforce Version Control or Helix Core.Corey: Back in those days, I don't believe it was differentiated.Tom: It was just called Perforce. Exactly right. But yeah, as Perforce has gotten bigger, now there's different product lines; you name it. But yeah, some of those modern scalable problems, being able to handle giant binary files, being able to do automatic edge replication for globally distributed teams so that when your team in APAC comes online, they're not having to spend the first two hours of their day just getting the most recent changes from the team in the Americas and Europe. Those are problems that Perforce is absolutely solving that are out there, but it's not problems that everybody faces and you know, there's just like everybody else, we're navigating the landscape and trying to find out where the product actually fits and how it needs to evolve.Corey: And I really do wish you well on it. I think there's going to be an awful lot of—Tom: Mm-hm.Corey: —future stories where there is this integration. And you'd say, “Oh, well, what are you wishing me well for? I don't work there anymore.” But yeah, but isn't that kind of we're talking about, on some level, of building out things that are easy, that are more streamlined, that are opinionated in the right ways, I suppose. And honestly, that's the thing that I found so compelling about LaunchDarkly. I have a hard time imagining I would build anything for production use that didn't feature it these days if I were, you know, better at computers?Tom: Sure. Yeah. [laugh]. Well, we do have our opinions on how some things should work, right? Where the data is exposed because with any feature flagging system or feature management—LaunchDarkly included—you've got a set of rules, i.e. who should see this, where is it turned on? Where is it turned off? Who in your audience or user base should be able to see these features? That's the rules engine side of it.And on the other side, you've got the context to decide, well, you know, I'm Corey, I'm logging in, I'm in my mid-30s. And I know all this information about Corey, and those rules need to then be able to determine whether something should be on or off or which experience Corey gets. So, we are very opinionated over the architecture, right, and where that evaluation actually happens and how that data is exposed or where that's exposed. Because those two halves need to meet and both halves have the potential to be extremely sensitive. If I'm targeting based off of a list of 10,000 of my premium users' email addresses, I should not be exposing that list of 10,000 email addresses to a web browser or a mobile phone.That's highly insecure. And inefficient; that's a large amount of text to send, over 10,000 email addresses. And so when we're thinking about things like page load times, and people being able to push F12 to inspect the page, absolutely not, we shouldn't be exposing that there. At the same time, it's a scary prospect to say, “Hey, I'm going to send personal information about Corey over to some third-party service, some edge worker that's going to decide whether Corey should see a feature or not.” So, there's definitely architectural considerations of different use cases, but that's something that we think through all the time and make sure is secure.There's a reason—I'm going to put on my sales engineer hat here—which is to say that there is a reason that the Center for Medicare and Medicaid Services is our sponsor for FedRAMP moderate certification, in process right now, expected to be completed mid-2022. I don't know. But anybody who is unfamiliar with that, if you've ever had to go through high trust certification, you know, any of these compliances to make your regulators happy, you know that FedRAMP is so incredibly stringent. And that comes down to evaluating where are we exposing the data? Who gets to see that? Is security built in and innate into the architecture? Is that something that's been thought through?I have went so far afield from the original point that you made, but I agree, right? We've got to be opinionated about some things while still providing the freedom to use it in a way that is actually useful to you and [laugh] and we're not, you know, putting up guardrails, that mean that you've got such a narrow set of use cases.Corey: I'd like to hope—maybe I'm wrong on this—that it gets easier the more that we wind up doing these things because I don't think that it necessarily has been easy enough for an awful lot of us.Tom: When you say ‘it,' what do you mean?Corey: All of it. That's the best part, I suppose the easy parts of working on computers, which I guess might be typing if you learn it early enough.Tom: Sure. [laugh] yeah. Mario Teaches Typing, or Starcraft taught me how to type quickly. You can't type slowly or else your expansion is going to get destroyed. No, so for someone who got their formal education in music or for someone with an eighth-grade education, I agree there needs to be resources out there.And there are. Not every single StackOverflow post with a question that's been asked has the response, “That's a dumb question.” There are some out there. There's definitely a community or a group of folks who think that there is a correct way to do things and that if you're asking a question, that it's a dumb question. It really isn't. It's getting back to the diverse backgrounds and diverse schools of thought that are coming in.We don't know where someone is coming from that led them to that question without the context, and so we need to continue providing resources to folks to make it easy to self-enable and continue abstracting away the machine code parts of it in friendlier and friendlier ways. I love that there are services like Squarespace out there now, right, that allow anybody to make a website. You don't have to have a degree in computer science to spin something up and share it with the world on the web. We're going to continue to see that type of abstraction, that type of on-ramp for folks, and I'm excited to be part of it.Corey: I really look forward to it. I'm curious to see what happens next for you, especially as you continue—‘you' being the corporate ‘you' here; that's like the understood ‘you' are the royal ‘you.' This is the corporate ‘you'—continue to refine the story of what it is LaunchDarkly does, where you start, where you stop, and how that winds up playing out.Tom: Yeah, you bet. Well, in the meantime, I'm going to continue to play with things like GitHub Copilot, see how much I can autofill, and see which paths that takes me down?Corey: Oh, I've been using it for a while. It's great. Just tab-complete my entire life. It's amazing.Tom: Oh, yeah. Absolutely.Corey: [unintelligible 00:36:08] other people's secrets start working, great, that makes my AWS bill way lower when I use someone else's keys. But that's neither here nor there.Tom: Yeah, exactly. That's a next step of doing that npm install or, you know, bringing in somebody else's [laugh] tools that they've already made. Yeah, just a couple weeks ago, I was playing around with it, and I typed in two lines: I imported the LaunchDarkly SDK and the configuration for the LaunchDarkly SDK, and then I just let it autofill, whatever it wanted. It came out with about 100 lines of something or other. [laugh]. And not all of it made sense, but hey, I saw where the thought process was. It was pretty cool to see.Corey: I really want to thank you for spending as much time and energy as you have talking about how you see the world and where you folks are going. If people want to learn more. Where's the best place to find you?Tom: At launchdarkly.com. Of course, any other various different booths, DevOpsDays, we're at re:Invent, we're at QCon right now. We're at all sorts of places, so come stop by, say hi, get a demo. Maybe we'll talk.Corey: Excellent. We will be tossing links to that into the [show notes 00:37:09]. Thanks so much for your time. I really appreciate it.Tom: Corey, Thank you.Corey: Tom Totenberg, senior solutions engineer at LaunchDarkly. 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 and insulting comment, and then I'll sing it to you.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.

Screaming in the Cloud
Doing DevRel on Easy Mode with Matty Stratton

Screaming in the Cloud

Play Episode Listen Later Apr 12, 2022 41:10


About “Matty”Matt Stratton is a Staff Developer Advocate at Pulumi, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences.Matt has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Matt is the keeper of the Thought Leaderboard for the DevOps Party Games online game show and you can find him on Twitter at @mattstratton.Links Referenced Pulumi: https://www.pulumi.com/ Arrested DevOps: https://www.arresteddevops.com/ 8bits.tv: https://8bits.tv Twitter: https://twitter.com/mattstratton LinkedIn: https://www.linkedin.com/in/mattstratton/ speaking.mattstratton.com: https://speaking.mattstratton.com twitch.tv/Pulumi: https://twitch.tv/Pulumi 8bit.tv: https://8bit.tv duckbillgroup.com: https://duckbillgroup.com 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: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Returning today for yet another round on the Screaming in the Cloud podcast is my dear friend, and hopefully yours as well, Matty Stratton. Since the last time we spoke, you've changed jobs, Mattie; you're now a staff developer advocate at Pulumi. I don't believe you were the last time you were on this show, but memory escapes me.Matty: You know, I was just wondering that myself, and I guess we'll have to go back to the archives.Corey: Yes, but that sounds like work, so we're going to roll with it anyway.Matty: Everyone who's listening, go do the homework for us. And, like, just tweet and let us know what my job was last time.Corey: And yell at us if we get it wrong, of course.Matty: Yell at us if we get it right.Corey: In the interest of being, well, I guess a little on the judgey side—because why not I tend to be good at that.Matty: I was hoping to be on the judgey side on this show.Corey: Oh, absolutely. You have a very strange career trajectory, in that—the companies you work for and how that winds up going back and forth. But when we first met, you were at Chef; and Chef, great company. And after that it was PagerDuty; great company.Matty: [laugh].Corey: And then it was IBM Hat, which I—was it Red Hat, was it IBM side?Matty: For me, it was Red Hat.Corey: So, it went from Chef, which is great, and a company that was doing a lot of things on the container side of the world became a thing and mutable infrastructure did sort of change Chef's business model. And then you went to PagerDuty, the wake-you-up-in-the-middle-of-the-night service named after some legacy technologies. And should be very direct in the popular consciousness, IBM views pagers as newfangled technology in some circles, in some areas, so it feels like you were traveling back in time a bit, again and again and again. On the federal side as well which, for excellent reasons, is not usually the absolute bow wave of innovation because you don't usually want your government doing that in some ways. And now you've leapfrogged into Pulumi, which is sort of the bleeding edge of the modern way we think about provisioning cloud infrastructure.It feels like it's a very interesting trajectory. Now, this is speaking as a complete outsider, I'm going to assume that's not how you view basically any characterization of any of those companies I've just named. How do you view it?Matty: You know, I don't know that I necessarily disagree with the way that you've put everything, but there's some nuance and some interesting stuff when it comes to that. So, I'm going to specifically talk about the Red Hat thing; why did I leave PagerDuty? And one of the interesting things is, I actually had an offer from Pulumi at the time that I took the job from Red Hat. So, it actually took me a year to come and work at Pulumi. And the little bit of the short answer is Red Hat backed up a big truck of money. And we all have a price.Corey: Yeah, the dulcet tones of a dump truck full of gold bricks emptying itself into your backyard, it's hard to say no to.Matty: The reason that I want to bring that up is that has nothing to do with specifically Red Hat the company versus other companies. It was the role. It was a sales-oriented role, so if you don't know, sales gets paid a lot of money and there's good reason. One of the reasons—again, if you don't work in sales, you don't necessarily know this—is, the last day of the quarter, you will have your VP of sales talking, he'll be like, “Corey, you are amazing. I love you. Look at this big deal you brought in.” Twenty-four hours later, “What have you done for me lately?”Corey: Mm-hm.Matty: That didn't matter, right? And I remember the CEO of PagerDuty—so Jen Tejada—at one of the sales kickoffs I was at, she said—you know, because salespeople, like, you might know this, like, the top sales reps in the company, they go on trips, they have all this stuff—and Jen said, you know, “I've got engineers here that are like, well, I don't understand.” It's like, “How come the salespeople get to go to Bermuda or do whatever?” And she's like, “Would you like your paycheck to change every quarter based upon specifically what you did and have the stress of what have you done all this stuff? No? Okay, cool. Then you can keep”—you know, there's a trade-off. So, the point of that was—Corey: And as your paycheck gets smaller, you're getting closer and closer to losing your job because a salesperson needs to perform to keep. It's very feast or famine. It's a heck of a role, and I have nothing but respect for people who can do it.Matty: And people can do it well. And I do feel like a lot of people don't understand how sales works, especially in a larger organization, and I think it's really important. So, one of the things that was interesting is we've all—I shouldn't say all, but many of us have worked in jobs that have some form of variable compensation, some kind of annual bonus. So, let's say for example, at x company I'm working at, they're like, “Mattie, your bonus is equal to 10% of your paycheck.” Well, the most it could be, generally speaking, it's like, let's say that your bonus would be, I'm just going to make up a number and say it's a $10,000 bonus.That's the most it could be, and that's if everything is amazing. Maybe I'll get a little more. Now, your commission, your what they call your on-target earnings and sales, they'll tell you a number and they'll say, “Okay, Corey, you're on-target earnings are, say $200,000.” And you're like, “Oh.” But whatever.The thing is, if you're only getting you're on-target earnings, you probably are needing to look for another job. So, you remember, like, we hear it differently, those of us that have done bonuses in a non-sales way. We're like, “But that's not a lot.” You're like, “No, but what they tell you your commission is, it's actually… it better end up being more or else you have trouble.” Anyway, point is—Corey: And in some cases, it could be a significant multiple of that number as well, for top performers.Matty: Absolutely.Corey: The upside is always interesting, and calculating out the nuances of the sales plan is always a challenge, speaking as a business owner. It is a very specific field that has a bunch of nuance to it. Something I learned very early on is that if you manage salespeople as if they were engineers, or manage engineers as if they were salespeople, you are going to have an absolutely terrible time.Matty: I think one of the things that, along those lines, I've have had conversations with people who work in different parts of technology, different parts of the business, who their long-term desire is to be a CEO, and I'm like, you really should go spend some time working in sales because most CEOs—again, this is blunt, but it's true—if you think about it, what is the area of the business that they pay the most attention to? And I don't mean, they don't care about the other stuff, but who is the person on the executive team that the CEO is mostly joined at the hip with, and it's your chief revenue officer, it's your head of sales because you have to understand that, you have to understand pipeline, how that—you have to understand a lot of things as a CEO, but if you don't know how sales works—it doesn't mean know how to sell but know the ideas behind it. I mean, you should know how to sell, but you know what I mean?Corey: Yeah, I think every CEO is selling. It is a sales job, whether that is selling the company to prospective employees, whether it is selling strategic partnerships, whether it's being brought in to help close strategic deals, et cetera, you're always selling in that role.Matty: That's a very good point. I should rephrase that, where I wasn't saying you don't need to know—Corey: CEO who has no idea how to sell [unintelligible 00:07:42] the fundamentals of—like, you put them in a meeting, and they wind up saying the wrong thing and pooching the deal, yeah, they're not CEO for very long.Matty: It's not just knowing how to sell, it's understanding how a sales process works. That's sort of the thing.Corey: I'll take it one step further beyond that, and that is that I believe that every professional is working in sales and is selling something, but not everyone's aware of it“. Well, I'm an engineer, and I don't do any sort of sales work.” Well, I hear about that from folks who are—“I have all these great ideas, but none of them ever get implemented.” Well, you're not doing an effective job of selling the idea. “I keep getting put up for promotion and not getting it,” or, “I'm not doing well in job interviews.” Or, “I'm trying to get a raise and it just isn't working for me.” And every job has elements of sales to it. I'd argue a lot of facets of modern life have sales elements to it.Matty: They do and I think the reason that people get hung out—I agree with you; I could not agree with you more. I have a talk I used to give called “The Five Love Languages of DevOps” but it was really a talk about effecting organizational change, and you have to be a salesperson, right? But I think we have this—and this is a much larger topic because it comes into how people always want to distance themselves from sales—we have this thing in our head that when we think of sales, we think of tricky people. Shysters, right? Someone that's trying to, like, pull a fast one on us, like the used car salesperson thing.And I'm like, that's not most salespeople. Like, salespeople want you to—because when we talk about learning how to sell, it's not learning how to trick somebody. It's actually learning about how to—I mean, here's the biggest thing. You want to know—we talk about DevOps all the time and stuff like that, you know, and empathy. You want to know one of the most important skills of a salesperson is? Freaking empathy.Because you need to be able to understand what your prospect—and that's if you've, you know, there's the book, The Challenger Sale, which like all business books can be summarized in a blog post, right, so you can just go read the blog post about The Challenger Sale; that'll tell you everything you need to know, but a good salesperson that's a challenger-style salesperson knows the customer better than they know themselves and knows there problems they might have that they're not aware of. And it's not because they're smarter; they have a different perspective. So, the same thing is true. So, to Corey's point, we're always selling. And even whether it's figuratively, like, conceptually—but I used to say when I was a Chef I said, the two best sales—most effective salespeople at Chef were Adam Jacob, the founder, and Nathan Harvey, the VP of community.Sales engineers are powerful because a customer will tell things to a sales engineer they won't tell the rep because they think the rep is trying to take advantage of them, which isn't true. Most important conversations that happen are on the walk from the front desk to the conference room. How many conversations would I have with the SRE, or whatever, who was the one who came to get me from reception, and we're just walking to the conference room. I learned so much there than in any other discovery session? You know, and then you use that to be—Corey: And there's not such thing as an easy sale either. And I think that gets overlooked a lot. Like, here at The Duckbill Group, if you bring us in on a consulting engagement to fix your AWS bill, you will turn a profit on that engagement. That has always been true. And we are quite literally selling money.It is effectively one of the easiest possible sales you can make; it is incredibly easy to calculate out what the ROI looks like on any of these things, and it's great, and we still have a full-on enterprise sales force because that is what it takes to wind up getting deals done when you're selling business-to-business. These are not selling t-shirts to the masses. It is a nuanced field, and honestly, when I'm interviewing people, one of the easiest ways for me to discount someone as a potential hire is that they start talking smack about sales because it is clear, first, they lack empathy, and secondly, they don't understand what sales does.Matty: One of the things that I think people who are not connected with it don't understand that again, back to Corey's point about because selling is hard, and selling internally is hard. So, this is the thing. So, you can have a champion inside your prospect who's, like, “I'm all about hiring Duckbill.” But they have to convince other people. So, what are salespeople really good at doing? They're really good at helping you build your business case to be able to get your thing that you want.Corey: How to turn your champion into an effective advocate for the thing that's going to make their job easier because they're not the person that signs off on it.Matty: And they're not the expert. Like, this used to happen when I was at Chef and I would have a customer who was like, “Okay.” They go and buy a bunch of licenses, and they're like, “Well, it didn't get deployed.” And we're like, “Well, how can we help you?” And they're like, “Well, no, it's just internal stuff. We got to convince people or whatever.”And I was like, “So, what you need to do is what you're telling me, what you need to do is sell Chef, right?” “Uh-huh.” There is nobody on this planet better at selling Chef than Chef. So, that's where that comes in because again, that's how everybody wins. So anyway, I went there because I was getting paid like a salesperson.Also, I one thing I wanted to touch on. So, you're right, usually, public sector is not seen as the most cutting edge. One of the things that's interesting at Red Hat, especially on the sales side—and friends of mine who are working on the commercial side may disagree with this, but it's generally not been true—what they call NAPS, so the North America Public Sector, I used to say I was a NAPS specialist, which sounded awesome. Because that was my title, I was NAPS specialist; I specialized in NAPS—is actually—Corey: Your status in the internal messaging system should always be sleeping at that point, why not?Matty: Sleeping. Yeah. But it's sort of known that actually the kind of emergent tech group and sales inside of the public sector, inside Red Hat, is very innovative compared to other ones. So, a lot of stuff was created there. So, it was we were doing something around a transformation office that wasn't being done in the same way anywhere else, so it was very exciting.So, I—also was the opportunity to go and work with people like Andrew Clay Shafer and John Willis and people that were—you know, it was all the people I was going to get to work with. So, that got me excited to be there. And then Covid happened, and I got news for you. Like, my job was to have challenging conversations with people about how they should do work differently. It's pretty easy to tune somebody out on the Zoom, it's a lot harder to tune somebody out when they're challenging you in a room.So, it was very hard to do this job during Covid, so our team really kind of disbanded towards the end of the year. I was really on the fence to join in the first place, and the person who was referring me to come work on the team who wanted to convince me said, you know, “What's holding you back?” And I said, “Well, it's not”—I said, “I really like developer advocacy. I like DevRel. That's not this job.” And he said, “Hey. Come try this for a year, and… if it turns out you didn't like it or wasn't for you, then go back and do DevRel.”And so that's sort of what happened. And I have seen though I am much happier in a smaller organization that's creating—you know, like, I like to feel my impact. I think everybody should spend some time in a large org because if you're going to be working with other people—right, you know what I mean—especially if you're a vendor, if you work on the vendor side like I do and stuff, Corey, you and I've talked before about background and doing developer advocacy, and I always say that, like, I do DevRel on easy mode because it's very easy for me to have empathy for my prospects and community because I did the job for 20 years. It's not impossible to be effective doing this job if you haven't literally done it. It's just that much harder. So, I [crosstalk 00:15:04]—Corey: It's a lot harder. And there's a credibility question and the rest. Yeah.Matty: I do this on easy mode. I can sit there and I can say, “Yes, I feel your pain. I literally did it for 20 years.”Corey: And you're at a point, too, let's be clear here, that you have a gravitas to you. I use you as my default example when I talk about, like, the expression of DevRel in that if you—like back when you were at PagerDuty, which I guess dates the reference a bit, but it was, okay. If you sit down and say you're doing on-call wrong, now I've been around this industry at that point 15 years or so, and I'm pretty sure I'm not. But if you're going to say that you have already got my attention in a constructive way, not in a, “Well, let me just tear this apart.” It's, no, no. I'm about to learn something by whatever it is you're about to say. And it's very hard to have that level of credibility without having done the role.Matty: That's true. Without doing it in that way. I mean, this is [crosstalk 00:15:59]—Corey: In the practitioner way of practicing the thing for which you are advocating. Like, someone telling me that I'm doing on-call wrong, who has never themselves been in a role where they themselves were on call is a little lacking in the authenticity department. It's not impossible and it can't be overcome.Matty: And you have to do it in a different way, right?Corey: Yes.Matty: And this goes back to another thing that I say a lot—my pithy Stratton quote is, “DevRel contains multitudes,” right? So, this is one of the things that we ran into, like, when we're building out our advocacy team at PagerDuty, it was seeing sort of my boss was an amazing dude and everything like that. I love him, but like, we don't scale horizontally. Our team was made up of enough of different kinds of people that, like, the way that I was able to do it because I had a certain experience, you couldn't expect that out of another one of my teammates because they actually had a different way of doing it that was just as effective, but in a different way because they have a different background, they have a different—so that's—Corey: And there's so many ways to do DevRel. Oh, yeah. Like, I'm going to call it my own bias here where when I think about DevRel, I think about it through a lens of the way I approach things, and when I give conference talks, of how I present myself, and the rest. And my approach would absolutely be aligned with what I just described, “So, you're doing AWS billing wrong.” And based upon who I am, and what I do, I can make that claim with some credibility.If I were relatively new to the industry and giving a talk about AWS billing, I would not lead that way because it does not present nearly as well, and it's going to call into question a whole bunch of skepticism. I would instead approach it as, “Here are some interesting facets about AWS billing that you may or may not be aware of.” There are different ways to approach it. Let's also be clear that it's not just conference talks; it can be blog posts, it can be documentation, it can be writing sample code, it can be Twitter, it could be TikTok of all things. There are so many ways to communicate with an audience, and your audience is wherever you happen to find them.Ideally, not in line at the Starbucks harassing the poor person in front who's just trying to order their coffee, but you know, as long as it's all consensual, talk to people who are interested in this stuff, wherever they happen to be.Matty: I think that's a really important statement you said there towards the end, which is meet people where they are, whether that's where you want them to be or not. And this comes up, it's interesting because one of the things—I'm a big believer in repurposing of content, and that's just partially because of effectiveness, but it's like, hey, if I give a talk, I should make that a blog post, I should make it a video, I should do a code example. And it's not so much because then I can hit all my OKRs with my boss.—I mean, that's part of it, right?—but not everybody likes the same kind of content.You know, there are people who really like videos, and there are people who are like, “I don't want to learn from a video at all.” And there's two ways you can approach that. One is you can say, “You're wrong. Videos are better. You should watch all my videos.” And take a guess about how well that's going to work with them getting your information or say, “I'll meet you where you are.”And I learned this even well before doing DevRel when I just thought about internal communication at an organization I was at when I was at Apartments.com and I was like, how do we get information? And you can't just say, like, well, we have this email we send to everybody. Well, everybody doesn't read email, right? So, it could be, maybe some people like RSS feeds, they want to capture it there. And the example I always gave was the most effective way that I ever saw that information was communicated inside our organization was signs in the restroom.Corey: Oh, yeah. That's a well-renowned way of doing it. That I think that Google pioneered this for a while. They had these all these things up about interesting things going on inside the—Matty: Oh—Corey: —company, about the way some systems worked—Matty: —I was at Google office and using the restroom, and I was standing there, and right in front of me with a whole good practice on cross-site scripting vulnerabilities. I guarantee they probably sent that email to everybody, it's probably been in meetings, and the people who saw it, [unintelligible 00:19:53] they saw it in the restroom.Corey: Now, of course, I'm sure they probably sell ads on those sheets, but okay.Matty: Yeah. You know, a little bit of that. When I was at Apartments.com, the floor that I worked on, the main restroom I used was a shared restroom with another office, which meant corporate never put anything up in there, and there was actually a fair amount of stuff that I didn't know about because I ignored it everywhere else and [unintelligible 00:20:14] anyway. So, the point is, back—if you will do work in person, which who is doing that anymore and why bother?—your most effective way to communicate. So, if you can figure out how to do DevRel in signs in a restroom at a conference—ohh, conferences should sell sponsorship of restroom signs.Corey: The jokes write themselves and almost certainly violate the code of conduct of at least four different [unintelligible 00:20:38], but it works. It works.Matty: [laugh]. We'll take those to Twitter.Corey: You've been around the industry for a while. You are one of the cohosts of the Arrested DevOps podcast; you've been instrumental in organizing a number of DevOps Days… or Devs-Ops days, however you want to mis-pluralize that is fine by me; roll with it. Ant—Matty: We argue more about the capitalization than the pluralization.Corey: Very fair. I want to talk to you a little bit of how the DevOps movement slash community slash role has evolved. For a long time now, it's been, “Great. So, where are the DevOps people sitting?” And then when you hear the shouted response of, “It's not a job. It's a culture,” good work. You found them. Now, you can go talk to them and all. What has changed over the past few years in the world of DevOps?Matty: So, I am fond of saying you can't buy DevOps, but I can sell it to you.Corey: Oh, absolutely. You're an exemplary DevOps salesman.Matty: Yeah. So, what happened? When we think back across the decade-plus, you know, back since 2009, one of the things I think that's interesting is, when we look at things like DevSecOps, or the other portmanteaus that are being created. It's a little bit like that meme, right, with the astronaut: “Wait. You mean, it's been DevSecOps all along?” You know, it's, “Yes, always has.”That's the thing. Like, for those who don't know, Andrew Clay Shafer is best known as coining the term. And I love Andrew, but wow, is it the worst name in the world for what we're talking about. Because it makes us all think that it's only about development and operations. And it's always been about cross-functional across all of those things. And if it helps us to give it a different name, great.Corey: It's replacing dysfunction with cross-function.Matty: Yes. There we go. That's DevOps right there. That's the best definition of DevOps I've heard. You heard it here.Corey: That one coins a phrase, in case you wondered.Matty: So, we still use the term CALMS to say what is about: It's about Culture, Automation, Lean, Measurement, and Sharing. That's held up for a reason. For something that was scrawled on a napkin in 2010, there's a reason we still talk that way. It sounds like we talk about culture more than anything else, and it's not because it's more important. It's because it's the one that we have to scream from the rooftops.You don't have to convince engineers to play with automation tools; they're going to do it. That's fine, right? So, they're all equal. Now, that said, what's changed is we have definitely found DevOps to feel a lot more that it's about automation. It's about the technology. We've veered away from the people to your statement about, like, “Oh, it's a culture, not a ti”—well, it's all of these things.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of “Hello, World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free? This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: Well, one thing I do want to call out because the whole point of having you on the show, of course, is to embarrass you with proof-positive, for example, that you are in fact, a good person at heart despite, you know, your dubious friendship with people like me, is we both used to be adamant about the idea of DevOps is not a role, not a job title, and we both stopped, but for different reasons. The reason that I stopped was that I took a job as the director of DevOps at a company because I was trying to solve about five or six different things that were important for me to negotiate for, and job title did not make the cut of impactful changes. You had a far less self-serving reason for no longer picking that particular fight. What was it?Matty: [laugh]. I do want to call out one of my favorite jokes which is not supposed to be gatekeeping, but it's making fun of Corey so it's okay—Corey: Hmm.Matty: —Nathan Harvey said years ago, and it was actually I think, intended as a shot at our friend Pete Cheslock, who also has had the title of director of DevOps, which said, “The only DevOps tool is a person that calls themselves director of DevOps.”Corey: Oh, absolutely. It's super lucrative. I was really insulted by that and cried all the way to the bank.Matty: Uh-huh. Now, I'll tell you there's two reasons that I've changed my tune on—you know, I used to say it's not a tool, title, or team. I still will agree that it's not a tool. The title and team—and the reason for that is twofold, and neither of which are self-serving other than I don't want people to think I'm a jerk. The first reason that deviated me from a little bit was again, to go back to your friend and mine, Pete Cheslock, he gave a talk, I don't remember where it was, but he made the point where he said, “You look at it, the title ‘DevOps engineer' is a 30 to 35% pay bump, so it's like, I don't care what you call yourself. Go get paid.” So, that's that.Corey: Yes.Matty: So, first of all, I was like cool—Corey: J. Paul Reed did a whole talk-pay thing that shined a light on that.Matty: Absolutely. The one that I think is more empathetic and probably was… is maybe a little more important—or equally so—Ian Coldwater has pointed out before, and this really resonated with me, is that when we get on Twitter and are like, “Oh, my God. DevOps engineer is not a real title, blah, blah, blah.” The people that hear that are the people who have that title. They did not give themselves that title. It's very exclusionary, and all that will happen out of that is it doesn't eff—Corey: “I'm going to go quit my job and not be able to make rent this month.” “Why?” “Because Twitter said that my job title was bad.”Matty: Yeah.Corey: All the reasons to quit a job, I promise you job title is not one of them. Unless it is something horrifying, as into the territory of discriminating or belittling. There are always exceptions to every rule, but by and large, “That's a ridiculous job title,” is not the reason to quit a job. Says the self-proclaimed chief cloud economist.Matty: Totally yeah. I mean, like, you know what is very similar? There's a meme about, like, every time people want to make fun of a political figure or something and they'll make fun of them being overweight, or any kind of thing, and the meme is like, the only people who hear that are your friends that have a similar condition, not the actual person you're making fun of, so all you're doing there is hurting people who… so that's a similar thing.Now, I will say—and I think you and I might disagree about this a little bit, so that'll be fine—Corey: I hope so.Matty: So, when I hear—and actually the title doesn't do this, for me; it's actually very specifically a DevOps team. When people say, “We have a DevOps team.” This is not a perfect analogy when I say it's a code smell; I call it an organizational smell. And what I mean by that—it's not as bad as a code smell—what it does is it makes me ask more questions. If it's relevant to me to ask questions. It might be none of my damn business. If you tweet that I'm on the DevOps team, I'm not going to come into your mentions and start questioning your existence, but—Corey: Oh please, I have way better personal attacks than that.Matty: Oh, yeah. But if I'm working with you and we're working on that, or we're having a conversation, and it comes up that you have a team called DevOps Team, I'm going to ask questions because that could be, okay or it could be, [sigh] I want to use the word dangerous lightly; it's not, but like, counter-effective. And the reason for that is if the DevOps team is the one who does all your automation and you haven't really enabled other squads and all you've done is move a silo around, doesn't make you a bad person, but that's not the most effective way you could be. So, it makes me start to ask questions, right? But sometimes DevOps teams are people who lead in the organization, they are empowerment teams, maybe they run dojo, maybe they are subject matter experts that help.As long as there are good bridges still being built, it's not bad, right? So, it just—again, it raises questions. It's not inherently wrong. I am sure that… Pulumi where wo—actually, many of the tools I've worked with have been called DevOps tools; I will still tell you there's no tool that gives you DevOps, right? You can't—Corey: But when other people—like, read as ‘buyers'—refer to you as the ‘DevOps tool company,' well, you can be right or you can make a sale, in some cases.Matty: [laugh]. Yeah, I'm not going to tell you—Corey: On some level, you have to meet people where they are, and this is a part of that. I say that in full sincerity. Same story with the idea of culture. I hear this question all the time, “How do we wind up making all of our engineers aware of AWS billing issues?” And to a point, you should have understanding that when you turn something on it runs forever, bigger things cost more than smaller things, but the knowledge fits on an index card.You shouldn't have every engineer wanting to—or needing to—become deep experts in this space. Having a centralized team that specializes in that, at a sufficient level of org size and maturity, makes an awful lot of sense, and they can float around. But yeah, having the AWS bill team, in some cases is the right answer and others it's the complete wrong answer, and it really does depend. I think the way that we solve this problem, authoritatively, is a way that neither you nor I can argue with it because the only source for authoritative DevOps answers is from the source itself, and that is, of course, Emily Freeman, whose treatise on the subject, DevOps for Dummies, despite the weird title, is absolutely fantastic work that gives insight into all of this. And are you prepared to tell her she's wrong? Because I'm certainly not.Matty: Well, there are plenty of people who will. As we know.Corey: Yes. And we call them shitheads if we're being perfectly honest with you.Matty: Yeah. [laugh].Corey: The internet what a ple—no, Emily is an absolute treasure in the space and I'm continuing to watch her meteoric rise with nothing other than pure admiration. It is just spectacular to see her succeed.Matty: I could not agree more. This is something I struggle with a little bit. I don't think Emily would mind me saying it this way. This is the thing where you don't want to sound condescending, but I always love when I look at people and it's not—it's going to come off a little bit about, like, “I knew them when,” and it's not like I was a Corey Quinn fan before he went pop, but I love to see and remember where we all came from, and it's true of myself and it's true of other people, but that's one of my favorite things is I love to see my friends succeed.Corey, I love to see what you've done. Like, I think back to when we knew each other. I'm not saying you weren't successful, but it's funny, this [unintelligible 00:30:08] sounds a little condescending to be like, oh, I'm so proud of you, but I am. And I'm impressed. It's great to see.And Emily's another example. Like, I remember when I first met Emily, and not like I was any big deal, either, but it's like, everybody comes from somewhere, right? Like Jacquie Grindrod who just recently left Hashi, I remember when she started to get into DevRel and I was talking to her because she's like, “I may be thinking I want to do this thing.” And you look and you see these people. And it's not supposed to be like, “Oh, I remember when you were like the cute little baby DevRel.” It's not like that.And it's like, it's just impressive to see—and not even impressive. It's you like to see people who do good work and have a good heart and want to help people grow and be successful. And I'll tell you something, here—we're going to get real for a second—you can be jealous of them. It's okay. And I'm going to be honest, there are times that—Emily and Corey are both good friends of mine, and there are times that I'm like, “Wow. I'm a little jealous of you. Sometimes I'm a lot jealous of you. Sometimes I'm not at all.” So, I'm telling everybody, it's okay to be jealous. [laugh].Corey: I agree with the sentiment that I changed the word ‘envious' because envy is one of those, like—Matty: Okay.Corey: —“I want that, too,” whereas jealousy is a lot more a shade of, “I want to have it and I don't want them to.” And I don't believe that's the direction you're heading in. [laugh].Matty: No. Thank you. No, you're exactly right. Envy is the better one yeah because it's never—Corey: Now, I recently learned the distinction there by getting very wrong and saying things I didn't intend to imply, which is why I bring it up. Again, let my mistake be something others can learn from. Sometimes the best purpose I can serve in this industry is as a counter-example.Matty: Example. I was going to say, you know, just for everybody, I remember at the beginning, you know, Corey said, “Maybe we'll learn something.” I'm like, I guess that's what we learned [laugh] is the difference between envy and jealousy.Corey: Yeah.Matty: [unintelligible 00:31:50] gotta say, you know, it took us half an hour to get there. But you know.Corey: No no. And I appreciate your friendship throughout the years. Like, you were one of those people that has been something of a guiding star, where it's, sometimes I get it right, sometimes I get it wrong, and you've always been someone who has been very willing to share which side of the divide you think I'm on with anything that I've done. And for lack of a better term, you knew me before I basically bought ink by the barrel. And back when I was just the conference speaker that had to follow one of your ridiculous talks, like, “Oh, God. Those are big shoes to fill. I'd better learn how to give a conference talk.” So, most of what I become is your fault. But I do want to thank you for your guidance over the years on these things.Matty: Can we tell the real story about how I claim ownership of The Duckbill Group?Corey: By all means, take it away.Matty: Oh, okay. So, [[laugh]] I honestly still think that I should have a part ownership in The Duckbill Group because for those of you who don't know, Corey mentioned that I had worked at PagerDuty, and actually that job came down between the two of us and Corey didn't get it. And then went and started his own company and became famous and amazing. So really, it's because of me is what I'm trying to get at. I—Corey: To be fair, they made the right hire. Which one of us do you think makes the better employee, let's be very clear?Matty: [laugh].Corey: And yeah, I am thrilled to deal in you in on ownership of The Duckbill Group because the way we're structured, you cannot have ownership without also assuming liability. So yeah—Matty: [laugh].Corey: I would love to dump legal responsibility for my shenanigans on someone else. Come on in. Yeah, there's always a cutting edge to everything else. But no, you're right. I always wonder what would have happened if that decision had gone differently.And I'm very glad it played out the way that it did. You were the right hire for the company in a way that I never would have been. But I would have given it a good try for a while before they begrudgingly had to fire me or I sensed the axe was coming and left on my own. That is the nature of me as an employee. You have a very different perspective because you're good at things that I'm terrible at.Matty: And vice versa. It was interesting. You just talked about, like, how would things go different? So I—yesterday—just recorded—I don't know when it's going to come out—I was on a podcast called 8 Bits—so it's 8bits.tv—and it's really a show about people's journey through tech.And what was interesting that came out of that conversation was, first of all, how much of how I got to where I am is because of spite. Which you're going to have to go back and listen to the episode to hear the whole story of all the spite. But we did talk about, like, those junction points that happen that seem innocuous. And it's like, I made this one choice that wasn't even necessarily a choice and you follow all the forking logic that gets you to, Corey, you and I are sitting here on a podcast right now. How many decisions that weren't even decisions? There's the alternate universe where this doesn't happen where this doesn't exist, right?Corey: It's weird how this stuff all works. Years before I'd met either one of you, you videotaped my wife's law school musical and burned it to CD. We found that out when you were here over dinner one night.Matty: That was my favorite thing.Corey: It was surreal.Matty: Yeah, I was at dinner with Corey and his wife and we got into a conversation about that she had gone to law school in Chicago. And I was like, “Oh, funny thing. Like, I produced the video of the law school mu”—and she was like, “Wait, what was that?” And I couldn't even remember. I had to, like, dig back into, like, an old blog post. And was that and then yeah, and Bethany, like—Corey: She walks into the other room and comes back with a DVD that you burned, your handwriting on it.Matty: Yeah.Corey: Yeah.Matty: Yeah, pretty much. Yeah. The world is small. Be nice to everybody.Corey: It never hurts. I want to thank you for taking time out of your day to basically tell stories once again. It's always good to talk to you. If people want to learn more about who you are, what you're up to, where's the best place they can find you.Matty: So, really the best place is Twitter. You know, so I'm at @mattstratton on Twitter. If you're not a Twitter person, that's okay. LinkedIn is not great for fi—I don't always remember to post stuff there. If you want to know about upcoming, you know, so if you go to speaking.mattstratton.com, that has all my previous talks, my upcoming talks, and things as hopefully we'll have more and more of that.And yeah, and every week, I stream on twitch.tv/Pulumi on Thursdays. And it's not webinars, it's not slick demos, it's just me screwing around and sometimes having fun people on, and sometimes just proving how little I know about coding. So yeah, good times. Thank you for having me on, again, Corey. It's always fun.Corey: Of course. Links to all that's going on in the [show notes 00:36:20]. And as always, it's a pleasure.Matty: Also, I will say, Corey, I'll give you the link to that 8bit.tv, if you want to put that in the [show notes 00:36:28]—Corey: Oh, of course, we will.Matty: —if people want to go and find that. Because I think it's similar, connected to what we talked about.Corey: Good. I look forward to listening to it myself. Mattie Stratton, staff developer advocate at Pulumi. 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 a long angry comment detailing that DevOps is in fact a role and here's what it means, and then go ahead and describe a sysadmin.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.

Serverless Chats
Episode #129: What To Do When the Servers Go Away with Tom McLaughlin

Serverless Chats

Play Episode Listen Later Mar 21, 2022 42:54


Tom is a cloud infrastructure and operations engineer with 13+ years of platform operations and IT experience, and over 8 years of AWS cloud infrastructure. He has worked in companies ranging from startups to the enterprise. His areas of focus around serverless started largely on the operational aspects of building and running reliable serverless systems. More recently his efforts involve mentoring teams new to AWS and serverless, and helping them successfully adopt these technologies through training and education.Tom is also a leading serverless advocate in the DevOps community. He is a regular speaker at DevOpsDays conferences where he works to guide operations engineers in identifying and further the skills they need to be successful with serverless infrastructure.What drew Tom early to serverless was the prospect of having no hosts or container management platform to build and manage which yielded the question: What would he do if the servers he was responsible for went away? As an early DevOps adopter he felt it was time to take a leap again into a new and emerging technology space. He's found enjoyment in a community of people that are both pushing the future of technology and trying to understand its effects on the future of people and businesses.When not working, Tom can be found racing his ‘87 Buick Grand National at the dragstrip, dabbling in photography, or playing with his cat Cinnamon. Twitter: @tmclaughbos LinkedIn: https://www.linkedin.com/in/tmclaugh/ ServerlessOps.io: https://www.serverlessops.io/ Serverless DevOps Ebook: https://www.serverlessops.io/download-the-serverless-devops-ebook Dev.to: https://dev.to/tmclaughbos

Built in Ohio
63. Warner Moore on Columbus's tech growth and future opportunities

Built in Ohio

Play Episode Listen Later Jan 26, 2022 36:09


Warner Moore is a strategic executive leader and manager with a background in technology and information security. In this episode we talk with Warner about Columbus's tech growth, future opportunities for tech in Ohio, and the cybersecurity landscape.  He has focused his career in working with entrepreneurial growth organizations where technology is their business and product. Within these organizations, Warner has an accomplished record of building successful cybersecurity programs and high performing teams who embrace DevOps culture and practices.As an international speaker, Warner has been invited to present to university students, technology professionals, and business leaders in a classroom setting as well as at conferences such as Startup Week, CloudDevelop, Path to Agility, InfoSec Summit, CodeMash, Security BSides, DevOpsDays, and Abstractions.Warner is passionate about culture, innovation, and community. His commitment to these values is demonstrated though his work leading organizations such as Ohio LinuxFest, LOPSA, and Toastmasters. The culmination of this work is the founding of Tech Community Coalition in 2016, a non-profit organization whose mission is to enable the greater tech community.After building security and privacy capabilities for numerous organizations across industries at companies such as CoverMyMeds and Bold Penguin, Warner founded the cybersecurity strategy firm Gamma Force. Through Gamma Force, Warner serves as a virtual CISO for clients that include Deep Lens and Smart Columbus and advises startups to scale them through concept and growth phases.Learn more about Gamma Force: www.gammaforce.ioConnect with Warner on LinkedIn: www.linkedin.com/in/warnermoore

Semaphore Uncut
How to Introduce Your Engineering Team to CI/CD with Kris Buytaert

Semaphore Uncut

Play Episode Listen Later Jan 25, 2022 26:30


In this podcast episode, I welcome Kris Buytaert, consulting CTO at Inuits.eu, one of the organisers of DevOpsDays. We talk about the conference, how to introduce CI/CD to teams, and what some patterns and antipatterns for infrastructure as code are. We also discuss why teams are reluctant to spend money on testing and operations, and what happens if they don't.Listen to the full conversation or read the edited transcript.What we talked about:The reality of conferences in COVID timesHow to introduce CI/CD to teamsInfrastructure as code: patterns and antipatternsDrawbacks of tech educationWhy do organisations not spend money on testing?How to get budget for DevOpsLearn more about Semaphore: https://semaphoreci.com You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Dünya Trendleri
Technical Evangelist Nedir? - Konuk: Resmo Kurucu Ortağı Serhat Can

Dünya Trendleri

Play Episode Listen Later Jan 1, 2022 39:26


105. Bölümde konuğum Resmo kurucu ortağı Serhat Can oldu. Serhat Can, geliştiriciler ve birinci sınıf güvenlik ekipleri için sürekli siber varlık görünürlüğü ve güvenlik çözümü olan Resmo'nun kurucu ortağıdır. Daha önce Atlassian'da ürünler üretti ve geliştirdi. Uluslararası konferanslarda ve buluşmalarda sık sık konuşmalar yapıyor. Serhat birçok konferans ve topluluk etkinliği düzenledi düzenlemeye devam ediyor. O bir AWS Topluluk Kahramanı. Dünya çapında 80'den fazla şehirde DevOpsDays'in koordinasyonuna yardımcı oluyor. Cloud & Serverless Turkey ve DevOps Turkey buluşmalarını yerel olarak organize ediyor. (00:00) - Açılış Patreon destekleri için; https://www.patreon.com/dunyatrendleri (02:53) - Technical Evangelist hikayesi nasıl başladı? Technical Evangelist Nedir? http://canserhat.com/ AWS Heroes - https://go.aws/3FY2wiU (09:05) - Çıkış noktamız ve Engineering Marketing önemi. (12:07) - Technical Evangelist Türkiye'de biliniyor mu? (13:28) - Resmo'nun hikayesi. https://www.resmo.com/about-us (15:14) - Bulut Bilişim ve 2022 ön görüleri. (19:32) - Önemli Technical Evangelistler kimler? Scott Hanselman - https://www.hanselman.com/blog/ Kelsey Hightower - https://twitter.com/kelseyhightower?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor (23:55) - Slack Podcast Hikayesi https://soundcloud.com/slackvarietypack https://gimletmedia.com/shows/startup (28:22) - Technical Evangelist ve Teknoloji Evangelist farklı mı? (29:07) - Bu konuda kendini geliştirmek isteyenlere önerilerin neler olur? Turuncu Pasaport - https://open.spotify.com/show/1jMTzvRku3kqjCtO53YrnQ (33:33) - Şirketler nasıl bakıyor? (36:30) - Son sözler (37:45) - Öneriler - Podcast - https://spoti.fi/3ELBUjR (38:48) -Kapanış Serhat Can - https://www.linkedin.com/in/serhatcan/ https://twitter.com/srhtcn Sosyal Medya Hesaplarımız; Twitter - https://twitter.com/dunyatrendleri Instagram - https://www.instagram.com/dunya.trendleri/ Linkedin - https://www.linkedin.com/company/dunyatrendleri/ Youtube - https://www.youtube.com/c/aykutbalcitv Goodreads - https://www.goodreads.com/user/show/28342227-aykut-balc aykut@dunyatrendleri.com Bize Bağış Yapmak İsterseniz Patreon hesabımız - https://www.patreon.com/dunyatrendleri

Profound
Profound - Dr Deming - Episode 24- Dominica DeGrandis- Making Work Visible

Profound

Play Episode Listen Later Nov 17, 2021 48:07


Dominica DeGrandis is my guest on this episode. In 2010, Dominica and I met at the first US DevOps Days. We discuss the early DevOps Days and the Kanban game in this episode. We also discuss her work on making work visible and the five thieves of time. Every time I speak with Dominica, it is always a great conversation. Here are a few links:https://itrevolution.com/making-work-visible-by-dominica-degrandis/ https://itrevolution.com/immersion/ linkedin.com/in/dominicadeg

Profound
Profound - Dr Deming - Episode 21- Steve Pereira - The Flow Collective

Profound

Play Episode Listen Later Nov 1, 2021 45:40


Steve and I talk about early DevOpsDays, Value Streams, Flow, Systems Thinking and of course Dr. Deming. Give talks about his thought about Dr. Deming's System of Profound Knowledge. We cover a lot of ground in this podcast.  I'm sure you will enjoy it.  You can find a link to all of the cool things Steve is working on here: https://vzbl.io/links

Profound
Profound - Dr Deming - Episode 2 - Ben Rockwood

Profound

Play Episode Play 44 sec Highlight Listen Later Apr 27, 2021 40:34


In this episode, I chat with my old friend Ben Rockwood.  Ben introduced me to Dr. Deming at an early Devopsdays.  Ben is a real student in this field and I am sure you will enjoy this podcast.

Arrested DevOps
Devopsdays Chicago 2020

Arrested DevOps

Play Episode Listen Later Nov 9, 2020 67:40


DevOpsDays Chicago 2020 was the first time the long-running conference went virtual. A panel of speakers and organizers discuss the event, how it was produced, and what the experience was like!

Arrested DevOps
Devopsdays Philadelphia 2019

Arrested DevOps

Play Episode Listen Later Nov 3, 2019 31:13


Bridget chats with guests Peter Shannon, Jocelyn Harper, and Tim Gross in front of a live studio audience at devopsdays Philadelphia 2019.

Arrested DevOps
Devopsdays Cape Town 2019

Arrested DevOps

Play Episode Listen Later Oct 2, 2019 36:59


Bridget chats with Devi Moodley, Daniel Maher, Adrian Moisey, and Cobus Bernard at devopsdays Cape Town 2019.

Arrested DevOps
Devopsdays Chicago 2019

Arrested DevOps

Play Episode Listen Later Sep 17, 2019 30:26


Matty and Trevor chat with guests Jessie Frazelle, Veronica Hanus, and Jeff Smith in front of a live studio audience at devopsdays Chicago 2019.

Arrested DevOps
Devopsdays Minneapolis 2019

Arrested DevOps

Play Episode Listen Later Aug 16, 2019 39:17


Bridget and Matty chat with guests Liz Fong-Jones, Alice Goldfuss, and RJ Williams, in front of a live studio audience at devopsdays Minneapolis 2019.

Arrested DevOps
DevOpsDays Kansas City 2018

Arrested DevOps

Play Episode Listen Later Nov 14, 2018


Matty (with special guest host Jessica DeVita) is joined by Ana Medina, Dan Barker, Ben Clayton, and Monica Hart at DevOpsDays Kansas City 2018.

Arrested DevOps
Devopsdays Chicago 2018

Arrested DevOps

Play Episode Listen Later Nov 14, 2018


Recorded live at DevOpsDays Chicago 2018, Matty and Trevor are joined by Aaron Kalin, Katie Prizy, and Jeff Smith to talk about bias and ethics in the tech industry.

Arrested DevOps
Devopsdays Salt Lake City 2018

Arrested DevOps

Play Episode Listen Later Aug 20, 2018


Matty discusses devopsdays Salt Lake City 2018 with a panel in front of a live studio audience.

Arrested DevOps
Devopsdays Minneapolis 2018

Arrested DevOps

Play Episode Listen Later Aug 8, 2018


Bridget and Matty chat about organizing conferences with guests Jam Leomi, Debbie Gillespie, and Christian Herro, in front of a live studio audience at devopsdays Minneapolis 2018.

Arrested DevOps
Devopsdays Amsterdam 2018

Arrested DevOps

Play Episode Listen Later Jul 22, 2018


Matty and Bridget discuss conference speaking with participants at devopsdays Amsterdam 2018.