The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. The biggest challenge with modern data systems is understanding what data you have, where it is located, and who is using it.   Select STAR's data discovery platform solves that out of the box with a fully automated catalog that includes lineage from where the data originated all the way to which dashboards star will set everything up in just a few hours. Go to Python podcast. Star will set everything up in just a few hours.   Go to pythonpodcast.com/selectstar   today to double the length of your free trial and get a swag package when you convert to a paid   plan. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.  

With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.   And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.   Go to python podcast dotcom/linode   today to get a $100 credit to try out their new database service, and don't forget to thank them for their continued support of this show. Your host, as usual, is Tobias Massey. And today, I'm interviewing Jigar Desai about building effective engineering teams. So, Jigar, can you start by introducing yourself? Yeah. Thank you for inviting me, Tobias. I'm Jigar Desai,  

[00:01:43] Unknown:

head of engineering at SISU Data,   and I've been there for 6 months. Prior to Sisoo, I was at Facebook for 5 years.   And prior to Facebook, I was leading infrastructure and product teams at eBay and PayPal for almost 15 years.   So that's kind of my journey in a in a succinct way of putting things into perspective.  

[00:02:04] Unknown:

And do you remember how you first got introduced to Python?  

[00:02:07] Unknown:

Yeah. So   my journey with Python mostly started with automation.   So I used to write a lot of scripts   within my dev environment   to kind of make sure that everything was zipped up and it was stored somewhere else. This is pre GitHub days   where we were doing our own backups and things like that. But a lot of exposure to Python also came from OpenStack.   So we were deploying OpenStack   at   eBay and PayPal. And for those who don't know OpenStack, it's a private cloud environment,   and it's been written   completely in Python.   So that's where I got a little bit deeper into how Python works and scales   for capabilities   like private cloud.  



[00:02:50] Unknown:

As far as the topic at hand, in terms of the question of building effective engineering teams, I'm curious what you have found throughout your career to be some of the central challenges involved in being able to build an engineering team that is effective and some of the ways that you think about the definition of what effective means for a given team or context?  

[00:03:10] Unknown:

So I have been managing and supporting teams for last 15   years. And what I've seen is sometimes   it's a team of highly caliber individuals,   but the team overall is mediocre.   And then I've seen mediocre talent, but team is high performing.   And major difference that I've found in these 2 teams is   1 team is really clear about their goals and objectives. There is a clear vision in place,   and everybody is kind of moving in the same direction.   Versus lot of mediocre teams, they just don't know which direction they want to go towards.   And, like, everybody's pulling in different direction,   making 0 progress effectively.  

I think any team needs a very clear set of goals and vision.   And then there needs to be a structure in which they can execute really, really well.   So I find that as a major difference between a high performing team versus   a mediocre team.   And throughout my 15 years of journey, anytime I take over a team,   I first pay attention to what are we trying to do as a team. And is everybody clear about that?   Once that is done, the second thing that I pay attention to, are we structured right? So a lot of times, structure of the organization matters as well. If you have multiple teams competing with each other   or working on the same set of goals   or or in fact competing set of goals,   it just doesn't become an effective team. Right? You need to have clarity of vision, goals, and structure to execute on a common set of goals.  

So I think that's super important, and I think you asked me about what is an effective engineering team looks like.   Yeah. I mean, it's there is a qualitative part of it. There is quantitative part of it. Quantitatively, I think the team should be executing well. There should be a lot of throughput coming from the team, and that's probably measurable in bunch of things like you can look at their GitHub PRs and how many features are getting shipped on time.   But to me, most important thing is the qualitative feedback. Like, what are the partners of this team thinking about? Do they feel that they are right set of partners?   What are the customers feeling about this team? And just overall happiness of the engineering team. I think that kind   of gives you much more insight on how is the team doing overall. Is it really a high performing effective team, or do they need changes?  



[00:05:31] Unknown:

To your point of understanding what is the kind of shared vision, shared goals,   when you encounter a team where that isn't clear and there isn't really agreement about what everybody is trying to move towards, I'm curious how you have thought about the process of trying to   identify and establish and communicate that vision   and some of the kind of practices or utilities or kind of process that you've put in place to be able to   establish that, but also how to maintain that over the long run, particularly   as team members join and leave?  



[00:06:06] Unknown:

Yeah. That's a good question. I'm actually going through that journey at CSO as well. We are coming up with a 12 month product vision and road map.   The first thing is   to make things clear in your mind. Like, as I was ramping up, I was trying to understand what SISU does, who the customers are, and what problem we are trying to solve.   So I actually ended up spending a lot of time with our customer success team and customers to understand   where our product is doing well and where our product has gaps.   Based on that, at least I started to form that framework around what should be our product strategy. If I have to describe our product strategy in 1 or 2 sentences,   how do I do that? And then the second part was, if this was the strategy,   how do I convert that   into a vision for next 12 months?  

Now this is not an individual journey. Like, I can't decide the product strategy and vision alone. So I started pulling in, you know, what I call influencers   into the mix. These are the set of people   who really broadly influenced the organization, and they're part of setting up the vision and strategy.   So   multiple sort of rounds of conversations around, is this making sense? And what I try to do is I try to put as many things on paper as possible and circulate the documents so people can openly comment, transparently discuss   the gaps in the strategy.  

And what we try to do is build that document into a shape where   it becomes something that we can share in prod.   So it's super important to collect feedback from the stakeholders once it 1 opinion about the strategy and vision. Like, hey. Is this the right set of things that we are pursuing after? So I get feedback from the customer success team, feedback from the customers, and also engineers and product team. Once that journey is done and we are ready to share it broadly with the whole organization,   we kind of set some time to hear feedback from them.  

Now I'm kind of running a smaller team like 40 or 50 people. So we just opened up the document and everybody's commenting on that. And we're taking some time to kind of comment on it or tweak our vision and strategy   based on the feedback we received.   2nd step that we did was based on this vision, let's come up with road maps. So we divided our engineering team into 5 different priority teams, and each priority team has a clear sort of owner or stakeholder   who's responsible and accountable for the road map. So they spend a bunch of time to say, here is the vision to make this vision a reality.   This is the road map I'm gonna come up. And these here are the milestones that we have for each of the priority teams. Then, of course, after that road map and milestones are becoming clearer, we kind of share it broadly with organization   again.  

