This week, host Conor Bronsdon welcomes back Kelly Vaughn, Director of Engineering at Spot AI, to talk about building influence as an engineering leader. Kelly shares insights on the importance of leadership skills for both individual contributor and managerial roles and outlines her three pillars of trust, communication, and empowerment.
Conor and Kelly discuss strategies for staying technically fresh despite moving up in management, exploring the balance between staying close to product development and avoiding micromanagement. Lastly, they touch on the potential of AR/VR technology, with a focus on the business implications of Apple's Vision Pro and the future of immersive experiences.
Episode Highlights:
- 01:09 How should engineering leaders think about building influence?
- 03:53 The impact of changing roles or companies on your performance
- 08:07 Why you lose important context when making assumptions
- 09:32 How ICs can help manage their team
- 10:49 Key ways to build influence and trust
- 16:00 How important is trust when giving or recieving feedback?
- 22:27 How do leaders stay close to their product as their org grows?
- 28:58 Our thoughts on Apple Vision Pro and AR VR in general
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: 0:52
Hey everyone. Welcome back to Dev Interrupted. I'm Conor Bronsdon and today I'm delighted to be joined once again by Kelly Vaughn, Director of Engineering at Spot. ai. Kelly and I promise not to talk too much college sports here, which we were doing right before this call. Um, and I think we have some exciting topics to dive into since, uh, Kelly, I know you've recently kicked off an engineering leadership course on building influence for engineers. Uh, congratulations.
Kelly Vaughn: 1:15
Thank you. Yeah, this has been many months in the making and I finally found the time to finish it and I just ran the first cohort of the course and based on the feedback I received, it's a really, really good course and I could not be happier with how everything went. Outside of things taking slightly longer than I expected to and I added an additional 30 minutes to each day for extra time, I would not, like the content, nailed it. So happy.
Conor Bronsdon: 1:43
Obviously we can't get all the insights from this course in this kind of conversation, but building influence is such an important topic and not something that everyone thinks about naturally. I know you took these two perspectives, one of the individual engineer, how to approach this, and one of the engineering manager, how to approach this. What's the overview for how both these categories should be thinking about building influence within their organizations and externally?
Kelly Vaughn: 2:09
Yeah, that's a good question. So regardless of whether you hold a managerial role or not in an organization, influence plays out the same way. Uh, I believe there are three pillars to building influence, and those are trust, communication, and empowerment. Now, how you take these pillars and really have them play out in your day to day is going to vary based on your role. And it was really cool having such a mixed cohort of experience for the first, the first, the first cohort that I ran for my course. It was about 50 50 ICs, like senior ICs. And you can see how they're all working towards that same idea of building influence, but in different ways. So, you know, let's take, for example, the first day we talked about building or identifying gaps in your team and helping to fill those gaps. What we are talking about at the beginning is how to basically categorize each of your team members as a high performer, medium performer, or low performer, and then what type of high performer or low performer they are, because a high performer is going to need a different challenge than a low performer. They're going to need different support than a low performer, and the risks that run from each of these types of team members is going to be different as well. So, as an engineering manager, you can use this information to help coach and guide your team, whereas with lower performers, of course, you might have to manage them out or choose to part ways with them. What you're going to be doing there is different as a manager versus like a senior IC or just an IC in general. And if you are that individual contributor, if you're identifying gaps on your team, just based on, you know, how you work with your peers, you can also mentor them as well and even identify where their strengths lie and where you identify yourself in this categorization and how you can learn from your peers too. Part of the relationship building is knowing who you're talking to and knowing how you two can work together. So whether you're a manager or you're an individual contributor, this plays out the same way.
Conor Bronsdon: 4:12
And this kind of mapping of the team, is a key skill because it identifies opportunities for growth within your team and ways for you to work better with your team as an IC or manager, to fill those gaps. What is the mindset or approach that each kind of group of people should be taking as they think through this process?
Kelly Vaughn: 4:33
The number one thing you need to remember when you're doing some sort of identification and exercise is people move around in these categories. So, somebody who is currently a high performer, who moves into a new role. Let's say they move from a mid level to a senior IC and they're taking on more challenge, or you're moving from IC to manager especially. You're no longer going to be that high performer. Naturally, because you're still learning the ropes. If you join a new company, you're not going to join a company immediately as a high performer. You need to figure out the business context. You need to understand the history of the company and what you're doing in order to do your best work. Can you quickly become a high performer? Absolutely. I think the other flip side of this is also, we all have things going on in our personal lives. You know, let's say you're moving, let's say, uh, you have a baby, let's say, you know, you're going through some kind of traumatic event in your life. You're not going to be continuing to operate as a high performer during that time. So you might move down to be like, okay, I just want to focus on getting my work done, show up to work, do my job, leave at the end of the day, set it aside. That's all I had the energy and time for, and that is absolutely acceptable, but you're not going to be seen as necessarily as a high performer during this time. And there's nothing, again, there's nothing wrong with that. And so it's important as you're identifying people on your team, think not just their day to day, how they're actually doing their work, but what else is going on in their lives? You know, what else is happening in their day to day that could be impacting the work that they're doing? You know, when you're working with engineers, it's not just about the code that they're writing and the PRs that they're reviewing and the communication they're having with their team. We are obviously all more than what shows up on Slack or Teams.
Conor Bronsdon: 6:16
I've definitely experienced this as a leader where, you know, early in my career as a manager, I had a high performer on my team who came in and frankly, on board really quickly. The first nine, 12 months they were crushing it. And then year two, uh, you know, there's some company strategy shifts and I could see them starting to struggle with it, but they never really, you know, kick back into gear. And I had a one on one with them where I asked them just very frankly, like, Hey, what's going on? Like it. It doesn't seem like you're feeling as aligned with the strategy, you know, is that the challenge? What's going on here? And it turned out they were having a personal life crisis and hadn't really felt they had the opportunity to speak up about it. And I think that kind of thing, we underestimate how much impact that is. A lot of us, I think, tend to focus on like on the work and say, Hey, this person isn't performing like they used to a month or two ago or last year. And we forget that life context sometimes.
Kelly Vaughn: 7:14
Absolutely. Although you do make a good point on shifting company strategy, and I think this is another really important thing. With engineers, I mean, with everybody in a career in any company, we all are drawn towards different types of companies. You know, I have always been in the startup space. When I worked at CDC, I hated it. It was too big. I was, you know, I didn't really feel like I was adding that much value, whereas in a smaller company, I know the value I deliver. My husband, on the other hand, he worked at a start a small startup for a while and he said never again. Like, I need to be at like hundreds, at least hundreds of users at the company or, you know, or greater. I say users because he's in IT and so everyone's a user to him. There's that difference. And as you're, let's say you're at a startup, And you're growing from zero to 10, 10 to a hundred, a hundred to a thousand. Your strategy is going to change over time. It has to, you know, what got us here today is not going to take us to the next step, but understand that your team may thrive in a smaller ship it will figure it out environment versus, Hey, we now have hundreds of customers, a thousand customers, and we can no longer take that risk that we could take before on figuring it out as we go. We need to be more, we need to slow down. And so people don't want to slow down. And that's when you often start to see that high performer shift to a medium performer, or even a low performer who you expect to be doing a better job. And that's when you have that check in like you have with this individual here. And you're just like, hey, what's going on? Sometimes it is a personal thing. Sometimes they're just not aligned with the company anymore. And that is absolutely fine. You know, we often say, turning a company is awful and like people are leaving, obviously something is wrong, but people are always going to be naturally leaving and joining different companies. And you know, we always hear on the leadership side of things, like you don't want to hold back your best engineer because you don't want to lose them. If this job is no longer suiting them, help them move on so they can thrive in their career again. The last thing you want is an engineer who's just not happy doing their work.
Conor Bronsdon: 9:12
Yeah. Cause their performance is going to be where you need it to be. There's going to be tension that that creates. And I think especially in startups, there's a kind of tour of duty sometimes where someone will have two years where they're really performing for you. And then. You raise your Series C and you're hitting that next level of scale and suddenly there's a lot more people on the team and maybe it's not the right fit anymore, or maybe the company direction shifts to your point. And it's really easy for us to kind of make these assumptions where we go around like, ah, this person isn't delivering what I need from them. You know, it's probably because this changed, and we have to build enough trust with them and have these frank conversations to say, hey, what's going on? Because. If we tend to assume we're often missing context, whether it's personal or their perspective on what's happening within the company, that may be crucial understanding how to ensure they're getting the most value out of the role and that we're getting the most value out of them as a teammate. But that's really a manager perspective. How should an individual engineer be thinking about these kind of growth opportunities? Or do you think they should be taking this influential role themselves and saying, Hey, let me go and be proactively meeting with team members who I think are struggling?
Kelly Vaughn: 10:18
When you're an IC and you're working with these team members, you're going to be much closer than your manager is to the day to day. Especially if your manager is managing a larger team. You know, I have ten direct reports across two teams. With that, I'm not seeing every single thing that's happening, but if this engineer and this engineer are working together, I know that they're going to be more in tune with the highs and lows of what's actually happening, and I'm not going to be able to catch everything. And so this could be an opportunity, for especially if you've built trust within your team and one of your engineers comes to you and says, like, Hey, I had a conversation with so and so I'm a little concerned about their future and how they're feeling at the company. If you haven't seen it, but they have, you can still flag it with your manager and the manager can talk to them because if you identify somebody as a flight risk, you know, what do you, what, what are you hoping to do there? You know, do you want to keep them? Usually the answer is yes. Uh, especially if there is an opportunity for them to get to be happy at the organization. And if they're not, then obviously you can help them out of the company. But it's, it's all about building that trust from the very beginning.
Conor Bronsdon: 11:22
So what are some of the baseline things that you recommend people do as they're looking to both build influence and build trust so they can leverage that influence better?
Kelly Vaughn: 11:31
Be authentic and meet regularly. Honestly, that's really what it comes down to. We all talk about one on ones, and I have actually on day one as well, I talk about this in my, in my course as well, you know. One of the biggest mistakes that I see people make with one on ones is that they treat it as project updates, and there's so much more to one on ones that you can be talking about, and it's one of the best times for you to be building trust and building that relationship with your direct reports and it's same as an IC, you know, you're talking to these engineers regularly. Go ahead and put 30 minutes on the calendar. Just like talk about whatever that does have anything to do with your work and you know, what you're actually coding or whatever it happens to be. Meeting regularly, of course, is one part of it. Being authentic is the other part of it. You know, people can always tell when you're going through the motions of pretending you care. You're like, quote unquote, saying the right things, but the actions don't follow the words. And if you're not bringing that level of authenticity to it, people are going to see right through that. It is very slow to build trust with somebody, and it's very fast to break that trust with somebody.
Conor Bronsdon: 12:37
I know in one of the first episodes we did together, we talked a lot about one on ones, and I think we should revisit that topic in depth sometime. Yeah. Because it's I think really shifted, uh, over the last couple of years, people have started to think more in depth about them, uh, particularly with some of the challenges we're seeing within our tech where layoffs are happening. People are feeling all the stress and this pressure. I'd love to revisit that with you sometime in depth. Cause I, I think to your point, it's, it's a really crucial piece of, of how we approach teams, uh, in the modern tech environment.
Kelly Vaughn: 13:08
Yeah, and it's also why I strongly encourage people not to cancel one on ones unless they absolutely have to, like, one of you is out of office or you're taking vacation for the week, but it's such a crucial time for your team to have that time one on one with you.
Conor Bronsdon: 13:21
Do you think that also applies to peer one on ones? So, you know, for example, I keep a certain like every two week one on ones with some of my, you know, peers at my level. Um, how do you think about canceling those or shifting those since they're kind of less essential to your cohort team, but very crucial to your, I mean, frankly, influence within the company and kind of peer interactions.
Kelly Vaughn: 13:43
I still strongly encourage you to not cancel one on ones unless you, unless you really need to, like, I will shift one on ones around all the time if I need to, um, you know, I have regular weekly one on ones with the other engineering managers at our company. I have regular one on ones with all the product managers, even if they're not like quote unquote, my product manager for my team, um, because. The work we're doing is cross functional. The work we're doing is always going to be touching somebody else's work. And it's important to be able to stay in sync. And this also goes for, for some people who I'm not actually actively working with on the day to day, but like the hardware team, for example, I still meet regularly, you know, every other week with, with somebody on that team as well, because I just think it's important to know one of the best things as you're building influence and you're building trust within an organization is knowing what's going on. Yeah. And the best way you can do that is just talk to people.
Conor Bronsdon: 14:31
Yeah, and I think there's, like, we really rely on this construction of how our kind of social strata within an organization works, this social circuitry, as Gene Kim would call it. And we have this instinct of like, oh, well, you know, I communicate my message on Slack. I show these updates here. It's in the product management piece. Like, I'm very transparent. But, you know, people aren't probably JIRA tickets. They may be busy. Yeah, they may not want to be in JIRA. And this kind of second layer of the intentional conversations particularly one on one is so crucial and I think a lot of developers have started to I mean not even started have created this view of like all meetings are bad because I want to be hands on keyboard I want to be coding and what they're thinking about is the six person meetings, the 20 person meetings the 15 person meetings are like, why am I here? What is the point of this? And there's a lot of studies that show, like, once you have six people in a meeting, it's kind of your max to actually get value out of it. Unless it's very much status report, and you shouldn't be doing that many of those. It should be like an occasional company all hands thing. And this is where I love that you're focusing on one on one. Saying, hey, how do I directly build connections? How do I build direct trust with them and give each other time to give context to that we won't get in that Slack update? I may not know that, you know, you ran a half marathon this weekend and you're all excited about that and you're training for a full marathon end of this year. That's really exciting. It's great to know that. I wouldn't necessarily get that if I don't talk to you about it one on one.
Kelly Vaughn: 16:01
Yeah, also it's one of those things that I probably just wouldn't be saying again and again on Slack, but it's something that's very important to me. Yep. And this is something that I've, I had multiple conversations about my, my half with the one on ones that I had this week.
Conor Bronsdon: 16:14
Totally, and that's something where it's like you are, you're being authentic and transparent and you're, you're talking to people and it's just an example, but it's, it's a really crucial part of this build trust situation. And, another crucial skill here is feedback. Yes. You know, both asking for and delivering constructive, actionable feedback. I know it's something you've also highlighted before. How do you think about feedback in the context of this trust building and influence building?
Kelly Vaughn: 16:41
Yeah, I mean, think about those three pillars, trust, communication, and empowerment. In order to receive feedback, you tend to have to have some sort of level of trust with them for them to actually take in the feedback and do something with it. And communication is obviously key to delivering that feedback and, and being able to speak in a confident manner with them. And on the empowerment side of things, have you ever gotten feedback that was just like, you're doing a great job? Or, or on the flip side, it's like, yeah, you know, I, I think that meeting could have gone better. Cool. What do I do with that? Right. And what's the action? Exactly. Like it has to be actionable. And if it's not actionable, you're disempowering the person on the receiving end from being able to do anything with that. And, you know, we often talk about the, and I bring this up in my, in my course as well, um, this is something that, Kim Scott talks about Radical Candor, where you give feedback that is positive, and then negative, and then positive. And, you know, the feedback sandwich, whatever you want to call it. And when you do that, it's, you're once again disempowering the individual on the receiving end, because they don't, they're walking away being like, so did I do a good job, or did I not do a good job? And it's very confusing. And so feedback is such a, such a strong way to also build trust with somebody, because it shows them you care. About their career. You care, you want them to do a better job.
Conor Bronsdon: 18:04
Yeah, I'll say I made that mistake early in my career as a manager where I, in one of the first teams I managed, I, I tried to be too nice about it. I was like, Oh, you're a compliment. And then like the thing I really need and then compliment again, like this. Classic training here. And I think we have to accept that like often people don't necessarily hear the part you need adjusted. I mean, to your point about building trust, a line of people enough that they can accept when you have feedback and you, yes, you need to work on how you deliver it. That's, you know, an important thing to do, but if you're working with other adults, you, you need to be able to convey. constructive, actionable, somewhat negative feedback at times. And you can also make positive feedback constructive and actionable too. Like, Hey, you do a great job about, you know, showcasing your work to others. Please keep doing that. That's, that's actionable feedback. It's saying do more. It's saying keep doing. And I think we underestimate that sometimes.
Kelly Vaughn: 19:00
Absolutely. And, and we, we, there's a, there's always this misconception that feedback has to be negative. It has to be critical in some way, you know, like if I get feedback to somebody saying, Hey, the PR description you wrote for this most recent PR was so in depth and so thorough as far as the testing plan goes, that what you're doing by writing all of this and spending time dedicated towards writing a very thorough PR description is one, we have a track record, like a receipt of what we actually tested and two, we're really reducing the chance of a regression, through the manual testing that's required for this particular change. And so you're making things so much easier for the rest of the team to understand how to review your code and what actually needs to be tested in this PR. So this is a perfect example of something I want you to be able to, you know, use as an example with, you know, with the team to say, Hey, I made this PR. This is a really good structure. You should do the same.
Conor Bronsdon: 19:51
Yeah, that's a great example of this because I think to your point, we too often default to, oh, let me make this negative feedback actionable. Let me give feedback. It has to be constructive and maybe not positive. And part of building trust is also acknowledging and recognizing others for the things they do well. And it's a really crucial part of building the right culture and getting people to continue to do things you want them to do. What are other key skills that you'd be thinking about as you kind of drill into this building influence topic? So we've got, uh, empowerment, we've got communication, we've got trust building. Uh, what are the ways you would start to actually action on each of those?
Kelly Vaughn: 20:28
Take my course.
Conor Bronsdon: 20:30
Great answer.
Kelly Vaughn: 20:31
No, so the way I structured my course is around three modules. Developing your engineering team. Conflict resolution across your organization and giving and receiving constructive feedback. All of these three things as you're building influence in an organization, all three of these are going to be playing out on the day to day. Uh, you know, I really like the conflict resolution one in particular, because I feel like this is a skill that everybody can work on, and the way that this is structured in the course is actually not just how to resolve a conflict between, you know, two of your engineers as if it, as if it's like you're a manager, but this is how to resolve a conflict with the peer, how to negotiate with your engineering manager counterparts, how to negotiate with your product manager counterpart, and most importantly, how to manage up. And this is something that literally every single person can benefit from. And so I think the most important thing is you're building influence in an organization and you're giving feedback and you're identifying who everybody is and you're helping to resolve these conflicts. Is that latter part of receiving feedback. You have to ask for feedback. You have to ask and check in and how things, how are things going? How are others perceiving your impact on the organization? And you can kind of do a gut check of, you know, one of the things I talk about in module one is around a quarterly development plan that you should do with each of your direct reports. If you have direct reports, if not, you should use this practice for yourself to basically check in on like, what did I do in the last three months? What did I set out to do in the last three months, and what, you know, what didn't line up? Like, where did I fall short perhaps, or where am I really, really proud of, like, that I actually built in the next three months, or last three months? And what do I want to do in the next three months? And I'd say, like, this, this QTP, this Quarterly Development Plan, is a perfect opportunity for you to update your resume, by the way. Because you've just done, you've just done a review of everything that's your most important accomplishments that don't want to have to reflect back, you know, let's say, you get laid off or you decide it's time to look for a new job. Nobody wants to go back and be like, what did I do over the past two, three, four years? I don't know. You already have it every single quarter you're updating it.
Conor Bronsdon: 22:36
I think that's a super smart recommendation. And one of the interesting things we see is that as people start out in their careers in R& D and engineering. You're very close to the product. And that's what you get promoted off of is, hey, I'm excellent at turning this product into something that's valuable. But to your point, as we kind of move on in our careers, we start to think about communication more. We start to think about the structures of the team more. How do we enable others? And that's very valuable and it helps us scale the organization, scale ourselves. But there is a risk that as you move up the org chart, you get farther and farther away from the customer. You get farther and farther away from actually fixing and building the product. What I would love to dive into is how execs and leaders should think about staying close to the product. And a great example of this is, a couple of weeks ago, Meta CEO Mark Zuckerberg posted a video where he talks about trying the Apple Vision Pro and compares it in depth to his viewpoint on Meta's own Quest headset. And obviously it's, you know, a competitor thing. He's, he's Just throwing a little bit of shade, highlighting how great they are. But I think many execs, particularly at large corporations like Meta, very much struggle to hold on to that level of detailed product expertise. It requires a lot of coaching, a lot of, you know, setup for them. They have to be very scripted on how they approach any of these product conversations. How do you think execs should be staying close to the product detail versus balancing other business priorities?
Kelly Vaughn: 24:00
Yeah, I've been honestly staying close to the product detail is a slippery slope as well. It's a delicate line that you need to balance because you want to know what's going on without accidentally, putting your position of power in, the forefront where you're going to be now impacting the roadmap and changing everything over just because you made one small comment that was like, Oh, it'd be really cool if it did this and somebody somewhere in an organization we know this happened. It's going to hear that. I'm like, well, the CEO said that. So the VP of engineering says this. So we need to drop everything and do this. It is a very, very easy thing to do. I think it's important to regularly check in with your, your engineering team. You know, in a larger organization, obviously, more and more layers get set there. And the higher you go in an organization, the higher your 50, 000 foot view is going to come, but If you're staying close, if you're having skip level conversations, if you're having conversations around your product and how it's actually playing out, you're listening to sales pitch the product, you're, you know, I'm assuming you're probably using some sort of system to record the sales meetings so you can go back and watch them and you can see how the, how the product is being represented as well on the day to day. It gives you an opportunity to, you know, really identify, here's where we're doing great, and here's where we might be falling short, like this, this is an area of concern to me, but you can bring it to the correct people within the organization, and let that float down, and the reason why I say let that float down is because, again, you have an imbalance of power. If the CEO were to go directly to one of my engineers and say, hey, I'm concerned about this, depending on the engineer they speak with, some of them might bring it to me and be like, hey, our CEO mentioned this, what do you think? And some of them will be like, I'm just going to fix it because I don't want to, you know, I don't want this to be a thing. Like, I don't want to do something wrong, whatever it happens to be. I think that's something that's just like really important to note. Now on the understanding what's happening in the competition side of things, I think that is something that you should never get away from. I think it's really important to know what the competitive landscape looks like. I think that's one of the most important key skills for, uh, you know, the difference between somebody being an engineering leader and being a business leader. In order to understand where your company can go, you need to understand also what that competitive landscape is looking like. You need to understand what your customers are actually looking for and actually asking for and how they're interacting with your product. But no one product is always going to be stand, these stand out as everything else is, absolutely awful. This is a one product. That's never, that's never going to be the case. Innovation is what drives, you know, new products into the market and drives you to continue to push your own, your own product and improve your own product. And so it's important to know what's going on. And I think that is kind of the balance of making sure an exec can stay close to the product without overstepping, into too much of the day to day.
Conor Bronsdon: 26:59
What about specifically retaining technical skills? Because I think that's something that I found as I don't do hands on coding really these days, is my very bad dev skills are atrophying. How should I be thinking about keeping and maintaining those, since they're obviously a valuable piece of understanding and approaching how we build products today.
Kelly Vaughn: 27:20
I think there's a level of accepting that as you move up in an organization, especially in leadership, you're going to get further and further away from the actual code itself. And to me, that's, that is honestly an acceptable thing to do, depending on your role. Depending on, you know, what is actually most important for your role. I recently wrote an article on how to stay technically fresh, uh, when it's no longer a job to code as it's no longer my job to code. And I highlighted some particular things that I, I do to stay technically fresh and, you know, for me, that is, for one, take a course. Um, not to call out my own, obviously, but I've been, taking a course on, uh, Vault. Because we use Vault internally, and I'm like, how exactly does this work? Because this is not in my, it hasn't been in my wheelhouse to this point. So, like, let me, let me just do this short, like, One hour, two hour course just to get a general high level understanding of what's happening here. And at least like, we'll pull up VS code and write some things into like the command line. And that's the extent of my coding there. So it's not super, it's not super deep. Um, I've got a number of side projects I'm working on. I'm building an app for a friend of mine. I have some clients through my consulting gig. Still focusing on the Shopify side of things on e commerce that I continue to work with. So I'm still writing code, um, but not for my day to day job. If you have time to do this, obviously, that is important. If you don't have time to do it, it's harder to kind of build that out. Within the organization, like within the day to day, I will review pull requests for sure, and I will look at the code, and I will say, and I think what's most important is like, the further up you go, if you don't have that much time to review the code, pick a pull request, look at it, and if you don't understand what's going on, ask the engineer, like, hey, explain this to me. I think that's perfectly fine to do as well, because as you move up, you're not going to be spending so much of your time focusing on, what came out in the newest release of React that we're now using, or, you know, you're not going to know the deep intricacies never necessarily, if it's no longer your job to know that, but it could be beneficial for you to understand what's happening under the hood. Should your manager come and say, what did this change actually bring? Like, what are we spending our time working on here?
Conor Bronsdon: 29:31
Love it. And since we started this conversation with, you know, referencing, uh, Meta and the Vision Proverse. MetaQuest, uh, debate here as an example. Uh, I'd love to just get like a fun take from you. Do you think the Vision Pro will succeed? What, what do you think is going to happen with AR VR?
Kelly Vaughn: 29:47
I think we've been trying to figure out AR VR for quite some time and we're going to continue to try to figure out AR VR for quite some time, so you reflect back on like the Google glasses, like they're a lot smaller than the Vision Pro, and to me, the Vision Pro is too big. Also, I have a tiny head, so that also contributes to it, and I don't really like the idea of something massive just being in front of my face. Um, I also have a control thing that we don't have to unpack, that's for therapy. I think we're still figuring things out. I think the Vision Pro is an important step forward, but it is by no means endgame for What's your take?
Conor Bronsdon: 30:29
Think it's a, it's a good strategic direction for Apple, to kind of hone in there and start fighting meta more, uh, in that space. The, it's interesting to now see them finally cutting off their electric car effort, uh, as well. I was
Kelly Vaughn: 30:42
just gonna say that. Yeah, this is a perfect example of focusing your efforts on what's actually going to move the needle for the business because building your own car is not.
Conor Bronsdon: 30:50
I think the other one that we're kind of all waiting to see is Apple's made a ton of acquisitions in the AI space. What's their play going to be on AI? And it feels like they're saying, okay, like, you know, we're, we're deep in hardware. We're going to add AR, VR because of that. And we're going to probably do something on AI here soon. What's that going to be? Those will need to be combined to be very powerful in the future. And I also agree with you, like, I'm not going to get one until I can have a slim down, something wearable. Um, like it, like the one use case where I really see like, Hey, like I would buy it today would be gaming where, Hey, I want this really immersive gaming experience. It looks really cool, but it's just not where I want it to be currently. And it feels like something where I'm going to wait a couple generations before I try it out.
Kelly Vaughn: 31:32
Yeah, I mean, Apple, like, the, the Vision Pro is very much like an early adopters product, product. For the diffusion of innovation theory, it is very much on the left side of the spectrum where we're not going to see even an early majority adopting it, in my opinion, until we see future iterations. And most definitely, I'm not going to see a laggard buying a Vision Pro any time soon.
Conor Bronsdon: 31:54
Yeah, because I'll probably be an early majority one on this one, and I feel like I'm at least a couple years away still here where I'm like, Ah, I don't, I don't feel compelled. I don't, I don't need this right now. I
Kelly Vaughn: 32:03
think in comparison to, let's say, when the iPhone came out. There were, there was a much stronger appetite for that at the outset than, uh, the Vision Pro, and I think part of it is just because the technology is fundamentally different, you know, we were already used to using a phone, whereas we're not really used to these AR VR headsets that is a new So, yeah. Technology that we're all kind of wrapping our heads around, no pun intended.
Conor Bronsdon: 32:31
Well, that, that pun is a great way to close things out. Kelly, I really appreciate the time today. Thanks so much. Yeah, thank you. And listeners, remember if there's a topic you want to hear Kelly and I discuss or Kelly and Dan discuss, let us know on social media or via our Dev Interrupted sub stack comments. We intend to do a lot more of these types of episodes where we dive into key things that engineering leaders, whether they're starting out and trying to grow or at that exact level, trying to stay close to the product can, can leverage to actually, uh, improve their careers and deliver more impact. So we'll see you all next week. And until then, you can find more of our content on LinkedIn and via substack com. And if this topic is interesting to you and you want to build more influence as an engineering leader, or as a NIC looking to grow your career, check out Kelly's course as well. We'll link it in the episode description.