Speaker: Purnima Kamath

Meetup: Speakers Session: Journey of Senior Developers - Women Who Code Singapore

Purnima Kamath shares what it takes to be an Engineering Manager.

Event Page: https://www.meetup.com/Women-Who-Code-Singapore/events/261464917/ 

Produced by Engineers.SG

Recorded by: Ka Ho Ying

Help us caption & translate this video!

https://amara.org/v/p5le/

Hi, my name is Purnima Kamath and I am a director with Women Who Code in Singapore.

I founded the network with Yulin in 2017 in January.

So that makes us around 2 or 3 years now.

I'm also an evangelist with Yao Conferences.

We bring experts from all over the world to Singapore to develop our communities.

So if you'd like to know more of what we do and all the cool things we have in store, So do chat with me later.

My topic for today is essentially around life hacks For an engineering manager.

Almost a decade back when I First took on my role of an engineering manager, I really wish somebody had mentored me and prepared me into Actually taking up the role.

So this talk is titled I wish Someone told me this.

What this talk is not about, it's Not going to be about how agile is good or how scaled agile will probably be beneficial to your organization It's not about measuring velocity of your team or how you could get estimates, right?

But yeah, what the best team structure could be.

But what this talk is about is essentially a few life hacks 101 for managing teams.

kind of bundle it up in 20 minutes and then present it to you.

A little bit about myself, my career journey.

I graduated as an electronics engineer and started off my software journey in 2004.

So my first job was as a java and a web developer.

So if you're familiar with technologies like 8051 micro Controllers using assembly language or java 2, the ancient Version, or spring 1.1 or hibernate or jsr268 portlets, that's the generation of software engineers I come from.

I've worked across various financial institutions, like Morgan Stanley, Lehman Brothers, and eventually Credit Suisse, which was my last job.

I had developed OTC derivative trading systems, and also the latest project I worked on was investment banking research distribution systems.

Almost a decade back, I was given this opportunity to manage a couple of development teams and product teams across multiple cities and different time zones across Singapore, Pune, London, New York, and Mexico.

So, whenever someone asks me what a manager does, this is the gist that comes into my mind.

So, managers are essentially middle men or middle women, and who manage stakeholders on 1 hand and teams

The most notably what you will see in this gif is the stakeholders and the team are never on the seesaw at the same time.

It's just like juggling both of these components together.

Goes to say something about the role, you cannot make everyone happy.

There are different people who do different roles.

And there is an all-encompassing engineering manager as well.

Some people call themselves as people's manager because they're more focused towards people's career developments and their aspirations.

Few of them are more technically minded who take architectural decisions for the teams on how the product should be delivered.

Few of them are more delivery oriented, like project tracking, resource management, or what are the schedules, what are the constraints in the particular schedule when you're delivering stuff.

All the ubiquitous engineering manager who does all of the above.

Managers hire people right now, or they kind of project what the hiring is gonna look like 6 months from now, Communicating with stakeholders, be it product Owners or users or if it's a small company, Coordinate with your ceo.

Track project from a Schedule standpoint, monetary standpoint or time Standpoint.

Team objectives and appraisals and timesheets.

So on a friday evening, just before you go for your family Dinner, you realize you haven't approved timesheets.

And then you open this humongously huge and slow System And you start typing in each 30 individual's names and try to Approve the time sheet.

The only downside as engineers that we see while we are Promoted to engineering managers is there's no coding involved.

There's a huge perspective shift that needs to happen when you Are a coder, when you code on a day-to-day basis and you move Into an engineering manager role.

It means that you have to start delegating.

As engineers, we have a tendency to do everything ourselves.

We want to do every line of code is something that you need to draft and craft and create and submit and publish to production.

couple of years back, we hired a vendor team in Pune.

the vendor selection, trying to figure out what is the contract that suits them best, you know, scope out the project, what they would need to do, and stuff like that.

And there was the only use case that we wanted them to work on is to convert this low-level Java transport, which used a messaging system for an SOA, a service-oriented architecture, and move it onto a shiny new technology at the time called as Apache CXF.