Make sure that they kind of believe in this is achievable set of targets.   And then we kind of start executing towards that. So 3 step process. 1 is coming up with a strategy and vision. Make sure that there is enough feedback we're getting from all the stakeholders.   2nd, kind of translate that into actual road map and milestones. Milestones. And 3rd, roll out those changes so that everybody knows these are the goals they're actually going after.   So in every step, we need to make sure that people are involved.   Their opinions are being heard, and not for just hearing them out, but also making sure that changes are happening to the strategy and vision based on their feedback. And then make sure that it's not a surprise to anyone in the organization   when this change actually rolls out. So I've now done this maybe, like, 5 or 6 times   to kind of change the direction of the organization or vision of the organization.  

And it's always challenging. I don't think so things get simpler.   But, you know, with the process in place, it just becomes easier to conduct this kind of changes.  

[00:09:50] Unknown:

In some of my experience, there's also the question of,   you know, a team versus just a collection of individuals who are working on the same thing.   And 1 of the points you made is having that kind of shared vision, shared   view of what is the overall objective.   But what are some of the   challenges that you've seen in being able to get people   kind of bought in or motivated or excited about that objective versus just saying, okay. Just hand me the next piece of work. I'll get that done. And not really keeping an eye toward the longer term goal or longer term vision of just, you know, just give me the next ticket. I'll get it done. And then, you know, how do you move from that to, you know, we're working as a cohesive unit, as a team, kind of engaging with each other and with the broader organization because we actually care about the work that we're doing?  

[00:10:36] Unknown:

In my mind, a lot of times,   people just kind of think about taking tickets or tasks from someone when they don't have enough context on what problem they're trying to solve. So what I generally do is set a lot of context on   what is the problem,   bring customers into the mix, and explain why we need to solve these problems.   Also, the vision and strategy should be focused on the problem set rather than solutions. So a lot of times people make a mistake where they mix up   vision with solutioning.   So they go into a lot of details about how you can implement things rather than what needs to be implemented.   So having a clear boundary between   here is the product vision. This is what we want to achieve in next 12 months from a product point of view, but there is no micromanagement in terms of how.  

Then the conversation kind of remains at a high level where engineers, instead of really focusing into   a particular milestone or granular task,   they still keep their focus on high level problems that we wanna solve. So really elevating this conversation towards customer problems and product vision, how it solves those customer problems,   is the key to keep this conversation   away from task based sort of mindset   and more focused on, hey. Let's look 12 months as a whole and figure out what we need to do as a team. So setting up that context is the most important thing, and I feel   lot of engineering teams that I work for and even I learned this hard way that if you don't set this context,   people will be looking on a daily basis what should I be doing, and I need somebody to tell me what that looks like. Absolutely.  



[00:12:16] Unknown:

Another challenge   in being able to build that team cohesion   is having   an environment of trust and kind of shared empathy   where you don't have to be fearful of asking questions or raising your opinions because, you know, maybe you'll get shot down by a more senior engineer saying, oh, that doesn't make any sense, or   saying, oh, well, why don't you already know that? You've been here x amount of time. I'm wondering what are some of the practices that you have engaged with to be able to kind of build up that shared understanding and empathy that this is a safe space. We're here to do the work, and everybody has questions. It's okay if you don't know exactly what to do in this situation.   You know, we've all been there, and just kind of making that a an implicitly understood but explicitly   enforced kind of safe space.  



[00:13:05] Unknown:

I think, you know, it starts with the leadership. Now at CISU, I have been lucky that our environment has been pretty collaborative and open. But I have been in other environments where, you know, this level of transparency   and empathy was missing. And I think 1 of the reasons is leadership at the top did not show that level of empathy either. Like, for example, if I'm in the meeting   and if somebody feels   unsafe raising a question   or challenging me openly,   then I have failed to set that culture within within the organization.   Like, as I take any kind of role, leadership role, I make sure that   this level of trust builds up pretty quickly.  

So I encourage people to ask questions. And instead of saying, well, this question doesn't make any sense, or why are you asking such questions?   Every question I take it as seriously as any other question   and making sure that I use those opportunities to set the context that I could have said. In some cases, it's actually good to even say that I've never thought about this, and thank you for raising this question, and we should actually take an action item on that. So I think if the conversation is merit based in terms of ideas   and points raised,   it kind of creates that trust based culture where   any person,   irrespective of their seniority, should feel comfortable   asking those questions.  

Like, I worked at Facebook for many years, and it was quite common that an engineer would come to me And they'll say,   I don't think I agree with your vision or strategy. And I would say, well, thank you for saying that. Now let's sit down and figure out   where I'm not able to explain it to you, or maybe there is an actual issue with the vision and strategy.   So I think that level of culture starts at the top, and it has to trickle down all the way to the bottom. But if I don't exhibit those qualities,   then others in organizations will also mimic my behavior.  

And then the culture will become toxic in terms   of pointing things at each other or not having that open environment where healthy discussions can happen. Another interesting aspect of kind of building and maintaining trust and establishing  

[00:15:10] Unknown:

kind of clear vision and purpose is the   size and organizational   structure and complexity of the team, which you mentioned that the team you're responsible for right now is in this realm of 40 to 50 engineers   broken up into   5 kind of smaller subgroups.   And I'm wondering what you have seen as some of the ways that the challenges of kind of shared vision, shared purpose,   you know, shared empathy   compounds as you are trying to encapsulate larger and more varied groups?  

[00:15:39] Unknown:

