There Is No Team Without Tea - Neville George On the Path from vSphere Admin to Platform Engineer

Episode 168 · 47:18 · SRT · archive.org · all Tanzu Talk

All right, folks, welcome back for another episode of Tanzu Talk. Today with me, I have Neville George. And the questions that I've got for Neville today, I'll let you introduce yourself a little bit here in a minute, are really around that journey from going from a vSphere admin background into whether you call it a DevOps engineer or a cloud engineer or a platform engineer. There's lots of different words out there floating around. But what does that look like? So I've got a bunch of questions. But first, let's just, Neville, please introduce yourself. Hi, Dormain. Thank you. And well, before I begin, I want to say I'm a big fan of, you know, the Tanzu podcast. And certainly you do a great job, as always, in bringing some of these conversations, which are critical for a lot of people to the Tanzu community. So thank you for that. And I'm super excited about this opportunity. I have one thing for you before we start, just to make it a little bit interesting. I will give you a phrase and, you know, I will tee it up for you. And, you know, when I tee it up for you, you would you would kind of respond by saying there is no team without tea. Okay. So remember that there is no team without tea. And I think, you know, as we go through the conversation, hopefully, you know, we will have a couple of places where I will tee it up for you and you're going to respond with. There's no team without tea. Okay, fantastic. I think we I think this is going to be great. Okay, so now this begs the question, Neville, are you a tea drinker? I switch between tea and coffee. So but there are situations where I exclusively go only for tea

and we call it tea time. So hopefully, you know, this will all blend in together well for us. Okay, okay. As I take up my sips of tea. You could, you could, you could, absolutely. So as for me, I am Neville. I'm a people leader at Comcast and I have worked for Comcast for about 14 years. I believe the end of May will mark my 14th year anniversary working for Comcast. I lead a team of super talented individuals who manage modern platforms such as Cloud Foundry and Kubernetes at Comcast. But before I became a people leader, I was an individual contributor for about 12 of my 14 years at Comcast. Every time I say 12 years, you know, it now feels like it's like a really long time. But I also keep telling me that, you know, I hear that young at heart is a new trend. So you know, I am very positive about that. I've heard 50 is the new 30. So I'm just, you know, I'll be transparent. I'm looking forward to that. But I also really like that that's what I have to look forward to. Yeah, yeah. Anything to keep us young, right? Also, I would say, you know, in the 14 years of my working at Comcast, I've played about seven to eight different roles. And it certainly kept things interesting on the way. Yes. Yeah. Having that kind of those shifts within an enterprise, keep things interesting. Yeah, 12, 14 years. I mean, that is, that's geologic timescale in technology. And so in that time, I'm sure you've seen a lot come and go, which is kind of a good setup for our conversation today. And so we'll start with, you know, let's, your background, you were once upon a time,

if I'm not mistaken, you were a vSphere admin. How did you get into that? Like, what kind of got you to that point? And how long were you in that mode? So I'll start with, so I mentioned eight roles, right? So I literally started off as an active directory specialist, though I was given the opportunity to do much, much more than that. And then, you know, I played a Microsoft lead in a couple of like, you know, responsive and proactive lead roles. I've certainly, you know, been an enterprise storage engineer, virtualization engineer, enterprise backup engineer, a platform engineer, and then now eventually, you know, a people leader. The longest stint in any of my eight roles has been as a VMware engineer for about like four years and as a platform engineer for five years. And it's funny, you know, since I started as a Windows admin, I still have a Windows laptop, though I also use, you know, an active Linux desktop that I heavily rely for many of the stuff that I do. One of my recent hires actually told me that, you know, when he heard me that, when he heard that I had a Windows laptop, he was about like, you know, not take the job. But they're also very forgiving since they understand, you know, now that I'm in a people manager role, you know, I need to create a lot of PowerPoint presentations, apparently, right. But, you know, how I got into the VMware role, I was a storage engineer. And essentially, you know, our organization was comprised of a larger umbrella of products such as virtualization, you know, storage, backups, automation, etc. And the biggest client of storage

