Beyond The Code

Maulik Sailor (00:01.54)
Hey, hi. Hello, and welcome to the next podcast of CodeMonk. And today we are joined by Munir Parikh, who is an engineering leader at Amazon Cloud Services, or Web Services, as they're called. And I'm your host, Malik Sailur, founder and CEO of CodeMunk.ai. And today we're going to discuss more about global engineering practices, how to really build your tech teams, how to really...

tech workers can build their career and just general some trends within the tech space. And without wasting too much time, let me introduce Munir. I think Munir, you're currently working as an engineering leader at AWS. Why don't you tell a little bit about your background? How do you really get to your current role?

Munir Parikh (00:49.566)
Yeah, no, that's a good question. So, by the way, thank you for having me. I'm actually originally from India and I was born and brought up in city Ahmedabad in the west coast of India. But I've been in US for close to 18 years now. And in last 18 years, primarily my career has been split between two companies. One is General Electric Healthcare Division, which is GE Healthcare, where I was in Midwest for eight years.

And then since last 10 plus years, I've been with Amazon. I was actually in Seattle for six years and last four plus years I've been in New York City office. Now we'll talk about Amazon a little bit more because that's a little bit recent past, but I joined as an individual contributor and couple of years in Amazon, kind of during my discussions with my mentor, my manager at that time.

conversation about like what do I want to do in the long term and I felt leading development team building solution and making impact through team is something I love and that's where we decided to kind of switch to people management role and since then I've been in people management role leading different teams in different part of US and then currently in the

AWS in the commerce platform division. I lead multiple teams in billing data space and what we do is build data infrastructure which is required to process all the AWS events and the usage data that come in and which ultimately becomes what we call AWS bills. So the computation requires a lot of data, a data infrastructure and that is what I lead.

In fact, one of my teams is in London today. And then I have a team in New York, as well as a team in Seattle.

Maulik Sailor (02:46.368)
Yeah, that's pretty good.

Maulik Sailor (02:51.852)
Yeah, that's pretty good. You know, funny enough, you mentioned about MDavad. You know, I was in MDavad only a couple of days back. I had a quick trip to India, you know, where MDavad is. And I went there after a long time and a lot has changed. You know, the city has completely transformed in the last, you know, five, six years that I know of. But, you know, just a small side talk. You know, our team at CodeMonk, we have, we all have been working remotely, you know, completely distributed manner.

And this was the first time I actually met quite a lot of those people in person, because quite a few team members we have in India. So when I was going to India, you know, we had a small team get together, everybody traveled from different places, and we everybody met each other for the first time. So I think that was a good experience, like an experience quite strange because you know these people, but you don't know them, you know.

You have been working together for many years and you're meeting them for the first time and suddenly, hey, you know what? You look different on the camera. You know, your personality is slightly different than what I imagine it to be and so on. So it was quite an interesting experience for us.

Munir Parikh (03:48.374)
Yeah.

Munir Parikh (03:59.926)
That's correct actually. That's one thing I always feel that being remote has its benefit, but then building this type of interpersonal relationship, knowing someone personal side of it, when you meet them in person definitely helps a lot.

Maulik Sailor (04:16.032)
Yeah, so we'll talk about remote in a bit, but why don't we talk more about your current role? What does your day-to-day activities look like being an engineering leader? I think a lot of people who work remotely, generally they tend to be senior to, intermediate to senior software engineers. And generally the engineering leader roles normally are in office or in a hybrid setup. So we would like to know, what does your day-to-day activities look like?

Munir Parikh (04:17.783)
Yeah.

Sure.

Munir Parikh (04:24.265)
Yeah.

Munir Parikh (04:38.778)
Right, right, right. Yeah. No, that's a good point. So currently I'm kind of in hybrid role. So I kind of work from home a couple of days.

We all have personal responsibilities, a family. So it kind of hybrid, which three days in office, two days in at home actually works out okay. But from the leadership perspective, I always feel like I'm a true believer of servant leadership. And as part of that, my focus is always like staying in touch with the team, SDMs or the leaders of the individual two pizza team, what we call it, working with them closely, diving deeper into some of their challenges

looking for opportunities where I can help. I can escalate or I can maybe help them brainstorm some of the solutions. So my focus, a lot of focus during the daytime is actually on helping teams. And that's where I would say if I divide my daily responsibility, and again, each day is different. So it's not a specific template that I follow every day, but if you kind of abstract it and maybe take a month,

most of the times. So I would probably bucketize them to the three buckets. The first one is helping team, like a lot of 101s, a lot of skip level 101s, team dive deep. I do have a separate mechanisms where I talk to each team separately every week, some for some time, dive deeper into some of the things that might have heard, educate myself about the things that teams are doing. And then in general, helping them in anything

help them grow.

Munir Parikh (06:22.966)
The second part of my work I would probably divide into strategic aspects. Amazon being a lot of document-driven or writing culture. We end up writing and reviewing a lot of documents, a lot of strategies, before we actually go and execute it. So we spend a lot of time in reading and writing documents, thinking big sessions, we call off-site sometimes, where we just talk about what is that big that