Yeah. So I've been fortunate   in terms of leading   teams of this size of 40 to 50 people small and very big team sizes up to 700 people as well in my previous life and previous experiences.   So I've seen the journey of, like, hey. For a smaller team, maybe it's easier to set vision and goals. But as your team grows from, let's say, 50 people to 500,   things may fall apart. And I've seen it many times happening as well.   And mostly, it is a issue of communication. Like, if I'm just dealing with 40 to 50 people, it's actually easier for me to almost communicate to them on 1 on 1 basis if I have to. I don't do that. But if I have to, I could actually do that. But once you reach a scale of 500,   you need to rely on lot more other factors in terms of communicating context   and trickling down these changes.  

So the way I've done it when I was running a 5 500 to 600 people team   is this exercise of strategy and vision is pretty similar. So instead of, of course, involving 4 to 500 people,   you involve a much smaller set of people who I call it influencers or sort of senior leadership within the team.   In terms of communication, you have to start broadcasting   when you are dealing with 4 to 500 people. So instead of dealing with 1 on ones,   those kind of communications happen in all hands or written documents   or, like, you know, if you are in Slack, written messages.   So 1 of the things I've observed that it may take 10 times or 30 times   before covering a team of 400 to 500 people.  

Every time you put the message out, you're probably reaching out to 10 or 20 people at a time because   not everybody is paying attention to your post.   And,   lot of times you assume that I've already written down this communication for, like, 5 or 10 times, but maybe it just reached   25% of your overall organization.   So I feel communication is, like, 1 of the most important factors in bringing changes   and communicating about the vision and strategy to such a large org. 2nd factor that I also observed and kept in mind is structure itself benders. So if you have team structure that is not clear, where roles and responsibilities are not clear,   even though vision and strategy, they look really clean,   they don't know how to implement because they just don't know what their roles are. So   a change that happens on the vision without   a right change on the structure side,   I think is bound to fail. So almost 90% of the times, all of my changes that were around strategy and vision,   they were followed by some of the organizational changes to make sure that   people understand their roles and responsibilities. Like, a clear example of it, when I was at eBay, we were trying to create the private cloud and platform as a service,   and it was super important that the layers were key. Like infrastructure as a service, they knew what they were doing. And platform as a service were building a layer on top of infrastructure as a service, not sideways.  

So it was super important to clear that those roles and responsibilities.   And when you actually add vision and strategy to it, it becomes easier for people to understand what role they're gonna play going forward in this larger mission. So I think those 2 are the main factors, I would say.   Clear set of roles and responsibilities   and constant communication with the team on vision and strategy   are 2 pillars for larger teams   to kind of buy into this.  

[00:19:09] Unknown:

On that question of role and responsibility,   that's also a   very kind of flexible and nebulous concern where   as the team grows, your role and responsibilities are going to change. As the product focus shifts, your role in that might change.   And I'm wondering how you have gone through the process of balancing   that kind of dynamic aspect of what are your responsibilities,   where that might differ because of the phase of a project, you know, your position in the team,   your title, you know, how the team is organized, and just kind of what the   other areas of expertise are among your team members. And then alongside   that, the question of   how do you help   to understand what that evolution looks like as somebody, you know, gains experience or   gains interest in a particular area and   understanding what is their kind of career path and maybe career ladder isn't even the right term because you don't always wanna just go up. You might wanna go sideways.  



[00:20:07] Unknown:

Yeah. I mean, I think I see this in 2 parts. 1 is at the organizational   level. As an organization   scales and org scales,   they would require different kind of roles and structure. For example,   if your organization is 40 to 50 people,   maybe some of the functions are not clearly defined. Like, we have a function called SRE or DevOps,   and they are kind of, like, 4 or 5 people working everything from releases to deployment.   As your org scales,   you start feeling that there are specialized skills needed in some of these areas. For example,   you start thinking about having a separate release engineering team   than a deployment team versus   somebody who's putting together test infrastructure.  

So there is an organizational   scaling up and making sure that you're looking at all the roles and responsibilities in a meaningful way. Like, for example, you don't want a team that is 50 people   working on a smaller part of the product or a 50 people team that is called SRE team, and they're all working on all aspects of infrastructure and platform. So that's where you start specializing things saying, we need something for releases. We need something for testing. We need something for deploy. And with that, you kind of also start identifying people who can step into it. And oftentimes, what happens is you start looking at people, and they start taking interest in 1 of these areas. Like, somebody we just said in scaling the product up versus somebody's more interested in doing iterative development on product. So you kind of map those 2 things. Here are the organizational   needs.  

As the org is scaling from 50 people to 500,   here are the people who are ready to take on those roles. And then the third aspect is sometimes you realize, and many times I have realized, is you don't have the right set of and that means you to hire from outside.   Like, for example, security is a great example of it. Your security needs and posture changes   as the team matures and org matures,   And you have to hire people who are expert in certain things. For example,   I need to hire people more focused on compliance now because most of our, let's say, customers are asking for,   you know, some kind of certification around ISO or HIPAA or things like that. And you need experts who have done it before. Suddenly, in the 500 people organization,   there are things important in terms of building   some kind of platform so everybody can build an application on top of that, which was probably not needed when it was a 10 or 20 people team. So I think those are the 2 aspects that there is an org change. So how does an org evolve into a different structure that you mentioned dynamic structuring?  

And then there is a talent available,   and people may be eager to take on some of these roles because of their interest or passion.   And then sometimes you have to identify people that you need to hire from outside   because there are clear gaps in terms of expertise, and you need external expertise to come in and help out. So this is how I kind of see, like, a 3 different ways of   scaling up the organization.   And, of course, lot of this ties back to growing the individuals and helping them out, you know, like scaling themselves up as well. So this can provide   really good career paths in some cases   as somebody is willing to kind of step up into a completely different role than they were doing it in the past several years.  



[00:23:27] Unknown:

As far as that   kind of career   trajectory,   what are some of the structures that you have found most useful for helping people understand   where their potential gaps are in being able to achieve whatever that next level or next position might look like   and when to kind of rigidly define, these are the kind   of job positions that we have, and when to say,   okay. This person is a great fit for a number of different things, so we actually should just create a position for that. Or, you know, the org is growing in a certain direction, so we need to identify a new role for being able to help with moving in that direction.  