So if you worked in software on open source projects in the last decade, you would know that the documentation was terrible.

And people hardly had documentation for open source.

And even if it did have libraries, Even if they had documentation, it was so convoluted and so complicated, people could never make sense of it.

And they were stuck at the minutest details that go into actually adopting that piece of technology.

And unfortunately, we were not able to meet the timelines.

My solution to it is I did the whole thing myself.

I felt really cool because I was a manager.

I was managing these 2 teams who are disparate, who are in 2 different locations and still not able to deliver.

I felt really cool, you know, but unfortunately I realized after some time I was the only 1 doing it all the time.

So it's it's it was great for the project but not for the team as such.

Even the senior management kind of understood that there is no outcome coming out from the team.

We moved on to a different contract altogether, and the team couldn't make it.

I could have actually spoken upwards to my managers and asked for some budgets on training, asked for more time on delivery.

I could have worked downwards to my team and asked them to, you know, guys, fuck up.

Or actually, I could have worked or trained these people to actually come up to speed and do the project and implement it.

This is what I did with the next vendor that we had and really happy to say that they are still around So hopefully thriving Another learning while growing in the engineering managers role was to create teams which are not dependent on you At any point in time if you are Managing at least 2 or 3 teams that could comprise of 20, 30 individuals, imagine a scenario where all these 30 Individuals come to you

There's only 24 hours in a day and you are not able to answer Each 1 of them.

The best you could do is to Create a team structure where you have only a couple of leads Reporting into you and have those leads build their leadership skills to actually manage those sub-teams.

a lot of your time to do more creative things and things that are more meaningful to you.

It helps not just to maintain your sanity, it Also helps build leadership in your team.

Call it, if you're into scaled, agile methodology, call it scrum of scrums, if you may.

We are no Captain Marvels or Supergirls here.

So yeah, delegate and build independent teams.

You know the biggest, boring-est stuff managers do is emails.

Emails on action items, emails on minutes of meetings, Follow-up on action items, follow-up on minutes of Meeting, it's just endless.

It's the most time-consuming And the least productive part of any manager's job.

And believe me, I've had nightmares, you know, the Email hell where you have nothing to do but just responding to emails day in and out.

Time boxing is an idea where you allocate a certain amount of time to a task and just get to it dispassionately during that hour.

It can be an hour, it can be 2 hours, or however many hours, whatever you allocate to it.

Dispassionate to get to that particular task, and you finish and you stop obsessing over it after that particular time period.

There is this author called Charles Duhigg who's written about power of habit, how creating habits around something and

getting to it consistently becomes a natural phenomenon.

So what it means is once you get to time boxing on a regular basis, it comes to you naturally.

So you just don't keep obsessing over emails all the time.

This especially is important when it comes to time boxing emails because, first of all, you would control the urge of responding to something immediately.

Control the urge of responding to something at night or at midnight when you've woken up for a sip of water.

It will set expectations Amongst your team, amongst your colleagues, your peers, and also your management They won't be expecting anything out of you at an unearthly hour Or in times of constraints, let's say you have a production issue Or you're not well, or you're on a vacation, people don't expect you

to respond Because you know you're not available You can also get to more important things that are more meaningful to you.

The biggest aspect of being a manager is to build trusting teams.

Trusting teams are teams that are, first of all, they're independent, they don't rely just on you.

And teams that believe that you have their back.

And this third point is extremely important in the software industry, unfortunately.

Few years back, there was this 1 particular session management bug in the app that I was managing.

And The impact was for a few users, but I think the bigger issue was a compliance issue since it was a banking

The bug was because of a poorly written code by this consultant in New York, who happened to not be around when the bug had

I and the team, we spent around 2 nights debugging the whole thing and fixing the whole Thing.

And eventually when the fix Went out, everything was hunky-dory and we had a Retrospective with our senior management on what went wrong, what we could do better.

1 of the senior managers, he was clearly upset because compliance issue, right?

