The biggest thing is to think about delegation as more of a
coaching mindset instead of the doer mentality that most of the
fresh engineers have there. As you mentioned, like, hey, I
can do this code faster and so why not, you know, just do it
myself. So it's not the idea about
looking at that immediate task in hand, it's about teaching
that to others. That way you can have like more
of a multiplier effect for future.
Hey everyone, my name is Henry Surya Virawan and you're
listening to the Technically Juno Podcast, the show where
I'll be bringing you the greatest technical leaders,
practitioners, and thought leaders in the industry to
discuss about their journey, ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our journal. Hi everyone.
Welcome to The Technical Journal Podcast, the podcast where you
can learn about technical leadership and excellence from
my conversations with great tall leaders in the tech industry.
If this is your first time listening, please subscribe on
your podcast app and social media on LinkedIn, Twitter and
Instagram, and also on YouTube and TikTok for video contents.
And to support my work in producing this podcast, you can
either buy me a coffee at techlijuna dot deaf slash tip or
become a patron at techlijuna dot deaf slash patron.
My guest for today's episode is Akansha Gupta.
She is the author of Think Like a Software Engineering Manager.
In this episode, Akansha described the role of an
engineering manager and the key traits of being a good
engineering manager. She gave advice on how one can
transition to the Em role. And talk about the difference
between engineering management and leadership.
Hakansha then walk us through the three key pillars of
engineering management, which are people, process and
projects. Throughout the conversation, we
discussed topics such as delegation, performance
management, cross functional collaboration and time
management. Hakansha also shared her
practical advice for women in technology who are also
interested in becoming an engineering manager.
That includes tips based on her own personal journey.
I hope you enjoy listening to this episode and learn various
aspects of an engineering manager.
If you find it useful, please help Share this with your
colleagues, your friends and communities, and leave a 5 star
rating and review on Apple Podcasts and Spotify.
It will help me a lot in getting more people discover and listen
to this podcast and I really appreciate it.
Let's go to my conversation with Akansha after quick words from
our sponsor. Are you looking for a new cool
swag? Techlejuno now offers you some
swags that you can purchase online.
These swags are printed on demand based on your preference
and will be delivered safely to you all over the world.
Where shipping is available, check out all the cool swags
available by visiting Techlejuno dot dev shop.
And don't forget to brag yourself once you receive any of
those swags. Hey, everyone, it's good to be
back here again with another new episode of the Technical Journal
Podcast. Today I have with me Akansha
Gupta. So today we'll be discussing how
to think like a software engineering manager.
So Akansha, thank you so much for your time.
Looking forward for this conversation.
Thank you Henry for inviting me and I'm really looking forward
for the next set of our. Right.
So I always love to ask my guests inviting you to share
more about yourself, maybe any career highlights or turning
points that you think are interesting to share for the
audience here to learn from you? Absolutely.
So for me personally, my journey in computer science started when
I was a kid, at the age of around 7:00 when my dad got a
computer for the first time in the house.
So obviously, as every other child, my first instinct was to
use it to, you know, play games, and that was the only purpose
for me for that computer. Eventually I took up some
computer science courses in my school, and I was fortunate
enough that they had that opportunity early in the school
itself. And that obviously turned my
head into using the power of computers.
And my dad always wanted me to be a doctor, but I always
dreaded that profession, so hats off to all the doctors out
there. And so I decided to pursue
computer science as my undergrad course.
So it was a fun time. Obviously with more male
engineers in the room, it is always a fascinating field.
And then the biggest turning point for me was getting an
internship with Microsoft as part of my third year internship
program. And that was the first time and
I actually got like some sort of industry experience working with
professionals thinking more other than the academia itself.
And I think that was the biggest, you know, Launchpad for
my career growth. I later on joined Microsoft as a
full time employee, worked for a few years back in India.
That's where originally I am from.
And then I decided to pursue my Masters in Computer Science.
At that time, obviously I applied to some of the dream
colleges in United States and I was fortunate to join Columbia
University in the City of New York, where I pursued my Masters
in Computer Science with specialization in Software
Engineering. And after that, one after the
other, I joined Audible as my first full time job in the
United States, then followed by Robin Hood.
And currently I'm with Amazon in their AWS organization as a
Software Engineering Manager. So yeah, that's me in a
nutshell. Thank you so much for sharing
your story. I think it's really interesting
what got you like so many guests that I have as well.
So the first time they got computer, they are always
intrigued and that let them into this industry, right?
You recently published a book titled Think Like a Software
Engineering Manager maybe. Looking back, what were the
story behind how you come up with this book?
Is it something like a collection of learning lessons
from your journey, or is it something else that brought you
into writing the book? Yeah, So getting the book out
has been one of my most interesting journey, as well as
like the proudest achievement I would say so far.
So this was basically an idea in my head when I was changing my
jobs from Audible to Robin Hood. So as a software engineer, every
time I was making a job change, there were tons and tons of
resources. You have hacker rank, you have
lead code and whatnot to go ahead practice questions, and
obviously, you know, coding in different languages.
As an engineering manager, I found very limited resources.
There were like a lot of Harvard Business Review books that I
could refer to, but nothing concrete in form of like
actually strategizing that job change or, you know, helping me
with that career move. And I did obviously Struggle
reached out to, you know, some of the awesome mentors and
sponsors I've had in my life to help me guide through that
process and all my experiences. You know, my notes really
intrigued me with the idea of whatever I struggled with.
Why not get something out for everybody that can help the
community? And that was the main motivation
behind getting the book out. Now obviously this was a thought
to begin with. The next step was to reach out
to my friend circle and my network to see if somebody has
published a book. And again, being an
international student, this is not something that a lot of us
think through. And so that again was another
journey and a struggle to actually go ahead, pitch your
idea, look out for publishers who would be able to vouch for
your book and get you published. So that was another interesting
journey going through it. And finally, I was able to
decide on one publisher and then go ahead with the book.
Yes. I think it's interesting.
It always started to solve your own problems, right?
And I can say there are limited resources like you said about
engineering management. Many of them actually come in a
blog post. There are few EM books, EM
related books, but I think still your kind will be helpful to the
industry for people who are new to this role, right?
Which bring us to the first question that I'd like to ask
from you is what is the definition of Engineering
Manager role and what is the role and responsibility of
Engineering manager? Maybe we can start from there.
Yes. So I think in my opinion and
again you know it's personal opinion, the Engineering Manager
role, really in layman terms it's basically you are an
engineer and you can also do management.
So you know engineering Manager. Overall, I feel that this role
is sometimes undervalued but comprises of a lot of important
roles and responsibilities to help you manage A-Team.
So let's say you are 10 engineers.
Obviously, each individually provides great output, but there
needs to be a single thread that kind of consolidates all of
them, makes sure they are on track.
Not only that, we need someone with basic career development
helping them guide and do like a cross check, hey, what's going
well, what could be improved, what are the future
opportunities? And I think that's where the
engineering manager role really comes into the picture, where
they cut across the three pillars of the people, the
processes and obviously the projects in the industry.
So from the people aspect, as I mentioned, helping people with
one-on-one conversations, career development and all those
opportunities from the processes and making sure that the team
and the organization is working well like a well oiled machine
and is you know performing to the best of its ability.
That is equally important. And obviously the third pillar
or the 3rd component which is the projects where you know we
are as a company, we are continuously delivering value to
our customers and making sure what we are building is actually
used by the end customers. So that's how I kind of look at
the whole engineering manager role and you know how it plays
against the three pillars. Right.
I can see that you group them into these three pillars.
The 1st is like people and then the project and then also the
process, right, which can be overwhelming.
So I can see so many engineering managers feeling overwhelmed
with this role itself. And you can see it touches so
many different aspects and not to mention probably also the
technical aspects because you mentioned in the beginning it is
like a combination of the engineer plus also management,
right? So there could be some technical
aspects that are also demanded from this role.
So for people who are contemplating, maybe they are
just software engineers. Now they are getting into the
senior level and looking into two different parts which is
common in most of the big tech companies.
What would be some of the thinking process that if you can
advise them to think whether this engineering management role
is suitable for them? Yep.
So this is a great question just because being a software
engineer myself I have done that transition to an engineering
manager and few years back this was exactly the question that
was in my head. So I think first of all I would
like to suggest to all the engineers that any type moving
to management, special engineering management is not a
promotion. I know some of the people think
like that or you know it is promoted in that way.
It's like a lateral move in all the big tech companies where
obviously you can continue to be an individual contributor and go
on in that path or make that lateral move to engineering
management. So I think that's the first
piece of caution I would give to everybody who's contemplating
about that. And I think the next way you
should be thinking about is what is that?
I'm looking out from that role. Is it just the title that
impresses me? Like, hey, you know, I'll be a
manager. What is the motivation behind
thinking about engineering management?
Now if your answer is that, yes, I love coaching people.
People's growth really motivates me, inspires me, I love to see
projects going end to end, then yes, that's the right role for
you. But as I said, you know, if
you're going behind the title and just the perks that come
with it like being able to manage a team, I would
definitely ask you to rethink your ideas of whether you want
to actually pursue engineering management.
So I think that's the first thing that comes on top of my
mind. Another piece of advice would be
that eventually you would have to take a step back from coding.
I know that sounds sometimes contradictory that yes you are
an engineering manager, but with the role comes other set of
responsibilities and if you continue to be a full-fledged
engineer plus manager, obviously you know you are moving towards
like burnout stage, right? In the end you have those X
number of hours which are your work hours.
Now, I'm not saying that you have to not have that technical
acumen, but you need to change your responsibilities maybe from
active coding to reviewing code or more participation in design
discussions versus actually implementing the design.
So those are the things just to keep in mind and accept them
before you're thinking about the transition.
And I do cover this whole individual contributor to an EM
transition in detail in my book. So yes.
Yeah, it's always the questions on top of your mind when you are
thinking of this transition, right?
So like you said in the beginning, it's not a promotion.
And likewise, if you try but you dislike the role and you want to
go back to the IC, it's also not a demotion.
Think that's a very, very first important thing that we should
think about, right. So these transitions is not like
one way journey you can always go back, doesn't mean that it's
a promotion or the emotion, right.
So I think that's really key. And you also touch on a good
point in my view is that the coding time, right, so many
engineers started their career as an engineer, their love
coding, they love building things.
But as you go into management, more of your responsibilities
should change, right? Instead of the hands on coding.
Could be something more like a review, or maybe just
validating, reviewing and things like that.
You also touch on a few things. That many people would be
classifying them as soft skills. In your book you cover a few
traits of how someone could become a good EM, right?
So maybe looking from the traits aspect, what are some of the key
traits or the soft skills that you think will be really crucial
if someone wants to be a good EM, Yes.
So some of the key traits that I feel, you know, kind of
differentiate good EM from not so good EM would be first of all
the people aspect, right. You really have to care for your
people, whether it's people who are reporting to you, whether
it's your peers or people above you in the leadership change.
So basically at all levels really helping them, the career
development. For example, you know, a lot of
people ask me, hey, how do you structure your one on ones?
So one on ones are for the people.
It's not about asking for project updates or looking at,
hey, did you, you know, finish that task right.
It's really the engineer's time to help coach and guide a road
map for their career. So caring for people is the
first thing. Second, I see an EM as more of a
visionary, someone who's there to kind of look at the overall
organization strategy, their mission statement and condense
it to what it translates to at the team level or the
organization level that they are managing.
So really making sure that the company's Okr's are translated
to a team level OKR objective key and results.
That's how they should be able to give that vision to the team
and make them understand if you are a team, why you are a team.
You know, we all are in this together and overall you know,
you need to be an effective communicator.
You should be able to communicate and comprehend the
ideas and share it with the broader team.
And obviously it's not a one way communication like keeping that
door open where you are approachable by your team
members and they can knock on the door anytime and be like
hey, this is you know, this is where we need your help or this
is a roadblocker where you can help.
So those are the things to definitely keep in mind.
I think these are like the top traits and obviously keeping
like the EQ factor as it is said emotional intelligence and the
empathy. I think that is equally
important. And the last thing I would say
is leading your team by example. So a lot of times you need to
make sure that what you're asking your team members is
something you would do. You're not having unrealistic
expectations from your team members.
So leading to example, I feel you know is very important
sharing my own one personal example, there was a time when
in the next quarter my team was stars to work on a new set of
AWS services and at that time our team was not very well
versed with the AWS set of technology.
So what I made sure is that since we had a heads up on
what's coming in the next quarter, I dived into you know,
understanding the AWS certifications, played a little
bit hands on with the AWS suite itself, got myself certified and
then obviously I had the story to share.
And next, you know, I went into the one-on-one, shared it with
my team, was able to also share my resources and get them ready
for what was coming in. So this was like an example
where I didn't go and expect the team to like, hey, go get
yourself AWS certified. It was more of like if I could
do it as an EM, then let's together get into this journey
and take it to the finish line. Well, thanks for sharing that
personal story. So if I can summarize the few
key traits that you mentioned just now.
The first is the people aspect, right?
You really need to care and you really need to kind of like like
working with people, right. It's not like super like, but
you have to deal with people and hence you need to be able to be
comfortable working with people, right.
And then the second thing is about visionary, right?
Trying to translate companies or chaos into the team or chaos,
making sure things get improved and.
To bring value and communicator and I like also the EQ part, the
emotional aspect. So sometimes you are frustrated,
but you cannot show that to all the people in the team, right?
Not to make everyone is frustrated as well.
And also the empathy part. Some people may have their own
personal challenges and you need to exercise that empathy to help
them instead of making them worse.
And I think the last one, always leading by example.
As a manager, I think you are not the boss all the time,
right? You also need to lead by maybe
working with the people showing by example, which kind of like
brings me to the next question. Some people think or confuse the
term engineering manager and engineering leaders, right?
Is there any kind of a distinction in your view?
And if there's any, what is the distinction here?
Yes, that's a great question, something that even I have got
confused in my life early on in the career.
So I would say that leadership is more of a mindset or an
approach while management is more of like a title or a
position that you hold. So what I mean by that is that
as an engineering leader, you are kind of there to inspire
your team, coach your team. You are more setting the culture
for the organization and the company as a whole, while the
way I look at management is more of the executional aspect of it
which can be obviously doing the admin tasks, making sure the
projects reach the delivery time and so forth.
So I know that these two terms, engineering manager and
engineering leader are kind of used interchangeably.
But it is important to understand the key difference
that management is more of like a role in position while
leadership is a mindset. And what is the key is all of us
to be like great engineering leaders and do you really help
move the needle and you know get towards the success?
So if I understand what you just now mentioned is that yes, there
is difference, right? The leadership is all about
mindset. The management part is basically
getting things done is the critical aspect to it.
And I think one key challenge that I see some people think is
like manager here is become the boss like I said in the
beginning, right? And they always have to decide
many, many things. Do you have some tips for people
who think like that? Trying to be the go to person,
Always deciding about things right?
Always making decisions? Is that a good indicator of a
good engineering manager? Great question, Henry.
So I don't think so and especially you know it kind of
boils down to the earlier idea that moving to engineering
management is not a promotion. So that person can be someone
who's an engineering manager, but maybe from the company's
leveling guidelines is at the same level as you.
So they are not your boss, but. The way I would think is
thinking the EM role is more of a facilitator and a career
coach, so they are there for you in terms of helping you succeed
in your career. At the same time, looking into
the team's execution, but not necessarily someone who's a
boss. Now at the same time, I would
not say it can be a completely informal friend relationship,
because obviously in the end you need to take things seriously,
both phase. And that's another interesting
topic I touch in the book, that you cannot be completely
informal or be fully friends. You know, as a software
engineer, be fully friends with your engineering manager.
But it's more of like a partnership that needs to be
done together and AM is more of a facilitator in terms of
communication with the cross functional partners and the
overall execution of the team. I like the term facilitator that
you bring up here. So I think that's really
crucial, right. So you are not there to always
make decisions. Sometimes you facilitate, yes,
sometimes you make tough decisions, sometimes you also
care about people. And I think it's really, really
key speaking about the industry these days.
You mentioned in the beginning, right?
So it is a male dominated career.
So any kind of interesting insights from your own journey
to become an engineering manager for female, right.
So for those women in tech, is there anything that you want to
give to them? Maybe some kind of advice for
them to have to think about? Right, definitely.
You know, being a women of color and obviously coming from India,
this is an industry that is currently male dominated.
But one thing I can tell you is that with the evolving world,
there are so many, you know, different programs even within
the companies and outside that are really helping get more and
more women into the industry. So just thinking from the
internal company perspective, I've seen multiple mentorship
programs where you can get mentors and sponsors to help you
in your journey. If you would like to get into a
leadership role outside the company, there are several
platforms that one can look at some of the.
Platforms where I myself am a mentor are things like Plato,
HQ, Growth Mentor, First Round, Fast track which accepts
applications and one can apply and you can mention what sort of
a mentor are you looking for. So there is a fact that it's a
male dominated industry, but at the same time there are a lot of
resources where you can break that bar and actually succeed.
Another thing I would say is that we need to, as women, we
need to build a community. Right.
Get together like basically hand in hand.
We can actually really change the whole industry landscape.
So really, find mentors or sponsors who have done that
journey and they can help you guide how they navigated through
those challenges. It's not just the professional
challenges, but at the same time balancing a family, your own
personal goals and career aspirations.
So kinda you know, I always look at female leaders and how they
have gone through that journey. I try to connect with them
either through LinkedIn or through these different
mentorship platforms. So that would be my 1 tip to
dream big and don't let the whole idea of that this is a
male dominated society to stop you from achieving what you
really want to achieve. I think that's a really
beautiful message, right, for those women who are thinking
about doing the career of engineering management.
So I think it is possible definitely.
Even though you think it's a male dominated thing.
I can also see in the industry there are so many female in the
engineering leadership roles. So don't hesitate, right?
Build communities, find mentors like Akansha mentioned just now
and learn from them, right. So I think it's definitely
possible. So let's go to the three key
pillars that you mentioned in your book.
Again, people project and process.
So let's start with the people aspect.
We won't be covering all of the people things, but I think there
are two things that I want to cover in this conversation.
The first one is about delegation.
Why it is important for me to ask this question is because
many of these first time transition kind of engineer.
The first challenge is always to delegate, especially about
coding, right? Because you always think that,
OK, I can do it better myself. So maybe tell us more about the
key of delegation, especially learning to let go.
Yes, yeah. Delegation is one of the key
skill set you have to learn as you move to any of the
leadership roles and especially engineering management.
So I think first and foremost I would say delegation is not
about just assigning or allocating the task to someone.
A lot of people, you know, kind of confuse it with that, that
let's say I'm supposed to do tasky.
I can just ask a person B to go and perform that task.
No delegation is not that. Delegation in my head is a
journey that you do together with the person that is the
delegating or you know, whoever has been assigned that task.
And if you are the delegator, you need to make sure that the
task is clearly communicated in terms of what is expected and
what is the outcome that you're looking for.
At the same time, as I say, it's a partnership.
You have to provide them the right resources and the training
material to put them up for success, because in the end you
are equally responsible for the outcome.
It's not that once delegated, the outcome is no more related
to you. So that's where it's a key
distinction between just allocating a task versus
actually delegating a task. And a lot of times, Henry, the
term comes right like, hey, effective delegation and that is
what we are aiming for. So, yeah, So that's what I would
say. And the biggest thing is to
think about delegation as more of a coaching mindset instead of
the doer mentality that most of the fresh engineers have there.
As you mentioned, like, hey, I can do this code faster and so
why not, you know, just do it myself.
So it's not the idea about looking at that immediate task
in hand, it's about teaching that to others.
That way you can have like more of a multiplier effect for
future. So yeah, I think that's a very,
very important things that you mentioned just now, right.
I like the way that you mentioned.
It's not just assigning tasks, right, delegating, it's not just
about, OK, I give you this task and please report back when you
have done or finish your work. So I think it's more about
setting the expectations. That's the first things I think
the outcomes, right, not necessarily the how.
So the people can figure out the how maybe they can do it better,
maybe they can do it in a more creative way.
But if you set the expectation and the outcome right, I think
that's really, really crucial for the effective delegation.
And I think, yeah, you mentioned a very good important point that
as a leader you are still accountable.
You are not delegating that responsibility of the outcome to
the person itself as well. So I think I really love that.
So the other aspect of people that I want to discuss is about
managing performance. Again, for first time manager,
sometimes they are not expecting to do this, especially if they
come from the same team. The people that they lead are
previously friends or peers and now they have to manage people's
performance. So maybe if you can touch on a
little bit of important points about managing performance,
especially for high performers and low performers and things
like that. Yes.
And I think managing performance is a very critical role as an
engineering manager. And it really touches upon the
whole people aspect that you're responsible for.
So the way I would say is that managing performance, the
biggest tools that you have in your hand is the one-on-one
conversations that you have with your team members.
So use those conversations to the fullest where your
motivation as an EM should be to figure out what are their
strengths and I won't say weaknesses, but more of like
opportunities for growth and the aspirations they have in their
career. Once you have that foundational
knowledge, you can work with them to set up actionable goals.
I usually use the SMART criteria which stands for specific,
measurable, actionable, relevant and time bound tasks.
So using that SMART framework to set up goals with your team
members and obviously doing checkpoints to have like a
constructive feedback mechanism. And that's most of the companies
as we've heard you know like performance reviews or mid year
check in. To kind of help and make sure
everybody is on the right track and there's like a bidirectional
communication between both parties.
So that's the key we're using. The power of 1 on ones is
really, really crucial as an EM. The other point in terms of how
do I identify whether it's a high performer or low performer,
I think the main art here is to actually identify, you know,
whether a particular performer is a high performer or a low
performer And this is definitely a gradient can be sometimes
subjective and that is what we have to caution against.
Now, the biggest thing that we can use in this is the company's
leveling guides. Which is what is a standard that
is followed across your company. So that way there's no bias or
favoritism happening in a particular organization versus
or different organization within the same company.
And for those who don't know what exactly is a company
leveling guide, it could be more of like the competencies in a
particular job role that are essential or that kind of
differentiate software developer one versus a senior software
developer two. So something on those lines
where it can be? As simple as these are the
technical competencies, dealing with ambiguity and having more
experience with designs, technical designs, such a matrix
can really help you understand where you are actually in that
job role level and what is the gap that needs to be addressed
for you to move to the next level.
And that can really help differentiate whether someone is
a high performer versus a low performer.
And obviously once you identify that then there are different
strategies to handle high performer for which you know you
would like to keep them challenged because they are
always craving for newer tasks and ambiguous tasks I would say.
So providing them those opportunities and that is
something you need for high performers and at the same time
for low performers or underperformers, we really need
to. Provide them the training
resources to help them address that gap.
Figure out what's the blocker, Is it some personal reasons that
is keeping away from performing to the full potential or
something at the work which obviously is in your hand and
something you can change. So really acknowledging and
identifying those and then working towards a road map to
kind of address those gaps is the key, right?
I really like the portion where you mentioned remove the bias,
especially when you rate people's performance, right.
So if you have leveling guide in your organization, please use
that, don't use your subjective opinions or maybe you have a
better relationship. Sometimes it works like that,
right? So you have some wave rates in
your team, right? You always go to this person,
but try not to do that because it can create a very bad vibe
within the team, right? And try to use the leveling
guide. If you don't have leveling guide
in your organization, I think it's important to maybe ask the
question and try to raise the importance of having this
leveling guide within the organization.
Yeah, absolutely. Like having a leveling guide and
you know, I know some of the small startups which do not have
one, if you are a new EM in that company, it's a great
opportunity for you to shine by helping set up something for
your company. And another key point you know I
would just call out here is the whole concept of adjusted
expectations. Which I feel that is not
something that is very well or openly talked about.
Obviously as an EM you're setting these expectations with
your engineers, you're following the leveling guide.
But at the same time you can't expect someone who let's say
just had a baby missing for four months on maternity leave to end
of the year have the same set of outcome or output as somebody
who was here for the 12 months. So you know, just a nuance that
we don't openly talk about it and.
Really, some of the companies acknowledge this concept, but if
you are setting up something for your company, definitely keep
these adjusted expectations in mind.
In the end, we are all human and you know the whole idea of
having that empathy is really important.
Thanks for the plug. So I think this is a good
concept, right? Adjusted expectation.
Don't treat everyone the same, especially if they have breaks
in between maybe because of maternity or paternity, right?
Or maybe because of sick leave or something like that.
So try to adjust the expectations as well.
So let's move on to the next pillar which is the project.
So one thing that I want to discuss here is about cross
functional kind of a collaboration because most of
the times when you work in software engineering teams, it's
not often that you will work just by your own team, right,
within your own team. So you always have to
collaborate and cooperate with other teams.
I found one important quote that I think you took it from HBR,
right? It's like there's a statistic
saying that 75% of cross functional teams are
dysfunctional. Knowing about this fact or what
would be some of your tips or insights for engineering
managers here to think about when they collaborate cross
functionally? Yes, great point Henry and.
You know something that I have faced myself working as being
part of different organizations when it comes to collaborating
with the cross functional partners?
Of course you need to acknowledge what is important
for them, right? Sometimes we forget that if we
were in their shoes, how would we react?
So that is really important to understand where is the other
person coming from now, whether you're talking to your project
manager or whether you're talking to your technical
program manager. So effective communication and
coordination is the key here, where you need to be very clear
with what are your goals. Obviously when I say your, it's
like your team's goals. And you know, what is the
expectation there? A lot of times you will face
competing priorities in any organization where roadmap for
your team might not be In Sync with the roadmap of the other
team. And that's where the power of
negotiations come into picture, where obviously you go ahead,
you negotiate, you figure out if.
You know, maybe sending your engineer on a loan to another
team could help them with their road map and at the same time
helps you move the needle in your own road map.
So being open to those negotiations and having that
candid conversation kind of really helps.
Another thing is to be really, really transparent about what is
expected. Don't assume things.
It's always good to have that discussion and clear out any
ambiguous thoughts that one might have.
I read about this concept called Anima Washi.
As far as I remember it's like a Japanese term that kind of talks
about that. As you work with cross
functional partners, sometimes it is important to set the
foundation of what is expected. So maybe individually talking to
the different stakeholders. And ensuring that we are all on
the same page in terms of these are the resources we have, these
are the time constraints and this is the outcome that we're
looking for. So I really found that concept
interesting and I just mentioning for those who want to
read about it. But yeah, I think that's the key
in terms of working with cross functional partners is to
acknowledge the competing priorities, be open to
negotiations and being, you know, an effective communicator
and collaborator. Right.
I haven't heard about this term animal washi, so I'll make sure
to put in the show notes. So maybe I will learn myself as
well and for people to learn more about this concept.
And I think it's very important. Yeah, you mentioned a few
challenges that I can see, right?
The road map's not In Sync because they are two different
teams and sometimes, you know either the priorities are not In
Sync or just the timeline is not sync right.
Because work in parallel. You always have these kind of
challenges and sometimes you also have crunch time right,
where you are busy delivering something, but hey, somebody
just comes asking you to help them do something and it's
always clear to make it transparent, like you want to
help them. But sometimes there are issues
that you couldn't, for example, prioritize their ask versus what
you have to deliver, right? And I think the last point that
I want to touch, which you mentioned in the beginning about
the people aspect is the empathy of the emotional aspect.
So expect that there will be tough negotiations, people
pushing you about stars, right? And always keep that in a
positive manner, I would say, rather than make it like a
tension. So I think that's really, really
important. So let's move on to the next
pillar, which is about the process.
I think here what is the most important thing I want to ask is
how can an engineering manager set up a good process within
their team, especially knowing that there are so many best
practices, there are so many things, right, maybe unique
within the team themselves. Is there any kind of, I don't
know, like a best recipe of how they should set up a process
within their team? Yes, I think the best recipe is
first of all to understand what's the problem in the team,
right? You cannot find a solution until
you, you know, identify what is it that's going wrong.
So I think first and foremost, it's important to understand
where the gap is. And once you identify that, I'm
a big believer in getting your team together, so more of like a
democratic leadership style where you get everybody in the
team together, have those open brainstorming sessions in terms
of, hey, this is how we've been working so far.
This is the output, what are the ways we can try?
And mind you that nothing is a oneway door.
You can always pilot few things within the team and try them out
and see what works and what doesn't work.
At one point in my team we used to have a lot of code reviews
that would stay in pending for quite long.
So I got the team together in one of the stand up.
We brought up this whole problem statement and we decided that
maybe what we can do is as part of stand up call out like hey I
have this code review pending and any volunteers for it.
So in that way you're not sitting open-ended.
Let's say you need a ship IT or a acceptance from two people.
You're not sitting in ambiguity. Who are the two people looking
at? It within the stand up itself 2
volunteers have stepped up or maybe you know have been forced
volunteer to kind of look into those code reviews and that way
there is more targeted thing in terms of you know what's going
to happen. Eventually the team learned it
and no more we had to kind of do it.
This wasn't a big process as such, but something that really
helped us set a good habit of making sure we are on top of our
code reviews. So I would say starting with
identifying the problem. Getting the people together to
solve the problem because that way they feel they are more
heard and are part of the process.
And then obviously evaluating if it worked or not.
And you can always, you know, iterate back and brainstorm
again to Step 2. Yeah, it's always important to
include the people to come up with the solutions, right?
Find the problems together and also come up with the solutions
together, right? Again, the manager here doesn't
mean the only person who can come up with solutions and try
to improve the process, right? Everyone should be responsible
to improve the process within the team.
So one part of the process that I always find interesting
because many times engineering manager have to report to their
leaders, right? So could be CTO, could be VP of
Engineers and so on and so forth.
So what will be some of the good things about the process aspect
that you think will be good for them to report back to the top
leaders? Top management?
Yes. Obviously, you know what have to
be reported kind of depends, right, whether it's like some
sort of team metrics versus visibility into the progress of
a project. But I think the key tenets here
is to maintain that level of transparency with the leadership
in terms of what's happening. And even if there's a risk or a
blocker, call that out early so that you can get help on it in a
timely manner and whether it's like you need more resources or
a change in the strategy. So I think transparency is the
biggest when it comes to transparency.
The idea is to make sure you have the right reporting in
place or some dashboards. You cannot go and dump a lot of
technical knowledge to the leadership team.
Now, I'm not saying that our leaders are not technically
sound. It's just that they are into way
too many things. So we need to be cognizant of
their time. And so keeping it at a high
level and if they want to drill down further, they can always do
that. But keeping a high level reports
that kind of give them a 360 degree purview of what's
happening, what's working well and where are the blockers.
I think that would really help them to not just gain the
visibility but also help your team if you need any support
from the leadership. So yes, transparency I would
think is the biggest and you know how you bring that.
Transparency is the key. Right.
Thanks for including that transparency aspect.
Again. I think it's very important,
right? Set the expectations right,
knowing what the leaders want as well and try to deliver the
reports and all the dashboards that you think best will give
them the information and raise the risk early.
It's always a very, very important right.
Don't risk late when it's close to being a disaster or an
incident, right. So try to raise it earlier if
you can. So another part about process
that I think many maybe first time manager also struggle A lot
is about time management and especially if they started from
engineer role where most of the day they are just coding right,
spending time alone and doing a lot of productive work, focused
time. But now in management role they
need to do a lot of meetings, a lot of communication, maybe
writing stuff. What is the key for effective
time management. I think this is also something
that many people want to learn, yes.
And I think time management is such a puzzle that I would not
say that even after working for these years I have still
mastered that. So I'm still learning.
But what I can share are the few things that I have been trying
to do. To manage my time effectively.
First and foremost is like decluttering my calendar being
an EMI get tons and tons of meeting invites.
So it is really important for me to segregate see if it's more of
like a physical presence that this meeting has versus more of
like how can I actually contribute if I have to attend
that meeting and if it's of no use then like politely
responding to the e-mail and keeping the calendar neat and
clean I would say. And as a EM, you do need time to
do your tasks right a lot of times.
And what I have found is I would start with you know, To Do List
over the day. I attend meetings and my school
list just increases and the day just gets over and have not
actually done work. So it's important to block some
focus work hours for yourself during the week.
I usually do like 2 hour blocks whenever possible and you know,
obviously try to reject meetings if they fall into that.
So yeah, keeping time for yourself to actually do work is
really important. Another practice that I have
tried to follow in my teams is the meeting Bill of Rights,
where don't entertain a meeting, which is just like sync up or
project status, right. Really someone who is sending
out an invite should give you some sort of agenda in terms of
you know what is expected out of that meeting, what's the input
that we are going with and what is the expected outcome.
And that also ties well to the first point, which is for you to
take an informed decision whether you are actually needed
in that meeting or not. So following this habit really
helped also remove some of the duplicate meetings that we had
where we found out that while we were setting the agenda, you
know, it's kind of the same thing that we are repeating with
a different set of audience. So that's one.
And another nugget that I will throw out is the Pomodoro
technique. If people have heard about it.
Basically, you know, in simple terms it just says you work for
XX minutes and then you kind of take break, recharge and then
work again. So a subset of that what I have
followed in my teams is instead of setting a 30 minute meeting,
send a 25 minute meeting invite so that people always have a 5
minute breather to catch to take a restroom break, grab some
water or like just you know even stretch at their seat.
So that's another concept that can really help you manage your
time and at least feel better physically and from that health
perspective as well. So I think these are the key
Nuggets. But at the same time, you know
this. I do acknowledge that there is
no silver bullet solution to time management as an EM.
Keep a priority list and always make sure and yeah, you know, we
discussed about delegation. Use the power of delegation
wherever possible. Where someone from your team is
better suited to go attend a meeting, you can always, you
know, do that. Yeah, the key is always
prioritization, right? Sometimes also saying no.
So if you're invited to multiple meetings, sometimes you are
asked to help, right? Sometimes you have to.
Maybe assess yourself whether you have the capacity or maybe
you have some people to delegate to, right?
If not then maybe you can politely say no.
I was intrigued when you mentioned in the beginning when
you describe about this time management is that you have A to
do list that is growing and ever growing right?
It can never finish. So what will be your personal
tips how to handle that? Because it cannot continue on
and on, right for sure. So I think I'll like as you
mentioned you know the priority obviously every day the priority
might change. So keeping that To Do List in a
priority manner could really help.
And if there is something that needs immediate attention, so
obviously you look into that and then use delegation to move some
of the tasks which others can do.
And at the same time you know we need to keep a mindset that
those are also growth opportunities for others.
It's not like you are just moving things out of your plate
to others. You are actually providing those
growth opportunities to other members in your team.
So you know it's a win win situation both ends.
Keeping those things in mind can really help you effectively
manage your To Do List. But yeah, I will be very candid
that there have been times where you know on a Friday I would log
in two hours earlier just to get through that To Do List.
So yeah, I'm still learning and if you or others who are
listening to us have some tips, would love to hear their tips as
well how they manage time. Right.
I think this is a topic that is always an Evergreen, right.
So I think nobody can find a perfect solution.
And I think it's also contextual, right?
Different people have different preference.
Sometimes you have a productivity technique that work
for one person may not work for the others.
So I think my key tips will be find something that works for
you, right? There's so many productivity
techniques and tips out there. Find something that resonate
with you and that's really, really work well for you.
So I think we cover a lot right from the basics of an EM and the
three key pillars. And as we wrap up the
conversation, I have one last question that I want to ask you,
especially related to this engineering management
discussion that we just had. So my question is called the
three technical leadership wisdom.
You can think of it just like an advice maybe from your
experience, your expertise, right.
So what will be the three key wisdom that you want to share
with all of us here? Sure.
So I think the first would be dream big.
I feel that that is really important, right?
We get into this rat race sometimes and its more of like
what others are doing and we try to mimic that.
It is really important to understand where do we, you
know, a lot of people ask that in interview question, where do
you want to see yourself in five years?
You should be the one defining that and it's OK to dream big.
You might not get 100% of it, but at least you will have a
high level framework or a road map to kind of try towards it.
So I think that would be my first advice.
My second would be find a mentor or a sponsor.
Now I know a lot of people shy away from this thing, at least
in my personal life. I feel like having the mentors
has really helped me all the way when I was a freshman all the
way. Even now I have mentors within
the organization and outside organization to kinda help guide
me in my career, suggest me resources that can help upskill
me. So having that mentor is really
important. So I think that would be my
second piece of advice. And my third piece of advice
would be don't shy away from this whole concept of
delegation. I feel it's really, really
important. As you grow in your career, you
really want to scale yourself and your teams, so getting that
art earlier in your hand and honing that can really help you
to scale well. I think spoken just like a true
EM, right? Delegate.
Well, delegate effectively, but don't forget to dream big as
well, right? I think sometimes we shy away
from trying to achieve what we always dream about.
But I think the key thing is maybe setting a direction where
you want to go and try to achieve that milestone over
milestone. She doesn't have to come all in
one day, right? So I think thanks for sharing
that piece of wisdom. So Akansha, thank you so much
for this discussion. If people love the conversation
and want to reach out and ask you about stuff about
engineering management, maybe is there a place where they can
find you online? Absolutely.
So. I am an active LinkedIn user, so
I can share my LinkedIn profile and people can reach out to me
through LinkedIn. Thanks for that.
I will put that in the show notes as well.
So thank you so much, Akansha for your sharing today.
So I really learned a lot about engineering management as well.
So thank you for that. Yep.
Thank you so much Henry, for having me.
This was really insightful and you know, I loved our super
candid discussion and all the best to everyone listening out.
And yeah. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode and if you're new to the
podcast. Make sure to subscribe and leave
me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at Tech Lead journal dot dev website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on tech lead journal dot def to get notified for any
future episodes. Stay tuned for the next
Technically Juno episode, and until then, goodbye.