So I spend a lot of time on that. So I would say probably a second bucket is that where you're thinking strategic, you are doing things which kind of is really, really long term like three years, five years from now. And then the third part, which is, which no one can take away is the tactical part, right? Like day-to-day activities, like there are firefighting, like when you have multiple teams, maybe one team are having some issues or some escalations are going on. So you need to help, you need to be there with the team. Sometimes we have this

mechanism called correction of error in Amazon. You might've heard about it online. So we spend a lot of time in COE or correction of error. And there you need to spend time with the team reviewing their deliverables and see if we have right, like right fixes or preventive things in place. So any error that happened would not happen in the future. So there are a lot of technical aspect of the job that you have to still remember. But even if you ask me to prioritize, maybe this is the priority order.

We're helping team thinking strategic and then doing technical stuff to kind of make sure that the current state of our services is healthy.

Maulik Sailor (08:02.532)
That's good. You mentioned about two-pizza team structure. What is that?

Munir Parikh (08:07.122)
Yeah, yeah, so that's very, as such it's not a kind of anything that Amazon invented, but the term particularly is kind of very, very close to Amazon. And Jeff Bezos used to tell that your team side should be where you can feed them with two pizzas, two large pizzas. So that's where,

Maulik Sailor (08:27.236)
Okay, large or American large or the UK large, you know, the sizes may be very different.

Munir Parikh (08:32.758)
Yeah, so I think I would say probably some American large because there are pizzas which are very small but in general like this large pizza that you have probably it's two pizza team and what it means is that team size ideal team size is anywhere between six to eight.

and with a leader or we call SDM, like some teams call, some companies call engineering lead or some module leader, whatever, but we call it SDM, Software Development Manager. So a team of six to eight.

and with an SDM is kind of a usually preferred team in Amazon. And what it size of the team, what it helps with and we'll talk about the structure or ownership of the team, but the size of the team, what it helps us with is that it kind of promotes right amount of conversations because it's not too big. But at the same time, it's not too small that if that team is owning a service, they cannot support that service because Amazon being more of

organization in general we try to give ownership of a service or a responsibility to that team and even you might have heard that we do our on-calls too right so if there is something wrong with the service it's the same team which is going to support so we have a kind of usually one on-call every time who is keeping eye on our dashboards and alarms and monitors to make sure that everything is healthy so that six to eight kind of gives us that

you'll probably get your rotation from every six to eight weeks right because you are rotating it and at the same time it's a small enough that when you're even in the meeting it's not like you have you don't know each other so you can build that personal relationship with other team members

Maulik Sailor (10:20.512)
Yeah, we, you know, we, we done some research around that actually on the team size. So on code monk, we have this feature where, uh, the talent can self-organize as a full stack teams amongst themselves. Uh, and we, we did not want it like, you know, let's say two people or three people team, uh, or a one person, they, you know, in the worst case scenario. So we, we done our research. We were not sure what should be the, like, you know, the structure of these teams.

Munir Parikh (10:32.31)
Hmm.

Munir Parikh (10:39.85)
Yeah. Right.

Maulik Sailor (10:48.1)
that we should support on the platform. And majority of the engineering leads or senior tech leads preferred a team on a lower end of four, below four very rarely, but on the lower end four and on the top end about 15, 16, but six to 10 was the most common answer that, okay, team of six, eight or 10.

Munir Parikh (11:03.073)
Yeah.

Munir Parikh (11:08.512)
Mmm.

Munir Parikh (11:14.931)
Okay. Right. Yeah. Right.

Maulik Sailor (11:15.584)
Tam, again, would be considered a large team, but that was the number we got from our own survey of the senior folks, right? So yeah, it's quite in line with what you guys are doing.

Munir Parikh (11:22.19)
Yeah.

Right.

Yeah. And I have actually, to be honest, I personally managed a team of 10 at some point, like, well, I was directly line level manager and.

at some point it becomes difficult, right? Because now as a manager, you want to do 101. So now we have 10 101s in a week. That itself is like a lot of time. And then when you're promoting people, then now you're talking about doing their individual assessment and helping with their career and all of that. That just becomes sometimes too big. But then there is always a place where you cannot split that team immediately into five, but as company grow, that 10 will become 12, maybe at some point. And then at that time, you logically split that into kind of twos.

up teams but that's how kind of progress happens with the team but you're right I think it is really a sweet spot in my opinion but then you can have smaller teams especially in certain company in certain situation the type of work requires really small team of people to kind of just stay focused and deliver but yeah it's usual guidance this is never a silver bullet

Maulik Sailor (12:34.836)
Yeah. Now we talked about the team size, right? But what do you think is a good composition of the team? Like, you know, what different roles a good engineering team would be performing for a fast-paced delivery, you know? Not really waiting onto each other, not really being blocked by each other. You'll always be blocked by somebody, right? But in your opinion, you know, what do you think is the best team structure?