[00:24:07] Unknown:

It's super important to   first bring clarity in terms of what   the technical ladder looks like. Like, how do engineers see themselves growing?   So at Sysu, we have clearly defined   technical ladder that, hey. You could be an entry level engineer.   Here is how you can get into a senior software engineer,   staff engineer, and so on and so forth. At every level,   it should be clear what the expectations   are of that role. And if somebody wants to go from level 3 to level 4, here are the set of responsibilities   they need to take on for being suitable for the next role. So I think having that clarity that there is a clearly defined ladder   where people can see themselves and how the next level looks like is super important.  

The second aspect I would call out is   having those conversations with engineers is also pretty important. So we call it this as a talent conversation   or a career conversations in this case,   where there is a conversation between a manager and an engineer,   and they talk about, hey. Here is where I am in my career. This is what I wanna do in next 2 years. Here are my aspirations now. Please help me out. These are the kind of areas that I want to actually grow on. I want to become a senior engineer. I wanna become a manager.   I want to actually go into a completely different role. So this conversation between manager and employee is super important.  

And what they put together is a career development plan,   which is like a document that is owned by the employee or engineer,   but it's been assisted by an engineer.   And what I generally insist is to have these conversations   at least once in a quarter, if not more, where there is an open conversation   on here is where the career is shaping up, and these are some of the areas of gaps that   manager can actually pinpoint to the employee that, hey. Maybe you I can help you out   growing and taking kind of responsibilities in these areas.   Offering you opportunities where you can actually,   you know, also demonstrate your skills. So I think second part of career development discussion is super important.  

The third factor is lot of times   traditionally when I was an engineer back in late nineties, there was just sort of 1 way of growing in career, and that was you become an engineer, senior engineer, and then you become a manager. So managerial path was the only path to grow. Now there are many ways of doing things. Like like, you could be an engineer. You can go all the way to distinguished engineer or fellow. And this is how Sisu has structured our,   ladder as well. The second part is there are different kinds of engineering profiles, and this is a question you were asking me before.   Some engineers are good at becoming TLs. They are, you know, kind of they have the qualities to kind of bring the other team members together. And this is like a traditional sort of technical lead role, which kind of little bit overlaps with the managerial role as well. But there are many engineers who just want to be deep engineers.  

They don't want to be TAs.   They want to be working on deep complex problems by themselves.   So how do we create sort of   path for them for these different profiles?   And what I've learned at my previous experiences and what we're doing at Sisu, that there are different profiles as you become   senior engineer. So TL is 1 profile, but a deep expert is a second profile.   A fixer kind of a profile could be a 3rd profile.   And all those profiles have a technical letter going all the way up to distinguished engineer or fellow. So instead of typecasting everybody into a technical lead,   we provide different ways of growing their career   based on their passion. I think in some cases, you are right that engineer   doesn't actually fall into a particular profile and their mix of 2 or 3, and that's fine too. I think they need to specialize in 1 thing at some point in time. But having those 2 or 3 sort of expertise   also helps in having a role which is much more cross cutting rather than wording. So I would say those 2 things, having a career development discussion,   clear technical   ladder defined for engineers and how to get from 1 level to the other 1. And third 1, just making sure that there are different profiles   and everybody is not typecasting to just 1 role is the way how credit development could be sort of a tool that could be applicable broadly to all engineers rather than a very few of them.  



[00:28:35] Unknown:

As far as that team composition question, we've been talking mostly about the engineering talent on a team, but there have been also a number of evolutions recently in the ways that you think about what a team should look like,   particularly if you're working in the data fields or kind of analytics, where   do you have 1 core team of engineers where they're very focused on a particular domain? Or do you have a number of engineers, but they're dispersed throughout the organization and embedded   in, you know, a team comprised of sales and marketing and business operations?   And   I'm wondering what you have seen too, what the particular kind of industry vertical that a company works in, how that influences the that you think about that team composition   and team structure?  



[00:29:20] Unknown:

Yeah. I have worked mostly in the technology companies. And what I've seen, there are some   common structures that all of these companies   generally end up having.   And the common structure looks like this, that there would be a horizontal team, which they would give different names like infra team or platform teams.   They would have horizontal concerns. They would be taking care of horizontal concerns like   infrastructure or how to build platform on which everybody can build application,   doing release management, creating test infrastructure.   So those are the horizontal teams. We had it at eBay,   PayPal, Facebook,   and even Sysu has this horizontal team that is much more focused on lower aspects of the stack.  

And then when you go into the product world,   things become interesting. And that's where a lot of domain specific   sort of context comes into the play. So, typically, what I've seen is   it kind   of maps to the verticals within the company. Like, for example,   at Facebook, we used to have teams called, like, Facebook newsfeed,   and then there was a team on Instagram, and then there's team for WhatsApp,   and there was a team that was focused on advertising.   So these were the verticals that mattered to the overall business and product team, and that's how they were kind of sort of structured organizationally.   And similarly, we had things at eBay and PayPal. They were much   more vertically focused on, hey. Here is the payments team. Here is kind of a UI team that is focused on wallet experience   and so on and so forth. So   horizontal,   generally keeping it constant that everybody kind of focuses on infrastructure and other   horizontal concerns.  

And verticals   vertical team structures are generally influenced by the domain itself.   What I see is in terms of expertise and talent,   lot of times on the infrastructure side, they are   DevOps, SRE, and infrastructure distributed processing kind of talent coming into the play. On the vertical side is much more focuses on products. So for example, at PayPal, we used to hire a lot of people with payments experience,   and a lot of people came from banking background.   On eBay side, we hired a lot of people from ecommerce. So lot of people were hired from other ecommerce players.   And Facebook interestingly,   you know, focused not on other social   companies because Facebook was the first company   that was doing the social engineering or social apps. And and lot of the engineers were just hired out of college who are, like, brilliant set of engineers, and they were put into kind of working on the product engineering side of the world. So I do feel I think there is something common in all of these structures, organizational structures. And then there is a vertical domain that influences   the rest of it, like, mostly in the product engineering side.  