at that time was our vSphere environments. And when virtualization was just catching fire at Comcast, it was a natural progression for me. And as I interacted more with storage and VMware, I started feeling that I could get used to this. At Comcast, during that same time, and it still is, right, like we talk about fungibility of resources. It was and still is a big thing at Comcast, having the knowledge and ability to put on multiple hats and contribute. And specifically for me, between storage and VMware, like appeal, like appeal very much to me. And that is where it all began. I did that for about like four years and loved it till Greg brought platforms to Comcast, right. And I'll name drop a few people, I really like to focus on, you know, people who have helped and who have made changes and people that I work with, you know, it's super important for me. Yeah, I mean, I think that, of course, looking at the skills and the training and the background, like sometimes you, you want to create this logical journey of an individual based on, well, they studied this, and then they got their first job doing this. But the reality is these, these twists and turns along the way of a career path are much more driven by the people. I'm just, you know, you're making me think of my own trajectory, um, leaving finance and going to my first job at a, at an IT vendor. Uh, it was because I knew the hiring manager and, you know, he was looking for someone who could write about technology. And I was like, you know, I'm, I don't want to end my career in finance. So, um, it had much more to do with who I knew than what I was actually doing or, or had been preparing myself

so much. So it'd make a great point there, but there's also something to be said that, you know, your, your point about going from storage to the, the VMware side, um, you know, that resonates in other ways. It makes sense because this reminds me of back in the day thinking about why did EMC buy VMware way, way back in, I think, 2004. And that, you know, I was working for the lead investment, uh, analyst at the time. And he would, he's, he kind of had always scratched his head a little bit about what, what was going on there. And then when V motion came out, but in order for V motion to work, you had to be connected to a San, um, suddenly the light bulb went off. It's like, Oh, now I get it. Now I get what this connection is between these two worlds. So it's interesting to see that come up again. Um, and, and also, right. Like I'm part of the Tanzu Vanguard's community and we have many, many, many, uh, technologists who have gone through similar situations in their lives over a period of time. They've switched different roles. They've put on multiple hats. They've, they've had to go through all of this, right? So I think they have a common story here that people, uh, love moving around and trying new things. Yeah, that makes sense. And, and thank you for bringing up the fact that you're part of the Tanzu vanguard. I, I failed to mention that at the beginning, but, um, yeah, that's absolutely a community for folks to take note of because it's, it's a lot of folks like many of our listeners who are working in and around the Tanzu ecosystem and community. Uh, but, uh, it's a special group that, that gets together regularly and, uh, and has really fun discussions and, and sort of interactions with the, the, the VMware Tanzu product team, um, and is willing to share out kind of a

lot of these lessons learned like you are today. So thank you. All right. I want to get to my next question, which is sort of, you know, one way I like to paint the picture of a contrast of, you know, some kind of transition is to think about like a day in the life. So you mentioned you, you, you were loving, uh, kind of the working in the VMware, uh, sphere and the vSphere world for four plus years. And then Greg came along and, and brought you over to the platform team and tell us a little bit about what was a day in the life like when you were on the, the vSphere side. And then how did that change? What does a day in the life look like for you now? Or if you kind of rewind a couple of years back to when you were at least an individual contributor on the platform team, what, what was a day in the life like then? How, how did things change? Sure. Certainly, you know, there are similarities and, and differences. Um, as a VMware engineer, I would, I would say, I like to split my days into, you know, slots and I, and I like to name them and then, you know, each of them have breaks in between. Uh, so let's, let's call the first one as, as dial time, right? So the dial time is essentially, you know, when you get into the office and you essentially start the day looking at the dials that show the health of your infrastructure, right? So if I am a VMware engineer, I look at, is everything functional? Do I have problems in my environment? Are there items that, um, indicate a capacity issue that is coming up? Right. And based on looking at all the dials or like what we call the metrics and dashboards, et cetera, we would, uh, spawn off different action items throughout the day or, you know, into the week. So that's like, you know, the, the, what I call the dial time,