And if you work in banking tech, you would know that that's a strict no-no.

And he got on to the call, he was a little bit angry, he was a little bit upset, and he called the dev team a failure, which was very upsetting because the dev team actually helped fix the whole thing.

It wasn't really the dev team's fault, if I can say so.

It reduces the morale of the team when you have so much negativity in a talk, in a call, and especially coming from a senior manager.

I lost 2 members from my team that month, and I think

not for 1 of my mentors in that particular organization.

all set up clear, defined processes and you communicate it well.

You don't assume that a particular consultant, since he's based in New York, he must be really cool and he would know what unit testing means, right?

See what works for your team, what doesn't work, and don't blame people for mistakes.

Instead, spin it off into a positive way, create learnings and improvements.

humanize the engineering manager's position is to create like a backup or a deputy of sorts, to actually also help to get a pulse of what's happening within the team and also create a little bit of leadership, you know, you mentor people on leadership.

Another critical aspect of a manager's job is hiring.

There was this talk by Jessica Kerr a few months back at YOW Sydney where she talks about teams being a semantasy.

Semantasy is a learning system, a learning system which is consisting of learning parts.

So she says that you don't make great teams by hiring all superstar Developers.

She says if you just build Teams where the developers work well with each other and such Developers create great teams.

And these great teams in turn create superstar developers.

So don't go looking for those champs who give really cool talks at conferences.

They might not be exactly what your team needs.

Tailor down your job description to make it more inclusive.

Try avoiding words like, you know, you want to hire superstars or hackers.

Try and hire more junior devs, Because junior developers are fresh minds.

They are willing to adopt what you are telling them, Essentially.

And they adopt your culture Very well and they really actually deliver the kind of things that you want them to do, and mentor more often.

I think as engineering managers, what we don't do is try to mentor people and build them up.

We are always expecting people to perform right from the get-go.

I think mentorship is extremely important.

most of a manager's job is just showing up.

It's just showing up, setting up meetings and showing up to them.

101s should not be just about work, or how many bug fixes have you done, or how many JIDAs did you solve, or telling off people that they haven't done well in their jobs or something.

It has to be about getting to know that individual more.

It has to be about their habits, their hobbies, their aspirations, and try and build the semantasy that you're actually expecting within your teams.

Give it enough time, and discussing with people is important.

If you're feeling more radical as an engineering manager, host, ask me anything.

But yeah, let me know if you actually ever host, or ask me anything.

The most common problem that engineers have when they take up engineering manager roles is job satisfaction.

As engineers, we are used to the pat on your back, like, great job, you fixed the production issue, or you know, congratulations, you know, here's your certificate of appreciation.

You fixed most number of JIRAs this month.

As engineering managers, nobody does that for you.

Because your senior management could care 2 monkeys if you've done a great job.

And your team is actually expecting you to pat their backs.

So it's essentially, I wouldn't say a thankless job, but tending towards there.

So how do you get job satisfaction in such a scenario?

First of all, you have to keep A track of your achievements.

Those little moments that you Get when you're a manager of your team, let's say that you Actually helped mentor somebody or you actually helped somebody towards their career aspirations.

I used to maintain an Excel sheet, and I'm a big user of Microsoft OneNote, with the tabbed notes, so that I can actually tabulate Every month what I have done.

Because it's important not just from your appraisal standpoint But also from your sanity.

Because sometimes what happens Is actually most times An engineering manager's job cannot be quantified.

You cannot count how many successes you have had or what You could do better.

You could only way to do it Is document the small moments that you had through the year.

I think if there's 1 learning that I would have is, as managers, it's so easy to not code And lose touch with coding.

And it's important because, especially when you're looking for jobs

externally, coding is the entry criteria.

A manager or a senior software engineer or a lead engineer or an architect, the entry level criteria is code.

So if you lose touch, your choices go lower.

And it's also important to understand how your team thinks, and also if they are giving the right estimates, and so on.

Try to see if you can contribute in a small way on your own projects.

Attend any other meetup across Singapore.