[00:32:05] Unknown:

As far as the   point that you were making earlier about when to bring in outside talent versus when to try and grow somebody into a specific role,   what are some of the strategies that you use to identify   what are some of the skills gaps that we have? Because a lot of times, if you are working in a team, people have fallen into a particular pattern   and,   you know, they demonstrate a certain set of skills that you can see because of the work that they're doing, but it can also be very invisible as to some of the other skills that they have or that they're interested in acquiring.   And so as you are starting to identify, okay, this is an area that we need to focus more effort. How do you kind of draw out some of that feedback of, oh, yes, this is something that I already know how to do. You know, I just haven't been doing it because I'm focused on this other thing versus,   you know, this is something that I'm interested in learning about and then balancing,   you know, that level of interest and kind of enthusiasm from the team against the kind of delivery constraints and timelines that you're trying to work toward?  



[00:33:04] Unknown:

Yeah. So there are 2 aspects that I generally kind of follow.   The first 1 is doing talent review.   So this talent review generally happens once every 6 months or 12 months,   but it's not happening in the just the current context. It's not about,   hey. What talent do we have and what are the requirements today?   But we look forward another 6 to 12 months that how is our organization   actually scaling?   What kind of requirements do we see coming our way in next 6 to 12 months?   Let's keep that in context, and let's map our   current talent   to our needs of the org for next 6 to 12 months.  

Now   that would give us a good picture   in which areas we are lacking, Telling. Like, for example,   a typical exercise that we had done in the past,   it would show up that   we need to really scale our organization from 200 people to 400 people.   If we double our organization,   we need a lot more senior talent. We need people who could actually play this role of horizontal tech leads   across multiple teams. Do we have enough talent in that particular area?   Or we need to actually build a next gen,   let's say, database solution   because we are almost reaching that scale with our current solution.  

Do we have expertise in database?   And if not, what do we do about it? So I think the talent review becomes a really good input in terms of here are the skills that we have today, and these are the gaps that we have. In the same conversation,   we could actually raise points around,   this is an engineer who's doing great work in this particular area,   but they've been actually passionate about this second area as well. Should we give them opportunity   and transfer them into that area and see how it plays out?   So sometimes talent review also includes   movement of the talent. Right? Like, moving from   1 area to another and see if they are able to rise to the opportunity.  

So that also happens during that. And the 3rd part, which is super important, is having those discussions with respective talent. Right? Like, as I was talking about career development plan. So it's good to have this conversation with engineers saying, hey. Here are the some of the gaps that we have with the org. What do you think? Are you interested in taking any of these opportunities   and try it out? Now in the safer environment as we were talking about before,   engineers generally get excited about these things. Right? Because they're not afraid of failing because there's an assurance coming from the leadership   that this is a trial. You can try this out. If it doesn't work out, you can always go back to your previous role. But we are providing you the safe environment to try something different and see if you're interested in that. At the same time, you know, what I've seen typically when you're growing, let's say, double in size,   even the the talent that you have   currently would not be able to kind of fulfill all the requirements.  

So in parallel, we generally start looking for talent from outside as well.   And generally, hiring from outside takes somewhere between 3 to 6 months. So you need to kind of start doing this much in advance rather than reacting to situation at the last so it generally plays out as a combination of giving opportunities   to people inside the org who are either passionate or willing to take on different roles. And second,   also in parallel, start hiring some more talent because   I generally believe in overhiring.   Because most of the times, even if people shoot for overhiring,   they are generally   resource crunched.  

So I would rather get you to a stage where we are proactively hiring   based on the talent review   and filling in those gaps as fast as possible.   So, yes, it could be a combination of existing talent plus looking outside for some specialized talent could actually bridge this gap for, you know, next 6 to 12 months in my opinion.  

[00:37:01] Unknown:

Another   aspect of trying to kind of manage teams and it being a constantly moving target is the ways that engineering   as a discipline and the   associated skill sets are a constantly moving target. And I'm wondering what you have seen as some of the impact on kind of the constant evolution of tool chains and best practices and paradigms and   programming languages, etcetera,   have influenced the ways that engineers   think about the jobs that they do and their responsibility   and the,   I guess, impact that they have on the organization as a whole and, you know, kind of recognizing that fact where maybe   30 years ago, engineering was just another kind of department. You know, it was largely IT. They're a cost center. Whereas now,   entire businesses are built around software, and so they are very much the kind of value provider for an organization. And I'm wondering how that has changed the ways that, you know, organizations think about engineering capabilities, the way engineers think about their own capabilities,   and, you know, how that looks as far as the way that work gets done   and   the kind of investment that is made in   building kind of effective structures to help support that work.  



[00:38:14] Unknown:

So when I graduated in 95,   there was no cloud.   Almost every software was shipped in a CD format, actually, all of it. You know, like, I remember I was working   for a bank,   and we needed some database.   And there was no really off the shelf database available at that point in time or no cloud database was available. And what I was told was, hey. Build 1 yourself.   Right? So this is what how the 95, 96 actually looked like. And   I remember building something which is very primitive on in in the Unix operating system   because we just did not have money to buy off the shelf, like Oracle database or something else.  

And since then, things have changed   drastically, right, with the invention of cloud and bunch of other technologies like machine learning that have come along.   What I figured it out, the most successful engineers are those who have ability to learn and change themselves.   So I've gone through multiple iterations of this   sort of innovations   that look like innovations at first and then they become mainstream.   And, you know, people who don't adapt to these changes, they struggle, and they generally become sort of unsuccessful   in their in their journey.  