right? So right after dial time comes like the break time, right? So during the break time, you are supposed to have tea with your team because there's no team without tea. Aha. Got it. Got it. I think, I think it's going to be great. That was the first test. Yes. Yes. Um, so the second portion of the day, uh, I call it the hustle and bustle time, right? This is where, you know, we are, we are working on, uh, satisfying customer requests. If we have projects, then are we delivering on the projects that we have committed to? Uh, we would follow up on, um, on all of them, making sure that they are on target, uh, a lot of team interactions, interactions with other, uh, teams, more specifically on the VMware side, you, you kind of like work with infrastructure teams, right? Maybe your data center operations, your, your vendors, et cetera. You know, that is where like all of that happened during what I call the hustle and bustle team. And that usually probably gets us to lunch and possibly, you know, I would say the, the, the 3 PM slump, right? But when you get to the 3 PM slump, you need to take a break again because, you know, it is time to have some tea with your team because there's no team without tea. Great. I think you're getting a hang of this. Uh, the last piece of it is what I call, um, introspection time, right now the hustle and bustle time and the introspection time kind of like, uh, blend a little bit, you know, together, right. You know, sometimes, you know, introspection on a daily basis, you know, can be a rough a little bit. Uh, but this is like, I would say the part of the day where, um, you know, you focus on improvements that you can make to your environment. What are the

things that are taking maybe the longest time for us to do the biggest pain points? Can we deliver them faster? Um, maybe even, are we adopting new technologies, right? Are we showcasing ourselves and the value that, you know, we do? So that is the introspection time. And I think, you know, it is very important that we spend some time of our, our week to understand, are we doing the right things to ensure that, you know, we can, we can keep up with the demand of what we are doing, right? I would say that is like the life as a VMware engineer. As, as, as I transitioned to the cloud platform engineer, I think there are a lot of similarities, things that, you know, I could easily adapt with, right? The dial time, for example, still 100% true. Yeah. If you remove like the infrastructure and just put platform, if you, if you put this on a boat and if you removed all the infrastructure and put platform, it would easily fit, right? And you should be good to go because this is like the basics for any engineer. You need to come in and you should be able to smell the smoke before you actually see the fire. It is crucial. It is something that every engineer does. And, and it's like, just like innate for all of them. So dial time, you know, holds good. I think introspection time is also 100% true. You have to be asking yourself, are we going fast? Are we automating stuff? Are we disrupting ourselves? And are we being prepared for shifts in the industry? What is the value that I provide? So I would say dial time and introspection time is, is 100%, you know, the same, except your focus is on a platform as opposed to the infrastructure. Yeah. So the, the metrics you're looking at in dial time are going to be different instead of looking

at maybe infrastructure metrics. Are you looking at, um, just the platform health metrics or are you also factoring in anything about the, the developer community that you're supporting? Yes. Yes. And I think this is where like, you know, I, I think the dials do look at platform and developer experience centric information. Right. Um, and, and that is where like the hustle and bustle time, you know, is where I want to kind of like focus where the main difference happens. Right. Okay. So, and a quick question for you, just to, to double click a little bit. I'm curious, what metrics do you look at for the developer experience that are kind of something you could, you, you, you could check on a daily basis in that dial time? Absolutely. Yes. Um, so, um, I, I, I, if you're an infrastructure admin, right, your calculation of a developer experience is can a person go to, you know, a portal or can they automatically get the resources that they need? Right. So there has to be something in the background that like constantly on a periodic basis goes and deploys a VM and says, yes, that was completed. Right. So I know that I have smoke tests, you know, on a constant periodic basis. And if suddenly, if it fails, I know that anybody who's going to go to the site may experience a failure, right? On the cloud platform side, it is exactly the same, except people are deploying applications to your platform. So you may want to create some kind of periodic process that deploys an app as an example into your environment and sees if it actually deployed successfully, is the URL available, right? That is a simple example, but there are many things that, you know, we can do on the cloud platform side. It may be related to, is there a service instance that a person can, like a DevOps team can get, right? Are we running out of