Most engineers, especially women who get into the engineering manager's role are normally filling in for somebody, somebody who's gone on a vacation, somebody who's gone on a sabbatical, or if it's a new role, amazing.

But when you are given that position, ask for a raise, ask for a promotion, because normally you are not offered that promotion and not offered that raise.

it will help me understand if I will like being an engineering manager or think that if I do a great job they will actually give me a raise or a promotion.

It did not happen to me and I unfortunately learned it a little bit late.

So, and be ready for resistance because when you ask them for, ask your senior management for a raise for a promotion because you're doing an engineering manager's job that you will be Given a little bit of resistance saying that you know, you probably should try and you know, think see if it actually works for you Keep reminding them That's what you can do And I think eventually things do settle down.

And once you know that the engineering manager's role is for you, you don't want to feel left out and you think that you actually spent so much time actually doing that role and not having been given a raise.

So that's all I had from the tips basket from what I've learned.

If you are going to take up your first gig as an engineering manager, be kind to yourself.

And it's building teams, hiring, communicating, minutes, emails.

You do not have to know everything and it's okay to ask for help.

And just remember, Everybody has a manager.

if you like generative art, you can follow me.


Speaker 0: Hi, my name is Purnima Kamath and I am a director with Women Who Code in Singapore. I founded the network with Yulin in 2017 in January. So that makes us around 2 or 3 years now. So yay. I'm also an evangelist with Yao Conferences.

Yao is

Speaker 1: a conference organization. We bring experts from all over the world to Singapore to develop our communities. So if you'd like to know more of what we do and all the cool things we have in store, So do chat with me later.

Speaker 0: My topic for today is essentially around life hacks For an engineering manager. Almost a decade back when I First took on my role of an engineering manager, I really wish somebody had mentored me and prepared me into Actually taking up the role. So this talk is titled I wish Someone told me this. What this talk is not about, it's Not going to be about how agile is good or how scaled agile will probably be beneficial to your organization It's not about measuring velocity of your team or how you could get estimates, right? Or how your project can be under budget.

Is there such a thing as under budget? I don't think so. But yeah, what the best team structure could be. But what this talk is about is essentially a few life hacks 101 for managing teams. Stuff that I learned the hard way.

Hope I can

Speaker 1: kind of bundle it up in 20 minutes and then present it to you.

Speaker 0: A little bit about myself, my career journey. I graduated as an electronics engineer and started off my software journey in 2004. So my first job was as a java and a web developer. So if you're familiar with technologies like 8051 micro Controllers using assembly language or java 2, the ancient Version, or spring 1.1 or hibernate or jsr268 portlets, that's the generation of software engineers I come from. I've worked across various financial institutions, like Morgan Stanley, Lehman Brothers, and eventually Credit Suisse, which was my last job.

I had developed OTC derivative trading systems, and also the latest project I worked on was investment banking research distribution systems. Almost a decade back, I was given this opportunity to manage a couple of development teams and product teams across multiple cities and different time zones across Singapore, Pune, London, New York, and Mexico. So, whenever someone asks me what a manager does, this is the gist that comes into my mind. So, managers are essentially middle men or middle women, and who manage stakeholders on 1 hand and teams

Speaker 1: on the other. The most notably what you will see in this gif is the stakeholders and the team are never on the seesaw at the same time. It's just like juggling both of these components together. Goes to say something about the role, you cannot make everyone happy.

Speaker 0: So who are engineering managers?

Speaker 1: There are different people who do different roles. And there is an all-encompassing engineering manager as well. Some people call themselves as people's manager because they're more focused towards people's career developments and their aspirations. Few of them are more technically minded who take architectural decisions for the teams on how the product should be delivered. Few of them are more delivery oriented, like project tracking, resource management, or what are the schedules, what are the constraints in the particular schedule when you're delivering stuff.

Speaker 0: All the ubiquitous engineering manager who does all of the above. What do these managers do? Managers hire people right now, or they kind of project what the hiring is gonna look like 6 months from now, Communicating with stakeholders, be it product Owners or users or if it's a small company, Coordinate with your ceo. Track project from a Schedule standpoint, monetary standpoint or time Standpoint. Team objectives and appraisals and timesheets.

