What exactly is “technical evangelism?” At Gitlab, it’s sharing opinions on what’s going on in the community as technologists — helping each other to collectively move forward to build better, ship better, and operationalize better so software is more responsive to customer needs. That’s according to Ledge’s guest, Priyanka Sharma.
The great thing about evangelists? They have opinions, and they can give us the historical context necessary to make sense of the rapid pace of change in our industry.
In this episode, Priyanka shares her thoughts on overtooling, how to handle the operations burdens of cloud and microservices efforts, and how to adjust process components for scale. Then she jumps into how to deal with media overload when you have a job that requires you to be up to date on tech trends.
Ledge: If you don’t mind, would you just give a little background story of yourself and your work so the audience can get to know you a little bit.
Priyanka: Absolutely! As I’ve said, I’m Priyanka and I’m director of technical evangelism at GitLab. My team’s focus is to build the technical leadership, the stories around the latest technology trends.
What are the best ways people are developing software? How are they operationalizing it? ─ having conversations around that in the public arena, so to speak, even though, being GitLab, everything is public.
That’s what I do. I’ve been here about a year and I come from the infrastructure world. I’ve been involved with cloud native technologies for a while. I was one of the early people on the Open Tracing project which was the third to join the Cloud Native Computing Foundation.
For folks who may not know the Cloud Native Computing Foundation, it’s the home for Kubernetes which is container orchestration and it’s pretty loved at this point, I would say. I also serve on the board of the Cloud Native Computing Foundation.
Ledge: I think it’s always useful for people to hear perspectives on developer advocacy. And even that “hey, there’s DevRel, there’s developer advocacy, thought leadership,” how do all these fit together because many of you are kind of in charge of stewarding the most important technologies like Kubernetes with any number of things?
All this stuff gets touched and maybe everybody doesn’t know where things fall down in the dev advocacy and DevRel kind of world. I’d love for you to just give some structure to that.
Priyanka: Yes, absolutely! Many companies call my team’s role “developer advocacy” or “developer relations.”
At GitLab, we call it “technology evangelism” because the focus is on evangelizing that technology story.
We have a separate DevRel, developer relations team, and their focus is on adding contributors to GitLab and working with the open source communities to build that up. And so, they’ll go wide in the community.
While with technical evangelism, we are very focused. We’re focused on the key technology stories and topics that are important to the ecosystem right now, and we go deep into technical talks, demos, blogposts, and even conversations like this. That’s kind of the difference in the GitLab world.
In general, in the ecosystem right now, developer advocacy or technical evangelism is really about sharing opinions on what’s going on in our community as technologists and helping each other collectively move us forward so that we build better, we ship better, and we operationalize better so that software is more responsive to the customers.
Ledge: Right. What are the key trends and what are your opinions about them?
Priyanka: How much time have we got? Okay, I hear you ─ key trends and my opinions on them.
At this point, I think the cloud native ecosystem has really established itself. Three years ago when I was starting out in this world, Kubernetes had just become the darling so there was a lot of momentum.
Kubernetes comes along. It’s about container orchestration. It enables portability. And because of the way it operationalizes things, it enables microservices development.
So people were shifting to the cloud and they started breaking things up into services although while using Kubernetes. And I think what folks realized is, yes, breaking a monolith is good because you can ship faster. You can also scale based on “Where is the load going? Where is the traffic?” so you don’t have to think of the entire huge behemoth. And that’s good.
However, we were used to operationalizing monoliths. We were used to standing them up, keeping the traffic coming, keeping latency low, and things like that, the things that traditional IT sysadmin or ops people used to think about.
Those were suddenly problematic once you were on microservices just because it’s a new paradigm.
And I think we, as a technology community, jumped in to solve those problems. I was part of that movement with the Open Tracing project where we wanted to make distributed tracing accessible to everybody so that they can visualize complex software systems.
I think we overdid it a little bit. If you look at the CNCF landscape, there are so many logos. You can’t really parse anymore with the human eye about what’s going on, what’s good, what’s a good project to use, and what’s a good technology to go for. There are too many options.
And I think we are seeing an impact of that. At GitLab, we work with over a hundred thousand enterprises. And so, we hear the stories from the horse’s mouth and a lot of it is like “Yes, I want to ship less. Yes, I want to break up into microservices. But, hey, the operational burden here is crazy and, by the way, when I tried to solve this operational burden with tools, suddenly, I have like twenty or a hundred tools.” And that’s its own burden.
So what we’ve seen is that there’s a lot going on and it behooves enterprises to actually hold up and think on what your tool change should be before buying everything or using every project.
GitLab’s philosophy is very much of a single application that does the whole dev secops life cycle, and that’s one way to approach it.
In general, you don’t have to just use one product but I do support sort of like a cohesive strategy around tooling where you have one major touchpoint that contains a lot of your processes, and then you have special sharp tools that integrate into that so that everything stays in sync; and you’ve had little context which is between tools. You’ve had little time spent integrating stuff and all that. That’s kind of something I’ve seen happen.
And it’s been interesting because first came Kubernetes and the rush with microservices, then the horror around operationalization; then, suddenly, we had all these options and sharp tools. People got really excited.
And at that time, GitLab was already saying, “This is too much. You need to have a cohesive approach.” And, at that time, people were like, “No, no, the sharpest tool possible.”
And I totally get that. I was on that fence. Now, the whole world is suddenly shifting to the GitLab message ─ even our competitors. There’s the Azure DevOps story now. GitHub had GitHub Actions.
I think the world is coming around to “Oh, yes, there’s something to this point of a streamlined tool chain, maybe a single application.” So that’s kind of the trends I’m seeing.
Ledge: I totally get it. And from our seat in the staffing world, the tool overload has been a major concern particularly when clients will come in and go, “I need a senior DevOps developer full stack who knows these fifteen tools perfectly. It has to be these.”
There’s a .01 percent chance that I will find that unicorn and that it will sort of all line up there; and we have to often consult and say, “Hey, why don’t you prioritize these things because you’re right. All those things are great tools but have you thought about the fact that operationalizing that or maintaining that is going to be a total disaster?”
Let’s say each one of those things adds five percent more complexity but it’s compounding; it’s not additive.
Ledge: And you have this chain management problem that anytime any one of those tools doesn’t update or anything, you’re going to a problem there. I totally get it.
And there are also corollaries to ─ marketing technology has come through the same where you get those logo pictures where it’s like “Congrats! Now we have 75 conduit MarTech vendors.”
Totally relatable! And, sometimes, it does sound like simplicity. If it’s not the best tool for every part of the job, it’s the best collection of tools that kind of gets you from Point A to Point B.
Priyanka: And there’s the whole concept of the sum is greater than the parts. That’s actually why GitLab started on this single application journey. We were version control to be begin with, as you know. And then, we have two co-founders, Sid and DZ and DZ is the person who built the initial GitLab and has been the greatest contributor ever since. He’s one of the co-founders of the company.
And DZ started building out CI and one of the community contributors whose name is Kamil said, “You know, here are some better runners for CI. And, also, by the way, you should connect this to your version control.” And DZ was like, “Oh, that’s weird because everybody has sharp tools and specific products and all that.”
Somehow, Kamil convinced him “Let’s give it a try” which is a very fair ask. Then they convinced Sid, our CEO, “Let’s give it a try even though, yes, it’s not the Unix philosophy and all that stuff.”
And when they did it, we saw it really work. And that was when it was like, “Oh, the sum is greater than the parts. You have the same data story. You have the context from a workflow perspective propagated throughout the tool chain.” It’s like “This is way better than isolated tools.”
And that’s kind of how it went along. Here we are with a large single application so I totally resonate that there is something about the simplicity and doing things in one place.
Ledge: Cool! There’s a tremendous trend there and something I definitely have heard from a lot of the tech leaders.
Let me ask you this. When you’re out on the road there sort of evangelizing, one of the things that strikes me in this seat is I often have to consume an insane amount of media because I need to read everybody’s stuff and I need to understand who I’m talking to and I ought to know the trends because I can ask questions because of it.
I wonder, how do you keep up and balance the industry media consumption and probably a little bit of cross disciplinary macro stuff? You just need to pay attention to the economy and stuff. What’s your personal strategy for not overwhelming the brain on consumption of articles, blogs, podcasts, Twitter?
Priyanka: I did a bunch of thinking around this around the new year when I was thinking about resolutions, aspirations, and things I wouldn’t do. I divided things up into ─ so resolution is something “got to do it.” Aspiration is something I’m going to track and try to get to and it’s okay if I don’t nail it because you can’t have too many resolutions. But you do need to track certain things in your life that you care about.
An example for me is dishes in the sink. I really need to stop having them all the time. But I know I’ll fail from time to time. So that’s an aspiration. And then, there are things that you’re just wasting time on.
What I landed on is that I decided that I’m really not going to invest time in reading long-form articles about political news. First of all, I get the TLDR from Twitter; secondly, I go down a rabbit hole on a topic that actually I have very little control over.
I want to stay informed but I used to always spend so much time on New Yorker and not leaving it, and it takes up time. So that’s what happened in the macro side of things. I’ll catch up on Twitter, read the headlines, but maybe not the details.
On the industry front, Twitter really is a savior for me. I find out so many things on it. I particularly love tweetstorms and the threads because I feel like they’re so communicative and I get so much out of it. And I make sure that who I follow is really important for that; so you need to follow the right people.
When new things happen like, let’s say, a new project comes to my attention, I’ll make sure to follow; I’ll make sure to follow the lead maintainer ─ that kind of thing. That gives me a touchpoint.
There’s this lightweight way of doing things. For example, when there’s a podcast, somebody will link to the podcast and I’ll often listen on 2X speed and jump through it to keep abreast. Then, there’s also the time when you really need to focus and deep dive. For me, that ends up being some of the key conferences.
KubeCon Europe which is coming up May 20 to May 25 is one of the big ones where I focus on the conference when I’m there. I drink from the fire hose. I go to as many talks as I can and spend time in person speaking with humans who are behind the technologies and connecting with them seeing how I can help them because, frankly, for me, I learn by interacting with people and by doing.
So if I’m like “Hey, gig tracing project, how I can help you?” and they say, “Oh, can you look over our case studies?” I’ll say “yes” because guess who’s going to learn?
I learn by doing and by engaging. So KubeCon and OSCON is another one; and there’s a bunch of other ones that are great ways for me to deep dive. And they do a great job, I will say, of bubbling up the key trends.
Last year at KubeCon Shanghai where I keynoted, it was such a great experience. I learned about the Harbor project. Maybe I learned about Harbor a day late but I don’t think it was a dollar short because there was a keynote on the topic; all the people from the Harbor team were there and we had time to talk to them, learn. And it was great. I caught up and felt up to speed.
So, in a nutshell, that’s kind of how I do it.
Ledge: Don’t you bring back a million things and you have to distill it out or do you keep a personal note system or something?
Priyanka: Great question! Something I like to do ─ and I have to be consistent with it, I’ll be honest ─ is when I go to a conference like this, I’m in absorption mode and I try to take notes every night.
At GitLab, we work in issues and it’s all public so anybody can see it. And I’ll try to do like an event recap and, there, I’ll do the basics like “Oh, met this, met that.” But then I’ll do my key takeaway section. This is opinion and not a research thingy and I’ll list, “Okay, trend one, I noticed this technology is getting really good response from end users; I noticed this one not so much; oh, here’s this new thing about and here’s how I think it impacts.”
It’s not one or two but maybe like six or seven points usually. I think it helps people stay up to date ─ and actually combining that from a collective knowledge perspective.
Our CEO, Sid, and a bunch of other GitLabers are big on Hacker News and things like that. So combining my learnings from there and hearing from those folks on their learning and the channels they’re on brings us all to a really good collective knowledge point.
Ledge: It makes me think that somebody needs to do a way to track “What all things do you really read and think about? How do you rate the validity?” because you can follow a hundred thousand people on Twitter and everything you’re touching your news up. I’m constantly thinking that as soon as I click this, now I’m going to get a bunch of articles that are related to it but “What am I missing?” because it’s algorithmic.
This is the stuff that keeps me awake at night.
Priyanka: I hear you, though, but over the years, at least, the conclusion I came to is that there will be things that you miss; it’s okay.
It’s surrounding yourself with other people who are also engaged and interested like Melissa Smolensky who runs corporate marketing at GitLab; she and I are really tight.
I missed the announcement about the Docker vulnerability, for example, and she was talking to me about something and she said, “Oh, by the way, did you hear…” and I said, “No” and, instantly, I’m on it.
So I think if you have a brain trust ─ Sid, Melissa, myself, a bunch of others ─ in the company and community, we sort of ping out on Slack and stuff ─ and that helps because always you will miss things. And then, I also think a really important factor is to bring your own lens to the learning.
Every event that happens like Google Next, KubeCon, re:Invent, Microsoft Build, OSCON, there will be announcements everywhere. It’s really important, I think, to do two things.
One is “What’s your own gut on this?” Forget the hype because it’s the announcer’s job to create hype. It’s literally what they’re supposed to do so you can’t be upset about that.
But just go to the fundamentals. Do you think this is useful? Do you think this is just a repackaging or do you think there’s some value here?
I feel like, at least, sixty percent of the time, your gut is going to be right.
And then, the second aspect which I think is so critical and, sometimes, the industry kind of misses is that we all talk to each other a lot but, really, we need to be listening to the end users. We need to be bringing them into the fold more.
So I had certain perspectives on multi-cloud serverless, for example, because I was on the team at GitLab that shipped the service. And my assumptions were completely checked and questioned when I started interacting with large enterprises who are heavy on serverless and how they taught about multi cloud.
I learned that they prefer certain clouds for certain work loads before they start working on them. Someone told me they liked doing _____ 0:20:11.5 workloads on GCP, for instance. And this is one person who told me this. And based on that is how they want the portability and all of that. It’s not like they’re just jumping clouds here and there.
And so, these are details. When you get involved with how people are making decisions, I think that, combined with your own sense of what’s really going on with the announcement, can help.
Ledge: Great insights! I love it. We see the same thing with staffing, that you can quickly convince yourself of what’s a great engineer and what’s the best way to do this.
And so, we have to really challenge ourselves to ask everybody we can “What do you value most in the zeitgeist guys of engineering?”
I can ask a hundred CTOs and they’re all going to give me an opinion and sort of the average opinion maybe ought to be baked into our vetting, process, and product.
But you have to constantly be aware of “Why do I care about this thing and how biased am I because of my own experience? And what does the customer really want?”
And I challenge everybody to say, “When was the last time you legitimately talked to five customers of your product in a week?” because I don’t think it’s very high. I think we need to not push that down to account management or what have you. That’s really important and all of us ought to just get that perspective from time to time.
I have some really important stuff. This is the lightning round ─ super critical.
Star Wars or Star Trek?
Priyanka: Star Trek.
Ledge: I’m kind of tied since I started this. This is interesting to me.
What are you reading right now?
Priyanka: It’s about dog training because I just adopted a dog.
Ledge: What can’t you live without?
Priyanka: And my dog now. My dog is trying to chew my footstool.
Ledge: What’s the last thing you do googled?
Priyanka: I just googled your Twitter handle. We want to follow up with you about Gun.io.
Ledge: That is the best answer I’ve ever heard. We will definitely be promoting that one.
I don’t know if you’re a fan of The Office but there’s a classic episode of The Office where Jim is screwing around with Dwight like he always does, and he sends faxes to Dwight from future Dwight like “Oh, the coffee is poisoned” or different things like that.
But that made me think and I like to ask everybody this. If I gave you one piece of paper and one of those big fat black Sharpies, what are you going to write on the piece of paper if you’re future Priyanka and you’ve got to send a ─
Priyanka: You mean, I’m current Priyanka writing to the past or I am ten years ahead.
Ledge: You get to fax right now ─
Priyanka: ─ or am I like genuinely helpful?
Ledge: Some people do it themselves but most people like to be helpful themselves.
Priyanka: So ten years ago in 2009, I would tell myself to focus on getting on the technical side of things as fast as possible because I started out in actually partnerships in Google AdSense. So I would tell myself ─ oh my gosh, there’s so much I need to tell myself.
I did a project with a couple of engineers. I was pm’ing it actually just by chance as a ten percent project. You know, at Google, it’s very hard to be in product. But, somehow, I just worked and things were awesome. And I actually had an offer on the table to join the engineering team.
And I would tell myself, “Go take that offer. I know it’s crazy but your future is deeply technical. This is what you love.” And I would say, “Move to San Francisco.” I was living in Palo Alto; it was really boring.
Ledge: Priyanka, we could do this all day. This is a lot of fun. It’s so much fun talking to you. Thank you for joining us on the show today.
Priyanka: Thank you so much. I had a really good time.