IPs, you know, when we provision on demand instances? A whole slew of things, but the idea is the same. We want to make sure, like, people who are consuming our products can get what we say they can get, right? And being more proactive than reactive actually helps. Okay. That makes sense. All right. So let's come back to it. Tell us, tell us how the hustle and bustle time has changed. Yep. As a VMware admin, right? If it's not a CPU memory and a storage issue, essentially when some, some, let's say an application developer comes to you and says, I have a problem deploying Java on my operating system. I, myself, right? And, and as an, as a VMware admin, you know, if it's not related to CPU memory or storage, it's like usually, yeah, it's, it's actually your problem now. Uh, and, and it's not my problem. Uh, but as a cloud platform engineer, I think, you know, it's a constantly evolving technology and we need to work more closely with the DevOps teams than, you know, if you were a VMware engineer, right? That's like one big, um, difference that, you know, I've seen, uh, also when people use the platform, there are much more, uh, things that, you know, we will have to make sure, um, that DevOps teams are doing, right? Are they optimally using the platform? Are they distributing their application, uh, to multiple sites to be more resilient? Are they following, you know, the, the 12 factor authentication things, right? Very different. Are they having proper data flows? Are they having proper log flows? I think this is where the biggest difference comes, uh, in the VMware world, I think the interaction with the

DevOps teams on their day-to-day work is actually a lot less, right? You, you give them, you know, the required resources and then, you know, they do the runtime, they do the install, they do the management, they do the security, all of that piece. Uh, but on the cloud platform side, it's a shared responsibility, I would say. And in terms of, um, I kind of like summarize it like if you are a VMware admin, I think you spend 80% of your time focusing on infrastructure and maybe 20% of your time with your customers, right? As in like DevOps teams, as a platform engineer, as a platform admin or an engineer, it's exactly the opposite. 80% of your time you spend with DevOps teams and your customers. And I think infrastructure is just, you know, 20% of the time. Um, I, and I think that is the biggest crux, you know, for me, I find like I, I am more close to the DevOps teams and I can actually see the value like much more directly. Um, I'll give you an example, right? Uh, when my kid asks me, uh, what do you do for work, uh, as a VMware admin, you know, I would, I would talk about, well, I have to set up all this infrastructure, et cetera. And, um, you know, I, I have to do a whole bunch of things, which again, you know, it's not really easy for, um, kids to understand, right? But as a cloud platform engineer, like when my kid asks me, I can actually tell you, I can actually show them examples. Like when we pick up, you know, my, my Comcast remote and, and, um, you know, pull something up and I say something on the speaker, right? Like, you know, we have, uh, we have, uh, voice remote. Right. Do it. Um, those calls actually run through my platform, right? It's something that they can see and they can feel. I can take my application. I can take my Xfinity account app and I say, well, if I type something here, it's going to respond with AI and,

and all of these calls are going through a platform that your daddy manages. It's very easy when you can actually show some of that. So I feel like I can see the value much more closely than, you know, when I was a VMware admin. Interesting. Okay. Yeah. I think, um, that, that sounds like it's more satisfying, but I don't, I don't want to assume or ascribe that. Uh, although I suppose I just did. I love it. I love it. Cause I, you know, when I, when I talk to even my team or when I find that, like, Hey, we have a new, uh, DevOps team who's using our cloud platform. Uh, and, you know, we, we asked them like, what do you do on the platform? Uh, and, you know, we, we had, you know, a few of our, our, uh, teams would come and say, well, Hey, this is related to, you know, uh, knowing the location or, or in case there is, you know, an emergency, we want to know stuff. And that is like such an eye opener. One, I'd not know there was a team that would actually do this. And now they're actually using our platform and I can see the benefit. Right. Um, that is super satisfying for me. And I, and I highly encourage, you know, if you are a, if you're a cloud engineer, you know, talk to your customers and know what they're doing and it makes your life so much easy to just explain and, and, uh, you know, be so happy about, you know, being part of like that contribution to the company. Would it be, would it be going too far to say that you should, um, have tea with your developers? Oh yes. The other piece that is still true is the tea time with your team because there's no team without tea. That is correct. And that along with the dial time and the introspection time still say, stay the same. Indeed. Okay. Um, all right. So that was kind of, that was really

