How And Why To Build Effective Teams As An Engineering Leader

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 4:25:46 PM
Duration: 3890.273
Channels: 1
1
00:00:13.165 --> 00:00:24.580
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.
2
00:00:24.880 --> 00:00:44.075
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.
3
00:00:44.455 --> 00:00:45.275
Go to pythonpodcast.com/selectstar
4
00:00:47.415 --> 00:00:51.540
today to double the length of your free trial and get a swag package when you convert to a paid
5
00:00:52.420 --> 00:00:59.080
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.
6
00:00:59.695 --> 00:01:06.995
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,
7
00:01:07.380 --> 00:01:13.400
including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.
8
00:01:14.180 --> 00:01:21.765
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.
9
00:01:22.065 --> 00:01:23.840
Go to python podcast dotcom/linode
10
00:01:24.620 --> 00:01:42.170
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,
11
00:01:42.710 --> 00:01:44.890
head of engineering at SISU Data,
12
00:01:45.350 --> 00:01:50.295
and I've been there for 6 months. Prior to Sisoo, I was at Facebook for 5 years.
13
00:01:50.835 --> 00:01:57.610
And prior to Facebook, I was leading infrastructure and product teams at eBay and PayPal for almost 15 years.
14
00:01:58.310 --> 00:02:03.610
So that's kind of my journey in a in a succinct way of putting things into perspective.
15
00:02:04.105 --> 00:02:06.525
And do you remember how you first got introduced to Python?
16
00:02:07.225 --> 00:02:08.125
Yeah. So
17
00:02:08.665 --> 00:02:11.645
my journey with Python mostly started with automation.
18
00:02:11.950 --> 00:02:13.890
So I used to write a lot of scripts
19
00:02:14.270 --> 00:02:15.650
within my dev environment
20
00:02:16.430 --> 00:02:22.485
to kind of make sure that everything was zipped up and it was stored somewhere else. This is pre GitHub days
21
00:02:22.864 --> 00:02:29.045
where we were doing our own backups and things like that. But a lot of exposure to Python also came from OpenStack.
22
00:02:29.680 --> 00:02:31.380
So we were deploying OpenStack
23
00:02:31.680 --> 00:02:32.180
at
24
00:02:32.560 --> 00:02:37.620
eBay and PayPal. And for those who don't know OpenStack, it's a private cloud environment,
25
00:02:38.435 --> 00:02:39.415
and it's been written
26
00:02:39.954 --> 00:02:41.095
completely in Python.
27
00:02:41.555 --> 00:02:45.735
So that's where I got a little bit deeper into how Python works and scales
28
00:02:46.480 --> 00:02:47.300
for capabilities
29
00:02:47.760 --> 00:02:48.980
like private cloud.
30
00:02:49.600 --> 00:03:09.330
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?
31
00:03:09.870 --> 00:03:13.205
So I have been managing and supporting teams for last 15
32
00:03:14.245 --> 00:03:16.265
years. And what I've seen is sometimes
33
00:03:16.805 --> 00:03:19.305
it's a team of highly caliber individuals,
34
00:03:20.085 --> 00:03:22.345
but the team overall is mediocre.
35
00:03:22.840 --> 00:03:26.540
And then I've seen mediocre talent, but team is high performing.
36
00:03:26.840 --> 00:03:30.060
And major difference that I've found in these 2 teams is
37
00:03:30.565 --> 00:03:35.864
1 team is really clear about their goals and objectives. There is a clear vision in place,
38
00:03:36.165 --> 00:03:39.144
and everybody is kind of moving in the same direction.
39
00:03:39.560 --> 00:03:45.180
Versus lot of mediocre teams, they just don't know which direction they want to go towards.
40
00:03:45.480 --> 00:03:47.660
And, like, everybody's pulling in different direction,
41
00:03:48.135 --> 00:03:49.835
making 0 progress effectively.
42
00:03:50.295 --> 00:03:54.155
I think any team needs a very clear set of goals and vision.
43
00:03:54.615 --> 00:03:59.010
And then there needs to be a structure in which they can execute really, really well.
44
00:03:59.390 --> 00:04:03.970
So I find that as a major difference between a high performing team versus
45
00:04:04.660 --> 00:04:05.970
a mediocre team.
46
00:04:06.325 --> 00:04:10.185
And throughout my 15 years of journey, anytime I take over a team,
47
00:04:10.565 --> 00:04:16.360
I first pay attention to what are we trying to do as a team. And is everybody clear about that?
48
00:04:16.820 --> 00:04:27.065
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
49
00:04:27.445 --> 00:04:30.105
or working on the same set of goals
50
00:04:30.565 --> 00:04:32.585
or or in fact competing set of goals,
51
00:04:32.910 --> 00:04:41.650
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.
52
00:04:42.034 --> 00:04:47.335
So I think that's super important, and I think you asked me about what is an effective engineering team looks like.
53
00:04:47.715 --> 00:05:04.634
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.
54
00:05:05.014 --> 00:05:14.530
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?
55
00:05:15.070 --> 00:05:21.795
What are the customers feeling about this team? And just overall happiness of the engineering team. I think that kind
56
00:05:22.175 --> 00:05:30.550
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?
57
00:05:31.250 --> 00:05:36.235
To your point of understanding what is the kind of shared vision, shared goals,
58
00:05:37.095 --> 00:05:48.389
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
59
00:05:48.930 --> 00:05:52.150
identify and establish and communicate that vision
60
00:05:52.675 --> 00:05:59.175
and some of the kind of practices or utilities or kind of process that you've put in place to be able to
61
00:05:59.699 --> 00:06:02.919
establish that, but also how to maintain that over the long run, particularly
62
00:06:03.220 --> 00:06:05.479
as team members join and leave?
63
00:06:06.020 --> 00:06:14.195
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.
64
00:06:14.580 --> 00:06:15.880
The first thing is
65
00:06:16.260 --> 00:06:25.875
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.
66
00:06:26.255 --> 00:06:32.275
So I actually ended up spending a lot of time with our customer success team and customers to understand
67
00:06:33.130 --> 00:06:36.350
where our product is doing well and where our product has gaps.
68
00:06:37.130 --> 00:06:46.135
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,
69
00:06:46.595 --> 00:06:50.695
how do I do that? And then the second part was, if this was the strategy,
70
00:06:51.139 --> 00:06:51.960
how do I convert that
71
00:06:52.260 --> 00:06:54.600
into a vision for next 12 months?
72
00:06:55.139 --> 00:07:03.595
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
73
00:07:04.055 --> 00:07:06.155
into the mix. These are the set of people
74
00:07:06.615 --> 00:07:12.590
who really broadly influenced the organization, and they're part of setting up the vision and strategy.
75
00:07:13.050 --> 00:07:13.550
So
76
00:07:13.930 --> 00:07:26.825
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
77
00:07:27.150 --> 00:07:28.530
the gaps in the strategy.
78
00:07:28.990 --> 00:07:32.290
And what we try to do is build that document into a shape where
79
00:07:32.670 --> 00:07:35.170
it becomes something that we can share in prod.
80
00:07:35.525 --> 00:07:56.525
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,
81
00:07:57.224 --> 00:08:00.604
we kind of set some time to hear feedback from them.
82
00:08:00.919 --> 00:08:11.855
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
83
00:08:12.315 --> 00:08:13.935
based on the feedback we received.
84
00:08:14.235 --> 00:08:27.395
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
85
00:08:27.935 --> 00:08:36.420
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.
86
00:08:36.880 --> 00:08:49.365
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
87
00:08:49.745 --> 00:08:50.245
again.
88
00:08:50.750 --> 00:08:54.290
Make sure that they kind of believe in this is achievable set of targets.
89
00:08:54.670 --> 00:09:04.605
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.
90
00:09:05.305 --> 00:09:14.670
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.
91
00:09:15.050 --> 00:09:18.270
So in every step, we need to make sure that people are involved.
92
00:09:18.925 --> 00:09:31.089
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
93
00:09:31.710 --> 00:09:36.529
when this change actually rolls out. So I've now done this maybe, like, 5 or 6 times
94
00:09:36.875 --> 00:09:40.655
to kind of change the direction of the organization or vision of the organization.
95
00:09:41.275 --> 00:09:44.255
And it's always challenging. I don't think so things get simpler.
96
00:09:44.560 --> 00:09:49.459
But, you know, with the process in place, it just becomes easier to conduct this kind of changes.
97
00:09:50.000 --> 00:09:53.060
In some of my experience, there's also the question of,
98
00:09:53.495 --> 00:09:58.074
you know, a team versus just a collection of individuals who are working on the same thing.
99
00:09:58.375 --> 00:10:02.394
And 1 of the points you made is having that kind of shared vision, shared
100
00:10:02.709 --> 00:10:04.649
view of what is the overall objective.
101
00:10:05.430 --> 00:10:06.730
But what are some of the
102
00:10:07.269 --> 00:10:10.250
challenges that you've seen in being able to get people
103
00:10:10.795 --> 00:10:35.905
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?
104
00:10:36.285 --> 00:10:37.825
In my mind, a lot of times,
105
00:10:38.220 --> 00:10:49.135
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
106
00:10:49.595 --> 00:10:50.735
what is the problem,
107
00:10:51.355 --> 00:10:55.740
bring customers into the mix, and explain why we need to solve these problems.
108
00:10:56.440 --> 00:11:04.495
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
109
00:11:05.035 --> 00:11:06.334
vision with solutioning.
110
00:11:06.714 --> 00:11:12.269
So they go into a lot of details about how you can implement things rather than what needs to be implemented.
111
00:11:12.730 --> 00:11:14.750
So having a clear boundary between
112
00:11:15.209 --> 00:11:23.215
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.
113
00:11:23.595 --> 00:11:30.150
Then the conversation kind of remains at a high level where engineers, instead of really focusing into
114
00:11:30.770 --> 00:11:33.750
a particular milestone or granular task,
115
00:11:34.130 --> 00:11:46.095
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,
116
00:11:46.410 --> 00:11:48.190
is the key to keep this conversation
117
00:11:48.890 --> 00:11:51.950
away from task based sort of mindset
118
00:11:52.410 --> 00:12:02.334
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
119
00:12:02.780 --> 00:12:08.480
lot of engineering teams that I work for and even I learned this hard way that if you don't set this context,
120
00:12:08.860 --> 00:12:15.505
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.
121
00:12:16.445 --> 00:12:17.345
Another challenge
122
00:12:17.805 --> 00:12:20.465
in being able to build that team cohesion
123
00:12:20.845 --> 00:12:21.620
is having
124
00:12:22.740 --> 00:12:25.480
an environment of trust and kind of shared empathy
125
00:12:26.100 --> 00:12:36.255
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
126
00:12:36.630 --> 00:12:55.035
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.
127
00:12:55.640 --> 00:13:01.980
You know, we've all been there, and just kind of making that a an implicitly understood but explicitly
128
00:13:02.440 --> 00:13:04.620
enforced kind of safe space.
129
00:13:05.125 --> 00:13:16.970
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
130
00:13:17.830 --> 00:13:27.055
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
131
00:13:27.435 --> 00:13:28.815
and if somebody feels
132
00:13:29.195 --> 00:13:30.975
unsafe raising a question
133
00:13:31.500 --> 00:13:33.200
or challenging me openly,
134
00:13:33.740 --> 00:13:37.200
then I have failed to set that culture within within the organization.
135
00:13:37.580 --> 00:13:41.695
Like, as I take any kind of role, leadership role, I make sure that
136
00:13:42.075 --> 00:13:44.415
this level of trust builds up pretty quickly.
137
00:13:44.875 --> 00:13:52.090
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?
138
00:13:52.710 --> 00:13:56.090
Every question I take it as seriously as any other question
139
00:13:56.404 --> 00:14:13.495
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
140
00:14:14.515 --> 00:14:15.654
and points raised,
141
00:14:16.035 --> 00:14:18.775
it kind of creates that trust based culture where
142
00:14:19.154 --> 00:14:19.975
any person,
143
00:14:20.275 --> 00:14:22.840
irrespective of their seniority, should feel comfortable
144
00:14:23.300 --> 00:14:24.360
asking those questions.
145
00:14:24.740 --> 00:14:31.014
Like, I worked at Facebook for many years, and it was quite common that an engineer would come to me And they'll say,
146
00:14:31.315 --> 00:14:37.574
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
147
00:14:37.980 --> 00:14:43.279
where I'm not able to explain it to you, or maybe there is an actual issue with the vision and strategy.
148
00:14:43.740 --> 00:14:51.324
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,
149
00:14:51.704 --> 00:14:55.004
then others in organizations will also mimic my behavior.
150
00:14:55.379 --> 00:14:57.639
And then the culture will become toxic in terms
151
00:14:58.019 --> 00:15:09.345
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
152
00:15:09.805 --> 00:15:12.465
kind of clear vision and purpose is the
153
00:15:13.050 --> 00:15:14.430
size and organizational
154
00:15:14.889 --> 00:15:20.990
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
155
00:15:21.449 --> 00:15:22.430
broken up into
156
00:15:22.795 --> 00:15:24.495
5 kind of smaller subgroups.
157
00:15:24.955 --> 00:15:31.615
And I'm wondering what you have seen as some of the ways that the challenges of kind of shared vision, shared purpose,
158
00:15:32.050 --> 00:15:33.350
you know, shared empathy
159
00:15:33.890 --> 00:15:38.550
compounds as you are trying to encapsulate larger and more varied groups?
160
00:15:39.225 --> 00:15:41.085
Yeah. So I've been fortunate
161
00:15:41.705 --> 00:15:42.765
in terms of leading
162
00:15:43.385 --> 00:15:51.850
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.
163
00:15:52.390 --> 00:16:02.175
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,
164
00:16:02.580 --> 00:16:05.880
things may fall apart. And I've seen it many times happening as well.
165
00:16:06.340 --> 00:16:24.300
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,
166
00:16:24.920 --> 00:16:29.260
you need to rely on lot more other factors in terms of communicating context
167
00:16:30.005 --> 00:16:31.625
and trickling down these changes.
168
00:16:32.084 --> 00:16:36.665
So the way I've done it when I was running a 5 500 to 600 people team
169
00:16:36.980 --> 00:16:43.560
is this exercise of strategy and vision is pretty similar. So instead of, of course, involving 4 to 500 people,
170
00:16:43.865 --> 00:16:50.285
you involve a much smaller set of people who I call it influencers or sort of senior leadership within the team.
171
00:16:50.665 --> 00:16:53.730
In terms of communication, you have to start broadcasting
172
00:16:54.270 --> 00:16:58.690
when you are dealing with 4 to 500 people. So instead of dealing with 1 on ones,
173
00:16:59.255 --> 00:17:03.355
those kind of communications happen in all hands or written documents
174
00:17:03.735 --> 00:17:06.635
or, like, you know, if you are in Slack, written messages.
175
00:17:07.230 --> 00:17:11.730
So 1 of the things I've observed that it may take 10 times or 30 times
176
00:17:12.270 --> 00:17:15.170
before covering a team of 400 to 500 people.
177
00:17:15.565 --> 00:17:21.184
Every time you put the message out, you're probably reaching out to 10 or 20 people at a time because
178
00:17:21.565 --> 00:17:23.985
not everybody is paying attention to your post.
179
00:17:24.350 --> 00:17:24.850
And,
180
00:17:25.150 --> 00:17:31.730
lot of times you assume that I've already written down this communication for, like, 5 or 10 times, but maybe it just reached
181
00:17:32.085 --> 00:17:34.345
25% of your overall organization.
182
00:17:35.044 --> 00:17:40.184
So I feel communication is, like, 1 of the most important factors in bringing changes
183
00:17:40.610 --> 00:17:54.575
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,
184
00:17:54.875 --> 00:17:58.255
even though vision and strategy, they look really clean,
185
00:17:58.600 --> 00:18:03.019
they don't know how to implement because they just don't know what their roles are. So
186
00:18:03.320 --> 00:18:06.139
a change that happens on the vision without
187
00:18:06.485 --> 00:18:08.585
a right change on the structure side,
188
00:18:09.044 --> 00:18:15.625
I think is bound to fail. So almost 90% of the times, all of my changes that were around strategy and vision,
189
00:18:16.170 --> 00:18:20.430
they were followed by some of the organizational changes to make sure that
190
00:18:20.810 --> 00:18:29.775
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,
191
00:18:30.155 --> 00:18:42.070
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.
192
00:18:42.505 --> 00:18:45.565
So it was super important to clear that those roles and responsibilities.
193
00:18:46.265 --> 00:18:58.110
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.
194
00:18:58.410 --> 00:19:00.030
Clear set of roles and responsibilities
195
00:19:00.775 --> 00:19:04.155
and constant communication with the team on vision and strategy
196
00:19:04.535 --> 00:19:07.035
are 2 pillars for larger teams
197
00:19:07.335 --> 00:19:08.875
to kind of buy into this.
198
00:19:09.230 --> 00:19:11.330
On that question of role and responsibility,
199
00:19:11.630 --> 00:19:13.170
that's also a
200
00:19:13.710 --> 00:19:16.929
very kind of flexible and nebulous concern where
201
00:19:17.395 --> 00:19:25.255
as the team grows, your role and responsibilities are going to change. As the product focus shifts, your role in that might change.
202
00:19:25.769 --> 00:19:29.389
And I'm wondering how you have gone through the process of balancing
203
00:19:29.929 --> 00:19:33.629
that kind of dynamic aspect of what are your responsibilities,
204
00:19:34.090 --> 00:19:38.804
where that might differ because of the phase of a project, you know, your position in the team,
205
00:19:39.105 --> 00:19:43.524
your title, you know, how the team is organized, and just kind of what the
206
00:19:43.880 --> 00:19:48.060
other areas of expertise are among your team members. And then alongside
207
00:19:48.360 --> 00:19:49.660
that, the question of
208
00:19:49.960 --> 00:19:51.265
how do you help
209
00:19:51.665 --> 00:19:56.965
to understand what that evolution looks like as somebody, you know, gains experience or
210
00:19:57.425 --> 00:19:59.685
gains interest in a particular area and
211
00:19:59.990 --> 00:20:06.570
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.
212
00:20:07.345 --> 00:20:10.884
Yeah. I mean, I think I see this in 2 parts. 1 is at the organizational
213
00:20:11.345 --> 00:20:12.884
level. As an organization
214
00:20:13.184 --> 00:20:14.565
scales and org scales,
215
00:20:15.100 --> 00:20:19.360
they would require different kind of roles and structure. For example,
216
00:20:19.900 --> 00:20:22.320
if your organization is 40 to 50 people,
217
00:20:22.945 --> 00:20:28.165
maybe some of the functions are not clearly defined. Like, we have a function called SRE or DevOps,
218
00:20:28.625 --> 00:20:34.360
and they are kind of, like, 4 or 5 people working everything from releases to deployment.
219
00:20:34.740 --> 00:20:36.039
As your org scales,
220
00:20:36.419 --> 00:20:41.575
you start feeling that there are specialized skills needed in some of these areas. For example,
221
00:20:41.875 --> 00:20:45.495
you start thinking about having a separate release engineering team
222
00:20:45.875 --> 00:20:47.895
than a deployment team versus
223
00:20:48.330 --> 00:20:50.350
somebody who's putting together test infrastructure.
224
00:20:50.970 --> 00:20:52.190
So there is an organizational
225
00:20:53.050 --> 00:21:02.825
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
226
00:21:03.285 --> 00:21:41.620
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
227
00:21:42.320 --> 00:21:42.820
needs.
228
00:21:43.200 --> 00:21:46.180
As the org is scaling from 50 people to 500,
229
00:21:46.720 --> 00:21:58.045
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.
230
00:21:58.529 --> 00:22:04.149
Like, for example, security is a great example of it. Your security needs and posture changes
231
00:22:04.690 --> 00:22:06.950
as the team matures and org matures,
232
00:22:07.275 --> 00:22:11.054
And you have to hire people who are expert in certain things. For example,
233
00:22:11.515 --> 00:22:17.360
I need to hire people more focused on compliance now because most of our, let's say, customers are asking for,
234
00:22:17.740 --> 00:22:27.075
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,
235
00:22:27.535 --> 00:22:29.635
there are things important in terms of building
236
00:22:30.000 --> 00:22:45.335
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?
237
00:22:45.750 --> 00:22:47.530
And then there is a talent available,
238
00:22:47.910 --> 00:22:52.730
and people may be eager to take on some of these roles because of their interest or passion.
239
00:22:53.065 --> 00:22:56.845
And then sometimes you have to identify people that you need to hire from outside
240
00:22:57.145 --> 00:23:06.140
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
241
00:23:06.520 --> 00:23:07.740
scaling up the organization.
242
00:23:08.360 --> 00:23:17.545
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
243
00:23:17.925 --> 00:23:20.184
really good career paths in some cases
244
00:23:20.660 --> 00:23:26.760
as somebody is willing to kind of step up into a completely different role than they were doing it in the past several years.
245
00:23:27.140 --> 00:23:28.360
As far as that
246
00:23:28.740 --> 00:23:30.125
kind of career
247
00:23:30.425 --> 00:23:30.925
trajectory,
248
00:23:31.945 --> 00:23:36.365
what are some of the structures that you have found most useful for helping people understand
249
00:23:37.330 --> 00:23:44.105
where their potential gaps are in being able to achieve whatever that next level or next position might look like
250
00:23:45.225 --> 00:23:49.485
and when to kind of rigidly define, these are the kind
251
00:23:49.785 --> 00:23:52.765
of job positions that we have, and when to say,
252
00:23:53.140 --> 00:24:06.725
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.
253
00:24:07.345 --> 00:24:08.965
It's super important to
254
00:24:09.300 --> 00:24:11.800
first bring clarity in terms of what
255
00:24:12.420 --> 00:24:16.600
the technical ladder looks like. Like, how do engineers see themselves growing?
256
00:24:17.125 --> 00:24:19.705
So at Sysu, we have clearly defined
257
00:24:20.164 --> 00:24:23.385
technical ladder that, hey. You could be an entry level engineer.
258
00:24:23.765 --> 00:24:26.424
Here is how you can get into a senior software engineer,
259
00:24:26.890 --> 00:24:30.030
staff engineer, and so on and so forth. At every level,
260
00:24:30.410 --> 00:24:32.110
it should be clear what the expectations
261
00:24:32.410 --> 00:24:38.965
are of that role. And if somebody wants to go from level 3 to level 4, here are the set of responsibilities
262
00:24:39.425 --> 00:24:47.230
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
263
00:24:47.530 --> 00:24:52.030
where people can see themselves and how the next level looks like is super important.
264
00:24:52.615 --> 00:24:54.635
The second aspect I would call out is
265
00:24:55.095 --> 00:25:01.195
having those conversations with engineers is also pretty important. So we call it this as a talent conversation
266
00:25:01.990 --> 00:25:04.410
or a career conversations in this case,
267
00:25:04.710 --> 00:25:08.330
where there is a conversation between a manager and an engineer,
268
00:25:08.765 --> 00:25:24.070
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.
269
00:25:24.450 --> 00:25:31.095
I want to actually go into a completely different role. So this conversation between manager and employee is super important.
270
00:25:31.395 --> 00:25:34.295
And what they put together is a career development plan,
271
00:25:34.755 --> 00:25:39.260
which is like a document that is owned by the employee or engineer,
272
00:25:39.720 --> 00:25:42.059
but it's been assisted by an engineer.
273
00:25:42.519 --> 00:25:45.419
And what I generally insist is to have these conversations
274
00:25:46.195 --> 00:25:50.695
at least once in a quarter, if not more, where there is an open conversation
275
00:25:50.995 --> 00:25:56.170
on here is where the career is shaping up, and these are some of the areas of gaps that
276
00:25:56.550 --> 00:26:01.130
manager can actually pinpoint to the employee that, hey. Maybe you I can help you out
277
00:26:01.485 --> 00:26:04.385
growing and taking kind of responsibilities in these areas.
278
00:26:04.765 --> 00:26:07.025
Offering you opportunities where you can actually,
279
00:26:07.405 --> 00:26:13.279
you know, also demonstrate your skills. So I think second part of career development discussion is super important.
280
00:26:13.740 --> 00:26:16.080
The third factor is lot of times
281
00:26:16.380 --> 00:26:40.715
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,
282
00:26:41.095 --> 00:26:47.275
ladder as well. The second part is there are different kinds of engineering profiles, and this is a question you were asking me before.
283
00:26:47.799 --> 00:27:05.405
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.
284
00:27:05.850 --> 00:27:07.390
They don't want to be TAs.
285
00:27:07.930 --> 00:27:11.550
They want to be working on deep complex problems by themselves.
286
00:27:11.930 --> 00:27:13.870
So how do we create sort of
287
00:27:14.330 --> 00:27:16.815
path for them for these different profiles?
288
00:27:17.275 --> 00:27:23.855
And what I've learned at my previous experiences and what we're doing at Sisu, that there are different profiles as you become
289
00:27:24.330 --> 00:27:29.470
senior engineer. So TL is 1 profile, but a deep expert is a second profile.
290
00:27:29.929 --> 00:27:32.669
A fixer kind of a profile could be a 3rd profile.
291
00:27:33.115 --> 00:27:42.860
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,
292
00:27:43.340 --> 00:27:46.080
we provide different ways of growing their career
293
00:27:46.460 --> 00:27:50.080
based on their passion. I think in some cases, you are right that engineer
294
00:27:50.764 --> 00:28:03.410
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
295
00:28:03.950 --> 00:28:12.365
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,
296
00:28:12.904 --> 00:28:13.804
clear technical
297
00:28:14.265 --> 00:28:22.110
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
298
00:28:22.490 --> 00:28:34.235
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.
299
00:28:34.535 --> 00:28:46.775
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,
300
00:28:47.155 --> 00:28:51.174
particularly if you're working in the data fields or kind of analytics, where
301
00:28:51.530 --> 00:29:01.615
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
302
00:29:01.995 --> 00:29:06.335
in, you know, a team comprised of sales and marketing and business operations?
303
00:29:07.115 --> 00:29:07.615
And
304
00:29:08.059 --> 00:29:17.865
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
305
00:29:18.165 --> 00:29:19.305
and team structure?
306
00:29:19.765 --> 00:29:24.265
Yeah. I have worked mostly in the technology companies. And what I've seen, there are some
307
00:29:24.820 --> 00:29:27.000
common structures that all of these companies
308
00:29:27.540 --> 00:29:28.680
generally end up having.
309
00:29:29.220 --> 00:29:37.235
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.
310
00:29:37.615 --> 00:29:41.860
They would have horizontal concerns. They would be taking care of horizontal concerns like
311
00:29:42.179 --> 00:29:46.040
infrastructure or how to build platform on which everybody can build application,
312
00:29:46.660 --> 00:29:49.400
doing release management, creating test infrastructure.
313
00:29:49.905 --> 00:29:52.805
So those are the horizontal teams. We had it at eBay,
314
00:29:53.345 --> 00:29:54.485
PayPal, Facebook,
315
00:29:54.865 --> 00:30:01.059
and even Sysu has this horizontal team that is much more focused on lower aspects of the stack.
316
00:30:01.600 --> 00:30:04.100
And then when you go into the product world,
317
00:30:04.455 --> 00:30:08.475
things become interesting. And that's where a lot of domain specific
318
00:30:08.855 --> 00:30:13.275
sort of context comes into the play. So, typically, what I've seen is
319
00:30:13.620 --> 00:30:14.360
it kind
320
00:30:14.740 --> 00:30:18.440
of maps to the verticals within the company. Like, for example,
321
00:30:19.059 --> 00:30:23.000
at Facebook, we used to have teams called, like, Facebook newsfeed,
322
00:30:23.495 --> 00:30:26.795
and then there was a team on Instagram, and then there's team for WhatsApp,
323
00:30:27.255 --> 00:30:29.675
and there was a team that was focused on advertising.
324
00:30:30.135 --> 00:30:37.440
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.
325
00:30:38.140 --> 00:30:40.865
And similarly, we had things at eBay and PayPal. They were much
326
00:30:41.825 --> 00:30:48.645
more vertically focused on, hey. Here is the payments team. Here is kind of a UI team that is focused on wallet experience
327
00:30:49.184 --> 00:30:51.230
and so on and so forth. So
328
00:30:51.690 --> 00:30:52.190
horizontal,
329
00:30:52.650 --> 00:30:57.710
generally keeping it constant that everybody kind of focuses on infrastructure and other
330
00:30:58.090 --> 00:30:59.150
horizontal concerns.
331
00:30:59.525 --> 00:31:00.265
And verticals
332
00:31:00.645 --> 00:31:04.025
vertical team structures are generally influenced by the domain itself.
333
00:31:04.405 --> 00:31:07.465
What I see is in terms of expertise and talent,
334
00:31:08.120 --> 00:31:10.380
lot of times on the infrastructure side, they are
335
00:31:10.760 --> 00:31:22.995
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,
336
00:31:23.429 --> 00:31:25.690
and a lot of people came from banking background.
337
00:31:25.990 --> 00:31:32.410
On eBay side, we hired a lot of people from ecommerce. So lot of people were hired from other ecommerce players.
338
00:31:32.805 --> 00:31:34.105
And Facebook interestingly,
339
00:31:34.405 --> 00:31:37.385
you know, focused not on other social
340
00:31:37.685 --> 00:31:40.105
companies because Facebook was the first company
341
00:31:40.480 --> 00:32:00.860
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
342
00:32:01.320 --> 00:32:04.380
the rest of it, like, mostly in the product engineering side.
343
00:32:04.680 --> 00:32:05.900
As far as the
344
00:32:06.415 --> 00:32:13.075
point that you were making earlier about when to bring in outside talent versus when to try and grow somebody into a specific role,
345
00:32:13.760 --> 00:32:17.220
what are some of the strategies that you use to identify
346
00:32:17.600 --> 00:32:24.554
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
347
00:32:25.015 --> 00:32:25.515
and,
348
00:32:25.975 --> 00:32:36.680
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.
349
00:32:37.295 --> 00:32:50.620
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,
350
00:32:51.080 --> 00:32:54.620
you know, this is something that I'm interested in learning about and then balancing,
351
00:32:55.265 --> 00:33:03.525
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?
352
00:33:03.990 --> 00:33:08.010
Yeah. So there are 2 aspects that I generally kind of follow.
353
00:33:08.630 --> 00:33:11.290
The first 1 is doing talent review.
354
00:33:12.495 --> 00:33:16.595
So this talent review generally happens once every 6 months or 12 months,
355
00:33:17.215 --> 00:33:20.915
but it's not happening in the just the current context. It's not about,
356
00:33:21.590 --> 00:33:25.450
hey. What talent do we have and what are the requirements today?
357
00:33:25.910 --> 00:33:29.530
But we look forward another 6 to 12 months that how is our organization
358
00:33:30.345 --> 00:33:31.165
actually scaling?
359
00:33:31.625 --> 00:33:36.285
What kind of requirements do we see coming our way in next 6 to 12 months?
360
00:33:36.585 --> 00:33:39.805
Let's keep that in context, and let's map our
361
00:33:40.170 --> 00:33:40.990
current talent
362
00:33:41.370 --> 00:33:44.830
to our needs of the org for next 6 to 12 months.
363
00:33:45.130 --> 00:33:45.630
Now
364
00:33:45.930 --> 00:33:47.630
that would give us a good picture
365
00:33:48.235 --> 00:33:51.054
in which areas we are lacking, Telling. Like, for example,
366
00:33:51.434 --> 00:33:54.174
a typical exercise that we had done in the past,
367
00:33:54.475 --> 00:33:55.855
it would show up that
368
00:33:56.180 --> 00:34:00.760
we need to really scale our organization from 200 people to 400 people.
369
00:34:01.060 --> 00:34:02.440
If we double our organization,
370
00:34:03.220 --> 00:34:10.035
we need a lot more senior talent. We need people who could actually play this role of horizontal tech leads
371
00:34:10.415 --> 00:34:14.755
across multiple teams. Do we have enough talent in that particular area?
372
00:34:15.260 --> 00:34:18.319
Or we need to actually build a next gen,
373
00:34:18.619 --> 00:34:20.240
let's say, database solution
374
00:34:20.859 --> 00:34:24.480
because we are almost reaching that scale with our current solution.
375
00:34:24.835 --> 00:34:26.535
Do we have expertise in database?
376
00:34:26.994 --> 00:34:38.599
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,
377
00:34:39.140 --> 00:34:41.000
we could actually raise points around,
378
00:34:41.424 --> 00:34:44.964
this is an engineer who's doing great work in this particular area,
379
00:34:45.265 --> 00:34:49.839
but they've been actually passionate about this second area as well. Should we give them opportunity
380
00:34:50.220 --> 00:34:54.000
and transfer them into that area and see how it plays out?
381
00:34:54.300 --> 00:34:57.280
So sometimes talent review also includes
382
00:34:57.835 --> 00:35:00.654
movement of the talent. Right? Like, moving from
383
00:35:01.115 --> 00:35:05.454
1 area to another and see if they are able to rise to the opportunity.
384
00:35:06.210 --> 00:35:26.300
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
385
00:35:26.760 --> 00:35:31.260
and try it out? Now in the safer environment as we were talking about before,
386
00:35:31.815 --> 00:35:38.474
engineers generally get excited about these things. Right? Because they're not afraid of failing because there's an assurance coming from the leadership
387
00:35:38.855 --> 00:35:55.575
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,
388
00:35:56.035 --> 00:35:58.135
even the the talent that you have
389
00:35:58.500 --> 00:36:01.560
currently would not be able to kind of fulfill all the requirements.
390
00:36:02.020 --> 00:36:06.200
So in parallel, we generally start looking for talent from outside as well.
391
00:36:06.535 --> 00:36:20.619
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
392
00:36:20.920 --> 00:36:27.984
to people inside the org who are either passionate or willing to take on different roles. And second,
393
00:36:28.445 --> 00:36:31.345
also in parallel, start hiring some more talent because
394
00:36:31.900 --> 00:36:33.680
I generally believe in overhiring.
395
00:36:34.380 --> 00:36:37.760
Because most of the times, even if people shoot for overhiring,
396
00:36:38.460 --> 00:36:39.280
they are generally
397
00:36:40.025 --> 00:36:40.924
resource crunched.
398
00:36:41.865 --> 00:36:45.405
So I would rather get you to a stage where we are proactively hiring
399
00:36:45.785 --> 00:36:47.244
based on the talent review
400
00:36:47.559 --> 00:36:49.900
and filling in those gaps as fast as possible.
401
00:36:50.279 --> 00:37:00.435
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.
402
00:37:00.815 --> 00:37:01.315
Another
403
00:37:01.695 --> 00:37:08.869
aspect of trying to kind of manage teams and it being a constantly moving target is the ways that engineering
404
00:37:09.250 --> 00:37:11.109
as a discipline and the
405
00:37:11.705 --> 00:37:23.869
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
406
00:37:24.170 --> 00:37:25.630
programming languages, etcetera,
407
00:37:26.285 --> 00:37:28.944
have influenced the ways that engineers
408
00:37:29.325 --> 00:37:32.145
think about the jobs that they do and their responsibility
409
00:37:32.605 --> 00:37:33.345
and the,
410
00:37:33.710 --> 00:37:40.210
I guess, impact that they have on the organization as a whole and, you know, kind of recognizing that fact where maybe
411
00:37:40.805 --> 00:37:47.705
30 years ago, engineering was just another kind of department. You know, it was largely IT. They're a cost center. Whereas now,
412
00:37:48.140 --> 00:38:02.195
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,
413
00:38:02.975 --> 00:38:06.995
and, you know, how that looks as far as the way that work gets done
414
00:38:07.440 --> 00:38:07.940
and
415
00:38:08.240 --> 00:38:10.420
the kind of investment that is made in
416
00:38:10.800 --> 00:38:13.940
building kind of effective structures to help support that work.
417
00:38:14.240 --> 00:38:16.500
So when I graduated in 95,
418
00:38:17.204 --> 00:38:18.505
there was no cloud.
419
00:38:19.204 --> 00:38:25.944
Almost every software was shipped in a CD format, actually, all of it. You know, like, I remember I was working
420
00:38:26.420 --> 00:38:27.320
for a bank,
421
00:38:27.780 --> 00:38:29.800
and we needed some database.
422
00:38:30.660 --> 00:38:39.635
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.
423
00:38:40.415 --> 00:38:44.675
Right? So this is what how the 95, 96 actually looked like. And
424
00:38:45.020 --> 00:38:50.240
I remember building something which is very primitive on in in the Unix operating system
425
00:38:50.700 --> 00:38:56.085
because we just did not have money to buy off the shelf, like Oracle database or something else.
426
00:38:56.545 --> 00:38:58.245
And since then, things have changed
427
00:38:58.705 --> 00:39:04.480
drastically, right, with the invention of cloud and bunch of other technologies like machine learning that have come along.
428
00:39:05.020 --> 00:39:11.200
What I figured it out, the most successful engineers are those who have ability to learn and change themselves.
429
00:39:11.765 --> 00:39:14.424
So I've gone through multiple iterations of this
430
00:39:14.724 --> 00:39:15.704
sort of innovations
431
00:39:16.244 --> 00:39:19.464
that look like innovations at first and then they become mainstream.
432
00:39:20.070 --> 00:39:26.330
And, you know, people who don't adapt to these changes, they struggle, and they generally become sort of unsuccessful
433
00:39:26.630 --> 00:39:27.930
in their in their journey.
434
00:39:28.255 --> 00:39:31.394
Like, a great example of this is cloud journey. And
435
00:39:31.694 --> 00:39:36.275
how many companies actually resisted cloud change when it was becoming mainstream
436
00:39:36.809 --> 00:39:38.670
back in 2010, 2012.
437
00:39:39.289 --> 00:39:45.869
And lot of, for example, operational folks, they wanted to work in a traditional way of, like, I would stare at the dashboard.
438
00:39:46.275 --> 00:39:47.974
I would do every change manually
439
00:39:48.515 --> 00:39:49.895
versus using automation.
440
00:39:50.355 --> 00:39:56.880
And, you know, over time, what ended up happening is, really, everybody's using cloud and those jobs where you need to manually
441
00:39:57.420 --> 00:39:59.440
log into a machine to do something,
442
00:39:59.819 --> 00:40:16.200
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,
443
00:40:16.900 --> 00:40:32.585
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,
444
00:40:33.059 --> 00:40:37.240
They've been all open to learning different things. Like, for example, I learned cloud.
445
00:40:37.700 --> 00:40:46.905
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.
446
00:40:47.205 --> 00:40:54.890
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.
447
00:40:55.349 --> 00:41:00.570
And to now, you know, like, all the way in 2022, we have been talking about
448
00:41:01.015 --> 00:41:05.355
complete automation on top of cloud using using machine learning everywhere,
449
00:41:05.735 --> 00:41:15.670
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
450
00:41:16.130 --> 00:41:39.694
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,
451
00:41:40.234 --> 00:41:42.335
even if something really good comes along,
452
00:41:42.875 --> 00:41:45.535
that doesn't seem like a mindset of growth.
453
00:41:45.850 --> 00:41:46.990
And that generally,
454
00:41:47.370 --> 00:42:02.115
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.
455
00:42:02.710 --> 00:42:03.450
As you
456
00:42:03.750 --> 00:42:11.450
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
457
00:42:12.315 --> 00:42:16.255
engineering as a practice and team structures and
458
00:42:16.555 --> 00:42:18.495
the kind of set of responsibilities
459
00:42:18.795 --> 00:42:21.535
that are core to engineering versus how much of those
460
00:42:21.950 --> 00:42:34.635
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
461
00:42:35.015 --> 00:42:40.710
dynamics and the work to be done evolving as we move forward kind of as
462
00:42:41.010 --> 00:42:41.670
a engineering
463
00:42:42.290 --> 00:42:42.790
capability
464
00:42:43.090 --> 00:42:47.109
and more broadly as kind of a society or business focus?
465
00:42:47.615 --> 00:42:51.075
I see that, you know, I mean, with COVID coming in,
466
00:42:51.375 --> 00:42:53.155
the whole remote working has
467
00:42:53.615 --> 00:42:57.075
really taken off. And even post COVID, now that,
468
00:42:57.410 --> 00:42:59.510
you know, I mean, we're at a point where
469
00:42:59.810 --> 00:43:03.110
some people have gone back to office, but a lot of people are working remotely.
470
00:43:03.410 --> 00:43:05.590
So I do feel as an engineering team
471
00:43:06.050 --> 00:43:06.870
going forward,
472
00:43:07.734 --> 00:43:11.755
this collaboration, which is happening on the Internet rather than in person,
473
00:43:12.134 --> 00:43:15.515
is going to continue. And we're gonna see many more tools
474
00:43:15.990 --> 00:43:21.450
which would actually enable this collaboration going forward. Like, I think there are tools like Zoom and
475
00:43:21.910 --> 00:43:23.530
GitHub. These are collaborative
476
00:43:23.830 --> 00:43:28.525
tools. But, you know, I think replacing in person interaction with something
477
00:43:28.984 --> 00:43:29.724
which is
478
00:43:30.105 --> 00:43:32.365
much more intuitive for for engineers
479
00:43:32.910 --> 00:43:36.210
has not been there yet. So I do feel in the coming years,
480
00:43:36.670 --> 00:43:41.994
this whole thing around how do people across the world can come together as 1 team
481
00:43:42.295 --> 00:43:47.275
and collaboratively work on that using those tools, that will become significantly important.
482
00:43:47.610 --> 00:43:51.070
The second thing which I see at least for next 10 years, in my opinion,
483
00:43:51.530 --> 00:43:56.990
machine learning will become part of everybody's life. So machine learning has been a pretty special skill
484
00:43:57.315 --> 00:44:03.495
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
485
00:44:03.875 --> 00:44:08.040
designing products. Like, you know, you're doing some recommendation, that's machine learning.
486
00:44:08.340 --> 00:44:10.040
If you are kind of thinking about
487
00:44:10.340 --> 00:44:13.640
some kind of data mining, that's machine learning. You're gonna learn about
488
00:44:14.075 --> 00:44:25.340
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.
489
00:44:25.720 --> 00:44:30.300
I do feel as engineers to also adapt to this coming changes. Right? For example,
490
00:44:30.825 --> 00:44:41.170
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
491
00:44:41.630 --> 00:44:50.225
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.
492
00:44:50.765 --> 00:44:55.665
This is going to go in a completely different world that libraries and tools are going to be available
493
00:44:56.090 --> 00:45:08.345
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.
494
00:45:08.724 --> 00:45:15.230
I think you did mention about low code or no code. I think it's definitely something that is picking up. I see,
495
00:45:16.090 --> 00:45:19.150
lot of tools that are making developers' life much simpler.
496
00:45:19.655 --> 00:45:24.235
The way I see it is there would be, like, certain tasks which are
497
00:45:24.855 --> 00:45:30.539
completely automated. Right? And you can just use this kind of tools where you are writing just the configuration
498
00:45:31.079 --> 00:45:38.140
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.
499
00:45:38.515 --> 00:45:40.055
So tools are enhancing,
500
00:45:40.515 --> 00:45:44.775
and they're getting better and better. That means you can now focus on real set of problems
501
00:45:45.075 --> 00:45:51.720
rather than spending your energy into something video call or, you know, really the task that should have been automated.
502
00:45:52.020 --> 00:45:55.800
So I feel that this will enable a lot more focused effort
503
00:45:56.315 --> 00:45:59.775
and sort of deep like, energy to solve deeper problems
504
00:46:00.155 --> 00:46:04.975
rather than superficial problems that people are spending too much time and energy right now.
505
00:46:05.310 --> 00:46:07.410
So I would love to see that,
506
00:46:07.869 --> 00:46:11.810
bunch of new machine learning algorithms coming up because now people have tools
507
00:46:12.244 --> 00:46:12.904
to experiment
508
00:46:13.845 --> 00:46:21.980
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,
509
00:46:22.520 --> 00:46:26.220
people will spend much more energy in doing innovative stuff
510
00:46:26.600 --> 00:46:31.565
rather than mundane stuff that they've been doing. So I think if we are spending 50% of energy
511
00:46:32.105 --> 00:46:42.940
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
512
00:46:43.400 --> 00:46:44.220
more creative
513
00:46:44.694 --> 00:46:49.115
and more focused on the problems that you wanna solve rather than peripheral issues.
514
00:46:49.815 --> 00:46:50.714
In your experience
515
00:46:51.015 --> 00:46:51.515
of
516
00:46:52.210 --> 00:46:55.670
managing engineering teams and helping to kind
517
00:46:55.970 --> 00:46:56.950
of grow the
518
00:46:57.490 --> 00:46:58.390
team capabilities
519
00:46:58.690 --> 00:47:09.035
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
520
00:47:09.540 --> 00:47:14.360
organizational leaders addressing that work of building and scaling that team capacity
521
00:47:14.660 --> 00:47:16.280
and team throughput and
522
00:47:16.735 --> 00:47:19.395
building kind of that cohesive vision and trust?
523
00:47:20.015 --> 00:47:25.315
So, I mean, I think if you think about organization challenges as they're scaling up,
524
00:47:25.695 --> 00:47:26.195
and
525
00:47:26.640 --> 00:47:38.505
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,
526
00:47:39.205 --> 00:47:43.705
lot of times those were hires that we did in colleges, like these were fresh schedules.
527
00:47:44.380 --> 00:47:47.039
In 1 of the companies, we actually hired contractors
528
00:47:47.420 --> 00:47:48.640
because we couldn't hire
529
00:47:49.019 --> 00:47:54.625
FTEs or full time engineers as fast. And in another company, we kind of got consulting
530
00:47:54.925 --> 00:47:55.425
companies
531
00:47:55.805 --> 00:47:57.425
who would actually take on the projects.
532
00:47:57.885 --> 00:47:58.385
So
533
00:47:58.820 --> 00:48:02.680
scaling at a velocity, at a very high velocity, brings a lot of challenges.
534
00:48:03.220 --> 00:48:11.385
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
535
00:48:11.765 --> 00:48:19.820
and your ability to really sustain that culture going forward. So for example, in an environment where you're bringing a lot of contractors
536
00:48:20.440 --> 00:48:21.100
and consulting,
537
00:48:21.560 --> 00:48:25.785
typically, what I've seen is it kind of breaks down the culture because now suddenly you have
538
00:48:26.184 --> 00:48:29.244
so many people who have not been part of this company
539
00:48:29.785 --> 00:48:42.420
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.
540
00:48:43.055 --> 00:48:46.595
On the other side, when we were hiring fresh college graduates in 100,
541
00:48:47.214 --> 00:48:52.515
it was also tricky because we need to train them. We need to make sure that they're actually becoming productive.
542
00:48:52.960 --> 00:49:01.380
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.
543
00:49:01.725 --> 00:49:12.870
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
544
00:49:13.170 --> 00:49:15.590
and making sure that you are doing the right hires
545
00:49:15.970 --> 00:49:18.870
than just kind of scaling up in a crazy way.
546
00:49:19.404 --> 00:49:26.704
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,
547
00:49:27.020 --> 00:49:40.305
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,
548
00:49:40.845 --> 00:49:43.905
culture is super important. And, like, if I give my example
549
00:49:44.520 --> 00:49:45.980
in my previous company,
550
00:49:46.280 --> 00:49:51.340
we used to have 1 month of onboarding time. And this was not really to
551
00:49:51.640 --> 00:49:53.420
train you on a specific technology,
552
00:49:53.955 --> 00:50:05.440
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
553
00:50:05.740 --> 00:50:06.560
actually functions.
554
00:50:06.860 --> 00:50:12.675
So to me, that's super important that how do you how do you make sure that people understand your company's culture?
555
00:50:13.055 --> 00:50:17.555
And for that, you have to have a proper onboarding program really going forward.
556
00:50:18.010 --> 00:50:18.830
That is meaningful
557
00:50:19.290 --> 00:50:21.470
in explaining how your company operates.
558
00:50:21.930 --> 00:50:27.390
The second thing I talk about is ongoing training. So as an organization actually scales,
559
00:50:27.994 --> 00:50:32.414
how do you identify the areas that you need more help
560
00:50:32.714 --> 00:50:38.720
and there is a talent gap or there is a skill gap? And how do you kind of make sure that your engineers are
561
00:50:39.020 --> 00:50:41.120
reacting to that and they are getting opportunity
562
00:50:42.140 --> 00:50:43.360
to learn new skills?
563
00:50:43.705 --> 00:50:46.205
So making sure that there are programs around
564
00:50:46.585 --> 00:50:50.205
learning new skills which are kind of fitting into your organization scaling
565
00:50:50.640 --> 00:50:58.260
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,
566
00:50:58.665 --> 00:51:04.925
by learning those skills, you are proactively sort of kind of working on those gaps as well? So I would say
567
00:51:05.465 --> 00:51:13.309
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.
568
00:51:13.609 --> 00:51:28.060
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
569
00:51:28.440 --> 00:51:29.260
sort of
570
00:51:29.640 --> 00:51:30.700
reinventing themselves
571
00:51:31.080 --> 00:51:34.940
and fitting into companies' needs as going forward. And your experience
572
00:51:35.415 --> 00:51:47.020
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?
573
00:51:47.320 --> 00:51:51.500
What are some of the most interesting or unexpected or challenging lessons that you've learned in the process?
574
00:51:52.015 --> 00:51:54.835
Yeah. So, like, I can give an example at Sisu.
575
00:51:55.135 --> 00:51:59.234
Like, we are a small company, so you would imagine, you know, everybody understands
576
00:51:59.960 --> 00:52:00.780
what our customers
577
00:52:01.560 --> 00:52:09.020
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,
578
00:52:09.515 --> 00:52:10.494
I found that,
579
00:52:10.795 --> 00:52:13.855
you know, information was not trickling down. Like, for example,
580
00:52:14.395 --> 00:52:16.815
lot of engineers were not sure about
581
00:52:17.115 --> 00:52:19.055
what our customer requirements were.
582
00:52:19.500 --> 00:52:21.440
And that to me was
583
00:52:21.820 --> 00:52:24.080
really kind of jarring experience because
584
00:52:24.380 --> 00:52:27.360
I thought there is information that is available everywhere,
585
00:52:27.934 --> 00:52:30.674
but that doesn't mean that people are consuming that information.
586
00:52:31.214 --> 00:52:39.770
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
587
00:52:40.070 --> 00:52:48.365
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
588
00:52:48.825 --> 00:52:49.565
in understanding
589
00:52:49.865 --> 00:53:01.320
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.
590
00:53:01.795 --> 00:53:07.735
We made sure that we are kind of talking in all hands, company all hands a lot more about customer needs.
591
00:53:08.115 --> 00:53:16.340
Got a process where we could actually absorb customer inputs coming in a systematic way. And just that culture of customer centricity,
592
00:53:17.120 --> 00:53:23.255
how does it trickle down in engineering is something I've been focusing on for the past several months. But this is definitely
593
00:53:23.635 --> 00:53:38.440
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,
594
00:53:38.875 --> 00:53:56.309
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.
595
00:53:56.714 --> 00:54:00.255
And you feel all great about how great things you are doing
596
00:54:00.555 --> 00:54:07.550
within your org, but you get feedback suddenly that you're completely disconnected from the needs of the overall organization.
597
00:54:08.329 --> 00:54:17.235
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.
598
00:54:17.535 --> 00:54:20.115
So in any of these cases, I do feel
599
00:54:20.530 --> 00:54:23.910
listening to your peer feedback, listening to customer feedback,
600
00:54:24.210 --> 00:54:27.589
and keeping an open mind in terms of how you can improve your teams
601
00:54:27.995 --> 00:54:50.025
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
602
00:54:50.490 --> 00:54:55.630
to what the needs of internal customers are. And please go and do your homework
603
00:54:55.930 --> 00:55:20.815
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
604
00:55:21.115 --> 00:55:23.775
particularly informative and helpful in
605
00:55:24.474 --> 00:55:25.694
identifying and understanding
606
00:55:26.299 --> 00:55:31.440
what not to do and how to kind of improve your skills that you're willing to share with the audience?
607
00:55:31.819 --> 00:55:36.125
Yeah. Absolutely. I've done so many mistakes. I can go on for 2 hours on that.
608
00:55:36.605 --> 00:55:41.985
In most cases, what I figured out is most difficult challenges that I've faced, they're not
609
00:55:42.445 --> 00:55:44.465
technology challenges. They're people challenges.
610
00:55:45.150 --> 00:55:45.650
So
611
00:55:45.950 --> 00:55:49.569
most difficult problems are when people don't agree with each other,
612
00:55:49.950 --> 00:55:53.970
and they somehow cannot even find a path to agree to each other
613
00:55:54.275 --> 00:55:55.015
as well.
614
00:55:55.395 --> 00:55:57.415
My important lesson learned is
615
00:55:57.795 --> 00:56:01.335
lot of times I was pulled into such kind of conversations where
616
00:56:01.635 --> 00:56:03.255
2 set of people are not agreeing.
617
00:56:03.630 --> 00:56:06.130
And instead of taking a neutral stance,
618
00:56:06.590 --> 00:56:07.490
I would take
619
00:56:08.190 --> 00:56:13.250
a prominent sort of a stance or a particular stance saying this is right and this is wrong.
620
00:56:13.575 --> 00:56:20.955
And I thought I think that behavior was not right because they actually involve me as a neutral party to help them out.
621
00:56:21.335 --> 00:56:21.835
And
622
00:56:22.520 --> 00:56:23.580
before I understand
623
00:56:23.960 --> 00:56:29.020
everybody's point of view or in this case, 2 parties point of view, and just kind of really
624
00:56:29.785 --> 00:56:31.165
help out with the conversation.
625
00:56:31.865 --> 00:56:33.165
If I jump to conclusion,
626
00:56:33.705 --> 00:56:34.445
I'm actually,
627
00:56:34.825 --> 00:56:40.349
you know, really impacting the outcome of this entire sort of, you know, process
628
00:56:40.810 --> 00:56:41.710
in some sense.
629
00:56:42.010 --> 00:56:44.910
So I've heard this and I've learned this the hard way where
630
00:56:45.530 --> 00:56:48.829
my job I need to understand when my job is to
631
00:56:49.165 --> 00:56:49.905
make a decision
632
00:56:50.285 --> 00:56:52.385
and when my job is to just,
633
00:56:52.685 --> 00:56:55.265
you know, help out with the overall conversation,
634
00:56:55.965 --> 00:57:00.580
hear them out, and make sure that I'm helping them reach to a certain conclusion.
635
00:57:00.960 --> 00:57:03.060
So your roles actually are different.
636
00:57:03.599 --> 00:57:05.619
And, you know, being a technologist
637
00:57:06.185 --> 00:57:07.645
and having my own opinions,
638
00:57:07.945 --> 00:57:09.805
I always found it easier
639
00:57:10.345 --> 00:57:12.125
to to make a decision on something
640
00:57:12.505 --> 00:57:13.325
rather than
641
00:57:14.059 --> 00:57:15.119
helping out people
642
00:57:15.660 --> 00:57:17.359
through this process of disconnect
643
00:57:17.740 --> 00:57:20.079
and making sure that we are landing into
644
00:57:20.539 --> 00:57:34.230
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
645
00:57:34.530 --> 00:57:35.030
prematurely
646
00:57:35.730 --> 00:57:40.470
and really not helping the overall conversation. I think that's 1 of the things that I keep repeating
647
00:57:41.095 --> 00:57:43.275
every time when I get brought into
648
00:57:44.215 --> 00:57:44.715
dysfunctional
649
00:57:45.095 --> 00:57:48.875
organization that my role is to play a neutral party
650
00:57:49.490 --> 00:57:52.310
and, you know, really help the team out rather than
651
00:57:52.690 --> 00:57:55.430
showing off how good I am in making decisions.
652
00:57:56.290 --> 00:58:10.360
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
653
00:58:10.900 --> 00:58:14.760
to understand more about the kind of context and practices and
654
00:58:15.205 --> 00:58:17.385
considerations around being able to
655
00:58:17.845 --> 00:58:22.745
build cohesion and maintain kind of direction and focus for an engineering team?
656
00:58:23.070 --> 00:58:27.490
I would say there are just ton of books that are available on management and leadership,
657
00:58:28.270 --> 00:58:31.170
and just there are too many of those books. I think
658
00:58:31.515 --> 00:58:34.335
if somebody is becoming a manager, I would ask them to read,
659
00:58:34.635 --> 00:58:37.935
you know, like High Output Management by Andrew Bro.
660
00:58:38.235 --> 00:58:44.079
Like, this is a classic book that anybody can read and figure out what it means to become a manager.
661
00:58:44.460 --> 00:58:51.119
There are leadership books like Good to Great. I think I really like that. Or Hard Things About Hard Things Now.
662
00:58:51.485 --> 00:59:02.869
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
663
00:59:03.170 --> 00:59:04.470
spending time on that.
664
00:59:04.849 --> 00:59:06.710
Second thing, I do feel that,
665
00:59:07.165 --> 00:59:10.545
like, having a mentor who can actually coach you
666
00:59:10.845 --> 00:59:16.305
in some of this situation is super important too. So I have been privileged to have
667
00:59:16.930 --> 00:59:18.870
really good mentors throughout my life.
668
00:59:19.250 --> 00:59:25.670
And what I do even today is sometimes I run into a problem, and I reach out to my mentor.
669
00:59:26.025 --> 00:59:39.119
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
670
00:59:39.579 --> 00:59:42.079
make sure that you're kind of having a
671
00:59:42.539 --> 00:59:48.395
relationship with your mentors or some other experience set of people whom you can reach out when you need help.
672
00:59:48.695 --> 00:59:50.795
And I think I would say third thing is
673
00:59:51.255 --> 00:59:52.075
just being
674
00:59:52.590 --> 00:59:57.490
kind of open to having this conversation broadly within an org with your peers.
675
00:59:57.870 --> 01:00:01.970
I think that helps. Lot of times people keep all of these details to themselves,
676
01:00:02.335 --> 01:00:05.154
all of their problems to themselves because they don't wanna show
677
01:00:05.535 --> 01:00:15.060
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
678
01:00:15.360 --> 01:00:18.660
because you'll get a good advice. You'll get a maybe good support
679
01:00:19.335 --> 01:00:21.835
from them. And I think your life becomes easier
680
01:00:22.295 --> 01:00:23.194
if you kind
681
01:00:23.494 --> 01:00:24.954
of open up rather than
682
01:00:25.414 --> 01:00:27.194
hiding everything within yourself.
683
01:00:27.510 --> 01:00:29.050
So I would say reading books,
684
01:00:29.350 --> 01:00:41.515
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.
685
01:00:41.895 --> 01:00:46.315
Are there any other aspects of the kind of work and considerations
686
01:00:46.695 --> 01:00:47.195
and
687
01:00:47.800 --> 01:00:56.224
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
688
01:00:56.525 --> 01:00:58.545
say, you know, lot of times,
689
01:00:59.405 --> 01:01:01.825
we get too serious about everything,
690
01:01:02.500 --> 01:01:05.080
about our goals, about our vision and strategy,
691
01:01:05.700 --> 01:01:07.080
that we forget to
692
01:01:07.620 --> 01:01:08.120
celebrate
693
01:01:08.900 --> 01:01:11.560
certain milestones. We forget to celebrate
694
01:01:12.465 --> 01:01:16.565
wins, and I feel that's an important part of engineering culture as well.
695
01:01:16.945 --> 01:01:22.770
So when we come together as a team, when we were talking about vision and strategy and road map,
696
01:01:23.150 --> 01:01:26.369
I think it's also equally important to celebrate successes,
697
01:01:26.750 --> 01:01:27.810
celebrate wins,
698
01:01:28.270 --> 01:01:30.450
recognizing people, making sure that
699
01:01:30.905 --> 01:01:39.325
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
700
01:01:39.670 --> 01:01:41.210
is something getting recognized.
701
01:01:41.510 --> 01:01:44.569
So I do feel creating a stronger engineering culture
702
01:01:45.270 --> 01:01:45.770
involves
703
01:01:46.390 --> 01:01:46.890
recognizing
704
01:01:47.190 --> 01:01:48.170
rewarding people
705
01:01:48.725 --> 01:01:56.025
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
706
01:01:56.645 --> 01:01:58.185
just have fun while working.
707
01:01:58.550 --> 01:02:18.400
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.
708
01:02:18.940 --> 01:02:19.760
Very entertaining.
709
01:02:20.220 --> 01:02:30.700
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?
710
01:02:31.099 --> 01:02:32.160
Let's see. I
711
01:02:32.540 --> 01:02:40.160
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.
712
01:02:40.694 --> 01:02:45.275
It's been amazing movie. And I watched Top Gun the first part
713
01:02:45.655 --> 01:02:50.450
when I was, like, 12 or 14 years old. So it's came after, like, so many
714
01:02:50.910 --> 01:02:52.690
years. And I didn't know
715
01:02:52.990 --> 01:02:56.450
how the movie would be because, you know, like, things have changed.
716
01:02:56.805 --> 01:03:01.465
But it's 1 of the really good movies that I've seen in the past, maybe several years. So
717
01:03:01.845 --> 01:03:17.145
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?
718
01:03:17.605 --> 01:03:26.570
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
719
01:03:26.870 --> 01:03:27.770
back in eighties.
720
01:03:28.550 --> 01:03:33.210
It's always fun revisiting old movies and saying, oh, wow. I used to think that was actually good.
721
01:03:33.830 --> 01:03:38.545
Yeah. It was good. It was cool back then, but this 1 is cooler. Exactly.
722
01:03:39.165 --> 01:03:48.630
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.
723
01:03:48.930 --> 01:04:05.890
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.
724
01:04:08.110 --> 01:04:21.220
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
725
01:04:22.240 --> 01:04:29.994
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
726
01:04:31.575 --> 01:04:32.315
with your story.
727
01:04:32.694 --> 01:04:37.595
And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.