The most fun part of being a manager. So on a friday evening, just before you go for your family Dinner, you realize you haven't approved timesheets. And then you open this humongously huge and slow System And you start typing in each 30 individual's names and try to Approve the time sheet. Fun job. The only downside as engineers that we see while we are Promoted to engineering managers is there's no coding involved.

There's a huge perspective shift that needs to happen when you Are a coder, when you code on a day-to-day basis and you move Into an engineering manager role. So what do I mean by that? It means that you have to start delegating. As engineers, we have a tendency to do everything ourselves.

Speaker 1: We want to do every line of code is something that you need to draft and craft and create and submit and publish to production. A Personal story, a

Speaker 0: couple of years back, we hired a vendor team in Pune. I was involved in

Speaker 1: the vendor selection, trying to figure out what is the contract that suits them best, you know, scope out the project, what they would need to do, and stuff like that. And there was the only use case that we wanted them to work on is to convert this low-level Java transport, which used a messaging system for an SOA, a service-oriented architecture, and move it onto a shiny new technology at the time called as Apache CXF. So if you worked in software on open source projects in the last decade, you would know that the documentation was terrible. And people hardly had documentation for open source. And even if it did have libraries, Even if they had documentation, it was so convoluted and so complicated, people could never make sense of it.

So naturally, the team suffered. They were not able to deliver it. And they were stuck at the minutest details that go into actually adopting that piece of technology. And unfortunately, we were not able to meet the timelines. My solution to it is I did the whole thing myself.

I delivered it. And it was amazing. I felt really cool because I was a manager. I was managing these 2 teams who are disparate, who are in 2 different locations and still not able to deliver. I felt really cool, you know, but unfortunately I realized after some time I was the only 1 doing it all the time.

So it's it's it was great for the project but not for the team as such. And this was visible to everybody. Even the senior management kind of understood that there is no outcome coming out from the team. So obviously we moved on. We moved on to a different vendor.

We moved on to a different contract altogether, and the team couldn't make it. What could I have done instead? I could have actually spoken upwards to my managers and asked for some budgets on training, asked for more time on delivery. I could have worked downwards to my team and asked them to, you know, guys, fuck up. You have to complete this project.

Or actually, I could have worked or trained these people to actually come up to speed and do the project and implement it. This is what I did with the next vendor that we had and really happy to say that they are still around So hopefully thriving Another learning while growing in the engineering managers role was to create teams which are not dependent on you At any point in time if you are Managing at least 2 or 3 teams that could comprise of 20, 30 individuals, imagine a scenario where all these 30 Individuals come to you

Speaker 0: with questions. There's only 24 hours in a day and you are not able to answer Each 1 of them. The best you could do is to Create a team structure where you have only a couple of leads Reporting into you and have those leads build their leadership skills to actually manage those sub-teams. So that kind of actually frees up

Speaker 1: a lot of your time to do more creative things and things that are more meaningful to you. It helps not just to maintain your sanity, it Also helps build leadership in your team. Meet with the leads regularly. Call it, if you're into scaled, agile methodology, call it scrum of scrums, if you may. We are no Captain Marvels or Supergirls here.

We don't want to do everything. So yeah, delegate and build independent teams.

Speaker 0: You know the biggest, boring-est stuff managers do is emails. There are so many emails. Emails on action items, emails on minutes of meetings, Follow-up on action items, follow-up on minutes of Meeting, it's just endless. It's the most time-consuming And the least productive part of any manager's job. And believe me, I've had nightmares, you know, the Email hell where you have nothing to do but just responding to emails day in and out.

Yeah, it's horrible. The solution to it is time boxing. Time boxing is an idea where you allocate a certain amount of time to a task and just get to it dispassionately during that hour. It can be an hour, it can be 2 hours, or however many hours, whatever you allocate to it. It's a life hack.