helpful to sort of think about how the day has changed, um, beyond just like, okay, here's, here's the routines and the rituals and some of the work. If you think about what are some of the things that have from your, from your vSphere and VMware admin days, what are the things that you've brought with you, whether there it's knowledge or skills or relationships, what sort of served you really well, not just then, but into this new role as a platform engineer? Uh, a lot of things for sure, you know, have helped. Um, and as much as, you know, there are two different titles, um, you just go back to, you know, I, I look at it as basics. If you have done it in one place, you will do it the same way, you know, in the other place as well. I can go through a few things just to give you a context of what are the things that I did as a VMware admin that still holds very much true when, when I'm like, you know, a cloud platform, um, engineer, right? Okay. Metrics and dashboard, right? If you created it for VMware, platforms are no different. The metrics that you have collected may be different, but the idea is the same. We just spoke about it. You need to know how well you are actually doing. If there is a problem, you need to know where it is 90% of the time. If you're going to be woken up in the middle of the night, you will just need to make sure you are looking at the right stuff. Right. And I say 90% because, you know, the 10% is always, um, like the ghost in the system, right? And you, and you will find it. And then you will be like, ah, this is another dashboard, you know, that I have to create. It is another metric that I have to be aware of, but still that 10%, you know, remains because it is a discovery phase. Um, but 90% of the

time you have the data, you will look at the data. If you did it in VMware, platforms are no different. The metrics are different. They're the same. Yeah. Okay. That makes sense. Automation skills. If you have had automation skills, it don't matter whether it was like bash or Python, go, whatever it's useful. I don't think, you know, we will get into the merits of one language over the other. Um, as long as it makes your life easy. And if you have done automation, it is going to serve you well as the platform engineer. If you have used Ansible, you can adapt coming into the platform side because I think the mechanics are the same. The tooling might be different, but the mechanics are exactly the same. If you have used a CI CD tool like GoCD or Jenkins, it's 100% transferable to platforms. That is how, um, you know, developers work. It makes your life easy. It's much more relatable when, when you know some of these things. Okay. And then, oh, sorry, go ahead. No, go ahead. Well, you know, I, that jumps sort of to my next question, but it sounds like there's still more that, that kind of carries over. Absolutely. And, and I, I think there are a few things, right? Like, so it's very easy to look at the two titles and say they're completely separate. So we just spoke about like, you know, metrics and dashboard and the automation skills, um, configuration management, right? If you use GitHub, Bitpocket, like they, they, they're all super handy skills. As a matter of fact, this is very much, you know, useful because these are the tools that DevOps teams are using. And the more, you know, you are familiar with them, the more confident you are working with them and, and, and providing recommendations. Yeah. I mean, just to, to poke at the configuration, uh, management question, it also seems like, I mean, regardless of the specific

tools, you mentioned a couple, but almost just like, I would imagine the principles of configuration management and, and, and sort of how you might track that separately from, um, other things, like, does that, is that also kind of applicable? Uh, yes, yes. And, and, you know, the idea is to make sure that, um, if you are on VMware, you know, you want to make sure you're applying a consistent profile to all your hosts. You have all the, all the configurations, you know, recorded in some fashion. If you're using VROPS orchestrator, um, you know, all of those things, you manage configuration so that you ensure consistency in the environment. The same idea on the platform and whether you're deploying an application, whether you're managing a platform, you want to make sure things are consistent, right? Whether you use like the mechanics, you know, and the tools may be different, but you know, the idea is exactly the same. So you can easily put, you know, like some of those things that you have done with the VMware side, you know, into the platform side. I think, I think learning itself is, is, is another, uh, big skill, right? And again, I don't want to focus on like the tools. It's just, um, innate things that you do because you are an admin of something and it, and it's your platforms, your baby. It's, it's your, uh, least your environment, right? Um, there is always something new to learn in VMware. They have new products, new features. It's a constant process of learning to keep up with the latest things. Um, it, it becomes like, if you've done this over a period of time, you do it just like you wake up and brush your teeth. It's as simple as that. On the platform side, it is exactly the same. What you learn may be different, but wanting to know, you know, having that thirst is, is super useful. Um, and not to forget

