How And Why To Build Effective Teams As An Engineering Leader

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Unknown (00:13):
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.

(00:44):
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,

(01:07):
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,

(01:42):
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.

(02:04):
And do you remember how you first got introduced to Python?
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.

(02:29):
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.
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?

(03:09):
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

(03:30):
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.

(03:54):
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?

(04:16):
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.

(04:42):
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.

(05:05):
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?

(05:31):
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

(05:52):
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?
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.

(06:14):
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.

(06:37):
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

(07:04):
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

(07:27):
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,

(07:57):
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

(08:27):
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

(08:49):
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.

(09:15):
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

(09:36):
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.
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.

(09:58):
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?

(10:36):
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.

(10:56):
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.

(11:23):
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,

(11:46):
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,

(12:08):
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.
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

(12:36):
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

(13:02):
enforced kind of safe space.
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

(13:27):
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?

(13:52):
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

(14:14):
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

(14:37):
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

(14:58):
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
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

(15:21):
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?
Yeah. So I've been fortunate

(15:41):
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,

(16:02):
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,

(16:24):
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.

(16:50):
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

(17:12):
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.

(17:35):
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,

(17:58):
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

(18:20):
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.

(18:42):
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

(19:04):
are 2 pillars for larger teams
to kind of buy into this.
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.

(19:25):
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

(19:48):
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.
Yeah. I mean, I think I see this in 2 parts. 1 is at the organizational

(20:11):
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.

(20:34):
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

(21:03):
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

(21:42):
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

(22:04):
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,

(22:27):
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,

(22:47):
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.

(23:08):
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.
As far as that

(23:28):
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

(23:49):
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.
It's super important to
first bring clarity in terms of what

(24:12):
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

(24:39):
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

(25:01):
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.

(25:24):
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

(25:46):
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,

(26:07):
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,

(26:41):
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.

(27:05):
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.

(27:29):
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

(27:50):
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,

(28:12):
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.

(28:34):
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

(29:01):
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?
Yeah. I have worked mostly in the technology companies. And what I've seen, there are some

(29:24):
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,

(29:46):
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

(30:08):
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.

(30:30):
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

(30:51):
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,

(31:23):
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

(32:01):
the rest of it, like, mostly in the product engineering side.
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

(32:25):
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,

(32:51):
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?
Yeah. So there are 2 aspects that I generally kind of follow.
The first 1 is doing talent review.

(33:12):
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?

(33:36):
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.

(34:01):
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.

(34:24):
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,

(34:45):
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.

(35:06):
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

(35:26):
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,

(35:56):
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

(36:20):
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.

(36:41):
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.
Another
aspect of trying to kind of manage teams and it being a constantly moving target is the ways that engineering

(37:09):
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

(37:29):
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,

(38:02):
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.
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

(38:26):
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

(38:50):
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.

(39:11):
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

(39:36):
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

(39:57):
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,

(40:33):
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.

(40:55):
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

(41:16):
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,

(41:40):
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.

(42:02):
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

(42:35):
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?
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,

(42:57):
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

(43:21):
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

(43:42):
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

(44:03):
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.

(44:25):
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.

(44:50):
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,

(45:16):
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.

(45:38):
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

(46:00):
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,

(46:22):
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

(46:43):
more creative
and more focused on the problems that you wanna solve rather than peripheral issues.
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

(47:09):
organizational leaders addressing that work of building and scaling that team capacity
and team throughput and
building kind of that cohesive vision and trust?
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,

(47:39):
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.

(48:03):
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

(48:26):
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,

(48:47):
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

(49:13):
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,

(49:40):
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

(50:05):
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,

(50:27):
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

(50:50):
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.

(51:13):
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

(51:35):
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?
Yeah. So, like, I can give an example at Sisu.
Like, we are a small company, so you would imagine, you know, everybody understands

(51:59):
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

(52:21):
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

(52:48):
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,

(53:17):
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,

(53:38):
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

(54:00):
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,

(54:24):
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

(54:50):
to what the needs of internal customers are. And please go and do your homework
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

(55:21):
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?
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

(55:42):
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.

(56:03):
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

(56:23):
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

(56:45):
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

(57:06):
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

(57:34):
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.

(57:56):
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

(58:17):
build cohesion and maintain kind of direction and focus for an engineering team?
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.

(58:38):
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

(59:03):
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.

(59:26):
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.

(59:48):
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

(01:00:15):
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:41):
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
say, you know, lot of times,
we get too serious about everything,

(01:01:02):
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,

(01:01:23):
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

(01:01:45):
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.
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.

(01:02:18):
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?
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.

(01:02:40):
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

(01:03:01):
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

(01:03:26):
back in eighties.
It's always fun revisiting old movies and saying, oh, wow. I used to think that was actually good.
Yeah. It was good. It was cool back then, but this 1 is cooler. Exactly.
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.

(01:03:48):
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.
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

(01:04:22):
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.

All Episodes

Summary

Announcements

Interview

Episode Transcript

Popular Podcasts

United States of Kennedy

Dateline NBC

Bookmarked by Reese's Book Club

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}How And Why To Build Effective Teams As An Engineering Leader