DevRel Career Q&A: My Journey into Developer Relations (with thanks to Rohit Ghumare!)
DevRel Career Q&A: My Journey into Developer Relations (with thanks to Rohit Ghumare!)
I joined Rohit's podcast to talk about my career path, what technologies I encountered, and how I learned to build and lead DevRel teams
I often joke that it’s a small world in the software development space, but in DevRel this really is the case. I’ve bumped into Rohit Ghumare many times through his great work at Solo.io and within the cloud native community, and so when he reached out and invited me to share my learning on building developer relations teams on his podcast, I jumped at the chance!
This post summarizes our conversation. We cover everything from my career path, how I ended up in developer relations, how I build and lead DevRel teams, and what I think of the current cloud native ecosystem.
Key takeaways
If you’re looking for a tl;dr of our conversation, this is it!
You don’t need to map out your career in detail, but having a “north star” helps. For example, I always enjoyed building things (technology, products, teams) and helping others understand technologies. Learning this early in my career enabled me to seek out and take advantage of relevant job opportunities
I prioritize my time to be able to read widely (little and often!) and I aim to keep up with emerging technologies and potential trends. I aim to “skate to where the puck is going” and invest in technologies and communities that I believe will have a big impact, e.g. microservices/containers, cloud native, AI-based dev tooling, etc.
Although not essential for career success, finding mentors has many benefits. They can provide aspiration (be a role model), provide context-specific guidance, and open doors for you.
When building a developer relations team, the most important thing to understand is the current stage and goals of the business. Start-ups require more “Jack/Jill of all trades”, whereas enterprises often require specialists. Organising your team around your product(s) and mapping team KPIs/OKRs to the overall department and company goals is often a recipe for success.
Communicating clear goals and challenges and then empowering your team to create solutions can lead to more effective (and more scalable) programs in comparison with you attempting to lead everything yourself as a manager.
Video
The complete recording of our conversation can be found on YouTube: “How to become an excellent writer? How to achieve a successful cloud native career? | Head of DevRel”
(00:16): Introductions
(02:16) What motivated you to move from Java-focused software development to the cloud native ecosystem?
(05:39) How did you gain technical experience within the software development industry? What was your career journey?
(11:35) How do you balance all the different tasks and goals with your career? You always seem to be doing a lot!
(16:39) How did you build the Ambassador Lab’s developer relations team from scratch?
(24:08) What’s your take on the current Kubernetes ecosystem? How have API gateways and service meshes developed?
(31:50) What is the future of software development? Is it all generative AI and LLMs?
(39:28) Thank you for joining me on the podcast!
Complete transcript
(Disclaimer: may contain unintentionally confusing, inaccurate, or bizarre transcription errors — let me know if you find any!)
Introductions
Rohit (00:16):
Hello, everyone. We are back with the cloud native episode 15, and as we can see we have one of the leaders in the cloud native, none other than Daniel Bryant. If you have heard about the Ambassador Labs, if you heard about the InfoQ, if you heard about the QCon and stuff, this is the guy who is aggressively working around that. InfoQ already everyone knows and Daniel's work has seen by everyone in the world. If you are familiar with the sum of the cloud native developer, you must have known him somewhere and somewhere because you have read his articles. You have never checked the who is the writer, but you listened what is written. That was one of introduction I wanted to talk about Daniel. Daniel, you are the one who can introduce yourself in a nicer way and a more efficient way so go ahead.
Daniel (01:16):
No, I think that was fantastic, Rohit. Thank you very much. You definitely made me sound better than I am, I think. But I appreciate all the love and respect there. As in, yeah, I've been in the space now for 20 or so years. Started as a Java developer, moved into ops and architecture and then briefly forayed into like CTO type roles and leadership. I love managing people, leading people in particular. And last five or six years has been in Ambassador Labs. That's where you and I have crossed paths several times in the same kind of space and focusing very much on Kubernetes, API Gateway, Service Mesh, all that good stuff. And I recently left there. I fancied something perhaps new, building something from the ground up again. I wish all the Ambassador Labs folks all the luck in the world and all the success in the world and I'm regularly in contact with them as well. But now I'm taking a bit of a break over the summer and then looking for new challenges starting September.
Rohit (02:06):
You will get the new challenges anytime.
Daniel (02:09):
Thank you.
Rohit (02:09):
People are looking for you.
Daniel (02:09):
I hope.
What motivated you to move from Java-focused software development to the cloud native ecosystem?
Rohit (02:16):
First of all, we can go with this thing. What do you think, what pushed you towards the Cloud Native world? Because you are from the Java background and then you came to the DevOps world. You have amazing talks on the Kubernetes and then DevRel and DevOps, how the DevOps is in the DevRel world and how the DevRel is in DevOps world kind of things. I have seen a lot of them and I have seen your work already and we have come across the parts when I am, but never got a chance talk or something directly face to face. That's what I want to ask you today, why you are into the cloud native space?
Daniel (02:57):
It's a great question, Rohit. And I think like several things in my career, I kind of stumbled on it. But when I say stumbled on it, not in a completely random fashion, it's always a little bit of luck and a little bit of skill. Do you know what I mean? I've been quite lucky finding the hot trends at the right time. Do you know what I mean? Jumping on them. I've not done as well as some people. I always maximum respect to people like Sam Newman, who got microservices at the perfect time and he just did an amazing, amazing job. But for me with Java, it was definitely going in that cloud native direction even before cloud native was a thing. You could see in the world of Spring Boot, in particular, it was going Ruby on Rails was influencing a lot of the 12 factor apps and these kind of things.
(03:42):
And then more and more as companies like Netflix, and I know we're not all Netflix, I'm always careful with that, but as companies like Netflix start adopting this cloud native way of working, and I remember hearing Adrian Cockcroft talking about this, Rebecca Parsons talking about the influence of ThoughtWorks, as they adopted these technologies, these practises we're now calling cloud native, it cascaded down into my day job. I was consulting a bunch with OpenCredo in London. This was five or so years into the actual release of the cloud. You can argue around 2006 time Amazon kind of kicked off, the cloud movement. Although we've been doing cloud-like things for a few years before that. But it just naturally pervaded my space. I couldn't help in the applications I was building, bumping into the cloud. When we were looking forward, particularly at OpenCredo and then some other companies I joined in InfoQ, we were always looking at what's the next thing? Do you know what I mean?
(04:37):
A few of my mentors said to me, the slightly American phrase is, skate to where the puck is going. Imagine you're playing ice hockey, you don't skate to where the puck is, you skate to where the puck's going. I always look for what is the up and coming thing. And I saw cloud, I saw microservices, I saw containers at the same time and the combination with all those things I've just mentioned. And I'm based near London and in particular, around 2012 time, the meetup scene just blew up in London. And everyone I was chatting to at the DACA meetups and even the Java meetups, everyone was talking about cloud. The fact that I positioned myself with being interested and the opportunities were there, to your point, that's exactly how I started my speaking career. Did a lot of speaking at the London Java community, a lot of speaking at the cloud native meetups, HashiCorp, Docker, all the brands we know and love these days. That's how I started my proper speaking career. And then like I say just everything now is in the cloud so it was a good choice.
How did you gain technical experience within the software development industry? What was your career journey?
Rohit (05:39):
Nice. You came from Java to cloud space, DevOps space, and then to the speaking space, like DevRel space so it has been a amazing journey. You gained the experience really well and you have built the products and you experienced the leadership roles and then came to the develop advocacy kind of roles. What do you think on this? What should be the ideal time to gain this kind of leadership roles for any person who is into the Cloud Native space and DevOps space? Because as we can see there is a lot of hypes around the new roles and people keep switching from here and there and they get confused. You are the one who can guide the folks.
Daniel (06:32):
It's a open question, I guess, Rohit. Because I was in a podcast I think it was, and a panel over the last couple of weeks and we've joked that we've known some people that have been throughout their careers as operators, sysadmins, platform engineers, and the job has not changed, the title has changed, maybe the money has changed sometimes. And respect as you always go and get your money if you become a DevOps engineer and it gets you more money rock on, even if you're doing the same job. It's interesting. There is always that notion of rebranding and I'm sure you and I both get it because we even perhaps even do it. You always got to be a bit careful of what is the actual job, what are the actual goals, what is the actual mission you're doing versus the title. And I come from a point of privilege, I guess. I've never worried too much about role titles, but I appreciate not everyone can do that depending on if you're starting your career, the title is more important.
(07:27):
Definitely some of my friends and peers I worked with, you need a certain title to get that gravitas or even get customers talking to you. You need to be a VP before other VPs will talk to you. And so as silly as that seems to me it is the way the world works. You've got to break down all these things that the roles are somewhat overloaded. But I think there's great science if you actually want to compare roles and role levels. I think it's levels.fyi actually maps the various fan companies and other companies and then you can actually have a sensible conversation of, what am I actually doing as a software engineer level one. I'm responsible for daily tasks at that level. And as you move up through the ranks, then you're responsible for the weekly tasks, the monthly tasks. And when I say tasks, I really mean mission, vision.
(08:15):
When you're up to senior levels, you're thinking big picture about the product itself, as you mentioned, not just the feature I'm working on, you're thinking bigger picture. And that's the journey I've gone on. I've been super lucky. And I always say to folks, if you can find mentors, that has really opened up doors for me. And mentors have not only given me something to aim for, like I want to be like that person. I always think of Trisha Gee back in her Java days, I want to be like Trish. Or Kelsey Hightower, I think we all want to be like Kelsey Hightower when we grow up because they're just amazing. You know what I mean?
Rohit (08:45):
Everyone.
Daniel (08:46):
Totally. Like that but I wouldn't say Kelsey's necessarily a mentor, but I've met Kelsey several times and I've learned a lot from him. But I've had other relationships where people have really guided me, opened doors. And I always try and do the same thing as well for other people at the moment. I always say, look around, see what other people are doing. That can help you make the decisions of what career to go for. I'm having a lot of interesting chats with folks at the moment around this as I'm doing some mentoring online and they're saying, Do I want to be a software engineer? Do I want to be an infrastructure engineer or platform engineer type thing? Do I want to go into leadership? And I always say to them, get your core skills first. Go deep as an individual contributor, as they call it. In terms of I went super deep in Java so I knew how to, not only code, but I knew about the memory models and memory maps.
(09:36):
I knew about how Java interacted with the infrastructure and not to the point where I could build a processor, but knowing how processors work and how memory works gave me an appreciation to it to write better code. And crucially, as I've learned new languages or new things, going super deep, that initial point in my career helps me very easily build new mental models. Do you know what I mean? If I'm working in a statically typed language, oh, I know what that is from my Java days or I'm working with a heap or a stack, I know what that is from my Java days.
Rohit (10:05):
Yes.
Daniel (10:06):
And I worked on Ruby and I worked on TypeScript as well so I've got dynamic language mental models. I always say to folks early on in your career, go super deep. And then I do find there's two paths with leadership. You can either deliberately go into it. And I recommend The Manager's Path, fantastic book by Camille Fournier. There's a bunch of other amazing books too. That will give you a primer for what's possible.
(10:27):
Or I think in reality a lot of us in this space just fall into management, fall into leadership. An opportunity pops up, it did for me. Ambassador Labs as an example. I'd been doing some leadership in the technical space, but there was a gap where we know we wanted to really into DevRel, but we didn't have a DevRel team. And Richard, who's the co-founder and mentor of mine for sure, said to me, "Hey, we're going to spin up a DevRel team. You are the logical choice. Do you want to do it?" And I could have said no and done other things, that's totally an option. But I was "Yeah, it sounds great. Let's build a team, let's do some interesting stuff."
Rohit (10:58):
Yes.
Daniel (10:59):
And that's my journey, Rohit, in terms of the option team was there. A couple times I've done a couple of CTO roles, a couple of head of type roles and I like building things, whether it's teams, tech or systems or whatever. People are really hard though. People are really hard compared to tech. But I do... An amazing team at Ambassador Labs. Although I've left now, I got to shout-out. Edidiong, Dave, Cindy, Erica, they were... and Gabby was an honorary member there. They were just amazing folks. And I was doing a small little part and just magnifying their amazing work. And that's kind of cool to see it. I've really enjoyed that part of my journey.
How do you balance all the different tasks and goals with your career? You always seem to be doing a lot!
Rohit (11:35):
You build everything from the scratch. What were the problems you faced and how was your journey building the entire team of yours at the Ambassador Labs if you would like to share? And also you are working for the Qcon... sorry, InfoQ side by side, so how do you manage all this stuff?
Daniel (11:56):
Everyone asks me that, it's a great question. I'll deal with that second bit first and we go and dive into building teams. But I am very disciplined and I learned this from another mentor, Richard Seroter, he's at Google now. He's at various other companies. And Richard's got five kids, a couple of dogs, Pluralsight courses, his full-time job. He just does an amazing amount of stuff. And over the years I'm like, "Richard, how do you do it?" I'm going to give him a shout-out because he's helped me a bunch. But two things he said was, be super disciplined every day. If you're trying to get into social media every day, force yourself to write a Tweet or do a LinkedIn post. Discipline, discipline, discipline. Every day whether you feel like it or not, write a blog, do a podcast, whatever you're doing, just keep chipping away.
(12:42):
And another thing Richard taught me was only go as deep as you need to. And this is a little bit of a contradiction of what we said up front. When you're in the beginning part of your career, you do want to go super deep and spend that time. But later on I said to Richard, "How are you doing all these Pluralsight courses?" And he was like, "I'm not going to the level of super expert, like a Josh Long or someone in that space." He was going, "I'm going just deep enough to be able to share what I'm learning." And I was like, "Ah." Because me, I get a bit caught up in these things. I want to know everything and I don't know when to stop. And that's why he goes, "If you can't stop, you end up only doing a couple things at a time."
(13:23):
Whereas if you can balance, it's not easy, and I'm not perfect myself, but if you can balance just good enough. And that's a very hand wavy term, but that's what Richard taught me. Is that combination you have those things is the way I... that discipline each day. I do a little bit of InfoQ stuff, a little bit of social media, obviously the main job, dah, dah, dah. But fitting it around in my schedule and then knowing how deep to go. It's so tempting to when you're spinning up a new project to go all in on it. And Richard taught me to throttle back a little bit. If you see success go deeper if you don't see success, you can do other things. So that's generally how I balance my time. And I would say I use the Getting Things Done system.
(14:04):
It's a very famous system. There's books written around how to do it. I use my email. Because again, I remember Edidiong on my team was like, "How do you balance all these things?" And I'm like, "I write everything down. It's all either post-it notes in front of me or email using Getting Things Done." And that has really helped me offload the stress of managing all the tasks. Do you know what I mean? I trust my system and then every time I'm looking for a new task to do, I look at my system and just pick it up and run with it. There's no mental baggage of constantly worrying about the next thing or deadlines. That system takes care of that. I've got a calendar with all my deadlines on all that kind of stuff. I'm just focusing on the tasks at hand, not worrying about managing my time. Do you know what I mean?
(14:48):
Because a lot of people I speak to, particularly early on in their career, they're so worried or so stressed about doing things sometimes they spend more energy doing that than actually doing the thing. Do you know what I mean? And I get it because I was there as well and I luckily found this Getting Things Done system and I'm like, offload the mental baggage, just focus on the tasks at hand. That's how I do a lot of stuff because it's a very common question. People are like, "You do so much."
Rohit (15:09):
Yeah, of course.
Daniel (15:09):
And I'm like, "People do more , trust me, I know people do more." But as in this is how I manage to do a lot of stuff. Does that make sense?
Rohit (15:18):
Yeah, it is nice. You are disciplined and you write it down so that is two of the important factor, which everyone should do it. Some people make the timetable of everything and some they do the social media. Social media, they prepare month of things only as a foreign kind of a thing. But in our job, I don't think that is a good way to go ahead because we have to be... I trust instinct. Anytime anything can happen and we have to create it or we have to post it and kind of a thing. That is the most consistent thing we have to do. It is not a part of the job, but it is somewhere related to what we are doing. We should be socialising it to the world so it is nice. That was nice points to be sure. And so another question which is, you built the entire team from the scratch. How was the experience? And yeah, go ahead.
Daniel (16:21):
The first part of your question there, because it is a good question. I always like to set up a structure first. And the team, we knew we needed to interact both sharing knowledge and listening to feedback with developers very early on in Ambassador Labs.
How did you build the Ambassador Lab’s developer relations team from scratch?
Rohit (16:39):
Why actually am I asking this question? Because there are only a few companies who have grown their developer relations team from the scratch to the nice way. And they are built really nice like Ambassador Labs. And that's why hearing from you will be a lot of guidance to all of the professional folks who are into the developer relations and also the cloud native world. That's why I asked this question.
Daniel (17:04):
Sounds good, Rohit. And I think we knew very early on that we needed to tap into developers, educate, but also learn from their feedback. And I was doing this. I initially was hired as a product architect, so I was doing a lot of product work. And product, the most important thing about product is listening to your customer. And Ambassador Labs, we were building tools for developers. Developer relations, developer advocacy, kind of as a no-brainer in that respect. Very early on, classic startup, I was brought in about employee number seven, I think it was so it was only a few of us. I was remote in the UK, I was going over to Boston a fair bit to interact with the team and there was six, seven of us in the office in Boston. Super early on and with an early stage startup, you literally do everything, whatever is needed. Even though I was product architect totally doing DevRel.
(17:52):
Excuse me. And over time it kind of evolved. We built out probably the engineering team and when we got product market fit, we got a bit of success with what we now call Edge Stack, which is Ambassador API gateway, we got a bit of success with telepresence. Once we got that product market fit, we built out the engineering team, the go-to market team, the sales team, and naturally there's a need for this kind of product evangelist, product expert kind of role. And then realised Richard and myself were chatting and Richard was like, you know what, we need to invest more in developer relations. We need to be educating the developers and clearly building a link between potential community folks, prospects, customers, building that bridge between them and the product organisation, the product team, getting that feedback. And then, yeah, Richard, I think it was three years ago or something like that, Richard was like, "Do you want to lead it?"
(18:40):
And I was like, "Yeah, why not?" He knew I'd built teams before. He knew I'd led organisations before and I was doing that role and we were working with a few freelancers as well. And it was fantastic. I think made my first hire a month or so later. At that time hiring for dev roles was really hard. If you remember 2020, 2021, the market was kind of crazy. The whole pandemic situation was obviously very strange so the market was really hard. Finding good people and not spending all my budget was actually really hard so that was a key thing. And the team has just evolved over the years. The final structure I ended up with was we had two DAs, so Dave and Edidiong. Edidiong was based in Lagos in Nigeria, Dave's based over in Denver way in the US.
(19:29):
And we had a content writer so Erika, doing fantastic content writing and summarising podcasts. And we had Cindy who had managed the community. So was on Slack running a lot of the conference stuff. And that for me was a really nice structure. Because we had two main products. Roughly speaking, Dave looked after the API gateway edge stack space and Edidiong looked after telepresence and the dev feedback space. But we all knew everything and I was helping out a bit in between. And then Eric and Cindy were quite cross-functional in that they were mainly enabling the community and listening for feedback so they could do that for both products as well. And the size of the company, I think we grew to about 50, 60 people. A team of DAs about five strong felt like a good fit, 10% of the org.
(20:14):
And then we had our manager... sorry, our marketing colleagues were running a lot of growth experiments and we were supporting them. The product team got built out and we were giving feedback to them and helping them articulate their message out to the audience. That's roughly how we landed on the team structure. And one thing I would say the most important thing is whenever you build a team is making sure you're adding value to the organisation. All the time Richard, the founder, our co-founder, and my managers along the way, like Mark Trang, I'll give him a shout-out. We were always saying, what's the most important thing for the company at this given point?" And we talked a lot about funnels. Classic marketing funnel, you have awareness, consideration and decision. And we were like, what's the most important thing? Is it driving awareness more blog posts, more conferences?
(21:03):
Is it driving consideration? Perhaps more a how to use more tutorials or is it decision making? Maybe some sales enablement stuff for the sales folks. As DevRels we knew our tech space and could empathise with the users. Every week, month, quarter, and we were saying what's the most important thing for the business? And that drove a lot of our work. What's the current KPI? Is it page views? Is it conference people we're chatting to? We talk a lot about MQLs, marketing qualified leads, sales qualified leads. I know not every DevRel organisation likes to be that close to marketing. We did at Ambassador Labs, that was the way it worked because we were very much about making sure we were generating revenue right because we were an early stage company and the investors like to see revenue. And I like business. For me, even though I used to be a technical engineer or whatever, I was always interested in the business side because like what are we building stuff for? Whether it's code, whether it's teams, we're building it for a mission for the business.
(22:07):
I was always asking a lot, what's our current goal? And sometimes we had these MQL, SQL goals. We even worked on what's called pipeline generation. Actually getting DevRel influenced revenue into the stack. And personally, I enjoyed learning how the sales folks worked all that. And then seeing someone you chatted to maybe in the community go all the way through to buying your product and being a happy user. That's pretty cool seeing that. I always like a complete journey. Do you know what I mean? Because otherwise you're chatting to folks and you don't know, am I helping you? I don't know.
(22:37):
But if they're buying your product and they're giving you good feedback or even not good feedback sometimes it's still useful. That for me was really insightful. And then over the three years, I think, I led the team, we reiterated on what was the most important metric for the business at the time. Quite commonly it was awareness and then it moved to a bit of revenue and some other things. And then the team, I set the parameters and I would say the team are amazing. One really good example is we were looking to generate more awareness. I was chatting to Edidiong and she was like, "Hey, we could do a guest writer programme." Like And LogRocket and a few of the other folks have done that. And literally Edidiong, and I was like, "Sounds great."
(23:14):
She went away, came back with a plan, she was like, "Here's how I'd run it, here's the budget I need, what I'm thinking." I asked a few questions, we refined it a little bit and then she just ran with it. And I was like, rock on. That's the kind of people I like to lead. You know what I mean? I don't need to say do X, Y and Z. Edidiong was like, "I think this problem could be solved with this solution." And I was like, "Sounds interesting, tell me more?"
(23:36):
And I asked a bunch of questions and managed to get the budget for it. And Edidiong, if you look at the Ambassador Labs blog, still going strong now. Most weeks we have a guest writer contributing and that's great. As in they get to learn from Edidiong and myself on how to write articles. They get to share the knowledge of the community, the community wins as well. We get a bit of visibility. That was a good example of the leadership style I like. As in we've got this problem, "Hey, team, we've got these constraints, this budget, what do you think?" And then they go, "Oh, we could do it this way, this and this." I'm like, "Brilliant."
What’s your take on the current Kubernetes ecosystem? How have API gateways and service meshes developed?
Rohit (24:08):
Awesome. People come with a guest writing thing or Ambassador kind of programmes, which I did at Solo. So that also helps to get the user base and the kind of things which we want to get. You mentioned everything. It was nice, awesome guidance to the folks who want to build their team. And also we talked about various things around the DevRel world I realize. I guess only you must have spoken this in a few talks. Other than that, let's come to the cloud native. We have the cloud native was our focus today. It should be on the cloud native. Why we are going to DevRel every time. Every time I'm like this, whenever any developer advocate a role is coming here and speaking about. Last time also I guess I had Henrik from Dynatrace.
Daniel (25:03):
Oh, yeah. I see him at conferences all the time. He's good.
Rohit (25:04):
and David was there. It was really like, we are talking about the Cloud Native and when we are switching to the developer relations, we don't know. So that kind of a thing happens. But you have worked aggressively with the Kubernetes and stuff. What do you believe is beginners and everyone still in Kubernetes world, they want to directly get into the Kubernetes, they want to learn Kubernetes directly and go to the platform engineering kind of a thing. There are new terms coming anywhere. And also another thing is it is not... QCon previously was just about the Kubernetes and stuff, but now it is not like that. There is Wasm, there is service meshes and various things are there. What is your take on this?
Daniel (25:56):
Yes, it's a shameless plug. I did a podcast which is going to be published in about a week's time from when we're recording this for InfoQ. You've mentioned InfoQ several times, I love the InfoQ folks. Myself, I think it was Helen Beal, Abby Bangser, Steve Jan and Matt from InfoQ. We jumped on and went to depth on this. We've got an hour podcast if folks want to know more about this. And I've had a few mentoring calls over the last couple of weeks where people have asked, is it a good space to get into this platform engineering or what's the deal? Should I learn to code or should I learn to build infrastructure and all this kind of stuff? And my answer to all those things is yes. Do you know what I mean? Because even though you and I, we live and breathe this stuff and it's very tempting sometimes, I think, everyone's on Kubernetes. And the reality is it's a very small fraction of the industry that actually are on Kubernetes.
(26:42):
And even when it's depending on what survey you look at, there's a whole bunch of folks that are not even on cloud. Do you know what I mean? When I saw this, when I used to work in the Java space, Java is quite conservative, the space. I was chatting to someone the other day, they were still on Java eight, which is, I don't know, 10 years old or something. But in the financial world, they don't want to move because they were so risk averse. They were like, if I upgrade to Java 20 something now, 21, I might break something. And I'm like, I get it. So know that there is all levels of adoption out there. And what I say to folks I'm mentoring, I'm like, what do you want to get out of your career? Do you want to be super deep as a software engineer?
(27:23):
Do you want to be super deep as someone that's an infrastructure person, which is platform engineering at the moment. Though the one thing I would say is platform engineering is a lot more of a product focus than someone who's just building terraform or something. I think there's a certain skill set around platform engineering that you might want to look at. But the market's a little bit weird at the moment with the macroeconomic situations. I think that's a global situation. But what I'm saying to folks is invest in your career now and then when we inevitably pick up again, it might take a bit of time because that's the way the cycles work in the economic sort of space. It might take a bit of time, but you'll be perfectly positioned when people start going back to do more cloud stuff.
(28:03):
And of course AI is driving a lot of this. The old LLMs blowing up everywhere. And people are a bit overexcited at the moment, but there's going to be new systems built and they will be built in the cloud on these things. You can go wrong in my opinion by learning some of this stuff. And one thing I would say is where we're at now, you and I got into this when it was super emergent. There was no real documentation, not much on YouTube, but there's some fantastic stuff out there. Like the casting folks, the CVO folks, yourself, Rohit. There's just so much information and knowledge out there these days. You don't need to spend lots of money, it's more your time, in getting up to speed. Do you know what I mean? And I think what I say to folks is get the fundamentals down first in cloud and Kubernetes and things and then go deep on something.
(28:49):
Whether you're like... like you and I are in API gateway and service mesh space, that's a good bet. Do you know what I mean? People are always going to need to get traffic into their backend services, always going to need to rank stuff. And you look at companies like Ambassador Labs, Solos and iSurveillance, there's a lot of kong, take your pick, titrate. There's a lot of folks out there that are doing this work so that's where I placed my bets. I was like, I see this cloud native comms space being really interesting. But I see also other folks using things like Backstage, which is an internal developer portal or platform from Spotify. There's a lot of investment on these service catalogues and all these things. If front end stuff, you could become a backstage developer and that's the kind of bridge between nice UX front end, service catalogue to these backend platforms. So there's plenty of opportunity out there.
(29:39):
The cloud native space is becoming a bit more boring and I think that's a good thing because Java is totally boring too, a heads-up. As in but when Java... when I very first learned Java back in the early two thousands, it was super innovative. And I've seen that whole journey from super innovative, wow, and now Java's properly boring compared to even Go and other stuff, right, and also .NET. I'd say pick where you want to go roughly, invest that time going super deep. The cloud is a good bet. I think the foundations, like the certifications out there from Amazon, Google and Azure and also the CNCF certifications. Like my team, Edidiong, a few of my team at Ambassador Labs did those certifications, the CKA and CCAD. And I've done the Amazon certifications, I learned a bunch from that. If people are trying to get into the cloud, that can be a good way to get started too.
Rohit (30:28):
Actually certifications, certifications are not just about getting the piece of a paper, but if it's just training like CKA and security CKAD are a lot based on live real world kind of situations. That will help you to get into the hands on labs and class and stuff so you guys will learn a lot. That's definitely recommended. And Linux Foundation and CNCF is promoting it really nicely so try to get coupons and stuff and you can get a good discount.
Daniel (31:01):
That's it. Good advice.
Rohit (31:04):
Other than that, that is the one thing. Fundamentals should be clear. People somewhere focuses not on Linux and security and networking directly goes on the Kubernetes so that is not idle. But like everyone, any speaker comes here, they tells the same. Audience, I would like to say to audience, listen to these folks because they are the industry leaders. They have done this thing, they have gone through the trial and error for sure.
Daniel (31:34):
That's it, definitely. As I was speaking now, totally. I've made the mistakes, Rohit, learn from my mistakes.
Rohit (31:38):
That's why they have gone through mistakes and they're educating you for the same. Free education, everywhere it's available. We just need eager to learn or something.
Daniel (31:49):
That's it.
What is the future of software development? Is it all generative AI and LLMs?
Rohit (31:50):
And another thing is, what do you think in the coming future, what will the trending kind of a technology? Today's the GenAI and today's everywhere. I see any Cloud Native companies that also want to integrate the AI into their products so that is everywhere it is happening. But let's see, Kubernetes is trending, Kubernetes was trending and it was talking a big thing everywhere. And Kelsey, now Kelsey is not in Google and he has recently announced the retirement.
Daniel (32:31):
Surprised.
Rohit (32:31):
There are lot of things happening in the cloud native space. You are sleeping one day before and wake up another day and there is new thing launched. A similar thing, there are a lot of things. eBPF is there, Wasm is there and various things are there. Everything has a various schools. What do you think will be the future of the cloud native space? And we know nowadays there is a term called it's a cloud native 2.0, 3.0 kind of thing.
Daniel (33:02):
I've seen this with web 2.0 and 3.0, Rohit, really crazy. I think there's two paths emerging and I have seen this because I'm old enough to have seen this perhaps other domains within our space. And I think there's the super hipster space you alluded to. GenAI, low-code, no-code and it even put Wasm and those kind of things like write once run anywhere in that space. And if you like the innovative breaking new ground, not being too sure what you're doing and learning a bunch and having a big impact, that is totally where it's going. Do you know what I mean? I think we're only just... I think we're on the bit of a peak of hype with the GenAI stuff like ChatGPT blew our minds and then now we're actually realising, oh there's a few limitations.
(33:47):
It is somewhat of a random sentence generator or plausible sentence generator. It's not actually sentient as some people might be saying, but there's a lot of potential there. If you're into that kind of space, I think that... it's definitely... I see more things that we're automating now even, like alerting as an example or building out experiments. I see a lot of that being harnessed by the domain of AI. So no longer will I have to go through a loco tool or even coding some of these things. I think business people, in quotes, and I consider myself a business person, sometimes we'll just write something out or say something and the thing will happen. Like reroute 10% of traffic, do this new service I've created that does this experiment and it will just happen and it will give you comments on, oh this experiment's not performing, should I turn it off? I'm like, yes. I can totally see that being the future.
(34:38):
It's basically what we're doing now, automating a lot of things, that's DevOps, that's platform engineering, but automating it in a more human, understandable way so that even the folks that don't have programming backgrounds like us can still do a lot of things. And we saw that with low-code no-code, and I think that's a massive bump with the AI space. And if you're in the more engineering space, I'm with you, Wasm and eBPF are two very interesting technologies. I think Wasm for extensions to things like proxies and API gateways. We used to write Lua for NGINX back in the day. I see Wasm, pick Rust, pick Go, whatever you like. You compile it down to Wasm, it's going to be a really nice language for extensions to those kind of tools.
(35:18):
And I think eBPF is a bit closer to the kernel by definition. But what I mean there is, if you want to work on those low level things for me it's not really my jam. I'm fascinated by it, but it's not my skillset. I leave it to Liz Rice and Thomas Graff and all those folks that are doing amazing work in that space. And the Isovalent folks doing really cool stuff. And I know Sysdig, same deal. They're doing it from the security space. That is really interesting. And if your skillset is more kernel level, I totally would recommend getting involved in that kind of stuff. But then just to close out, that's the one kind of innovator path that's where I like earning my money, I like spending my time there. But a lot of people I chat to want a more stable thing, want it more well known.
(36:02):
And I think that's a lot of opportunity in the cloud space. Kubernetes, again, you and I love it, but the average developer's like, I don't care about Kubernetes. I want to just code, ship and run. I want to ship my thing and run it. And therefore I see, when I was at CubeCon in Amsterdam, a lot of DevOps engineers I was chatting to, a lot of people self-identified as DevOps. They were deliberately trying to hide Kubernetes from their engineers. They were like, we're hiding Kubernetes, we're hiding Kubernetes API, kubectl. We're just exposing a UI for our developers. There's a lot of opportunity there for people that want to... if you're getting into a classic programming space, you can be building these UIs like we talked about with Backstage and other things. And there's just a lot of underlying infrastructure stuff that it's more... it is kind of, I think, classic infrastructure engineering.
(36:49):
It is building the Terraform or the Pulumi or whatever you're using to create the foundations for these platforms. Do you know what I mean? I think that's a big space. The people in the Amazon, Azure, DigitalOcean, all those folks, they're building the kind of metal level and the services, the real core APIs. And I think there's a lot of companies that will call themselves platform... or teams in companies or will call themselves platform teams or engineering enablement teams as Sarah Wells calls it, which I like. They're taking some of these lower level primitives and bolting them together. And I think there's an even a higher team that is a bit more product focused, bit closer to developers, SRE-like maybe, I don't know, there's a lot of names flying around there. But there's just a lot of opportunity for ultimately helping the business deliver value. Do you know what I mean?
(37:36):
Whether you're writing the app code, you're helping people run these things in production or you're building the platform foundations, it's just so much opportunity there. I think the hardest part when I'm chatting to... focused on mentoring, the hardest part is picking a bit that makes sense. Do you know what I mean? A lot of people want to know all the things and I'm like, hey, just learning how to write Terraform stuff it's a good chunk of work. And thinking about how you treat a platform as a product, that's a good chunk of work there. You've got to learn about design thinking and UI and UX and then let alone all these things. So there's a lot of opportunity in that space. I did a presentation actually in Valencia last year in QCon, where I talked about from Kubernetes to past what's next.
(38:21):
I literally on my final slide I had, I think there's a lot of innovation going to happen around the backstage kind of integration type level. And not just the UI, it's the APIs and all these other of things. Because actually I saw a great kweek, great Tweet, sorry, from Kelsey Hightower. Kelsey's always doing amazing Tweets. I'm so jealous, I wish I could do his tweets. And he was really satirical. He was like, "It's really easy to get started in the cloud. Just choose 200 of these services from the CNCF landscape and you're good to go." Do you know what I mean?
(38:48):
And unfortunately that's the reality of the situation. We all joke and the CNCF are genuinely amazing, but where we've had this Cambrian explosion of innovation and services and all these things, and you and I have been part of that in our companies, now for the average developer, and I use that as a not rude way, for the average developer that's overwhelming. They don't want 200 options, 200 things. I just see that that is the next big evolution in the more safe, more boring side is making that stuff easy for the rest of us, not the Kubernetes innovators, the rest of us, making that stuff easy to actually use to ship your code and to deliver business value.
Thank you for joining me on the podcast!
Rohit (39:28):
Shipping the code is one of the major business from the long time. But when I hear from you and Kelsey and other folks, these are the really innovative, I think, I also somewhere think this will be one of the potential future for our cloud native space because not everyone can go and start using the services. There are big landscape, what all they can choose and go ahead. That's all for today. I want to disturb you. So it was a long talk and we had various things talked about and I know I will... if I continue you will talk more.
Daniel (40:11):
That's right.
Rohit (40:13):
But I don't want to take more of your time because it is really valuable. But you shared a lot of points. To summarise, you mentioned your journey and then how to be the efficient developer and build the teams and to develop advocacy. And how the collaborative company work and how the things are there. In the somewhere future when we connect again, we will also like to share with the audience what actually is this new stack in InfoQ and this companies what they actually do and what happens around that. That is one of the point we can take anytime. There are a lot of things we discussed and I would recommend audience, please check the things which we share today and it will help you to start your career in the beginner as a DevOps engineer, a platform engineer, whatever you want to be.
(41:09):
Because don't directly go to the trendiest things which are available now because it will be a long short problem for you. Make the fundamental scale first and then you can move ahead. Thanks for joining today and if you like this podcast and other podcast and stuff, do like, share and subscribe. I will give the links in the description for the Daniels and Daniel and his work and whatever he mentioned today, like the writer's programme and various things. That will help you to explore all the things. Thank you for joining guys and if you want to connect Daniel, if you want to ask him, he's available somewhere.
Daniel (41:55):
Everywhere.
Rohit (41:55):
It's not like he will not reply you just in a go, but he will reply for sure I believe. He is one of the humble available in our cloud native space. Thanks for joining and I hope Daniel also enjoyed our today's cloud native talk.
Daniel (42:14):
Thanks, always. Some good topics there so I appreciate the questions.
Want to know more about DevRel?
I hope this post has helped clarify the journey from DevRel individual contributor to management and/or to leadership.
Please comment below and let me know if you would like more content on the DevRel career path.
And don’t forget to subscribe! I’m aiming to share a post every two weeks or so.