the last piece that I have here is like people connections, right? This is the most crucial of skills that has served me, uh, across, you know, both the, the VMware side, as well as the platform side. In our day to day, I bet like most of our work gets done, you know, faster, not because of, you know, processes being efficient or automated or, or the fact that there is no red tape, but it, but it is because of the folks we talk to, you know, folks, we collaborate the folks where we help each other out, scratch each other's backs, um, put ourselves in someone else's shoes, being patient, listening, et cetera. You know, this will absolutely serve you well because now you are going to be working with a larger group of people, possibly, you know, spanning different countries. And, and it's very, very important to keep building those bridges. You know, when you, when you transition from a VMware admin into a cloud platform engineer. Yeah. That's, that's a, you know, there was something you said in there, like, you know, part of me is like, well, yes, of course the people connections, but you said something about, you know, things don't go faster because of some process improvement that goes faster because of, you know, just collaborating with people. And it makes me think about folks who like the, the sort of the big consultant sort of led process improvement engagement. That's kind of going through and looking into some extent, like, sure, it's good to sort of have a high level understanding of like, what is our process? Maybe there are some things broken, but I think there's also a risk, which you're, you're bringing to light with what you've described. There's also a risk of blaming the process and not then being willing to do the work. Uh, so, you know, sort of saying, ah, the process is broken. Um, but not then saying like, well, let me just pick up the phone and call that person. Let me set up some time to understand

what they're trying to do, uh, so that we can kind of adjust how we're coming at this. And at the end of the day, that's actually how processes evolve. It's like, you can, you can bring in the big, expensive consultant or an individual can just take it upon themselves to reach out, reach across the aisle, if you will, and try to understand what someone else is dealing with. And so how can they work better together? Um, that that's a, that's a really great point. Um, that's just, you know, I think for everybody to take with them. Absolutely. There's nothing better than picking up the phone or having a call with somebody on Slack or, or whatever your mechanism might be. It solves it, the tones translate, you know, much better than an email or like an IM, right? Mm hmm. So, um, now let's kind of shift. This is the other side of that question, which is around what did you have to learn to become a cloud platform engineer? I mean, it's, you know, I think it was great that you called out just the process of learning and the habit and mindset of learning is something that you can carry from one, uh, one sort of role to the next. But what are those topics you, you touched on a number of specific say technologies, whether it's GitHub, Bitbucket, you know, CICD tooling. But what are the things that when you think about your own journey, what did you have to learn? Uh, what new skills, uh, knowledge did you have to pick up in your new role? Yeah, I, I became a cloud found cloud platform engineer because of cloud foundry. So I had to like learn cloud foundry, which itself is a big ecosystem and you know, how everything works within that piece, uh, closely related to cloud foundry is Bosch, uh, did a lot of that, uh, a bigger learning curve, uh, Docker, Kubernetes, uh, absolutely troubleshooting and advanced configurations of