Like, a great example of this is cloud journey. And   how many companies actually resisted cloud change when it was becoming mainstream   back in 2010, 2012.   And lot of, for example, operational folks, they wanted to work in a traditional way of, like, I would stare at the dashboard.   I would do every change manually   versus using automation.   And, you know, over time, what ended up happening is, really, everybody's using cloud and those jobs where you need to manually   log into a machine to do something,   they've all gone at this point in time. So people who did not adapt to this particular change, they're kind of out of the system. So I generally encourage all of my teams that look at the change with an open mind. This could be something new right now, But if there is a potential,   it is going to become a mainstream pretty soon. And there are number of changes that people have seen now in the span of 30 years. Some have resisted and some have kept really open minded in terms of learning it. So I do feel most successful engineers who have a long term successful career,   They've been all open to learning different things. Like, for example, I learned cloud.  

I learned, let's say, even Java when it came out. When I joined eBay and PayPal, I did not know how to actually build, like, a web services or web application.   So I learned all of them from scratch. I remember I had an interview, and they asked me about cookies, and I didn't know what cookies were back in 2002.   And to now, you know, like, all the way in 2022, we have been talking about   complete automation on top of cloud using using machine learning everywhere,   collaborative tools, and whole bunch of other innovation. So I think the essence of this is keep an open mind, keep learning things, and make sure that you're adopting   to this constantly changing culture all the time. So those are the tools I generally encourage. And when I'm interviewing somebody, I actually test people on this as well. Are you open to learning new things? It's good to have a point of view, but the point of view should not be like a fact of the better that you don't wanna compromise on. Like, it's okay to say this is how I work right now. But to say that I'm not going to change my ways of working,   even if something really good comes along,   that doesn't seem like a mindset of growth.  

And that generally,   like, I would think that that would be pretty risky hire at that point in time. So people who are able to learn, people who are able to adapt to different technologies are the most successful sort of engineers that I've seen or leaders I've seen in my kind of career of 25 years.  

[00:42:03] Unknown:

As you   project forward into the coming years based on the experience that you've had up to now, what are some of the ways that you see   engineering as a practice and team structures and   the kind of set of responsibilities   that are core to engineering versus how much of those   responsibilities or capabilities are moved into other units of the business because of different utilities like low code or no code or self-service platform access and some of the ways that you see kind of the team   dynamics and the work to be done evolving as we move forward kind of as   a engineering   capability   and more broadly as kind of a society or business focus?  



[00:42:48] Unknown:

I see that, you know, I mean, with COVID coming in,   the whole remote working has   really taken off. And even post COVID, now that,   you know, I mean, we're at a point where   some people have gone back to office, but a lot of people are working remotely.   So I do feel as an engineering team   going forward,   this collaboration, which is happening on the Internet rather than in person,   is going to continue. And we're gonna see many more tools   which would actually enable this collaboration going forward. Like, I think there are tools like Zoom and   GitHub. These are collaborative   tools. But, you know, I think replacing in person interaction with something   which is   much more intuitive for for engineers   has not been there yet. So I do feel in the coming years,   this whole thing around how do people across the world can come together as 1 team   and collaboratively work on that using those tools, that will become significantly important.  

The second thing which I see at least for next 10 years, in my opinion,   machine learning will become part of everybody's life. So machine learning has been a pretty special skill   in terms of, like, only handful of people are kind of focusing on it. But I feel machine learning will be everywhere in terms of   designing products. Like, you know, you're doing some recommendation, that's machine learning.   If you are kind of thinking about   some kind of data mining, that's machine learning. You're gonna learn about   developers' behavior where their productivity can be increased through machine learning. You look at bunch of such tools, which are not powered through machine learning today, will all be powered through that.  

I do feel as engineers to also adapt to this coming changes. Right? For example,   I still go to office, like, 2 times a week. But what if that gets completely replaced by remote working? I need to figure out what is the best way to keep in touch with everyone   while not overloading or texting them too much. In the case of machine learning, I feel this is just like we are in the 1st or second phase of evolution.   This is going to go in a completely different world that libraries and tools are going to be available   for all the engineers to leverage ML in their day to day life. So I think those are the 2 significant technology changes that I can see happening going forward, and it would have a huge impact on engineering culture.  

I think you did mention about low code or no code. I think it's definitely something that is picking up. I see,   lot of tools that are making developers' life much simpler.   The way I see it is there would be, like, certain tasks which are   completely automated. Right? And you can just use this kind of tools where you are writing just the configuration   or few lines of code to get the work done. And then lot of times, your energy will be spent in doing much more complex things.   So tools are enhancing,   and they're getting better and better. That means you can now focus on real set of problems   rather than spending your energy into something video call or, you know, really the task that should have been automated.  

So I feel that this will enable a lot more focused effort   and sort of deep like, energy to solve deeper problems   rather than superficial problems that people are spending too much time and energy right now.   So I would love to see that,   bunch of new machine learning algorithms coming up because now people have tools   to experiment   on thousands of compute and petabytes or exabytes of storage. So that would be awesome. So as more and more tools become sort of mature,   people will spend much more energy in doing innovative stuff   rather than mundane stuff that they've been doing. So I think if we are spending 50% of energy   doing in things which we should not be, in next 10 years or 20 years, I'll see that maybe 10 or 20% of it will be taken off or maybe all 30 or 40% of it. And we'll be all kind of becoming   more creative   and more focused on the problems that you wanna solve rather than peripheral issues.  



[00:46:50] Unknown:

In your experience   of   managing engineering teams and helping to kind   of grow the   team capabilities   while driving forward the vision of the business and, you know, ensuring that everybody is aligned for success. What are some of the most interesting or innovative or unexpected ways that you have seen   organizational leaders addressing that work of building and scaling that team capacity   and team throughput and   building kind of that cohesive vision and trust?  

[00:47:20] Unknown:

So, I mean, I think if you think about organization challenges as they're scaling up,   and   let's say you're kind of giving my previous example that you're doubling the team size. The question is how do you double a team size in a year's time? That means now you look at various ways of scaling up your team. Like in my previous experience,   lot of times those were hires that we did in colleges, like these were fresh schedules.   In 1 of the companies, we actually hired contractors   because we couldn't hire   FTEs or full time engineers as fast. And in another company, we kind of got consulting   companies   who would actually take on the projects.  