Dispassionate to get to that particular task, and you finish and you stop obsessing over it after that particular time period. There is this author called Charles Duhigg who's written about power of habit, how creating habits around something and

Speaker 1: getting to it consistently becomes a natural phenomenon. So what it means is once you get to time boxing on a regular basis, it comes to you naturally. So you just don't keep obsessing over emails all the time. This especially is important when it comes to time boxing emails because, first of all, you would control the urge of responding to something immediately. Control the urge of responding to something at night or at midnight when you've woken up for a sip of water.

It will set expectations Amongst your team, amongst your colleagues, your peers, and also your management They won't be expecting anything out of you at an unearthly hour Or in times of constraints, let's say you have a production issue Or you're not well, or you're on a vacation, people don't expect you

Speaker 0: to respond Because you know you're not available You can also get to more important things that are more meaningful to you. The biggest aspect of being a manager is to build trusting teams. What do I mean by trusting teams? Trusting teams are teams that are, first of all, they're independent, they don't rely just on you. They rely on each other.

Multiple sub-teams rely on each other. And teams that believe that you have their back. And this third point is extremely important in the software industry, unfortunately. A personal outage story, if I may. Few years back, there was this 1 particular session management bug in the app that I was managing.

And The impact was for a few users, but I think the bigger issue was a compliance issue since it was a banking

Speaker 1: application. The bug was because of a poorly written code by this consultant in New York, who happened to not be around when the bug had

Speaker 0: actually surfaced. I and the team, we spent around 2 nights debugging the whole thing and fixing the whole Thing. And eventually when the fix Went out, everything was hunky-dory and we had a Retrospective with our senior management on what went wrong, what we could do better. 1 of the senior managers, he was clearly upset because compliance issue, right? And if you work in banking tech, you would know that that's a strict no-no.

And he got on to the call, he was a little bit angry, he was a little bit upset, and he called the dev team a failure, which was very upsetting because the dev team actually helped fix the whole thing. It wasn't really the dev team's fault, if I can say so. It reduces the morale of the team when you have so much negativity in a talk, in a call, and especially coming from a senior manager. I lost 2 members from my team that month, and I think

Speaker 1: I would have left 2 if it was

Speaker 0: not for 1 of my mentors in that particular organization. So how do you build trust? You first of

Speaker 1: all set up clear, defined processes and you communicate it well. You don't leave it to assumptions. You don't assume that a particular consultant, since he's based in New York, he must be really cool and he would know what unit testing means, right? Apparently, he doesn't. So communicate them clearly.

Be flexible with those processes.

Speaker 0: See what works for your team, what doesn't work, and don't blame people for mistakes. Instead, spin it off into a positive way, create learnings and improvements. Anger really doesn't help anybody.

Speaker 1: I think a brilliant way to

Speaker 0: humanize the engineering manager's position is to create like a backup or a deputy of sorts, to actually also help to get a pulse of what's happening within the team and also create a little bit of leadership, you know, you mentor people on leadership. It also kind of builds more trust. Another critical aspect of a manager's job is hiring. There was this talk by Jessica Kerr a few months back at YOW Sydney where she talks about teams being a semantasy. So what is semantasy?

Semantasy is a learning system, a learning system which is consisting of learning parts. So she says that you don't make great teams by hiring all superstar Developers. She says if you just build Teams where the developers work well with each other and such Developers create great teams. And these great teams in turn create superstar developers. So don't go looking for those champs who give really cool talks at conferences.

They might not be exactly what your team needs. But try hiring for more diversity. Tailor down your job description to make it more inclusive. Try avoiding words like, you know, you want to hire superstars or hackers. It just doesn't work.

Try and hire more junior devs, Because junior developers are fresh minds. They are willing to adopt what you are telling them, Essentially. And they adopt your culture Very well and they really actually deliver the kind of things that you want them to do, and mentor more often. I think as engineering managers, what we don't do is try to mentor people and build them up. We are always expecting people to perform right from the get-go.

I think mentorship is extremely important.

Speaker 1: In my experience,