Munir Parikh (12:44.229)
Mmm.

Munir Parikh (12:53.304)
Right.

Right, right.

Munir Parikh (13:00.754)
Yeah, I think usually the best team is the self-serve team, right? Like they have self-sufficient, they do not have to rely. But even the seniority and juniority wise also, we always say that if it's like 100 percent, if you think about.

maybe around 40% of is your like relatively junior talent, your 40% is relatively mid-size or medium career talent, and then maybe 20% is a little bit more senior talent. And that way the juniors would learn from the seniors and then they will be able to coach others so they can grow as well. So that composition from the experience wise works out better or good for us. So it's like a team of six, you might have two or three engineers who are entry level.

two or three are kind of in medium, and then the one or two are kind of more senior. Now from the role-wise or the job responsibility-wise, it depends. Like some of the work we do, it's like hardcore backend data computing, data storage, where we do not have a portion to do a lot of full stack work, right? So there we have all of it, most of the engineers are backend engineer, and they're also are backend engineer with really, really large distributed computing experience and interest.

matter. But if it's a full stack team then yes you would have maybe a one or two front-end engineers and then one or two full stack and then maybe you have a couple who are kind of more back-end. So the composition from the experience or the skills wise would probably have a little bit more standard template but from the roles and responsibility wise or their

Maulik Sailor (14:47.173)
What about QA? How many QAs you will allocate per team?

Munir Parikh (14:51.162)
So in Amazon, we are kind of a truly believer of automation. So a lot of our testing in general is kind of automated. Of course, there are teams which are again, customer facing, which require some of the experience. There you would have a lot more QA, but for example, none of my teams right now today have any QAs because the work we have is a lot of backend and it's a CI CD with the integration test and automated testing.

And some functional testing is done, but that's usually kind of done by the engineers themselves. So we do not always have QAs. But there are, of course, teams in Amazon. Like if you talk about some of the Alex organization or some of the front end based, even AWS has consoles and others, they all would have QA. And there a lot of time we have a separate organization who are expert in QA. So if a senior leader would have an organization with just QA organization, and then that

own end-to-end testing because usually service level testing is done automatically but then when end-to-end testing comes you need either some automated tooling or at least QA or QAE is doing some testing which is end-to-end.

Maulik Sailor (16:04.7)
Yeah, talking of that, you know, QA and just generally quality assurance within software engineering. In my experience, I got, I, in one team, we had like a pair, like a developer and a QA working together. So QA doing, like, or we used to call the developer in test whose job is to write all the script, the automation script and the other developer will basically write the code to pass those tests.

Munir Parikh (16:25.783)
Right.

Yes.

Alright. Mmm. It's a role playing.

Maulik Sailor (16:32.884)
And they will keep switching between the two. So one sprint, one of them would be doing development. The other one will be doing, yeah. Uh, like, uh, like the, uh, the automation test automation and the following sprint, they'll switch around. Uh, so that was an interesting setup that I experienced. Um, and then at one organization, they did not had like QA within the team. The developers were responsible to write their own test and make sure that, uh, the code passes all the tests.

Munir Parikh (16:42.17)
Right. Okay.

Munir Parikh (16:55.095)
Hmm.

Mm-hmm.

Maulik Sailor (17:01.228)
But on the merge before going to production, they used to have a separate QA environment where they will run like a QA sprint. And they will run like a one sprint behind the DAO. So all the DAO work gets completed and pushed into QA. They follow, do all the testing in that bi-weekly sprint. And then they'll push it out to production. So it's quite an interesting one. That particular organization, this is BBC I'm talking, right?

Munir Parikh (17:06.698)
Yes.

Munir Parikh (17:10.175)
Right.

Munir Parikh (17:13.832)
Okay.

Yeah. Right.

Munir Parikh (17:29.46)
Okay.

Maulik Sailor (17:31.072)
like completely different engineering practices. And they had this belief that they should generally have just a very high quality of software put out to the end user and a little bit water-foil is process, but still try to really ensure that there is a faster feedback loop from the QA back to DAO and fix issues before they go out to...

Munir Parikh (17:50.04)
night.

Maulik Sailor (17:59.788)
you know, live audience. But I found it a little bit low. Sorry.

Munir Parikh (18:00.03)
Yeah. I think to- Yeah, no that's fine. Yeah I think in-

The teams that we had interaction with QA, the setup was like what you just explained, the first one is a little bit involved QA early enough and then work with them even during design phase. But again, at that time also we had a separate QA teams who were working with because they had understanding of end-to-end pipeline versus individual service owners who would just know about their service and they will make sure that their service operates as per the specification.

Maulik Sailor (18:16.952)
Hmm.

Maulik Sailor (18:36.324)
Yeah, I normally prefer a triangle setup as in two developer in a QA, basically forming a trial and working on like within the sprints together. So in a team of six, I would normally have four developers and two QAs. Yeah, that's the normal structure that I personally prefer. I'm not sure whether that's efficient or not, but that's my personal preference normally.