Linux. Very important. Uh, I think, I think a lot of open source tooling, uh, has, has really helped me. Um, influx, DBs, uh, Prometheus, Grafana, Telegraph, HA proxies, um, JQ. I love JQ. Uh, I, I think I'm an expert at it every time. Um, but then when I see Sergei writing a JQ one-liner, I'm blown, blown off, right? Like I, it's like, what, what have you written here? I have to like go and figure that out. Um, certainly, uh, public cloud, uh, cause you want to have your platforms portable across, you know, different clouds. So, uh, AWS, uh, latest, uh, movement is towards Azure. Um, and also that as my friend, like James says, you know, there are many ways to learn all of this and everyone learns very differently. I have learned all of these by doing, you know, watching videos, reading, et cetera. Um, and I, I mentioned this early on, you know, a lot of vanguards who have gone through very similar paths of progression. And as much as, you know, I, I rattled off, you know, a whole bunch of things, uh, I think it's impossible, impossible to be fully proficient and an expert in all of these technologies. It's just a continuous learning process. Uh, definitely need to need, need to make sure, you know, there's a lot more patience and a lot more empathy, I would say, um, very important to put yourself in, uh, other shoes, uh, as an individual, there are things that I learned, you know, that we all need help along the way. Yeah. There are many, many times when, you know, DevOps teams have helped me learn something new, uh, see things, you know, in a different light when I was wrong. And my teammates, you know, certainly, you know, have paired with me during days and nights, you know, when I was new,

um, my leadership, uh, team, you know, for sure have allowed me, you know, a lot of bandwidth. Uh, I remember I started learning AWS, uh, and I had like execute a project and it took me six weeks. Um, and, and, and I remember going at every sprint and saying, I'm still working on it. And I also wondered why they hadn't fired me yet. Um, so certainly, you know, during those times, there were folks who had reached out to me and asked me, Hey, like, do you need some help? Uh, can we, you know, have a session together, you know, very important. And, um, they've given me positive feedback, constructive criticism when needed. Uh, and, and, and especially I would say, you know, my, my leaders have been, um, pushing me, you know, to avoid being satisfied with just average. Right. Um, so this is, this is, uh, you know, part of the learning process for everybody is that it's not an individual thing, right? It is a collection of, um, how your teammates, your managers, your leadership and your company as well. Like, you know, Comcast as a company encourages all of us to pursue things that interest us. Right. Even if it may be outside your organization, you have the bandwidth to go and be part of another team for six months, be part of projects for other teams. If you like to switch within the organization, there are a lot of things that everybody has to do. And, and all of these things definitely, you know, help. Yeah. I, you know, and it's, I think this is really valuable for a lot of folks out there who are, you know, vSphere admins and, and VMware infrastructure admins today and whether they, they currently aspire to working with, um, uh, sort of some of these other ecosystems of platform technologies, or these things are kind of coming at them. Um, anyways,

with things like Kubernetes now getting baked into vSphere seven, um, you know, powered by, by TKG tongue, Tansu Kubernetes grid, you know, it's going to be a journey. So I think, you know, what you've shared today has been really, um, I think very helpful. I wasn't exactly sure what it was going to, what you were going to say in terms of how big of a leap, but I really like all all the things that have connected you through the work that you've done before as a VMware infrastructure admin into being a, a, a platform engineer. And that learning culture seems to be a really big, important part of that. I have one more question for you, which is that, you know, now you're five plus years in on the platform team, you're managing a team. Um, but if you were to go back and make that transition again, would you do anything differently? And what would that be? Absolutely. Um, there are like, if you are a VMware admin, right? I would say you have already mastered a very complex system that is used by millions of companies around the world. It connects to various system routers, networking, hardware, you name it. You've got technology, right? And you understand technology, technology comes easy for you and, and cloud form platforms is just another technology, right? Personally, for me, in retrospective, uh, I think back to when I started up, started my career off, uh, I wanted to learn everything, right? I have some engineer ones on my team today and I can see that curiosity to learn. And as I have switched many positions, you would think that, you know, change is normal for me. Um, and I've seen change and it's not normal. It's uneasy, but you have to go back

