Here's the truth. Hiring remote engineers doesn't have to be expensive and time consuming. Our friends at Revelo can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revelo.com forward slash ELC today and save $2,500 off your first hire. You know when you're talking about AI or any technology for that matter, imagine you're presenting it to your executive leadership team or to your board. As an engineering leader, you want to spice up that message with how it is interesting to your customers. The
framework that I use in scenarios like this is called WaterFansore that Framework. If you're running an email platform, what if you're able to search through millions of emails in a sub millisecond so that your users can have faster search abilities compared to our competitors? Build a dream scenario and tell them how the technology can help them meet the dream scenario. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering
Leadership Community. I'm Jerry Lee, founder of ELC and I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. To be an effective leader, one of the most essential things that you need to be able to do is to advocate for your ideas and clearly communicate your thoughts and strategies to
other people. One of the most difficult scenarios where this shows up is in the impromptu conversation and that's what today's conversation is all about. We talk about the framework that you can use to excel at impromptu communication in any scenario and then we deconstruct how to apply this framework with a few different common scenarios that you are likely facing right now and that's around team topologies or team restructuring and AI tools and AI
strategy. Not only do we talk about the framework for impromptu communication but we also talk about some of Lakshmi's perspectives around those two topics so it's sort of a two for one special. Let me introduce you to Lakshmi. Lakshmi, Baskaran is an accomplished business leader, entrepreneur and an angel investor with over two decades of experience in the tech industry. She's built and managed high performing engineering teams for startups, scale ups and publicly listed companies across
North America, Europe, Australia and Asia. She's currently serving as the VP of engineering at metadata, a SaaS company that offers a marketing operating system to prominent brands in businesses worldwide. Enjoy our conversation with Lakshmi, Baskaran. Well, to kick off our conversation Lakshmi, first off just wanted to say thank you so much for joining us. It's great to have you here on the show with us. How are you doing today? Happy Wednesday.
Thank you. Happy Wednesday to you. It's been an amazing day so far. I love it. We get a good, have a good, good after or I guess it's early morning. It's still early morning. We have a good early morning conversation together. So we want to talk about effectively communicating and impromptu communication as sort of this high level theme.
And we've identified a couple really interesting and maybe common use cases for engineering leaders, things like delays, new ideas, team composition, AI adoption, some of the hot topics right now, the big areas of focus. So first to start, I was wondering if we could start by bringing people into this moment here. And in a way that's probably really relatable to what they're dealing with or focusing on right now. So I was wondering maybe Lakshmi, if you could share with us,
like, why is this topic so important to you? And then maybe do you have a memorable experience where maybe a major project was off track that you needed to communicate that delay and it maybe didn't go well? Sure. So why is this topic important to me? I am a non-native English speaker. Born and brought up in India, English was not my first language. So when I moved out of my home country, one of the things I often struggled with is communicating in an impromptu situation.
Most engineering leaders, we have different channels and different modes of communication. When it comes to presenting your project idea, your project execution, to your executive team or to the board, we are well prepared. We have rehearsed it for a few times. We have thought through what kind of questions we might encounter. So that's a completely different genre of communication. It's prepared and organized communication. The other genre of communication is the
impromptu communication where you don't expect something is going to come your way. You don't expect you're going to meet someone in your CEO and the elevator and he's going to ask you about something that you have not been actively thinking through for a while, right? And that is one of the biggest challenges that I haven't encountered. And I've heard this from a lot of my engineering friends and colleagues that impromptu communication is something that truly wished that they could craft
that skill well. Some people have shared with me terrified is a word that comes up in that story. Oh, yeah, that's exactly right. Oh, well, terrified. Why now? What am I going to say? I'm one of the things when it comes to impromptu communication. Imagine you're meeting your CEO and the elevator and he's asking you about a project that you're leading. We believe that's the
time to showcase the limelight on you and your team. But something we often tend to overlook is impromptu communication is about conveying the message and accepting a media critique in your message. And what I mean by that is you don't need the flashy terms, you don't need the flashy words. You want to be able to tell your CEO, this is the status of the project and this is what we are doing to accelerate it or this is what we are doing in order to like have a good
product market adoption on the project. And this exactly happened to me in probably somewhere early to mid part of my career. So this was back well before pre-COVID. We were all working in offices and I used to work for a huge enterprise company and I meet the CEO on the hallway and we exchange greetings and he was like, what's happening with this project? This is like a project that had a lot of his attention primarily because it had a big impact on our customer base and he
was closely monitoring this and he's like, what's the status of the project? And you know what I did Patrick? I thought this is the time to like burst out everything. Oh, this is all that's happening. This is what we are doing. These are the challenges and this is how I'm trying to resolve them. So I used those two minutes to talk continuously rather than pausing to understand what I said doesn't
convey the message to him. And after the conversation I was like, oh really? Did I convey the message that he truly wanted to hear or did I overrun him with a lot of message? And that's the time I even start thinking deeper about how I can be more prepared to structure my own proper communication.
And I touted that many of your listeners can resonate to this because we all go through these challenges of like being asked in an unexpected situation what's happening here and having some frameworks to be able to clarify the message in a succinct way would ensure that you're not just showing the limelight on your team but also showing them how you acknowledge and appreciate the business impact of what you're doing as well. That moment you shared I think is so relatable.
I found myself so many different times in that space where somebody asks a simple question and you unleash every detail, every piece of context, every probably philosophical element you've even considered or trade off you've had to make to get to an area. And then you leave that conversation where they have absolutely no idea what it is you were trying to tell them. And so I'm hearing that I'm like, oh my gosh, that's been me and I know a lot of other people feel the same way.
And as you're sharing this, I'm also starting to see like how just thinking about like some of the the core framework elements that you can consider on the front end can be applied to so many different use cases or scenarios that I think in this in this case. So when you're thinking about like this moment, like can you outline the framework that you use like in this sort of impromptu communication
and then like let's talk through them like what this looks like. Like if you had to redo that scenario over again applying these tools, what did that look like and can you help us bring us in there? Most of your audience are engineering leaders and I would imagine they'd all have come through this situation or scenario where they've been asked about a delayed project. And the immediate feeling and emotion that go in use like when someone is like pointing fingers at you and your
team about a misproduct release, you go through a lot of emotions internally, right? You think about the number of geraticates that your team worked on, you think about the late nights, you think about the number of bugs that they fix before the release. And as a result of all this mental model that you have when you become a lot more defensive and as a result your conversation does not go the way that you want to present yourself as. So what happens in scenarios like that?
I mean in order to navigate your thinking or channel, your thinking to how to exactly address such scenarios like that is a framework that I often use comes in handy to me a number of these impromptu scenarios is very easy to remember framework, triple A, A, A, A. The first A is about acknowledge. If your boss is telling you, hey, here is a delayed project from your team. The first thing to do is acknowledge if that is true, if that's truly delayed, instead of being defensive,
just acknowledge to say yes, the project has delayed. And what do you do after that? That's the second A. The outcome of any delayed project has a business impact. So as an engineering leader, you're expected to focus on the engineering, but you're also expected to have an appreciation of the overall business impact that the delay of your project has caused. And you want to be able to share and echo that. So that's the second A, which is appreciate. So appreciate the business
impact that it has caused. So talk about what was the code KPI that you were trying to target might be growth, might be customer retention and your delay of your project by a month would mean that your customer retention is going to be delayed by a month. So that's the appreciation factor. And the last factor is A, the last A, which is amend. And what do you do? So you've acknowledged that there is a delay and you've appreciated and you've shared the business impacts that your
project caused. But the most important thing is to like give the confidence to your boss that you are on top of it trying to amend situation. And in the case of the last A, something that engineering leaders, especially when we are leading a huge org, sometimes we are caught by surprise. You might have like probably 20 teams under your org and you might not have been made aware of this delayed project in this specific team that was made aware to your boss. So you're caught by surprise.
Don't panic. You would have solved several scenarios like this in the past, but the framework would let you to think, how do you amend the situation? To share with your boss and your peers, what would you do to actually solve the situation? And if you have already been made pre-meat to the delays, then you would have definitely already done something. So this is this scenario to say what have you done to solve the problem? So just in summary, and this is one of the techniques
of frameworks that's very easy to recall. It's just triple A. The first A is more about acknowledged that yes, there is a delay. Appreciate the impacts of this delay and talk about what you've done to amend or solve the problem. In my experience, once I channel my thinking from those emotions or from the defensiveness over to this framework, you could easily channel your communication easily based on the framework. And sometimes we tend to misconvame something when we are in an
impromptu situation and with the framework, you're like, okay, this, this, and this. So the orderliness of communication makes the communication more effective. As soon as you're talking about this, the orderliness of communication makes this more effective. I start to feel more relief because for me, I definitely fall victim to the personal blame and responsibility and defensiveness that comes up a lot when someone's like, how come this happened? And it was an area of responsibility
that I had. I think that high responsibility characteristic is something that a lot of people listening in, probably share. And so when I'm thinking, oh, cool, here is my response, because I default to defensiveness so fast to it's all on different things. And so this framework seems super helpful for that. As a US company, hiring remote engineers can be time consuming, expensive, and frustrating. You could hire freelancers, but you don't know how much they'll focus on
your business. Out sourcing to dev shops, risks, control over who works on your projects and expensive long-term contracts. Or you could look overseas, but working across lots of time zones can really slow things down. Enter Revello. Your gateway to a talent network of over 400,000 pre-bedded engineers in Latin America who are proficient in English, work in your time zone,
and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts. You only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control. You get to decide who to hire,
what to offer, and you get to decide how long to keep them on your team. To learn more, visit Revello.com forward slash ELC today and save $2,500 off your first hire. Can you walk us through just like a quick example of, you know, there's this big project of life. CEO gets you in the hallway again, or maybe it's a quick huddle or a quick spin-up conversation. Walk us through, like, what does the best response look like in this case? Or like a
high quality example of what this looks like? Sure. I think this time it was not in the hallway, but in a virtual conversation, I get a ping from this was like probably a few months a year ago. I get a ping from my CEO saying, I would like you to jump on a quick zoom column, like, okay,
something is not right. This is an unplanned impromptu conversation. There was a delay in a project where we were targeting two key KPIs for the quarter, both growth and retention, and as you can imagine, for every company, growth and retention are the two important KPIs, and any project that leads into these KPIs are the high profile projects. So, of course, one of these projects were getting delayed. The fact behind that is like, this project was closely monitored by me and by
everyone in the org because of the impacts that it would have on the business. So just towards the end of the project life cycle, as we were doing a performance testing on the project, we realized that our system is able to contain the maximum level of threshold that we want to have in terms of number of transactions per second. But however, there is a third party system that we integrate with, and when we put that through a high effective performance testing, the system
basically failed. As a result, it was like a, oh, moment for us. It's like, oh, yeah, we have designed our architecture to be more scalable for a metric that we wanted to achieve for our users. But then there is this one API that talks to the third party system, and we completely overlooked the performance metrics of the external system here. So we realized this issue probably three days before we were supposed to go live because we were running some performance tests towards the end
of the development life cycle. And then we reached out to the third party vendor. They were trying to make some amends on their side, but they had their own priorities to focus on. So of course, it was very clear this project was not going live on the day it was supposed to go live. So my immediate point was like not using defensiveness, but using my framework to say, yes, of course, this is a failure. I mean, this is something we should have observed and noticed when we designed
the architecture. So I had to acknowledge that and appreciate the impacts this would have on both the ARR and of GRR, the annual recurring revenue and the retention, gross retention revenue as well. And then I had to talk about what am I doing in order to amend this situation. So then we are we are working with the third party vendor. They are bringing some of their staff engineers to accelerate the solution and then some timelines on when we were going to meet them and when we can
relaunch or launch the product again. So while going through this, I was glad that I was able to convince my boss about the impacts of the delay and what we are doing to actually amend the delay. But something that I learned Patrick as part of this exercise is like, I took the ownership of going and sharing with my peers because the VP of sales, the VP of sales, they also had some KPIs targeting growth and retention. And delay of my project would have consequential delays
of cascading delays on their side as well. So what I did was I used the same framework, the AAA framework when I spoke to them. And you know what's the icing on the cake Patrick? I decided I'll speak to customers as well because somehow for existing customers were the were depending on this feature or project to go live. And I decided it's me and my team that needs to own the delay and I'll start bringing in fewer foreign customers to talk about this
delay. And to them as well, I used the same framework. I acknowledged the problem, appreciated the delay that this has on their side of the operations, the customer side of the operations. And shared them with what am I doing to solve the problem. And after all this, we had two percent of customers that we couldn't retain who were depending on this project. But the rest truly appreciated our communication and they supported us and worked with us. This is one of the
memorable events in my career journey because this was like a big setback. We have huge KPIs for the business. Two weeks of delay on the project is going to have a potential impact on the revenue. So it was a very memorable event in my career and leveraging this framework to be able to address that moment truly taught me that defensiveness is not going to help and having a sort of mental model to manage these kind of communication will make these situations a lot easier.
I love the idea of defensiveness is not helpful in this situation. So, impact wise you're saying only 2% churns you retain 98% of customers in that space. So what about the impact on your peers when you're closing the loop for communication because like beyond just like having this framework, it sounds like the question you were also asking was like who else needs to know this and how can I take ownership over that communication.
How did that also impact your peers? I think as much as everyone was frustrated about amazing deadline here, they appreciated the fact that it was caused by us overlooking something on Avengers architecture and what we are doing to actually amend that as opposed to like giving them deadlines on when we plan to resolve that and when we plan to resume our performance testing
and when we can go live. So being well prepared in terms of those amended schedule is something that people truly appreciated and the most important thing, especially when engineering leaders come across scenarios like this, it's not a one-time communication. It is a communication of repetitiveness.
So if your project is delayed by 2 weeks, you're not communicating today and going back 2 weeks later, you are sharing status updates, constant status updates with the stakeholders of the project informing them whether you're able to keep up to the deadlines that you shared and what risks have been mitigated and what risks are still pending. That's something people appreciate about communication
and frequent communication when you encounter scenarios like this. So I want to transition our conversation down a different area of focus but I think there's going to be two things that this is going to open up. One is we're going to be able to talk about a specific competency area around team topologies and team composition. But on the other hand also is the way that this framework shows up in advocating for a certain plan or approach within that context. So it's kind
of cool. It's going to kind of be meta and very deep down in detail, I think both at the same time. I know that you and I were talking about team topologies when we were connecting beforehand. You mentioned that this is one of your favorite things to talk about ever and so you mentioned like I have to talk about what I wish the book team topologies covered and some of your reflections on the different elements of that that you've now integrated into your approach to building engineering
teams. So I guess the question is like what do you wish was covered and like what aspects or characteristics do you believe are essential for different types of engineering teams? How are you thinking about that? Thanks for bringing up team topologies right sitting right here in my library and this is a book that I often take from my library to actually go through a few chapters
from time to time. So this is something that's a very near and dear book to me. Most engineering leaders who have read team topologies and if they haven't I highly recommend reading the book. One thing that the team topology talks about is like how do you effectively create an engineering org and it uses Conway's principle and Rua's Conway principle on how an engineering org should
be created which is great. But when you trickle down from your org composition to your team composition one of the things that you often think about is the kind of engineers you have in the team. Let me ask you this Patrick how many times you've come across a new idea and then you shared the idea with an engineer and the engineer probably a week later they would pull you into a conversation and then they'll say here is a prototype for the idea. Could you think of an engineer who has
done this in the past for you? I can I think there's a couple there's a couple that come to mind there. Yeah and imagine you're sharing the same idea to a different engineer and then you immediately hear about hey this is a brilliant idea but how we'll keep in mind we have the customer service and the accounting service that's currently bottlenecked by a lot of performance challenges and before we fix them if we build a new service we are going to have a lot of cascading
products right? That one's me. So you are one of those genre. Do you think either the first kind of engineer I referred to who would bring up a prototype when you share an idea? I see them as a product minded engineer, a product focused engineer and the second kind of engineer the genre that you represent are tech minded or tech focused engineer. So do you think one or the other is good or bad
like what are your thoughts? Well I think by instinct is I guess I've been probably one of those those different types at different points or like in different needs like small team big team depending on what I'm or optimize for. So that makes kind of makes me think that like maybe it depends. It's context you're right but what is more important is engineering leaders to think about the composition of the team and see if they have the right composition of a product minded engineer
and a tech minded engineer in the team. Now who's a product minded engineer? There is a very quick
like musters that you can run for a product minded and a tech minded engineer. A product engineer is someone who truly focuses on speed, a tech minded engineer focused on quality and a product minded engineer would have a very good wrap on relationship with the product manager because they are the product managers pet child and a tech minded engineer would always clash with product manager because they'll always be talking about efficiency and predictability and scalability of a technical
service rather than how quickly you can live through things right. So it's very easy to do some litmus test. I've published a blog post about how to identify a product minded and a tech minded engineer might be we can put that in your show notes. Absolutely. But what is more important to understand is both product minded and tech minded engineers are equally important if you're building a high performing team. One focuses on speed and the other focuses on quality and a good ratio
and composition of both would make your team super successful. Now I'm sure some of the people who are listening are wondering what's ideal ratio. So like you said, it depends. It's the context but a good and quick and easy way to differentiate that is like if you are part of a very fast growing organization or if you're part of an early stage company where you need to quickly iterate on ideas to get to a product market fit, you want to have more product manage a product minded engineers in
your team. If you're part of a mature organization where you have a very strong product market fit and you're looking at enhancing your offerings, enhancing your features, then probably you need more tech minded engineers because when your product and organization is mature, you want to look for more scalability and efficiency and other non-functional aspects of a product and tech minded
engineers are good at that. So a good ratio I've always started with 70-30, 70% of product minded engineers and 30% of tech minded engineers I use that as a benchmark and then depending upon the stage of the company, depending upon stage of the team and sometimes each team is unique by itself.
A team that has newly been built to tackle probably a brand new AI feature, you might need more product minded than tech minded engineers but as you release this feature and the feature matches you, you want it to continue to enhance the feature, you need more tech minded engineers than product minded. So it depends but however there are some clear litmus tests that you can run, you can start with a benchmark of 70-13 and use your context to lean in more towards product minded
engineers or towards tech minded engineers. One of the other questions that I had about this was about it is continuing on about assessment. So when I'm thinking about an early stage team, how are you assessing brand new hires or are you then reassembling teams, people from different teams that already are pre-existing? How does that come into play when it comes to assembling your team, whether bringing in new hires or reforming or reorganizing new teams and resources in that way?
I can probably share an example or share an incident quite recently where we are trying to hire for a new staff developer for one of our teams and the first thing I asked the team is, what is that we are lacking in the team? We have some great engineers, great people with high agency, very high agency, we have all the right characteristics but in terms of product mindedness and tech mindedness, what are we missing? And it is important to make your team aware that
it's not that one is better than the other. Both are equally important for a team to perform at their high levels. So knowing that what is missing from the team, they said we are missing a tech minded engineer, we are moving extremely fast and as a result there are some elements that we are not paying attention to or we haven't paid attention to. We want someone to come and put us into the more operational side of a specific service that we are building and we need someone
who is truly tech minded. When we went to hire, it starts with the job description actually. A job description should extend and elevate what you're looking for in this hire. Are you looking for someone who is deeply technical, who has a very strong operational mindset and has a strong inclination towards the scalability, reliability and performance of the system, then call that out
in the job description. And we did that and also as part of our assessment of the candidates, we looked whether these candidates carry these characteristics and that's something I tend to do during the yawg says well, bringing in the right ratio for the team knowing who are the product minded and who are the tech minded engineers and building a team based on the right ratio, that's also helpful. I'm glad you asked this question because when we are hiring, we don't think
about this dichotomy of product and tech minded engineers. As a result, you bring someone might be their passion as technology and you put them in a product minded role and vice versa. So being able to understand the candidate's motivation but by starting that from the job description, we'll make your hiring highly reliable and highly successful and make sure the person you're bringing
on board fits into the right role. And I'm wondering kind of along this note as well because you were talking about this conversation and this dynamic with with your teams and helping guide them in the process of developing their criteria. How do you align with your teams about what they're what they're looking for? Like is this something that you are discussing with them and helping calibrate with them? Like are they working operating off of the same framework? Like what is it extending
this look like in terms of team operations? I mean, I do share with them about how I think about product and tech minded engineers and sharing it with the line light of like it's not one of the other, it's both but it is important to be aware of who you are as a developer and also the most important
thing to realize and I often tell this to my senior and staff developers, one would change from one kind of engineer to the other kind of engineer and it's often possible that in the early stages of your career, you're more product minded engineer because you want to move fast, you want to break things, you want to learn things, but as you've gone through this experiences as the staff develop as a principal developer, you become more tech minded because you've leveraged all the skills
of product minded and you become more tech minded. And I've seen a lot of engineers as they've grown from the early stages of their career to late stages of their career, they have changed their centrality either towards product or towards technology. So being able to appreciate that and being able to like be aware and make them aware of how I see them, either as a product minded or tech minded will actually help them prepare for conversations when I'm trying to hire for a role, asking them,
who do you need? I mean, do you need like one of you who's a tech minded or one of your peers who's a product minded, then probably that conversation becomes more of a fruitful conversation because they now have user archetypes to think about, is it Joe who's a product minded engineer or is it Sue who's a tech minded engineer? Do we need a Joe? Do we need a Sue? It's very easy for them to emulate if you have an architect for who's a product minded and who's a tech minded engineer.
Are there other questions that you found really helpful in like helping consult and guide on like the needs of each team? Just even that first question that you introduced in terms of like, well, what do you need? Like what are the qualities? Like what's missing here? I think is really powerful. Like what other questions have you found really helpful in that conversation? I think is one of the other things we also talk about is what kind of technical skill set that you
envision to bring into your technology framework or into your service framework, right? Here is a good example. I mean, in one of my previous logs, we were trying to move away from a synchronous communication layer to an async communication layer. So obviously, we were leaning more towards
either a Kafka or a rabbit MQ. So we would like to hire someone or we would like to have someone within our team with this exposure towards a technology, not what we're building now, but what we are envisioning to build probably next quarter or probably as part of your subsequent roadmap. So being able to have the conversation and have that forward thinking towards what skill sets is actually missing, that's a great way to actually use hiring or leverage hiring to
put technology gaps within your team. The other element of this, so beyond like assessing needs here, I think also the interesting thing to explore is how this impacts engineering culture and helping shape or intentionally craft like the type of culture that you want to build within your organization. So, some of you can share maybe like how is engineering culture, you know, dictated or determined or influenced by product and tech minded engineering leaders? Culture is defined by the people in
your org, people in your team. They are the ones who define the culture. You could have the flashy engineering values and engineering principles, but if your people do not emulate those values and principles, you're not seeing the culture that you want to create. So the most important thing is like when you're talking about how product minded and tech minded engineers dictate the culture of
an organization, the thing that comes to my mind is Facebook and Google. Facebook has to my knowledge, number of product minded engineers because you'll see the way that their culture is shaped from those engineers. Facebook's culture is more about move fast, break things, fix things and keep moving fast. So you have a lot of product minded engineers who will have a great sense of urgency, a great focus on speed to be able to deliver results in outcome. And Google on the other way is
a tech minded engineer. Google elevates perfection because of the complexity of problems that they are solving. The entire world's search is different on Google. So because of the complexity of the problems they are solving, they have no tech minded engineers. So going back to a conversation about
how do these people dictate the culture? We have these two organizations where we see the product minded engineers dictating speed and urgency over tech minded engineers dictating perfection in what they're doing. And again, I want to re-emphasize there is not one thing like this is right and this is not
right. It's about having the right balance. And as an engineering leader, it's our job to have the contextual awareness of what is most important for an organization at this point in time and creating your team and your org to match with the need that dictates a very successful high-performance team. I want to revisit some of the things we talked about earlier. You know, we're talking about
impromptu communication. And I think we've kind of opened up a whole new area of consideration when it comes to team composition, culture change, like assessing what are the skills or the needs within your organization right now. And so I was wondering if you could share maybe like when it comes to like this conversation about team topology, like where have you seen moments of impromptu communication come up where having like the AAA framework in your back pocket might be a really
powerful tool to use. Like where have you seen opportunity here and what's been the impact of being able to apply those types of tools in this team topology team composition conversation? Yeah, I think come one of the things that engineering leaders can resonate with is often when they go through reorg. You want to be in a position to explain bottom up and talk down about what is the principle behind the way you're reorganizing your engineering org. And that's where you want a
framework. It is not impromptu, it's a planned communication, but that's the framework you could use where you can acknowledge some of the challenges of your current organizational structure as a result of which there are some business setbacks, there are some customer setbacks. So acknowledge the
challenges and appreciate how these challenges are having an impact on the business. Let's say for example, your tech support arm staying outside of your engineering org will have an impact on your SLA of how quickly your tech support folks are able to relate, communicate or respond to your
customers about a technical problem in a product. So being able to acknowledge and being able to appreciate some of the impacts of your longer SLA because of this org sitting outside of engineering and then come back to your last year, which is amend what changes your making in order to
resolve the problem. So yeah, the trouble of framework is not something that gets always used in the impromptu, it's also getting used more using in the very planned conversation as well, it's more about acknowledging the problem, appreciating how it has an impact outside of your org or within your org and talk about what amendments you're making in order to resolve the problem.
I love it. Just being able to revisit everything we talked about just within this context, this is a two for one special one, you had a more sophisticated understanding of how to shape your teams and two, how to communicate effectively that change in a meaningful way. I love that. I wanted to transition to one more area that there's probably a big need for folks to be able to
apply more effective communication in an impromptu way. I think the scenario, a lot where a lot of folks are finding themselves right now, they're in some part of the spectrum of assessing or determining their strategy around AI adoption. This has come up a lot. We've had a series of different executive dinners around this conversation and it changes every time from your perspective.
We'd love to get a sense of what are some of the challenges of AI adoption right now that you're observing and what are you thinking about when it comes to these challenges around AI adoption? Again, this is in hopes of this parallel conversation of both this particular topic and challenge and how do you then, as an executive engineering leader, communicate effectively around all of the considerations around that challenge. What are the challenges of AI adoption that you're
seeing right now and what are you thinking about? This makes me think about a podcast. AI podcast. Imagine the number of podcasts that these days, engineering and product podcasts, they talk about AI. So every time I tune into a podcast, there is something about AI, like what we're talking now. So it's listening to this podcast where the guest was an executive from Epic Tech Company and they were talking about AI adoption. How quickly are they moving through
adopting AI across a huge organization? And I hear this executive saying that they're inviting for a direction from the CEO about how to adopt AI at different parts of the business. I'm listening to that. Made me think quite deeply about, is it the CEO who is directing about AI adoption to the rest of the organization? If that's true, then companies are not moving fast. Your product is going to be stale when every other product is going to embed AI into their
product ecosystem. If you're waiting for your CEO to give the direction, your product is going stale. So there has to be a different framework or a different way of thinking about it. So in my usual style, I grabbed a piece of paper and pen and started thinking about like what kind of framework could actually accelerate adoption of AI? And when I thought deeply about it, I could think about four pieces of this puzzle. And the beauty of this is like it's not just for AI adoption.
I mean, 10 years later, if you talked about cloud adoption, we could have used the same framework. In future, if we are talking about a different new technology, we could still use the framework. And the framework goes like this, Patrick. So when you're at the peak of a specific technology, it's not that your organization is not has never used the technology. Imagine we're talking about AI, but I can bet you, all those many products have an element of AI that already exists in the
product. It's not so massive. It's not so explicit, but there is an element of AI that we are targeting in the product. So they might have a handful of data scientists, few data science teams that's already solving some of these problems through ML models, right? So let think about that piece of the pie. That's the piece of the pie, which is the status quo. And your job as an engineering leader is to learn from the status quo. How are those teams operating? What are some of the challenges
that they result? What are some of the challenges that they currently have? And most importantly, what tools and what external partnerships that they have? Because as you're continuing to adopt AI into your other teams or into the rest of your org, you don't want to build a new tool set. You don't want to create a vendor list. You want to leverage what your status quo teams are doing. So the first piece of the puzzle is learning about what your current teams are doing. And the most
important thing, Patrick, is to identify champions from those teams. Because you need these champions to be planted across the newer teams in order to share their learning, share their experience of how to move faster in the AI world. So that's one part of the framework. The other part of the framework is AI for optimization. AI doesn't need to be this one big thing. You need a brand new
strategy. You need like a full vision. No, AI could be more incremental. So think about your product and think about a product user journey and figure are there some elements in your user journey where you can use AI to do the job for the user? If a user is doing five tasks to finish the entire user journey, can you inject AI into it so that the tasks two and three were done by the UI that user can validate in the fourth step so they can finish that entire journey in less than
half of the time they are used to? This is a simple example to think about AI for optimization. And you know what? You don't need a CEO. You don't need a CPU. You don't need a product manager to think about it. Engineers are equipped to think about how you can optimize your customers' user journey and they can look at different tools, different platforms to be able to like supplement the user journey to make it more optimizable. So this is AI for optimization. The third one is the
one which is AI for innovation, which is what many organizations are doing. And when it comes to third piece of the puzzle, when you're looking at AI for innovation, that is mostly driven by product and you want to be driven by product. The reason is that's a strategy bit. You look at probably a
specific opportunity in the market, a specific business problem. So if you have read this strategy book by Richard Riemalt, he talks about like three ways to think about a strategy, your problem statement or your diagnosis and then what is your guiding policy towards solving the problem and your set of actions. It needs a very comprehensive thinking when you're using AI for innovation.
And probably on the third one, you need more of a product driven strategy. The last piece of the puzzle is what this executive was talking in the podcast about needing a CEO direction, about how do you want to leverage AI across your business? How do you want to capture some market segments using AI? And that is a top-down direction. This could be accomplished in different levels of ownership. Status go great, leave the team to work the way they are, identify champions, then when you're
looking for AI for optimization, empower your engineers to think about ways to optimize. When you are talking about AI for innovation, have a very clear product driven strategy and then the last piece of the puzzle is your overall direction and your vision of how you adopt AI in your business and in your market. And that could be like, not just from the CEO, your executive team could collaboratively work together and share the message with the CEO and promote the direction to
the rest of the company. The way you've broken this down, it almost seems like it contains the innovation into different orders of magnitude chunks. You've got the large scale strategy CEO direction which can be broken down into either larger innovation chunks, incremental, more optimization oriented elements. So I see this really elegant roll-up and you can sort of address it from different directions from bottoms up or top down or you can go middle out to top and bottom
at the same time simultaneously. I think it's multi-directional. How should engineering leaders apply these areas in their decision making or is there a story or example of how this helped influence or impact, how you were able to navigate some of the early decisions around navigating some AI adoption? I could probably share an example from a current org. So basically we have all these four elements in the current org. So after I put this framework in place, then I start thinking about
do we have these frameworks in my current org? And yes, there is knowingly or unknowingly, there this framework exists. So we have like a data science team that is currently leveraging building ML models to solve some of our current problems. So I was able to learn from the team on the tools that they are using. What are some of the challenges that I need to be aware of while
I'm incorporating AI into the other teams? And then when it came to optimization, exactly how I described our engineers were able to identify a piece of the puzzle that could be optimized by invoking an API request to chat GPT and getting a response so that it could basically do the job of a human by automating that specific part of the journey. So this essentially reduced the time that someone does a specific job in a product by less than half because we were able to embed
intelligence into it. So that's the second piece of the puzzle. And then when we are thinking about a product roadmap and a product journey for the next few quarters, we are more thinking about innovation and a product managers are working through the innovation aspects and looking at areas of strategic implications that we can use. And then as an executive team, we talk about how we can adopt AI to tap into specific markets. And we also clearly observe and monitor how
our competitors are using AI to tap into the same market segments. So being aware helps us to craft a strong journey for us as an organization on how we can leverage AI to tap into newer markets and newer customer segments. The last question to wrap up this part of our conversation before we transition to rapid fire questions, Lakshmi was, we've talked about improv to communication, how did that show up in team topology to go full circle? How does the improv to communication framework
that we talked about show up in these AI adoption conversations? When you're talking about AI or any technology for that matter, imagine you're presenting it to your executive leadership team or to your board. As an engineering leader, you want to spice up that message with how it is interesting to your customers and how it is going to translate to a key organizational KPI that could be revenue
that could be retention water breters. And something is engineering leaders, we are very logical thinkers and we're talking about a problem and a solution, we are very binary about here is the problem, this is how we are going to solve it. But if you can twist that a bit and think about imagine let's take the same AI example, you're using AI to optimize a specific user journey. So the framework that I use in scenarios like this, I start with saying what if we can do this?
What if a user spends less than half their time when they're working on this specific user journey in the product? If a user takes two minutes to create an order and place an order through your website, what if you were able to make some intelligent choices for the user on what they want to buy so that they spend less than half the time in order to make a transaction on your platform?
Right? And this framework is called what if and so that framework? If you're running an email platform, what if you're able to search through millions of emails in a sub millisecond so that your users can have faster search abilities compared to our competitors? And it's not just this, I mean like you could actually pair up your water fence so that so that you're able to build that spice from the perspective of a user, a customer, an executive team or a board member,
rather than just talking the dull technology that sits behind it. Because technology is something engineers love, but we also need to empathize to the fact that when you're talking to a non technologist or someone who's semi technologist, you need to show that from the sense of like a water so that more build the dream scenario so that what you can achieve with the dream scenario and tell them how the technology can help them meet the dream scenario.
Fantastic. We've got some rapid-fire questions, Lashmi if you're ready to jump in and dive into those. Let's do that. All right, first question. What are you reading or listening to right now? I'm reading two books at the same time, Bill Larson's book on engineering executives primer. That is a sequel to a legend puzzle. I don't think well wrote it as a sequel, but I've read a legend puzzle and I could see how he's able to connect
some of the topics from the prior book to the current book. So that's a highly recommended read. I still haven't finished that, but I'm thoroughly enjoying it. And yeah, I'm also reading Einstein's biography. So full books happening at the same time. Love it. Next question. What's a tool or methodology that's had a big impact on you? We talked about reading and I read a lot. I use digital medium to consume information from books. And often as I'm reading through books,
I do make highlights within the book. And you know when you actually read a lot, you might have read so many things about solving a specific problem that you might come across, but you come across the problem. And you're like, I've read somewhere a few years ago about this specific problem and someone had a brilliant solution of how to solve this problem. And that's called a reader's block, similar to writer's block. And I've suffered by that for a very long time. So I was recommended this
app called Readwise. Readwise is an app that directly connects to your iBooks or your Kindle, whatever platform that you're using for digital reading. And it imports your highlights. It sends you like 15 highlights every day. So what it happens is I probably have some 2000 highlights in Readwise, but it uses its own emeral algorithm to say like, okay, bring me the top 15 highlights
I should be reading today. And this is something I've been using for a year. And I can tell you that the retention level has at least been three, X of four X since I've started using Readwise. Because Readwise sends me those highlights, probably I will be coming across those highlights like every month or every other month. And you're able to read that information better. I am so excited to check that out. I feel like, you know, I was showing you some of the books
that I was reading earlier. And I have so many notes and highlights in Kindles and across different platforms and everything like that. And it's so true. Like it just, it's gone. And I never referenced it ever again. So like, this is a huge need. I love this. I'm checking that out right away. Next question. What is a trend that you're seeing or following that's been interesting
or hasn't hit the mainstream yet? I mean, we all are following AR and VR. But I think a mix of both AR and VR is spatial computing that merges your physical and digital realities together. There is a lot of blogs that talk about spatial computing, but there is not a lot of focus at the moment that's happening in the spatial computing space. But I could see that being the next big thing for people to follow and people would be interested in.
Last question, Lakshmi. Is there a quote or a mantra that you live by or a quote that's been resonating with you right now? Lead by context is a quote that always resonates with me. And something that I truly stood by, especially when I'm in a difficult situation, it's not about a binary thinking this or that. It's about what is the context and what decision do I need to make in order to matter to the context? I think I'm extending that more to life as well,
living by context because there are some things that could be binary. You may have brush your teeth, have a shower, that's binary. You don't have to think about it. But there are a lot of things in your life that is very contextual. I was talking to a friend of mine and she was saying, is it in draining that when you always think about context contexts when you come across scenarios
like this? And no, it is draining to start off with, then it becomes a bit refreshing because when you're coming across a scenario, you ask this question, what is the context that I'm dealing with? And you can relate to this in multiple things in your life, like if you're a parent. When you're parenting, like instead of saying, oh, you eat sugar or you eat ice cream and you don't eat ice
cream? No, what is the context that you can eat or you cannot eat? If you're an investor, like use the context and use the contextual environment to define, am I going to invest in public market or private market? So I think I'm extending that a lot into life as well and living by context
is becoming something that's very close to my heart these days. Lakshmi, thank you so much for just a fantastic, multi-layered conversation, you know, diving deep to impromptu communication, as applied to so many different scenarios when we're talking delays, ideas, team composition, AI adoption. Thank you so much for a ton of fun and an incredibly impactful topic to get into to help people to be more effective in their roles. Thank you. I'm Steph Brick, it was a pressure
talking to you today. If you enjoyed the episode, make sure that you click subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on head to sfelc.com that's sfelc.com. See you next time on the engineering leadership podcast.