Munir Parikh (18:42.606)
Hmm.

Munir Parikh (18:55.726)
Sure. Yeah.

And that is the beauty of in general engineering, right? Like you can adjust based on the situation. These are all now options available to all leaders and then depending on your requirements, you can always make those adjustments.

Maulik Sailor (19:14.268)
Exactly, exactly. Just coming to team building or creating a high-paced, high-quality, high-engineering tech team, what are some of the tips that you leverage to attract some of the best talents out there? Especially, you are based in New York and where probably the competition for talent might be quite high. What are some of your tips?

Munir Parikh (19:43.946)
Yeah, and I would probably combine this question with the hiring and even retaining, right? Because we always say that as a high as a

as a manager of an employee, every 101 is another opportunity to keep that employee with you, right? Or we call builders. So keeping your builder with you, you have every 101 to keep them because they are in demand. There will be a lot of companies who will be looking for good talent even in this time. And so that's where your priority should be keeping them with your team as well. And of course, if required, hire more. Now, the question, since question is more on the hiring,

Maulik Sailor (20:04.94)
Mm.

Munir Parikh (20:21.848)
let's maybe start with hiring. And I think hiring right talent is definitely the first most important thing irrespective of where you find it, because they need to be, the engineers are good engineers or builders, get inspired or get pumped up when they work with more smart and good engineers, right? So that hiring right people and hiring good quality people,

should be one of the thing, it's not just hiring. So that good talent is very important and that's why some of your hiring practices that even Amazon we have does help, making sure that whoever we are hiring are kind of raising the bar for that level and for that job. So that's the first. Now to hire right talent, the one of the thing that worked well for us in the past and for me personally I've seen is referrals.

whether internal referrals or external referrals. Like your engineers are in general connected with a lot of people, even within Amazon or outside Amazon. And a good engineer bringing some saying that, hey, I work with this guy or this girl and they are really, really good. We should see if we can hire them. I would probably rely a lot more on their words than maybe looking for a best resume out there.

another tool that we leverage a lot and then if we are in the need we ask our engineers and say hey we are looking for the specific skills if in your network whether internal or external you know someone who can be a good fit please bring them and that it does two things one it kind of confirms that the person they are bringing they at least have already on their trust because you are not going to get someone who you don't trust and then on the other side it kind

give them opportunity to say what type of engineers or builders we are hiring for the team. So referral is another tool. In general, flexibilities and different options even moving around in Amazon and this is where kind of we may segue into more of a retaining tool but just providing flexibility to those engineers who are coming. Like there might be always company policies on certain things but within those policies and boundaries you can provide a lot more flexibility to your team members

Munir Parikh (22:46.896)
especially somebody you're hiring. If somebody's coming and say, hey, I understand that you have kind of a hybrid culture and I'll be expected to come to office, but maybe I will need three more months before I can relocate and we'll be like fine. We are willing to accommodate those flexibilities, right? So providing those flexibilities, or in general, if an engineer who kind of been working, doing really great for two years in the same team, just providing them options that,

we have these other teams or other type of work that's also really exciting and if they are really good and they want to kind of try that out we encourage them. I personally change probably five or six teams within Amazon even I change city too from like Seattle to New York so that providing those flexibility and different options is super important and then last thing I always say that building a culture which is promoting like bias for action which is one of the Amazon's

like providing, moving, making progress, like it cannot be always perfect. Even some scrappy solution which solves customers need, promoting that culture actually gives sense of accomplishment to engineers a lot. Then it's like waiting for a waterfall, a full life cycle project, which takes like nine months to go to production. And then after that, we don't know whether customer is going to use it or not. So promoting that bias for action and scrappy solution is another thing.

Maulik Sailor (24:11.457)
Yeah.

Maulik Sailor (24:16.404)
You know, you talk about that referral and that, you know, like talent referral. We had like, you know, when before founding my company, you know, I, like every place I worked, I always had like a few people in my team that I wanted to work more, you know. So when I was changing the job, I was like, hey, I wanted to work with that guy. I would like to bring that guy with me in the new organization. So I had a hunch about that.

And so we launched a talent survey on LinkedIn and also in our talent community. We have about 80,000 plus developers in our community and we launch a survey for them. Asking the very same question that, oh, hey, would you want to, when you move the job from one organization to another, would you want to bring some of your colleagues with you? And about 80% plus said yes, that we would like to bring our, not everybody, like some of our colleagues.

Munir Parikh (25:12.682)
Yeah.

Maulik Sailor (25:13.56)
together when we change this talk, or together we want to pick on new projects as we go along. Hence we launched, that was one of the biggest driver for us to launch our team's feature, that we wanted people to indicate that who they want to work with. And funny enough, that was one of our, the flywheel feature that literally accelerated our talent acquisition, every talent we sign up.

Munir Parikh (25:17.015)
Yeah.

Sure.

Right. Mm-hmm.

Munir Parikh (25:28.92)
Yes.