and reflect on similar situations and know that you have like a support system. You're, uh, I like to call it the work family that you can rely on to get you there. Uh, for me, when I made the transition, uh, from VMware to cloud platform engineer, it was difficult. And I've always thought about this and I think it's because it chose me and I did not choose it. Like I knew that I wanted to do all the other stuff that I transitioned to, but cloud platforms just showed up and you know, it was like, okay, you're here. Right. Um, I, I have a story where I distinctly remember, um, I was adapting, you know, very slowly, uh, or I would say slower than usual, uh, to becoming a platform engineer. And we had only like three platform engineers, literally Tim, Sergei, and myself. And one day, you know, Tim and Sergei were off and I had to like be in the driver's seat during a huge outage. Um, and as I managed, I just managed to eek through the outage and, and have band-aid solutions. Right. And that was an eye opener for me and I knew I needed help. Right. So I would say that the biggest takeaway for me would be, um, leaning in, right. It's, it's difficult, it's uneasy, but you need to talk to your, you know, teammates, um, make sure you talk to management because, you know, we're all humans and we all need the help, the training, whatever is required to learn, you know, to get ourselves, you know, faster into, uh, get more easily adapted. I would say not faster, uh, but just knowing that you have, you're given the benefit, you have the backing of your leadership, I think is super helpful. And I would say that is one thing that I would lean and go going from like a V VMware admin, you know, into a cloud platform engineer. But I also think now that I've worked in this environment for about like five years, I think it's, I also see one of the things

that I would have done as a vSphere admin differently, right? Like based on like all these learnings, I, I could have done this there, uh, or things that, you know, I, I kind of reflect on, um, you know, some of the things that I really love about what we do on the cloud, cloud platform side is that transparency, right? Like everything, all the metrics that we use to make decisions on the platform are available for our customers, right? I, I really think we could use, at least during my time, you know, we could have used some of that transparency, you know, in, uh, management of our VMware infrastructure, um, establishing trust, the way we communicate with our DevOps teams are really different when you come to the cloud, cloud platform side that I think, you know, we can absolutely, anybody who's done this before can look at it and say, yes, we can do that on the VMware side as well. So I've, I've kind of like walked both sides of the aisle and I can see things I would have done differently, you know, uh, fight to swap either way. Yeah. That's interesting to think, um, especially as you know, it, it might be too early to say, but are these, uh, are these roles going to start to blend and merge more? And, uh, in your case, it kind of took, there had to be a separate platform team, um, and you were brought over into it. It chose you, as you said. Um, and that kind of made this sort of hard, hard transition, but you know, maybe as the technologies become more broadly embedded and the practices, uh, start to just become better understood to your point, maybe there's things where the, the VMware, um, infrastructure teams can start to evolve towards that, that platform cloud engineer,

uh, operating model, uh, without really changing teams. And that just sort of becomes part of their job. So it's, you know, I'm not going to put, you know, hard dollars against that. Cause it's, it's a bit speculative, but I would, I would put some money on it. Uh, if I, I would absolutely put some money on it. How many pounds of tea would you put against that? Uh, I, well, I, I cannot go out and have tea with my team. So I would say not anything, not, I would not put any kind of tea on it, but you know, technologies are merging, right? And, and I think the delineation of infrastructure and platforms, you know, are, are, is a certainly evolving thing. And, uh, you know, with certainly, you know, some of the Tanzu, uh, grid VMware, pivotal merger, et cetera, you know, you can, you can see that happening. And, you know, the most important thing, you know, if I had to tell somebody who was in either boat is to know that everybody has apprehension, right? Like everybody, you know, is fearful of change. Um, even for me who has seen a lot of it, it is difficult, right? But always trust that, you know, uh, everybody's there to help. Um, you know, you have done this for a long time. This is just another new technology that you are going to have as part of your skillset. You know, it's, uh, it's something that we all will have to work together. All right. Well, Neville, this has been fantastic. I think it should be required listening for, I mean, I'm biased of course, but I think it should be required listening for, for every, uh, vSphere admin out there. Um, and so I, I thank you for taking the time and sharing your experience and wisdom, uh, with the, the Tanzu talk community. Fantastic. Thank you. The pleasure is all mine, Dormain, and thanks for being a sport. Have some tea. Oh, I will do just that. All right. Have a great one.

Tanzu Talk · 🍕 Get more pizza.