So   scaling at a velocity, at a very high velocity, brings a lot of challenges.   In my opinion, I think you wanna make a really good decision on how fast you want to scale because it has a lot of impact to your culture   and your ability to really sustain that culture going forward. So for example, in an environment where you're bringing a lot of contractors   and consulting,   typically, what I've seen is it kind of breaks down the culture because now suddenly you have   so many people who have not been part of this company   also kind of changing code and making changes to processes and things like that. So suddenly people feel like there are there is no really a feeling of 1 team when you are kind of scaling so rapidly.  

On the other side, when we were hiring fresh college graduates in 100,   it was also tricky because we need to train them. We need to make sure that they're actually becoming productive.   And that was actually putting a lot of tax on our senior engineers because they would have to spend so much time in just training and getting people up to speed.   So it's a super important decision to be made whether you want to scale at that velocity or not. In lot of cases, I would actually make a call that slow it down because it's better to conserve the culture   and making sure that you are doing the right hires   than just kind of scaling up in a crazy way.  

Despite doing all these precautions, there would be challenges. Right? There'll be the same challenges that I mentioned around how do you maintain the culture,   How do you make sure that all your processes are scaling up and they're not, like, completely falling apart? And what I generally do is having right set of people responsible for some of these aspects. So for example,   culture is super important. And, like, if I give my example   in my previous company,   we used to have 1 month of onboarding time. And this was not really to   train you on a specific technology,   but it was to make sure that you understand the culture well. And when you graduate out of that boot camp, you are actually almost ready to take on challenges, and you know how the organization   actually functions.  

So to me, that's super important that how do you how do you make sure that people understand your company's culture?   And for that, you have to have a proper onboarding program really going forward.   That is meaningful   in explaining how your company operates.   The second thing I talk about is ongoing training. So as an organization actually scales,   how do you identify the areas that you need more help   and there is a talent gap or there is a skill gap? And how do you kind of make sure that your engineers are   reacting to that and they are getting opportunity   to learn new skills?  

So making sure that there are programs around   learning new skills which are kind of fitting into your organization scaling   or just making sure that people are passionate and they want to learn something about it. How do you bring that to the table as well so that in future,   by learning those skills, you are proactively sort of kind of working on those gaps as well? So I would say   be cautious in terms of scaling your teams. Because if you go too fast, you're actually putting your culture and some of the values at risk.   2nd, I would say have a extremely robust onboarding program so people understand what your company's culture is, what your engineering culture is. And 3rd, keep on constantly having training programs where people can uplevel their skills so that they're constantly   sort of   reinventing themselves   and fitting into companies' needs as going forward. And your experience  

[00:51:35] Unknown:

of working in this space and being a leader to engineering teams and interacting with, you know, other leaders in the company, whether they're your peers or your superiors in the organizational hierarchy?   What are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:51:52] Unknown:

Yeah. So, like, I can give an example at Sisu.   Like, we are a small company, so you would imagine, you know, everybody understands   what our customers   need, what we need to build as a product, and large part of the company does understand. But as somebody who came in into the engineering org,   I found that,   you know, information was not trickling down. Like, for example,   lot of engineers were not sure about   what our customer requirements were.   And that to me was   really kind of jarring experience because   I thought there is information that is available everywhere,   but that doesn't mean that people are consuming that information.  

So information is there, but people are not consuming it. And this is what I got feedback from my peers as well that, hey. Your organization doesn't really know   what we need you to build. So I had to kind of work on that particular problem saying, well, how do I make sure that our engineers are spending time   in understanding   customer needs? They're spending time with customer success team. So we had to change certain sort of rhythm within engineering org. You know, we exposed them to a bunch of calls with our customers.   We made sure that we are kind of talking in all hands, company all hands a lot more about customer needs.  

Got a process where we could actually absorb customer inputs coming in a systematic way. And just that culture of customer centricity,   how does it trickle down in engineering is something I've been focusing on for the past several months. But this is definitely   is something very surfer surprising experience for me because I expected coming into a smaller team that this would all be fine and taken care of. And when my peers actually shared this feedback, I'm like, wow. I can see now that despite having access to all the information,   engineers are busy. They're spending their time in doing something else and not focusing enough on customer needs. Disconnects do happen in a larger org. I kind of manage teams which are much larger. And there, it could be that, hey. You are kind of in your own sort of island, and you are not connected to anyone.  

And you feel all great about how great things you are doing   within your org, but you get feedback suddenly that you're completely disconnected from the needs of the overall organization.   So this happens many times when there is just not enough trust between the teams, or there is just not enough time spent with your peer teams.   So in any of these cases, I do feel   listening to your peer feedback, listening to customer feedback,   and keeping an open mind in terms of how you can improve your teams   is a key to kind of bring those changes in. If you just start believing that you understood the product, you understood the need, and stop listening to all of this information coming to you, I think people will just get it wrong over time and your organization will feel. And I've personally gone through that experience as well where, you know, somebody gave me feedback that you just you guys are just not listening   to what the needs of internal customers are. And please go and do your homework  

[00:54:56] Unknown:

in terms of what the customer needs are and change your roadmap to reflect that. So I think these kind of lessons are super important to learn and make sure that those kind of mistakes could happen again in the future. And on the subject of mistakes, those are often some of the most helpful lessons that you can learn rather than just looking at people's successes. And I'm wondering if there are any other kind of mistakes or missteps that you've made on your path through engineering leadership that you found   particularly informative and helpful in   identifying and understanding   what not to do and how to kind of improve your skills that you're willing to share with the audience?  



[00:55:32] Unknown:

Yeah. Absolutely. I've done so many mistakes. I can go on for 2 hours on that.   In most cases, what I figured out is most difficult challenges that I've faced, they're not   technology challenges. They're people challenges.   So   most difficult problems are when people don't agree with each other,   and they somehow cannot even find a path to agree to each other   as well.   My important lesson learned is   lot of times I was pulled into such kind of conversations where   2 set of people are not agreeing.   And instead of taking a neutral stance,   I would take   a prominent sort of a stance or a particular stance saying this is right and this is wrong.  