Maulik Sailor (25:40.436)
on our platform, they get this option of creating a team and invite other people that they want to work with. And that kind of like just literally 10x year-on-year talent growth for us, basically. So I'm a strong believer of that, that good people attract better people. You also mentioned, I picked up that you talked about relocation. So is it like, you know, it's Amazon?

Munir Parikh (25:44.854)
Nice.

Munir Parikh (25:54.546)
Right. Put that in, yeah, yeah.

Munir Parikh (26:05.653)
Yeah.

Maulik Sailor (26:09.872)
ask about Amazon, but generally, what do you guys do? Do you prefer in-office, hybrid, or remote team setup?

Munir Parikh (26:18.226)
Yeah, I think I mean, of course, during pandemic, like, the whole world had to pivot to complete remote and there were there were reasons for it. But in recent past, like, I was we have seen industry not only Amazon, right, industry kind of move a little bit more towards hybrid approach. Now

This is one thing where I would say it kind of answer, it depends, right? Because there are teams or companies which are in certain stage, where having everyone in a room working kind of day to night and just kind of solving complex problem, requires maybe everybody in the room in place. But at the same time,

There are teams, there are individuals, it's a relatively established teams, the type of the work doesn't require a lot of collaboration and you can work remote. That actually those things kind of can be done better remote. You are kind of saving a lot of commute time, energy, and kind of help people do their work-life balance harmony. So this is one place where in general industries, even today kind of split. Some companies are fully kind of

You need to be in the office and some companies like we are remote first still. But Amazon kind of in general and this is kind of open public policy so I'm not kind of revealing something which is kind of internal is that we are hybrid teams and we promote collaboration so there are days and there are there are things or activities that we prefer that you do all together in office but at the

Munir Parikh (27:59.172)
appreciated part of being remote and that is where working remote is also supported but not completely and this is where there is a debate that individual being remote brings productivity to individual but then there are also arguments that the kind of team productivity sometimes is better or teams are able to deliver faster things when they are meeting

in person and then building that relationship. So we are kind of hybrid. And I personally, if you ask me my opinion, I like the hybrid one better, especially it's really good for engineers who are early in their career, kind of in the office, working with senior engineers, being with the leaders and doing whiteboarding and all that does help them kind of expand their skills, grow their skills faster. And I've seen that happening.

leaders or experienced workers or engineers, builders, they know how to manage stuff remotely and they have done it probably equally well when either they are in the office or in the remote world.

Maulik Sailor (29:13.248)
When you talk about remote, is like remote in country or remote anywhere?

Munir Parikh (29:19.762)
Now currently in Amazon it's remote in country or at least because again remote anywhere has a kind of a different

angles to it right like we need to look for what is that you are optimizing for by having a team especially when talking about six to eight people now having that team split across time zones because mostly when they were talking about out of country it will be like some people here some in your states some people in Europe or maybe some people in Asia somewhere so that whole thing kind of brings additional challenges so we need to look for what is

If you are optimizing for efficiency with this time zone difference and all that will always bring a lot of challenges. Right at the same time if you are optimizing for talent then the talent is basically maybe there is a specific talent you are looking for and that is available only in certain part of the world or certain individuals and then at that point you have to adjust to that. And then I think there is also an angle of optimizing for cost but if you are doing that

expect efficiency or good talent, but then you have different reasons to optimize for cost. So it's something what you're optimizing for, but in standard team, I would say in a single two pizza team, having multiple folks across country would make things really, will slow us down for sure.

Maulik Sailor (30:49.476)
Okay, cool, interesting. I have a slightly different take over there. Now, in terms of your state about optimizing for talent or cost, right? I think my approach generally is to optimize for the attitude basically and the culture. Because I'll give you a small example. I'll ask you a question, right? Tell me about top designers, like fashion designers. Where do you think they come from?

Munir Parikh (31:20.12)
Paris, France or maybe New York or London yeah that's true

Maulik Sailor (31:21.588)
Paris or Italy, and see, I mean, Armada, Gucci, you know, all those things. So generally I have seen that Italians or certain Europeans like Spanish and Italians, they're very good in terms of creative sense, like, you know, design and all those things, right? Generally, like, you know, Americans, they're very good with like, you know, past space, you know, decision making, you know,

Again, communication, they're really good with communication and presentation and all. Generally, like, you know, Central and Eastern Europeans, they tend to be very detail-oriented. You know, they follow the instructions well. You know, again, given to their past in the Cold War past with the communism and all, they tend to follow instructions very well. You know, that's ingrained in their behavior and so on. So that's what I look for, that, you know, in a team.

For certain roles, I want to risk takers. I want people to break rules and just literally challenge the norm. Whereas in some teams, I want them to follow the rules. I don't want to experiment too much. I would just want them to make sure nothing is broken, just calm and carry on kind of approach. Depending on that, I tend to build different teams in different locations. Again, I'm from India like yourself, and I have done a lot of work in India as well.

Munir Parikh (32:33.506)
Yeah.

Munir Parikh (32:37.527)
Night.

Right.

Munir Parikh (32:44.525)
Yeah.

