Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revello 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 revello.com forward slash ELC today and save $2,500 off your first hire. So basically the first-team concept was launched at my level and then I went through this journey and I realized like, oh, this is very powerful. First, it was confusing that I
need to put my team aside and take my peers as my first priority. But then I became more curious and then I was intrigued by the results and I'm like, oh, this is so powerful. I need to put this in my own organization. So I started with my directs like, hey, we have studied about this. We did a whole session and walked them through some really examples. That's where it was like, oh, we need to implement this and see it.
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.
In this episode, we deconstruct how to apply the first-team concept and approach across different functions and levels throughout your engineering organization with Monica Bajaj, VP of Engineering at OCTAB. In this conversation, we talk about how first-team could be applied across functions like architecture, quality, and security. We also get into the nuances of what this looks like at the executive and the frontline leadership level and everywhere
in between. Plus, we talk about how first-team impacts things like onboarding new teams and developing new products and even how this concept encourages both bottoms-up initiatives and more self-sufficient teams. We get into a lot more different tactical steps to implement first-team throughout your entire organization. Let me introduce you to Monica. As VP of Engineering at OCTAB, Monica leads the developer experience portfolio for customer
identity cloud. She has taken products into the global market by launching localization and globalization programs delivering multimillion-dollar growth. Previously, she's held senior engineering leadership positions at Workday, Perforce, Network Appliance, and UKG. Monica is an active supporter of diversity in STEM and has launched several women in technology initiatives. Enjoy our conversation with Monica Bajaj. Monica first off just wanted to say welcome
to the show. We're sort of winding down 2023, so I really appreciate you being able to make some time to join us. How are you? What's going on in your world right now? Thank you so much and so glad to be here. This is a great way for us to end, you know, 2023 coming back together. Lot going on. As an engineering leader, you can think of everybody is looking for planning, budgeting, getting ready for holidays, calibration, and then on top of it, you want to have some
fun in your life as well with extended families. So it's a mix of everything but all good. Well, it's kind of special. This is a fun moment to sort of pause and reflect in. I know we're going to talk about a concept and a practice that has made a huge impact on you as a leader in a lot of different ways. And that is this concept of the first team. You know, you joined us at our conference in August and we talked a lot about how to implement a first team mindset
in your organizational culture at a lot of different levels. Well, the thing is I have a lot of follow up questions from that. What you illustrated was so powerful in terms of unlocking different results for your team in terms of collaboration, performance, coordination alignment, all of the things that people are looking for. And so what we want to talk about today is to learn a little bit more about how to apply this concept and how it varies across different functions, different
levels in different areas. So I guess the rewind for people maybe that are listening for the first time here and are like, what's a first team concept? Maybe we can start at the beginning. So I was wondering if you could share with us again. What is this first team concept and can you share a little bit about how it's impacted you? Before we jump into the concept of first team, I want,
you know, our listeners to close their eyes and imagine a rowing boat. And as all of us know that rowing is a team sport and there is a saying that row in the same direction and trust the row beside and behind you. And why is that important? The importance lies because the rower beside you help you steer the things and what keeps your belief high is trust, transparency and accountability. So those are the three things which I want the audience to understand, like trust, transparency
and accountability is the key thing to the success of every single organization. And as organizations grow and leaders get hired, it is very easy to lose the sight of the big picture. So the definition of success in their mind is about themselves and their teams, but the big picture is, are we aligned with the core business priorities? Whether your team is on the driver's seat or whether
team is contributing doesn't matter. So in order for someone to visualize the concept of first team, let's say you are an executive in an organization and there are many other executives working with you. Each of you have a function area, I have a function area, I have a team of people and it's very natural that I will make my team as the first priority or my agenda as the first priority and vouch for them. And suddenly it becomes like a hub, you know, you are lobbying for your own agenda,
but if everyone starts doing this, then you can see there's a lack of cohesiveness. And so there is an onus on folks, us all executives and we will talk through this in multiple layers. For the greater good of organization, it is really, really important that we are cohesive, no matter whether it's our agenda or whether it is someone else's agenda. This is where the first team comes into play. So it's a concept organization, health concept, which was the device by Patrick Lensuni,
who is an expert in this area. And the idea behind the first team is that true leaders always, always prioritize supporting their fellow leaders over their direct reports. And why this is needed when we talked about this whole circle, if we take a step back, if I'm not cohesive with my peers, I'm missing that part to trickle it down to my directs. So my directs are always interested to know, am I getting along well with my peers? Because if there's a disruption at my level,
the disruption trickles down and it doesn't go in favor of a healthy organization. So it's really, really important that we focus on that. I think this is such a powerful framing because of what I'm trying to do is to take stock of my relationships and where maybe that doesn't exist and where maybe the lack of cohesiveness shows up. And so what I'd love to learn a little bit about is like having applied this, where have you noticed that this has created impact within
your role and with the different peer leaders that you work with? Were there certain results that this unlocked conversations that this opened up? I'd love to get a sense of just like how applying this has helped change some of the relationships that you've had. In the first team concept, we started it very small because that was something very new concept personally for me and many other folks. So first we started at our level, like how we come together as first team with my peers
and how do we align? And the messaging was loud and clear that our goal is to understand what are the key business priorities? How are we unblocking each other? So the word unblocking each other is really important, which means that if someone is driving a business priority or an agenda and they need my help depending upon, and if this is the highest business priority, I should pull back my own agenda and help them unblock. And once you do that, that's where the trust starts building up
and that's where the communication opens up. And the same thing, I'm going to message it down to my organization as well, like why we need to invest in this because it's one of the business priorities we need to meet. This also brings up uniform messaging across the board to every single employee in the team what matters the most. Now that being said, there are times when people might feel like, okay, why I need to sacrifice my own agenda or why I need to sacrifice my own
deliverables. But that's where the context comes into picture. And as a leader, it is really important for me to play that role to help them understand why. And that has gone really, really well from time and time. So over the time, like we have applied this model for almost close to now two years. And I have to say that the relationships between me and my peers are much, much tighter because of this.
I can immediately see like if you sort of pull back your agenda to make room and unblock somebody else, like the trust that that opens up, because what you're demonstrating is I value us being successful together versus my piece of the organization. Exactly. Is there like a specific story that comes to mind of like when that happened, how that then like allowed the organization to to make a greater impact or like accomplish something together? Yeah, I can give you one example.
So I manage engine development teams and quality engineering team as well. And we call them as domains because you know, a domain has multiple teams. And these are all directors who are reporting into my organization. And these are the folks who are in a position to make some strategic and some tactical decisions. So how do we make sure that here there are two organizations. One is focused on a big product feature functionality. Another is focus on the quality, which is cutting
across multiple teams or multiple domains in the organization. That can happen only if there is a cohesiveness, if there is a trust, right? And holding the line is really, really important. Yet being collaborative, I'm not saying you have to compromise everything and trying to look nice. So I also want to make sure that first team concept is not about trying to look nice or being nice.
It is understanding what is important. So walking you through a real example, quality organization is driving cross cutting initiatives, building a quality maturity model for the entire engineering. Now, their internal customers are every team who is shipping a code right now. Because of this first team of directs, I had all the directors and the quality director as well, the individual leader was able to do a beta version internally within my domain rather than
circulating it widely. It's like, Hey, you're my first team. I have built this quality maturity model. Can you help me give it a POC within your engineering organization, a smaller group? And that really helped in multiple ways. One is quality team got what they wanted. That whether the maturity model was successful to scale further out, the second part was the trust between my team, like developer experience teams and quality team was built was like, okay, if there is a need for
quality, I can reach out to this quality leader. And likewise, quality leader felt that if I'm going to build something new process, new technology, here is a team, a smaller group of people with whom I can try it out. So I can say that that has helped really well. And now I can tell you the impact is so huge that the quality organization has been to the next level, like in terms of maturity, in terms of voice of quality, and quality has become the first principle for the entire engineering.
That's a game changer. Absolutely. Well, like a lot of people can say like, oh, effective teams you need to build trust where that insight goes wrong. It's like, what are the concrete things that you do to facilitate trust? And then like again, I think sometimes follow-up answers can be ambiguous. And I think this specific interaction is such a great example of the specific things that build trust that give people a sense of we are working together towards a common goal in like that trade
off in understanding of what's most important and how can I support other people? And I think that's such a powerful thing. Yeah. And one more thing I want to add here is like while we talked about business priorities and processes, understand first team is also a team where you can lean on. If you're going through some challenge, whether it is people related challenge or something which you want to have a second opinion about whether it's your outside professional network or
internal professional network, this is the team, right? You can trust on. So having that discussion that, hey, I'm facing this challenge, how have you solved it? And that's where the role of first team comes into play, like a team with whom I can share, I can trust, and I can open up a little bit more. So I ask a follow up question specific to this context here with the directors, uh, developer experience and quality. How did this first come to be to like set up this relationship?
Like was the sort of implementation of this first team concept, like a formal introduction, or was it more of like a here is how we can operate better together? I'd love to get a sense of like how did the conditions get set up beforehand to help facilitate that interaction? Yeah. So basically the first team concept was launched at my level and then I went through this journey and I realized like, oh, this is very powerful. First, it was confusing, uh, that I need to
put my team aside and take my peers as my first priority. But then I became more curious and then I was intrigued by the results and I'm like, oh, this is so powerful. I need to put this in my own organization. So I started with my directs like, hey, we have studied about this, we did a whole session and walked them through some really examples. That's where it was like, oh, we need to implement this and see it. So we started with my directs. That's where our quality leaders and my engineering
leaders work together. And then as it became successful, we went to the second layer, which is our managers, engineering managers, because engineering managers are facing similar challenges. This opens up the door of open communication because this avoids, first of all, everybody knows who is working on what and this also avoid duplication of effort. This also helps unblock some of
the complexity because some other team might have already solved the problem in a certain way. So having these first teams at multiple layers was the first step we did as a result of this. The concept was introduced to answer your question. I love that idea of like, it gives visibility into who's working on what the duplicate effort, the unblocking complexity, like I could totally see how just like facilitating those cross-group conversations like can immediately bring that visibility.
One, one question. So you mentioned like you've gone on the journey applying first team, yourself first with executive peers, and then begin to introduce this to different levels. Like, are there any distinctions that come to mind about like the difference between maybe your experience at the level in the peer-gate working with versus like the director level first teams? Like, are there any kind of nuances or differences that might be interesting to call out for folks?
So our security engineering team is my sister team, like my peer team. And my first team is the senior director of security, who is in my first team. But as you know, security teams are very small as compared to other parts of the organization, but they're very, very critical. And the friction is always about, hey, I have multiple priorities, product priorities, engineering priorities. Now I have security priorities as well. And it's important, right? And how do
I prioritize this? How do you scale this organization where there's a limited resources on the security side? And I have limited resources as well. What we did was we made sure that we partnered with the security engineering team. We also had like, you know, I have like 11 to 12 teams. The best way to do is built in that security first mindset within the engineering teams as well. So we asked engineers who are passionate about it, who care the most, and who can be our ambassadors.
There is their hands. So, not only we have like now 12 people to form that group of security experts like SMEs, internal SMEs. And they work with the security engineering experts to bring that knowledge back. The benefit of this was we started introducing security right from the cat go in the planning stages. They used to pull in the security product security teams as and when needed. And they formed a first team, the first team of security SMEs, I would say internally.
Suddenly they start seeing like the cross collaborating initiatives and security issues are very complex. So we wanted to make sure that again, not repeating, learning from each other. And that became like a tight cohort. So now, even if someone is missing, we are able to actually have some coverage. That's the beauty of this. And that really helps scale my team across the board. I think what's interesting as we were kind of two examples in sort of like the
collaboration between like DEVX and quality. And then now we're kind of talking between like developers and security and this intent to be security first. Like I think what's interesting is we think about like the dynamic shifts that have to happen in terms of strategy or in terms of
objectives for the business. I know you were probably sharing things after the fact and it probably wasn't as like quick or easy, but it seems like you're able to shift in a way that makes sense where there's there's better alignment where there's more there's more like agreement or buy in in terms of what needs to happen. Is that what the first team sort of structure helped facilitate is like maybe faster shifts to tackle different priorities in the organization?
Yes. To a great extent, I would say the starting point is forming these first teams and growing your talent is part of it for you know, a lot of the engineers started learning new things, which is like growing the talent. I would say the end result is like, hey, we had a quality first mindset, we have a security first mindset, which is very much needed for any engineering organization to ship the products and across the board. So the outcome is pretty impactful. When I started this,
my goal was not like, hey, I need this outcome. Outcome came naturally out of all this journey. I would say. That's awesome. 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-vetted 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 revelo.com forward slash ELC today and save $2,500 off your first hire. With the security example, are there other lessons about that collaboration from applying the first team concept that would be interesting to share with folks? Yes. I'll bring two examples.
First, we'll talk about M&A's. Every company goes through some sort of M&A in their journey. We all know that companies acquire companies, and then the struggle starts around migrations, or how do we integrate them in our products suite, and a bunch of other things. This is where the first team comes into play. Whenever companies buy either organizations or technology stack, it is really important to understand how the first team can play a role
in bringing the new organization up to speed. Giving them those nuances around like, hey, this technology has to move to a new platform, or new tech stack, or adapt new processes. These are the new stakeholders now you have to work with. This is where the first team helps in onboarding the new organization. I had to go through this journey, and this was extremely
helpful. I can tell you, it was mind-blowing how this team came along and gave them pointers, hey, if you need help on platform, go and talk to this person, and how we saw the problem. So, having them being welcomed in that bigger ecosystem, the first team played a huge, huge role. And guess what? Now there is strong trust, there is better collaboration, there's
faster execution across the board, and faster decision making. So by sharing their learnings, the first teams definitely uplevel the game by inviting other members into the team. Well, what were some of those conversations that helped bring that new product area up to speed? How did that first team sort of envelop them and welcome folks in? Were there any specific conversations that were helpful as a part of that onboarding process that you might point people
to you? First of all, the goals were being set, like what is expected of the new organization? What are the milestones they need to meet and giving them that onboarding platform as well? Like, hey, this is your first team. If you need to know about platform, go and talk to this person, right? So I had set that stage, and I had set the same expectations with the group of
people as well, like, hey, this is a new team. The expectation is you bring them on board. So it was not like a buddy system, but in general, making them part of that cohort and making them feel that they are not like external. That's really important. And many organizations fail in that. It's really important, like when you acquire a company or a technology, you need to make them welcome. This concept really helps them. Even like little, little things like about processes,
about fun stuff, about our frameworks. And this may or may not apply because the new team and the self figuring it out, but bringing them up to speed is really key. Absolutely. We've talked about quality. We've talked about security. And then we've talked sort of about the new product area and an M&A example in onboarding. And I know there's also an example about like the impact of this or how this shows up within kind of an architecture context. So I was wondering if
you could bring us into what happened? Where was the friction and how did this concept apply in that context? As a VP of engineering, I work closely with my RGF architect who is my first impier. The working principle that we all have agreed on is whenever we put architects in our teams for advice, we look at two parts. One is making sure we are leveling up our people's stack and our tech stack boats together because it's a win-win situation. Many times we over index
on technology and forget about our people and we don't want to do that. So the way to do is like, you know, I have like tech leads and principal engineers and they go to architecture round tables. And they sit with architects and they learn about the big vision of architecture which is being planned. They also contribute how their areas fit in. The tech leads and the principal engineers are going
deeper and architects are going a little bit broader. And some architects are also going deeper as well. The secret sauce for our every engagement model is writing it down. That's really, really important. Everything you talk about, you write it down. Now what happens is the tech leads come together. Back to the team, back to the domain and that's the first team. First team of tech leads. Now they come
with a plethora of information. They work together to understand and hash it out on how it applies to developer experience. And that's where the magic happens. Sometimes they go beyond their teams as well, right? Because there's a key area. This is very impactful. We need to do this. So on the tech stack, as you can see, better collaboration is there. They are shared goals and there is avoiding repetition. Right? So that's that's going to be the key. On the people's tag, what happens is we
are scaling our talent. When my tech leads are going, they're observing architects as their role models. So they're building. They're part of that long term vision. And we are able to ship things faster because the talent is building. Plus, most importantly, we are building next set of technical excellence.
That's really important. So I also want our listeners to view first team concept as not just for collaboration and solving the business party, but you are up leveling your leaders, your people at every single level. And so you are up leveling the technology roadmap. You are up leveling the people skills as well. And that definitely helps in better employee engagement. It helps in retention
across the board. What stands out to me about this example, you know, having gone through a couple days so far is how powerful it is for context sharing and how much more autonomous or self-sufficient down to the tech lead level or all the way to the tech lead level, how far that self-sufficiency and autonomy can be extended when there's that much deeper context. And so for me, it's like I'm almost seeing the neural network of the organization, how it goes from idea to then folks sort of at the
front of helping build or execute or make some of the like more granular decisions. I think that's so interesting. You gave a pretty good example of neural networks. That is very true. It seems like a mesh, but it produces a pretty good results. Are there any examples that come to mind, like specific to this architecture example, about where some of these teams can either operate more
autonomously or in a more self-sufficient way? Like are there certain types of decisions that become easier for them to make having had like the architecture vision conversation who have been involved in like how they contribute or fit into this vision? Like are there certain types of things that become easier in the type of conversation? Yeah, especially if you're doing huge efforts. For example, companies go through the effort of, hey, you know, breaking monolith
to microservices or migration effort, right? Which is like very cross-cutting. This is where, you know, these tech leads can play a big role. They go to these round tables, they understand the big picture and then they come back and say, okay, now I understand all the moving pieces. This is the piece which I need to focus on and make sure like I'm aligned with the big picture as well.
So some of these examples are really, really powerful when tech leads have to step up or solving some key dependencies between to business priorities and when you are, the tech leads are subject matter experts, they jump in and they help resolve. So that's going to be really powerful as well. One of my favorite quotes of all time is this idea that authorship breeds ownership. And so when I think about the moment where like in the architecture round table, there's like this invitation to
like contribute or think about how you fit within this picture. And I think immediately then, you know, the team member becomes less of a, you know, somebody listening and consuming information, but they become an author in that moment. And then they become more empowered or willing to
want to engage in solving the problem. And I think that that's such a different shift from being passive to following directions or orders or delegation or whatever to all of a sudden, an owning now the creation or the implementation and such a powerful mental shift. Yeah, that is very true because one of the things which came out of the first team is it empowers bottoms up initiatives. And the reason which I want to bring it because it is very, very impactful
for the overall culture. Every organization, if we have bottoms up, totally bottoms up or totally top down, it's not good. It has to be something hybrid. We talk about top down many times, but bottoms up is another part which I want to focus on this as a concept of first team is with this, there is a sense of ownership which has come up many times because they are held accountable for delivering
a certain vision across the board. There's innovation and creativity which has also come up. It forces people to think that, hey, you are on a hot seat, you are a part of the first team, you are accountable for this. The forcing function of that is collaboration and communication. There has been enough times when folks who were not comfortable or not extra words, they have turned into extra word because
it is forcing function for them to collaborate and communicate as a part of this team. And then everybody is learning and growing together. That's really, really powerful. In this case, at all levels, at my level, at my directors, my managers, tech leads, name it. So it's a continuous learning effort without competing with each other. So that's another big part of it. And then as we all know, our business environment is changing rapidly. We have gone through this many times.
Having this tight first team hold each other accountable and give us a sense of empathy for each other when it comes to being adaptable and being resilient in these tough times. I would not call it as a family, but it is a team which holds each other tight in tough times as well. I imagine the metaphor you start off with in the more, in the beginning, the conversation, imagining being on the boat together, person to your left, person to your right,
front and behind you, rowing. And that environment, I imagine, is like a dark and stormy sea. And the people sort of around you as a part of that first team are there to assure that we can weather the storm together. Exactly. Exactly. You said it right. And I'll take it further. If there's a hole in the boat, how do you make sure that you are focused on the whole rather than worrying about,
like, can I save my life? Absolutely. We've covered a lot of different examples here. And I think one area that I'd be curious about, because I think how I became familiar with the first team concept was like in the context of executive leadership and like folks sharing with their peers at that level. And so I was wondering if you could share a little bit more about how can an executive leader who has begun to become familiar with applying this with their peers begin to build
and launch and effectively leverage like their own first teams at different levels. Like, is there a pathway that you might recommend or like how can somebody help really leverage this within their own, their own teams of company? The way, I mean, I'll keep it very simple, but there are four things which I keep in mind when it comes to me as a leader helping my reports. One is be clear. And when I say be clear is provide clarity on what is important, why it is important,
and how my leaders play a role towards the success of those priorities. So when you talk about this, it brings in a lot of sense of accountability and ownership. So one is clarity. The second is consistency. When it comes to communication about new initiatives or new process, be consistent about it. Then the third one which I focus on is being cohesive, which touches a little bit of, you know, the cultural aspect of it is like bringing that culture of cohesiveness,
result oriented little bit of autonomy as a part of it is really important. And that's where the collaboration, because if I'm collaborating with my first team, my leaders will collaborate with their first team as well. So I'm bringing that culture by leading by example. So those are the four things which I mentioned, clear, consistent, cohesive and calculus.
Powerful, absolutely powerful. I had one follow-up question about cohesiveness. The scenario I'm thinking of is like when it is apparent that a first team is not cohesive, how would you have people consider how to regain that cohesiveness? What's the intervention? What's the pathway to
do that? I'm thinking about like maybe a group where somebody is stuck, where they are over-optimizing maybe if they're function and are not necessarily in that place where they're considering or empathetic to maybe their function is like not in the most important priority for the business and they're over-optimizing for that in the context about theirs. Like how might you recommend like regaining that sense of cohesiveness or intervene there? Having those direct one-on-one conversations and
helping them understand why certain things are important. And I have done that in a situation where I had to put a pause on one of the business priority. Bringing them along in that journey is really important rather than penalizing them for that, right? So it should not be a punitive effort. It should be helping them understand why certain things are important, giving them the context, giving them showing them the impact that if you put a pause on your current task or
current charter and pick on new charter, what is the power you are bringing on board? So everybody wants to do work on highly impactful things. We are all humans, so we all want to do that. But as a leader, it's an onus on us to explain them why we are doing this thing, whether we are dropping the current charter and picking new charter, why does a business priority, what role you are going to play and what's the impact you are going to bring? And the last which is very important is like
you have my support. That support part plays a big role because now you are building that cohesiveness and trust with them that you are not alone in this journey. I hear your pain, but this is the priority right now. And I'm with you in this. I'll help you succeed. So that's the part which we need to have. And then there are times when you know some folks are like I'm going to go
my way. That's where the hard conversations have to start. Absolutely. I think it was a great way to sort of cap off the boat in the storm metaphor is like when the boat is no longer cohesive running together, here is how you can intervene and get it on track. So thank you Monica. Are you ready for some rapid fire questions? Of course. I love these rapid questions. Perfect. Okay. Well, here we go. Rapid fire question number one. What are you reading or listening to right now? So I'm reading this
book which is called as the habit of winning by Prakash Iyer. It's a beautiful book. I like the books, you know, which is a collection of short stories. It takes me back to my you know school days. But the stories are all focused about self belief leadership teamwork and every story is very different and a lot of perseverance. One is don't change your rabbit. And what does it mean is you should identify rabbits. You want to catch and focus only on that one because if you try to catch
them all, you will not be able to catch them. Right. You may end up with none. If rabbit is like different or elusive, you have to change your tactics. But do not change the rabbit. So that's really important. It means staying focused is important. Do not try to get down to the bandwagon and try to do everything what everybody else is doing. So you need to know what is your not star and chase with that. And then the second part which was very close to my heart was call as flat
tired leadership. I do not know if you've heard about it. Flat tired leadership is about famous industrialist R.J. Tata who runs the Tata business in India. He was with one of his senior directors driving to meet some customer and the tire went flat on the road. And everybody got out of the car and people were like, oh gosh, good that we got a break. R.J. Tata sat with the driver to help him out. He was the CEO and chairman and he sat with the driver and put the flat tired
together and get it functioning. So that is called as like flat tired leadership is like set the role model leading from the front is really important for a leader to succeed. So I'm still reading every story. And yeah, man, enjoying the book. Next rapid-fire question. What is the tool or methodology that has had a big impact on you? The model of four piece I always follow for any hyper growth phase whether you're building teams or business. One is people that are you building
the right organization for future, which is who who you are bringing on board. The second part is product, which is you need to understand your customer base. Process is another one where you want to make sure you are not putting processes, but you are building processes which can help you bring more alignment and execution and faster delivery, which is the how part and then platform. But you have to build a best-in-class service, which is resilient, reliable and scalable. If you think
about all these four things right from the get-go, you'll be fine. Fantastic. Next question. What is a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet? There are many, but this is something which I think all of us would love is 5G and the 5G application. We all have 5Gs on the phone, but we do not know whether it's real 5G. I wish like 5G was picked up a little bit faster, but I know the limitations have been there. I mean, the
technology is remarkable. Like in the whole point was increased speed and reduced latency and all the features which bells and whistles it came up with. But the factors I see are not being able to pick up is of course infrastructure development, device compatibility, regulatory changes, and then of course more security and privacy concerns have raised up. So it is really important, I wish, you know, this technology is going to be a game changer for a consumer. Great trend to call out,
really excited to learn, remember, the implications of what that might make available. That's great. Last question Monica, is there a quote or a mantra that you live by or a quote that's been resonating with you right now? One quote I always try to keep to my heart is that smooth seas do not make skillful sailors. You need to be willing to own some challenging opportunities and I feel that success and failure both create equal opportunities. So you have to be ready to disrupt yourself many
times in order to learn a powerful way to close. I would also remark like an artful way to link the beginning metaphor of rolling in the boat with sailing in the ocean and navigating the navigating the stormy seas. And so we will leave it at that. But Monica, thank you so much for sharing your stories and all of the ways that you've been able to apply the first team concept to help unlock better results, more self-sufficient teams. We really appreciate it. Thank you Patrick
for having me on this podcast. I really, really appreciate that. It was fun chatting with you. 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.
See you next time on the engineering leadership podcast.