And I thought I think that behavior was not right because they actually involve me as a neutral party to help them out.   And   before I understand   everybody's point of view or in this case, 2 parties point of view, and just kind of really   help out with the conversation.   If I jump to conclusion,   I'm actually,   you know, really impacting the outcome of this entire sort of, you know, process   in some sense.   So I've heard this and I've learned this the hard way where   my job I need to understand when my job is to   make a decision   and when my job is to just,   you know, help out with the overall conversation,   hear them out, and make sure that I'm helping them reach to a certain conclusion.  

So your roles actually are different.   And, you know, being a technologist   and having my own opinions,   I always found it easier   to to make a decision on something   rather than   helping out people   through this process of disconnect   and making sure that we are landing into   a good spot where both parties agree. In some cases, they disagree but commit. But it's an environment where healthy conversations can actually happen. So I've gone through this multiple times where I've made that mistake of taking stance to   prematurely   and really not helping the overall conversation. I think that's 1 of the things that I keep repeating   every time when I get brought into   dysfunctional   organization that my role is to play a neutral party   and, you know, really help the team out rather than   showing off how good I am in making decisions.  



[00:57:56] Unknown:

For anybody who is either working in engineering leadership or aspires to do that or is maybe a a team lead, what are some of the resources and reference reference material that you found most useful that you recommend people look to if they're trying   to understand more about the kind of context and practices and   considerations around being able to   build cohesion and maintain kind of direction and focus for an engineering team?  

[00:58:23] Unknown:

I would say there are just ton of books that are available on management and leadership,   and just there are too many of those books. I think   if somebody is becoming a manager, I would ask them to read,   you know, like High Output Management by Andrew Bro.   Like, this is a classic book that anybody can read and figure out what it means to become a manager.   There are leadership books like Good to Great. I think I really like that. Or Hard Things About Hard Things Now.   You know, the like, Ben Horowitz is 1 of the investors in SISU, and I just recently read that book again. So there are lots of books that people can read up on management and leadership that I really recommend people   spending time on that.  

Second thing, I do feel that,   like, having a mentor who can actually coach you   in some of this situation is super important too. So I have been privileged to have   really good mentors throughout my life.   And what I do even today is sometimes I run into a problem, and I reach out to my mentor.   They either listen to me and give me some advice, or they share their experiences from the past, and that's super useful. So thinking that you know everything and you can sort out everything by yourself is also not correct. So I would suggest that   make sure that you're kind of having a   relationship with your mentors or some other experience set of people whom you can reach out when you need help.  

And I think I would say third thing is   just being   kind of open to having this conversation broadly within an org with your peers.   I think that helps. Lot of times people keep all of these details to themselves,   all of their problems to themselves because they don't wanna show   that they are kind of facing problems or they have certain weaknesses or gaps in them. I actually suggest that, you know, freely share with people whom you trust   because you'll get a good advice. You'll get a maybe good support   from them. And I think your life becomes easier   if you kind   of open up rather than   hiding everything within yourself.  

So I would say reading books,   having right set of mentors, like, you know, who can coach you and guide you, and just be open about your problems and share it with broadly with people who can help you out. That always helps, and it's been helping me even after 25 years.  

[01:00:42] Unknown:

Are there any other aspects of the kind of work and considerations   and   goals involved in building engineering teams and helping them to be effective that we didn't discuss yet that you'd like to cover before we close out the show? I would  

[01:00:57] Unknown:

say, you know, lot of times,   we get too serious about everything,   about our goals, about our vision and strategy,   that we forget to   celebrate   certain milestones. We forget to celebrate   wins, and I feel that's an important part of engineering culture as well.   So when we come together as a team, when we were talking about vision and strategy and road map,   I think it's also equally important to celebrate successes,   celebrate wins,   recognizing people, making sure that   they not only feel that they have a lot of work to do in terms of achieving this vision and strategy, but everything that they're they're working on   is something getting recognized.  

So I do feel creating a stronger engineering culture   involves   recognizing   rewarding people   and celebrating successes too. So that's 1 part we didn't discuss it in-depth, but it's an important part of the culture and   just have fun while working.  

[01:01:59] Unknown:

Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. This week, I'm going to choose a movie that I watched a few weeks ago called Bullet Train, 1 of the newest ones from Brad Pitt, but just a really goofy, fun kind of action comedy movie.   Very entertaining.   Definitely recommend that for somebody who's looking for, you know, a few laughs for an hour and a half or 2 hours, however long it ran, but definitely just a fun movie overall. And so with that, I'll pass it to you, Jigar. Do you have any pics this week?  

[01:02:31] Unknown:

Let's see. I   am not into movies so far, but, you know, the movie that I saw and it stays in my mind even now is the Top Gun Maverick.   It's been amazing movie. And I watched Top Gun the first part   when I was, like, 12 or 14 years old. So it's came after, like, so many   years. And I didn't know   how the movie would be because, you know, like, things have changed.   But it's 1 of the really good movies that I've seen in the past, maybe several years. So   I highly recommend people kind of watching that. And, you know, it's the same rush that I had it when I was, like, 15 years old. It's just amazing. Tom Cruise does an excellent job. Did you go back and watch the original before you watched the new 1? I did. I did. How well did it hold up?   I like the new 1 better than the old 1 because the technology has evolved so much. Right. So all the scenes, they look so real now as compared to what it was   back in eighties.  



[01:03:29] Unknown:

It's always fun revisiting old movies and saying, oh, wow. I used to think that was actually good.  

[01:03:34] Unknown:

Yeah. It was good. It was cool back then, but this 1 is cooler. Exactly.  

[01:03:39] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share your experiences and expertise of working in engineering leadership and building effective teams.   It's definitely a very important aspect of the work that we do, so I appreciate all the time and energy that you've put into building teams at the various organizations that you've been in and helping to kind of share your experiences for the audience. So thank you again for taking that time, and I hope you enjoy the rest of your day. Thank you for having me.  

[01:04:08] Unknown:

Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. It. Email hostspythonpodcast.com   with your story.   And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.