Maulik Sailor (32:47.616)
And again, in India, the attitude tend to do very a lot from where you're hiring people for. So I think that is what I normally optimize for. And then the cost, you know, cost is always there. But I generally believe that, you know, if you want to, you can't compromise on quality and the outcomes, you know, for the cost. If you want something cheaper, it's only going to bite you later, you know, and it's mostly going to be quite expensive later on, right?

Munir Parikh (32:51.746)
Mm-hmm. Okay.

Munir Parikh (33:10.818)
Right. Yeah.

Yeah.

Maulik Sailor (33:16.924)
And anyways, but we have found some really good talent, you know, in different countries. You know, right now I have a fully distributed setup with people working in, I think, maybe six countries, if I'm not wrong. Yeah. But what we optimize for, you know, you mentioned about the time zones and all, which is definitely is a challenge when people are in different location. But imagine, let's say you have a team in the US, you have four time zones, right? So

Munir Parikh (33:26.411)
Mmm.

Munir Parikh (33:31.669)
Oh wow.

Munir Parikh (33:40.453)
Yeah.

Munir Parikh (33:46.156)
Yeah.

Maulik Sailor (33:46.368)
you still got to work across multiple time zones, right? So what we do is dictate like a core working hours that, hey, for example, GMT 10 to four is our core working hours. And regardless of where you are, you've got to be available during that time for your team, basically. So we try to, like, you know, like there's a lot of flexibility, but we still try to create like a baseline framework that, okay, you know, this is like a rule that you cannot break.

Munir Parikh (33:59.936)
I see.

Hmm... Yeah. Alright.

Munir Parikh (34:13.835)
Yeah.

Maulik Sailor (34:15.992)
Kind of.

Munir Parikh (34:16.402)
Yeah, and I think what you just mentioned is very important. You respect your weather, even not only in kind of country, right? Even if remote, even within the same country or even the same team, even if you are in the same location.

defining those team norms with specific rules and say, this is the time all of us are going to be available. And then, because there are individuals who want to start their day early, like maybe there are early risers who want to start their day 7 a.m., but then there are people who start their day 11 a.m. So within even same city, you now have five hour lag between two individuals on your team. So that what you define, decide, what you mentioned at the end is actually super important that you need to have those norms within team.

Maulik Sailor (34:48.568)
Hmm.

Maulik Sailor (34:59.08)
Cool. I just want to ask a slightly different question, right? AI is doing backgrounds nowadays. You don't have to divert any sensitive information from Amazon, but asking, right? Do you guys use AI in your delivery processes?

Munir Parikh (35:05.205)
Yeah.

Munir Parikh (35:09.527)
Right.

Munir Parikh (35:15.674)
Um, yes, so we have started exploring that. I would say we are, I would not say, and I would not give again, a lot of details behind that, but we have definitely started exploring that. Of course, some of the services you heard about from AWS itself, like Code Whisperer or even Code Guru and all that, which kind of provides you some of the, um,

developer productivity utilities. So that is already kind of started adoption internally too. Of course, there are internal initiatives that we are working on, even in the space we are operating to kind of.

make better life for our customers. But in general, I see across industry, there has been an adaption and that adaption is kind of rapidly increasing across board. So the use cases I can definitely see even the few companies that I'm kind of mentoring or coaching or helping, like the automated AI chatbots or answering some of the common questions for our customers or in general, kind of automating your day-to-day workflows.

is something AI is definitely accelerating a lot and that has impact on the work we do internally too.

Maulik Sailor (36:28.792)
I'm also exploring some good AI tools, right? I mean, recently I experimented with a forwarding name, but it was an AI tool to generate the wireframes, basically, high fidelity wireframes in Figma. You give the instruction that, okay, I want a dashboard with XYZ features. And I tried completely random features, like, you know, not like a business dashboard or anything, like really weird situation that, hey,

Munir Parikh (36:40.278)
Hmm. Oh, okay.

Munir Parikh (36:52.27)
Good night.

Maulik Sailor (36:56.388)
I want to build a dashboard for this and it was actually very good. It actually created the basics fairly good. I was I was pleasantly surprised.

Munir Parikh (36:58.151)
I see.

Munir Parikh (37:01.494)
Wow. So is it like a, is it a plug-in to Figma or is it a separate thing which Figma provides or? OK.

Maulik Sailor (37:09.584)
It no, it's a separate tool. It's called use Galileo. I just remembered use Galileo.ai and you just tell it like, you know, you, you give input that, okay, I want dashboard to have XYZ features. Uh, it will generate the entire user journeys, uh, in the tool itself. And then you can download that as a design system into Figma and then make whatever changes you need to do. Um, so for me, that was like a, like a groundbreaking tool because

Munir Parikh (37:17.706)
Yeah. Right. Yeah.

Munir Parikh (37:25.453)
Right.

Munir Parikh (37:29.003)
Nice.