Speaker 0: most of a manager's job is just showing up. It's just showing up, setting up meetings and showing up to them. Setting up 101s and showing up to them. 101s should not be just about work, or how many bug fixes have you done, or how many JIDAs did you solve, or telling off people that they haven't done well in their jobs or something. It has to be about getting to know that individual more.

It has to be about a personal life. It has to be about their habits, their hobbies, their aspirations, and try and build the semantasy that you're actually expecting within your teams. Give it enough time, and discussing with people is important. If you're feeling more radical as an engineering manager, host, ask me anything. But yeah, let me know if you actually ever host, or ask me anything.

The most common problem that engineers have when they take up engineering manager roles is job satisfaction. As engineers, we are used to the pat on your back, like, great job, you fixed the production issue, or you know, congratulations, you know, here's your certificate of appreciation. You fixed most number of JIRAs this month. As engineering managers, nobody does that for you. Unfortunately, that's the truth.

Because your senior management could care 2 monkeys if you've done a great job. And your team is actually expecting you to pat their backs. So it's essentially, I wouldn't say a thankless job, but tending towards there. So how do you get job satisfaction in such a scenario? You create your own yardstick.

First of all, you have to keep A track of your achievements. Those little moments that you Get when you're a manager of your team, let's say that you Actually helped mentor somebody or you actually helped somebody towards their career aspirations. You document all of this. I used to maintain an Excel sheet, and I'm a big user of Microsoft OneNote, with the tabbed notes, so that I can actually tabulate Every month what I have done. Do it on a daily basis.

Because it's important not just from your appraisal standpoint But also from your sanity. Because sometimes what happens Is actually most times An engineering manager's job cannot be quantified. You cannot count how many successes you have had or what You could do better. You could only way to do it Is document the small moments that you had through the year. If not, it's easily forgotten.

And do not lose touch with coding. I think if there's 1 learning that I would have is, as managers, it's so easy to not code And lose touch with coding.

Speaker 1: And it's important because, especially when you're looking for jobs

Speaker 0: externally, coding is the entry criteria. A manager or a senior software engineer or a lead engineer or an architect, the entry level criteria is code. So if you lose touch, your choices go lower. And it's also important to understand how your team thinks, and also if they are giving the right estimates, and so on. Try to see if you can contribute in a small way on your own projects.

If not, start a pet project. Attend Women Who Code meetups. Come and join us. We talk about code on a regular basis. Attend any other meetup across Singapore.

They're all awesome. Keep up skilling. Most engineers, especially women who get into the engineering manager's role are normally filling in for somebody, somebody who's gone on a vacation, somebody who's gone on a sabbatical, or if it's a new role, amazing. But when you are given that position, ask for a raise, ask for a promotion, because normally you are not offered that promotion and not offered that raise.

Speaker 1: Do not ever do it for the learning or

Speaker 0: it will help me understand if I will like being an engineering manager or think that if I do a great job they will actually give me a raise or a promotion. It never happens. It did not happen to me and I unfortunately learned it a little bit late. So, and be ready for resistance because when you ask them for, ask your senior management for a raise for a promotion because you're doing an engineering manager's job that you will be Given a little bit of resistance saying that you know, you probably should try and you know, think see if it actually works for you Keep reminding them That's what you can do And I think eventually things do settle down. And once you know that the engineering manager's role is for you, you don't want to feel left out and you think that you actually spent so much time actually doing that role and not having been given a raise.

So that's all I had from the tips basket from what I've learned. If you are going to take up your first gig as an engineering manager, be kind to yourself. And it's building teams, hiring, communicating, minutes, emails. It's a lot to do. It's a tough job.

You do not have to know everything and it's okay to ask for help. And just remember, Everybody has a manager. Even a CEO reports to a board, right? So they've got managers too. Thank you.

That's my Twitter handle. So yeah,

Speaker 1: if you like generative art, you can follow me. I keep doing a lot of generative stuff. Thanks.

See all Engineers.SG transcripts on Youtube

Life Hacks for an Engineering Manager