Maulik Sailor (37:37.408)
generally that process would take us about a week. And I can see that the weeks worth of work was done within like few minutes. So I was pleasantly impressed by that. And something that I'm like now keen to adopt in our internal team. Plus there are a few other tools we are using as well. We are also having a lot of AI stuff on our platform. But moving off from AI a little bit, is there anything else that you're seeing can have massive impact?

Munir Parikh (37:42.508)
Yeah.

Munir Parikh (38:06.67)
Yeah, I've been actually following a lot AI, but at the same time, I'm like, okay, if AI is going to free up a lot of bandwidth from individuals, like, what are the what are the things that we can do, or it's kind of happening, we should we should accelerate, right? So one of the sorry. No, that's a good one. No, I think in general, I think I was like looking at what are the

Maulik Sailor (38:21.336)
TikTok Reels? To making TikTok Reels? Hahaha!

Munir Parikh (38:32.894)
like when there was a wave of digitization or big data computing and automation, like what are the industries or the segments that were not kind of, that did not move fast enough, right? And this is where two or three came up kind of quickly in my mind. Like, so the healthcare systems are still kind of relatively backward.

So that's why investing and then redeploying some of the bandwidth or even leveraging AI tools on modernizing healthcare systems or healthcare in general, life science and healthcare, is going to be accelerating. Education is another one. The way our schools and even universities, some of the things that are happening has not changed for years. Even pandemic did brought a little bit of digitization or virtualization of this education, but

I feel that space has a lot of opportunity to catch the wave. And then government portals or how our government operates, there also that leveraging technology is not greatly...

done well and that's where I think those are the areas definitely the digitization of these three industries is one thing. The other one is I personally kind of very excited about it. I'm kind of following closely the whole interplanetary travel and the kind of our ability to go to Mars and landing on moon and all that stuff that's happening. The SpaceX and Blue Origin and all those kind of private organization exploring

travel to space more affordable and maybe accessible to all. That's industry I feel is going to be fun to watch. The VR and what's your reality which was kind of.

Munir Parikh (40:28.67)
Of course, it has its own pros and cons, but I feel with some of the AI tooling and AI thing available, VR or augmented reality is going to be a space where more and more innovations will happen. And then last one is, of course, the whole green energy and EV side of the world. There we see when governments, all governments across world are kind of now pushing more for it, promoting it, even United States recently

legislation to kind of reduce some of the promoting EV in the next 10 years.

Maulik Sailor (41:10.084)
I think quite a lot you covered that, right? But in that, like, you know, what you call the sustainability transportation, right? I think I'm quite a bit about the hydrogen fuel cells, right? I think battery, I'm not too sure. You know, there's a lot of negativity around that, but like, you know, hydrogen fuel cell is something that I'm quite a bit, you know? And I definitely want to try, you know, Toyota, they launch.

Munir Parikh (41:17.464)
Yeah.

Mmm. Right. Yeah.

Yeah.

Munir Parikh (41:29.398)
I'll just turn it off.

Munir Parikh (41:33.986)
Yeah.

Munir Parikh (41:37.997)
Yeah.

Maulik Sailor (41:38.63)
this real self car. I've seen it on the road moving here in London, but I would like to buy one at some point. Yeah.

Munir Parikh (41:42.111)
Okay, I see.

experiment. Okay. Yeah, I think the Japanese like that I see difference between the approach from the American and some of the European automakers versus the Japanese one. I think Japanese are kind of focused a lot more on the hydrogen based. So it's going to be interesting to see where we land. But in respect to that, in general, the greener energy is going to be something I will see a lot of innovation, I'm pretty sure.

Maulik Sailor (42:10.932)
Yeah, cool, cool. All right, I mean, I'm just mindful of our time. And I think our conversation can probably carry on for another 15, 20 minutes. I'm not sure, maybe longer. But I think maybe our time for us to wrap this one up. But I would like to ask you a few questions that we normally ask like everybody, every guest we have. So, feel free to answer them as you like, but these are generic ones, right? So...

Munir Parikh (42:28.622)
Sure.

Munir Parikh (42:35.786)
Yeah.

Munir Parikh (42:39.438)
Sure.

Maulik Sailor (42:40.902)
Personally, to you, who do you think that is one person or an event that motivated you the most in your life or career?

Munir Parikh (42:53.246)
Yeah, I think I mean, if you talk about the personal side of it, my dad, of course, has a big impact on who I am and how I operate. But in general, sports, anything I'm big fan of sports, I follow a lot of sports and I can watch any sport anytime.

And one of the sports which of course we being Indian is very close to is cricket. And then Sachin Tendulkar is someone I feel has inspired me a lot. And when the whole cricket like when you believe like there is a pressure on you, you are the one like whole nation is kind of relying on. And then taking that pressure and then still performing is something is amazing talent and which probably a lot of people don't realize till you are in that like

stage where the whole 100 crore people is kind of expecting you to perform and then you end up performing. So that's something I learned a lot from him how to handle things when you are under pressure especially as an individual.

But yeah, I would say Sachin Tendulkar is someone has I've been always following him, how he handles situations and off ground or on the ground or on the field when he's playing.

Maulik Sailor (44:13.028)
Yeah, no, definitely, genuinely a genuine gentleman, I would say, you know, I'm not a big follower of sports or cricket in particular. I'm probably one of the Indian out who doesn't watch cricket a lot. But never mind, I have watched his biography, actually, such as biography. And there's something that quite interesting came out in that. So apparently, during playing cricket, most of the time, he would not get bowled out. Right. But if he did.

Munir Parikh (44:20.066)
I see. Okay.

Munir Parikh (44:28.366)
Mmm.

Maulik Sailor (44:42.136)
got bowled out in any of the occasion. Post match, he will practice the same bowl and the shot like you know thousand times, you know ten thousand times until he's sure that he will never be bowled out again. He'll just keep practicing the same shot you know for as many days as needed to be confident that this will not happen never happen again.

Munir Parikh (44:53.422)
All right. Bye.

Munir Parikh (45:06.486)
And that is one of the things I think sports teaches us, right? Like the perfection, like practice, practice and practice. That's it.

Maulik Sailor (45:09.73)
Yeah.

Maulik Sailor (45:13.14)
Yeah. And I was like, you know, how can you like, you know, just do one thing for like continuously for so many days, you know, how can you, how can you, what kind of mindset do you need for that? You know, how much focus you need to do that? You know, that was like, you know, amazing for me. And that is one thing that I really learned. I think I personally really learned from him, you know, after that, after that biography that I watched. Yeah. Okay. Another question. Is one person living or dead?

Munir Parikh (45:19.97)
Yeah. Right.

Munir Parikh (45:37.046)
Right, nice.

Munir Parikh (45:41.863)
Uh-huh.

Maulik Sailor (45:43.16)
that you would like to meet, if you can.

Munir Parikh (45:47.67)
I think, I mean, I would probably go back in history. I mean, in general, I like history and reading about history. I think one person, if it's just one person, then there are many actually, but Alexander the Great. I think he's one, I would be definitely curious to just sit next to him and think, understand his thinking. When you're talking about someone who is kind of

ruling, starting to rule kind of something like Macedonia in like 20 years and then expanding it to probably one of the biggest

largest empire when he turned 30. So it's just like when you're in 20s, even if I compare myself, my thought process and what I was thinking of in 20s versus what he would be thinking, I would definitely like to go back and sit next to him and understand. It's like, what was your thought process when you said, I'm going to start fighting with Persia and expand into Persian territories and then keep expanding all the way, in fact,

Munir Parikh (46:56.64)
and then 30 years. So in 10 years he kind of just expanded that much. And just learning those strategies, how you are kind of being in so small country, but still envision to be this big in 10 years, and then delivering it, I think that's something, some really good lessons to learn from him.

Maulik Sailor (47:16.264)
Yeah, definitely. Definitely. I think in my 20s, I was like total loser, just to be honest. Right. Anyways, who do you think we should be inviting to this podcast, in your opinion?

Munir Parikh (47:22.885)
Exactly.

Munir Parikh (47:32.142)
like I mean you should it should be Elon Musk I guess I think he's good

Maulik Sailor (47:33.028)
Can we anybody?

Maulik Sailor (47:36.837)
Interesting, you know, we had somebody say that as well earlier. Yeah.

Munir Parikh (47:41.49)
Oh yeah? Yeah. I think he has... I mean of course everyone has positives and negatives, right? Nobody's perfect. But I think his idea about some of the things in future...

It always amazes me. Of course, there are a lot of things probably I would probably not agree, but at the same time, some of the things like when he was talking about Deslas, or now he's talking about SpaceX, all of this thing is like really, really 20 years, 30 years, 40 years in future. So just hearing him probably would be a fun.

Maulik Sailor (48:14.472)
Okay, cool. Interesting. We'll try. Let's see. We can grow a podcast to a level where he'll be interested to come in. Would be good. But yeah, we had another guest as well mentioned about him that, okay, try to get him. Well, we will someday. Yeah. Anyways, I think it has been a great pleasure, I would say, to talk to you and, you know, discuss some of the practices that you follow at Amazon. And I would like to thank you.

Munir Parikh (48:16.93)
Hehehehe

Munir Parikh (48:26.298)
Okay. All right.

Munir Parikh (48:32.834)
Yeah.

Maulik Sailor (48:41.048)
for making the time and joining this podcast with us. So, you know, to our audience, if you want to listen more of this podcast, then please subscribe to our channels on YouTube and Spotify or also to our newsletters. And if you're an employer, who's looking to hire or build best tech teams, then sign up on our platform and see how you can leverage AI to find gaps in your team and recruit talent accordingly.

And if you're a talent, then why don't you sign up as well on our platform and invite your colleague to create a full stack team and get hired together. You know, that would be exciting. You know, so thanks a lot to everybody, to you, Muneer as well. And tune in soon for the next episode. Thank you very much. Thank you.

Munir Parikh (49:31.095)
Bye. Thank you.

‍