Software Engineer or Manager? Things to Know Before Making the Switch

Summary

In this insightful video, the speaker shares their personal journey transitioning from a Software Development Engineer to a Software Development Manager and back again. They delve into the decision-making process, the stark differences in day-to-day responsibilities, and the pros and cons of each role. Highlighting the importance of team culture, the challenges of constant interruptions, and the loss of hands-on technical work, the speaker provides valuable insights for those contemplating a similar career shift. Their experience underscores the value of trying different paths to understand one's true passions and the significant growth opportunities that come with stepping out of one's comfort zone.

Takeaways

• 😀 The speaker transitioned from a software development engineer to a manager and then back to an engineer, providing insights into both roles.
• 🔧 There are two ways to become a software manager: directly request the role or take the lead in a team without a manager, demonstrating management skills.
• 🏗️ The speaker's transition into management was natural, as they joined a team in need of organization and process building.
• 📚 The importance of training and resources was highlighted, including company-specific training and the book 'Managing the Unmanageable'.
• 🌐 A manager's day is filled with meetings and interruptions, contrasting with the focused, uninterrupted time an engineer might enjoy.
• 💼 The role of a manager involves mentoring, developing team culture, and balancing technical roadmaps and priorities.
• 🚧 The speaker felt a loss of technical depth as a manager, which was a significant drawback for them due to their passion for technology.
• 🤝 A key part of management is achieving through others, which requires building a strong team and fostering collaboration.
• 🔑 The speaker realized their passion for technical work after an intense hour of problem-solving, which was more satisfying than their managerial duties.
• 🔄 The transition back to an engineer was a gradual process to ensure minimal disruption to the team.
• 🛑 The experience as a manager provided the speaker with valuable skills and clarity on their career preferences, despite the challenges.

Q & A

What was the individual's initial career transition from software development engineer to what role?

The individual transitioned from a software development engineer to a software development manager.

Why did the person decide to switch back to their previous role as a software development engineer?

The person switched back because they missed the technical aspects of software development and felt more passionate about it compared to the managerial responsibilities.

What are the two general ways to become a software manager according to the script?

The two general ways are either directly requesting the role from your manager or by taking the lead in a team without a manager and doing the tasks that a manager would typically do.

What was the individual's approach to stabilizing the team they joined as a manager?

The individual focused on setting up processes, such as regular sprint planning and being accountable for time spent on tasks, to build a culture and community within the team.

What challenges did the person face when transitioning to a managerial role, especially during COVID?

The person faced challenges like building team camaraderie without in-person interaction, maintaining team culture, and dealing with the absence of large blocks of uninterrupted time for deep technical work.

What type of training did the individual undergo to prepare for the managerial role?

The individual underwent extensive training provided by their company, which included many hours of resources to understand what it means to be a manager at Amazon.

How did the person describe their day-to-day experience as a manager?

The day-to-day experience as a manager was filled with meetings, stakeholder management, and less time for deep technical work, which was a significant change from their previous role.

What was the individual's realization about the importance of team culture in their role as a manager?

The individual realized that building a healthy team culture was crucial for success, as the manager's effectiveness is directly tied to the team's performance and ability to work collaboratively.

What was the 'inflection point' that led the person to reconsider their career path as a manager?

The 'inflection point' was a moment of intense frustration during a series of unproductive meetings about a technical solution, which led to the realization that they missed the technical depth and problem-solving aspects of software development.

How did the individual's experience as a manager impact their current role as a software development engineer?

The experience as a manager provided valuable insights into people management, communication, and empathy, which have been beneficial in their current role as a software development engineer.

What advice does the individual offer to others who are considering a transition from an individual contributor to a management role?

The individual advises others to try the management role to gain clarity on their preferences, as they believe the experience can provide valuable skills and insights, even if they ultimately decide that management is not the right path for them.

Outlines

00:00

🔄 Transition from Software Developer to Manager

The speaker reflects on their transition from a software development engineer to a software development manager, a role they eventually left to return to software development. They share their motivation for trying management, the process of becoming a manager at Amazon, and the initial steps of setting up processes and building team culture. The speaker also discusses the two common paths to becoming a manager: directly requesting the role or leading a team in the absence of a formal manager.

05:01

📚 Resources for Becoming a Manager

The speaker discusses the resources available at their company for training new managers, including extensive hours of instruction on managerial roles specific to Amazon. They also recommend the book 'Managing the Unmanageable' as an invaluable guide for transitioning from a software engineer to a manager, highlighting its relevance to their own Amazon-centric experiences.

10:01

👥 Managerial Duties and Team Dynamics

The speaker outlines the day-to-day responsibilities of a manager, emphasizing the shift from focused development work to a schedule filled with meetings and stakeholder management. They discuss the importance of building a collaborative team culture and the challenges of information silos, sharing strategies to encourage open communication and knowledge sharing within the team.

15:02

🚀 The Pros of Being a Manager

The speaker enumerates the advantages of being a manager, such as the opportunity to mentor and develop the careers of software development engineers, controlling the technical roadmap, shaping team culture, and witnessing the team's achievements. They highlight the sense of accomplishment that comes from guiding a team to success and the personal growth that results from these experiences.

20:03

🔍 Cons of Managerial Role and Personal Realizations

The speaker delves into the downsides of being a manager, including the prevalence of meetings, the loss of hands-on technical work leading to a feeling of becoming outdated, the sense of responsibility without direct control, and a shift in the type of accomplishments experienced. They share their personal realization that the manager role did not align with their passion for technical work and the direct satisfaction it brings.

25:05

🔙 Decision to Return to Software Development

The speaker recounts a pivotal moment that led to the decision to revert from a managerial role back to software development. They describe a frustrating situation involving repeated meetings to explain a technical solution, which culminated in a personal realization of their deep-seated passion for technical problem-solving. This realization prompted a smooth transition back to their previous role as a software development engineer.

🤔 Reflections on Managerial Experience

In conclusion, the speaker reflects on the valuable skills and insights gained from their managerial experience, such as enhanced communication, organization, and empathy. They express gratitude for the opportunity to have tried management, as it provided clarity on their career preferences and enabled them to better understand and support their current manager's role.

Keywords

💡Software Development Engineer

A Software Development Engineer (SDE) is a professional who designs, develops, and maintains software applications. In the video, the narrator transitions from this role to a managerial position and later returns to it, highlighting the differences in responsibilities and personal satisfaction derived from each role. The term is central to understanding the career path and professional identity discussed in the video.

💡Software Development Manager

A Software Development Manager oversees a team of software developers, focusing on team leadership, project management, and strategic planning. The video script describes the narrator's experience transitioning into this role, the challenges faced, and the decision to transition back to an individual contributor role, emphasizing the shift in daily tasks and responsibilities.

💡Transition Process

The term 'transition process' refers to the experience of moving from one career role to another. In the script, it is used to describe the narrator's journey of becoming a manager from an SDE, the learning curve involved, and eventually reverting back to an SDE, reflecting on the personal and professional growth that occurred during this period.

💡Individual Contributor

An individual contributor (IC) is a professional who contributes to an organization's goals primarily through their personal efforts rather than through managing others. The video discusses the decision between pursuing a path as an IC, potentially becoming a principal or distinguished engineer, versus moving into a management role.

💡Managerial Role

A managerial role involves overseeing a team, making strategic decisions, and handling administrative tasks. The script uses this term to describe the responsibilities and expectations that come with being a Software Development Manager, contrasting them with the more technical, hands-on work of an SDE.

💡Career Path

A career path is the trajectory of professional development and job opportunities one might follow. The video script discusses the decision-making process regarding whether to pursue a career path in software management or to continue as an individual contributor, highlighting the personal and professional considerations involved.

💡Team Culture

Team culture refers to the shared values, norms, and practices that characterize a team's interactions and work environment. The script emphasizes the importance of building a positive team culture as a manager, which can influence collaboration, communication, and overall team performance.

💡Mentorship

Mentorship is the process of guiding, coaching, and supporting someone's learning and development. In the video, the narrator mentions the rewarding aspect of mentoring and developing the careers of software development engineers under their management, which is a key responsibility and benefit of a managerial role.

💡Technical Expertise

Technical expertise refers to a high level of knowledge and skill in a specific technical area. The script discusses the narrator's realization that as a manager, they were losing touch with the technical aspects of their field, which was a significant drawback for them and led to their decision to return to an SDE role.

💡Accomplishment

Accomplishment refers to the feeling of achieving a goal or completing a task successfully. The video script contrasts the types of accomplishments experienced as a manager, such as team successes and promotions, with those of an SDE, like solving complex technical problems, which the narrator found more personally satisfying.

💡Meetings

Meetings are gatherings for discussion or collaboration, often a significant part of managerial work. The script describes the numerous meetings as a con of being a manager, which can be time-consuming and mentally exhausting, taking away from the time available for more focused work.

Highlights

Transition from software development engineer to manager and back, reflecting on the experience.

Exploring the decision between individual contributor and management roles in software development.

Personal backstory and interest in management, leading to a transition attempt.

Two approaches to becoming a software manager: direct request or taking the lead in a team without a manager.

The importance of building processes and culture in a team, especially in challenging situations.

The realization of wanting to become a manager and the decision-making process.

Training and resources available for new managers to understand their role.

The shift in daily activities from focused development work to constant interruptions and meetings.

The challenge of achieving through others and the impact on team success.

The benefits of mentorship and developing other software developers' careers.

Control over the tech roadmap and the responsibility of balancing various team needs.

Developing team culture and the importance of collaboration and communication.

The downside of numerous meetings and the exhaustion that comes with constant interaction.

The loss of technical depth and the struggle of staying current with technology as a manager.

The feeling of powerlessness despite responsibility, and the need to course correct team actions.

The change in the type of accomplishments and the longing for the satisfaction of direct technical problem-solving.

The moment of realization about the true passion for technical work, leading to the decision to step back from management.

The transition back to a software development engineer role and the process of readjustment.

Reflection on the benefits of the management experience, including improved communication and organizational skills.

The conclusive learning from the experience, knowing that a management role is not the desired path.

Transcripts

about a year ago i transitioned from a

software development engineer to a

software development manager and it was

a really interesting experience but i

ended up switching back to my software

development engineer role i want to kind

of talk to you about what that

transition process looked like because i

realized that there's so many people

that are in a very similar boat that are

trying to decide if they want to pursue

the individual contributor or the

software development engineer role all

the way to you know principal engineer

distinguished engineer whatever that is

and they're trying to decide between

that or changing their career path

entirely to be a software manager

so i wanted to kind of tell you about

what my experience was like

give you a little bit of a back story

about like kind of my interest in

management

how i transitioned into a manager what

the role looks like in terms of the

day-to-day uh some of the pros and cons

as i perceive them and then just some

closing thoughts on the transition

process and back to being an ste so

that's what this video is about um let's

start a little bit i guess with my

backstory

so many of you know i'm a software

development engineer senior software

development engineer at amazon been here

for around seven years or so um and

shortly after my promotion about a year

ago i decided to try out that software

development manager role so like what

did that process look like how did i

decide uh and how did i approach things

so the first thing that you have to know

is that if you want to become a software

manager um there's generally two ways

that you can do it you either directly

request that from your manager be like

hey manager i want i'm interested in a

software manager role i want to do this

and kind of you have a conversation

there so that's one approach is very

direct and to the point the other way is

to kind of put yourself in an

environment in an environment where

there's no structure in a team

necessarily and you kind of build the

processes so you take the lead of that

team and do a lot of the things that the

manager would typically do that being

said like if there's already a manager

on the team you may struggle with that

if there's no manager on the team then

obviously it's easy to do so the latter

was my situation i had joined a team

that was kind of underwater they only

had a couple sds on the team they

managed some really really important

services so myself and another engineer

kind of went into this team to try and

help out and stabilize things

so even before this i already kind of

knew that at some point in my career i

wanted to try to become a manager just

to see what that role is like and i'd

always respected a lot of like vps and

directors those were kind of the later

levels of the manager role and so i

thought you know maybe i want to do this

and like how do you know unless you try

it right so that was kind of my my

starting state so i was on this new team

and you know things were kind of up in

the air the processes were all kind of

broken you only had a couple more junior

sds on the team so there wasn't much

going on they didn't really have a

direct manager at the time

that was involved in the day-to-day

so immediately kind of when i entered

the team like my first instinct was to

try and stabilize things by setting up

processes so things like you know having

your regular sprint planning being

accountable with the amount of time that

you're spending on tasks

kind of building that kind of culture

and community in your team so

it's very difficult i guess during covid

when you're not in person all the time

but you know things as simple as during

stand-ups turning on your camera so you

actually can make a connection with

people like all this stuff like started

to put in place and i found that it

started to build that culture and build

that kind of camaraderie between myself

and my peers and i always say like

you're only as good as your team as an

as an ic or even as a manager so it's

not just all about the individual it's

about building a culture and building a

team that can kind of contribute as a

group and think about these complex

problems and solve them as a unit as

opposed to you know siloing everything

soloing all your knowledge or just

assigning people to different parts of

different projects so as i was doing

this and kind of setting up these

processes like part of this was i was

reporting back to my manager at the time

like what was going on what was good

about the team like what needed some

work that kind of stuff um so like she

had a good idea of what i was already

doing and so

naturally the question came like do you

want to try to be a manager for this

team and at that point like i didn't

really know how to react to be perfectly

honest with you but at the time i was

like kind of excited kind of nervous

kind of um interested in learning more

basically because it was something that

i had thought about previously it was

something that um you know come to my

mind multiple times

so she had kind of approached me with

that i thought about it i decided that

you know what like if i fail who cares i

can always go back to my other role and

if things work out and i love the role

then great like i get a fast track to

becoming a manager and now i know what i

want to do

so it was a pretty easy process to

decide like what i wanted to to do in

that position and i ended up accepting

the role

and so like what did the transition

process look like at that point well for

me in my circumstance like not really a

lot changed um because i was already

kind of building these processes and

kind of acting as a manager from the

start so not a lot in my day-to-day

change early on um in terms of like the

training and like let's talk about that

first actually like how do i learn how

to be a manager because i think that's

probably an important thing that people

struggle with because they're nervous

like i don't know anything about being a

manager how do i do this

um

so at my company there's like some

really really great resources so there's

like 40 hours or 80 hours some massive

number of hours of training that you can

do to talk about what it means to be a

manager at this particular company at

amazon and that was excellent that

training i personally thought so

it kind of shed a lot of light on what

the manager role looks like what you do

how to evaluate you know performance and

and types of things like that

and kind of what it means to be a

manager at amazon because i think this

is another key part uh that i realized

later like what a manager looks like at

one company can be a totally different

thing than what it looks like at a

different company it's kind of like you

know subject to interpretation you have

this set of roles at a particular

company as a manager that could look

very different somewhere else

so learning about what it means to be a

manager at amazon was something that

kind of took me a little bit of time to

get through all these different

resources another really really valuable

piece of material for me was a book

called managing the unmanageable and

it's by

two guys named mickey mantle and i think

it's ron lichty i'll put a link in the

comments and description section so you

can check it out but this book is

basically um a software development

engineer to software management like

kind of trans transition guide or

transition book uh and i swear the guy

that wrote this book or the two guys

that wrote this book must have worked at

either amazon or some fang company in

the past because a lot of what they talk

about is very similar to the processes

that we have internally so it was a very

very um good read for me because i was i

already knew the processes but now i'm

kind of learning more about what it

means to to be the manager and what you

actually have to do

on the day-to-day

um so now that naturally transitions

into like what do you actually do like

how do you spend your time

um i guess the first thing to say is

that if you if you as an sd enjoy having

large blocks of time of uninterrupted

time where you can focus on things then

you're probably not gonna like being a

manager because your day like very

quickly fills up with meetings and like

talking to people in stakeholder

management organization all that kind of

stuff

so you don't have the time anymore to

really um dive into the code and like

pour over the technical side of services

that you manage that was one thing that

kind of was difficult for me like i used

to have periods of you know four or five

hours sometimes of an uninterrupted time

and that was valuable for me to like

learn how services work to design things

to implement code all that kind of stuff

but as a manager you need to embrace

interruptions you're constantly going to

be getting interrupted either by people

on your team or stakeholders or your

boss or you know other people that need

help with something

and i wasn't really used to that and so

it took a little bit of time for me to

adjust but once i got into the groove it

was pretty easy

there's a lot of like other types of

meetings and things that you're involved

in so personal mentorship priority

planning

organization and future roadmap planning

that kind of stuff capacity planning is

big too like how many people do you have

how many people are you gonna have in

six months from now how many people do

you need for the projects that you

committed to what are the dates you

committed to do you need to push them

back these are the kinds of um questions

that you need to be thinking about and

you know your managers are going to be

expecting the answer because ultimately

you are the responsible one for the team

in terms of deliverables and this kind

of leads naturally into the other part

of it which is

you're kind of responsible but you're a

little bit powerless to do things

yourself like sure you can set up a team

how you want but ultimately at the end

of the day you are not the person

implementing the code anymore you are

not the one designing things anymore you

are not the one that is in the weeds

doing all the low-level work the people

under you are and that means that you're

only as good as your team and the people

that are on your team so this is like a

very fundamental fact if you don't have

a good team in a good team culture and a

good team environment it doesn't need to

start that way but you can build it if

you don't like put in that effort to

build it and build a healthy team like

you're going to get screwed because

your team's not going to be able to

deliver they may be kind of not

cooperating the way that you want them

to cooperate maybe not collaborating in

an efficient way

and i'm of the opinion that you know

it's great to have a lot of people in a

room to make a better decision like if

you're just one person trying to make a

decision if you have five people it's

going to be a lot better quality

decision because there's going to be

criticism from other people's experience

from past failures from past successes

so building that culture of being

collaborative

and kind of working with each other was

extremely important in my success and

one easy way that i did to do this maybe

i can just give you an example really

quick is you know when we had feature

requests or like a new project typically

when you have larger projects it's kind

of assumed you assumed that you do

design documents and have design reviews

but for smaller things like a minor

feature like a minor new api like you

don't necessarily have these large

design documents but i kind of made the

the habit of asking whoever was working

on it like can you do a mini design

document and then share it with the team

so we can collect feedback and so this

had like multiple benefits it gave your

sdes the opportunity to practice leading

a meeting to practice writing a document

to practice their communication

both verbal and written skills and

facilitating the meeting so that's great

for career development and it was also

great from a perspective of keeping the

team kind of informed of what key

decisions were being made and having the

opportunity to put some some um kind of

thought into are we making the right

approach maybe we are maybe we're not

but if you don't have the conversations

about it you'll never know

um so that was a kind of a quick and

easy way that i i think helped build the

team's culture and de-silo information

that's another big problem that you need

to deal with as a manager is if you have

certain people that are kind of like the

experts in a very specific area so kind

of not a all jack-of-all-trade the

opposite so you know they know something

really really well and not ever not

anyone else or no one else knows about

it that well uh or no one else knows

about it at all that's a big problem

because if that person leaves um or

something happens and they're out of the

office then you're kind of out of luck

and you know you need to figure out what

to do with these services and how to

manage them you've got to keep on moving

forward with the business

so that was kind of something that you

need to be careful of and try to prevent

of the siloing of information

so like i kind of said i'm just taking a

look at some notes here um you got to

learn to achieve through others and

build this community and build this uh

team because ultimately you achieve

through others at this point and uh

that's kind of your function as a

manager achieve through others tear down

roadblocks make your ste's lives easier

and

yeah try to keep your your sanity

because you'll be in a lot of meetings

um so to jump in so that's a little bit

of a background actually of just like

what i thought about being a manager was

like and like what the role looks like

in terms of like more direct and to the

point um pros and cons so let's start

with some pros um so the first pro is

that you get to mentor and develop the

career of many stds that are under you

and personally for me like i thought

this was great like i love talking to

people about technical things and giving

people career guidance and giving people

actionable feedback that they can do to

improve themselves uh sometimes it's

hard when you're on the other end like

the receiving end to understand like

where you went wrong or what you should

do in certain circumstances so you get

to give people like good feedback well

all feedback is good feedback but you

know positive sounding feedback so you

did great here

good job on this task blah blah blah but

you also get to give people ways to

improve themselves so if you notice

something that like maybe someone

approached a situation in a way that was

a little bit rough around the edges you

can give them feedback and say like i

noticed you did this

you know good job on the follow through

but you know this this approach caused x

y and z problems have you thought about

next time doing it this way um so

there's a nice way to say it you don't

need to attack the person but um you

know it's all about growing your peers

and watching them grow over time and

just seeing some of my previous peers um

you know six months ago and and where

they are now there's like massive growth

so it's very rewarding as an individual

to know you kind of played a critical

role in that

so that's pro number one the other one

is the fact that you have uh control

over the tech roadmap um so you get to

decide like what the team is going to be

working on uh who's going to be working

on what um how much you want to balance

new features new news projects with

operational excellence and also keeping

in mind that people need projects in

order to work on for promotion data

points um so balancing all of this stuff

together is kind of an interesting um

balancing act i guess you can say to

make sure that you're you're hitting all

the bases here and not leaving any area

really

or not neglecting any one area i guess

is the right way to say it

uh the other one which i the other pro i

think i've mentioned this multiple times

but you get to develop that team culture

and mold it in any way that you want

sometimes if you have particularly

strong sdes under you that are very

opinionated the culture can kind of just

build itself

but sometimes that's not always the case

you have people that may be a little bit

more quieter and require a little bit

more guidance and so in that case you

get to define the culture very clearly

of like what the expectations are is

this going to be like a strictly working

you know a professional environment

where everyone is always serious all the

time don't do that that sucks no one

wants to be on a team like that

or is it going to be kind of a

open-minded friendly conversational uh

experience where you trust your

teammates and you know you're willing to

share and they're willing to share with

you like you want that right that sounds

good that's a good trusting environment

where you act as a unit not as an

individual that's what you want to build

and then the final pro that i would say

is you get to watch your team deliver

and you know you're not the one putting

in the low-level work you're not the one

designing the solutions but the through

your actions your teammates are you know

able to work on certain projects you

give them feedback during design

you coach them and guide them you are

accomplishing goals through your

teammates they are your kind of vectors

for

achievements so watching your team

deliver is really a positive thing and

you know it's a feel-good moment that's

for sure

now in terms of

cons of being a manager

you probably have a guess of some of

them but let me let me state them

very clearly so the first one was that

there's meetings many many meetings um

you're constantly in meetings at

particular times of the year it's worse

but other times of the year um it's not

so bad but especially during like

planning phases and busy busy times of

the business it depends on like what

industry you're in of course um but

expect to have like a one-on-one with

every one of the sds under you at least

like once a week once every two weeks

maybe for some of you

yeah once every two weeks it's probably

more reasonable actually but

there's that there's

some sprint planning if you're using

sprints there's stakeholder management

there's new feature requests there's

meetings with your boss there's mediums

with other um kind of parallel managers

that are in your that report to your

same line manager uh so there's a lot of

busyness

and um this is part of the problem like

you have all these meetings and you're

exhausted by the end of the day honestly

like i was exhausted and not because i

was doing something particularly hard

but because you're in meetings all day

long a lot of the time you have to be

actively listening and you know actively

give good feedback and that kind of zaps

your brain at least for me personally

that zaps my brain after like eight nine

hours of that and um it wasn't something

i was used to so i learned to kind of

protect my time i would block off um

periods in my calendar my outlook

calendar for like two hours if i needed

a break to like

for personal time for for getting things

done during the work day or else your

calendar like any open time you have in

your calendar that's like a free free

game like anyone could could sign up for

that so you got to protect your time and

protect the time of your sds

so that's something i didn't really like

now the other thing is that this this

one hit home this is probably the most

important one

and that's that you lose touch of the

tech

because you got to remember like being a

manager is a completely different career

path

sure you are a software development

manager but again you're not in the

weeds you're not learning about new tech

you can't you don't have enough time to

do that anymore and so for me that was

kind of a dagger through my heart

because like as you know i have this

channel i have like a website i have all

these different things all about

learning tech and i thought originally

that okay i have this youtube channel

maybe that'll give me enough

satisfaction um of learning tech or

exposure to tech and so this wouldn't be

a big problem as a manager but it ended

up being like a really big problem and i

quickly found myself becoming like out

of date with what was going on in aws

and like cloud computing and all that

and that sucked for me so um that's

something that you know think about that

if you're considering going down this

path because

um

it's something that'll that'll creep up

on you and you don't realize you love

something until it's gone um i guess

that's the lesson

uh the other con is that you are

responsible for everything but in some

cases kind of powerless or you get the

feeling of powerlessness

and that's kind of takes some getting

used to so like i said before you're

achieving through others when they fail

you fail and so you need to kind of keep

an eye on that and course correct and

make sure that your team is staying in

um staying on track and able to deliver

ultimately

and the last one was that

um i guess you can say like i had a lack

of feelings of accomplishment or maybe

the right way to say it is that i had

accomplishments but they weren't the

same types of accomplishments i had as

an sde so it felt like very very

different to me so the types of

accomplishments you'll have as a manager

like getting someone's promotion

document through or giving someone's

someone feedback and watching them

action on it or watching your peers grow

from you know a junior confused ste to a

very independent and kind of um

excellent sd that can carry their own

weight so like those are the types of

accomplishment you would get or like a

doc review you'd have a good doc review

meeting great woohoo awesome

but as an sd there's like a very

different set of accomplishments that

you get um

at least for me

the most

kind of satisfying feeling that i have

as a software developer is a designing

things i love designing things and b

when you know when like you're working

on some kind every st is going to know

this every programmer you're trying to

solve something like you're trying to

debug a problem that you've been like

just grinding out for hours and hours

and hours you've tried everything you're

like so confused like why isn't this

working it should be working does it

work on your machine yeah it works on

mine does it work on this machine no

what's going on you know those moments

where like you just you're grinding it

you need to figure it out and then

finally after like 10 hours whatever it

is you figure it out and it's like

ah

i am like the king of the world like

that feeling i love that feeling and you

don't get that feeling anymore as a

manager you don't have that that time to

do these types of tasks anymore

and i realized when i wasn't in the role

anymore how much i missed that and how

much i wanted that to be part of my

day-to-day life

so those were kind of the the major

cons in my opinion

of being a manager

and so now i kind of want to bring it

back to

like how i got out of the manager role

and like what made me decide like how

did i know it wasn't for me

and i was having some like thoughts uh i

guess after so i was a manager for about

a year so i want to say between like six

to eight months i started having some

thoughts of like i don't know if this is

for me just based on like what i was

working on and how i was kind of feeling

about the role

so there was a very particular moment

where i had this i want to call it

inflection point of um you know deciding

my my future career path

and um so we were we were part of a team

that um operated a kind of an

infrastructure service and we were

onboarding a brand new client for the

first time we were doing this

re-architecture where we were offering

this new solution that was more generic

just easier to use

and so one of my like lead us to ease

was meeting with their us sds and like i

was in these meetings we were explaining

to them our approach seemed like they

got it and everything was good

and

it turned out very quickly a couple days

later they didn't get it and we kept on

having these kind of meetings for an

hour at a time talking about these

things me talking about it my sd talking

about their sd talking their manager

going at it and we just weren't making

any progress and like it felt like we

were making progress in the moment but

afterwards like we'd have further

follow-up questions and then another

meeting and then like we went through

like a ton of these meetings and it was

just so frustrating and i remember

asking myself like why is this happening

why like this shouldn't be that hard to

figure out and i was like is it me like

am i doing something wrong am i not

explaining it am i not talking about it

do i not understand it 100 in a way that

i can explain it and be confident about

it like what's going on here and the

truth was like i wasn't 100 confident in

exactly how the solution worked because

like i knew generally how it worked

obviously but um you're not implementing

it anymore right you're not in the weeds

you don't know the nuances you don't

know the edge cases you're not

necessarily engaged directly in the

solution like as a low-level example but

you know broadly how it works and so i

was asking myself this i'm like what is

going on so i finally got fed up with

this and i'm like you know what i'm

gonna just spend an hour and i'm gonna

you know pull out a piece of paper i'm

gonna draw like a flow diagram of how

this system works an example to run

through and like what this person's

situation is and how this solution

should work for them

and so i did that and i was having like

the time of my life honestly like i had

so much fun doing that um i was honestly

shocked but a ton of fun doing that and

i had more fun in that one hour working

through the technical complexity and

figuring out what the problem and where

we were going wrong and more fun doing

that in one hour than i've had probably

in like the past two weeks of being a

manager

and for me like that was it i i knew at

that point that um this wasn't something

that i can sustain for a long period of

time and that i knew where my passion

was like my passions were very very

clear to me in that instant and they

continue to be clear to me even now as

i'm talking to you like i know for a

fact that like i'm a tech person i'm

probably always going to be a tech

person unless something catastrophic

happens and i lose my fingers and i

can't type anymore maybe that won't stop

me

but um that was that was it that's when

i knew and so um i told my manager the

same story and she kind of agreed it's

like you know what like that's how you

feel then you know the writing is on the

wall um i think you should transfer or

she didn't say that but like i made the

decision and she was in agreement

um so a couple months after that it was

like a slow transition back to

sde um and it was over the course of a

couple months just because i wanted to

have a smooth process and not interrupt

like the day to day and affect the team

in any meaningful way um so it was over

like three months or so uh ended up

staying on the original team that i was

managing which i thought may have been

awkward because now you're going from a

a relationship where you know you're

managing someone and now you're their

peer and you don't want them to just say

yes to you just because you were their

old manager you want your the merit of

the ideas to decide and so that was a

little bit kind of tough to work through

but i got over it they got over it ended

up being fine

um but yeah that's kind of the the

journey of how i got there and decided i

wanted to share some retrospective and

just some closing thoughts and like this

is important um about my experience

being a manager

and honestly i don't regret it for a

minute

i learned so much about well first of

all i developed a ton of skills like

communication organization people

management skills uh not people

management just people skills in general

i guess you can say like those went

through the roof in terms of my

development so i grew a ton as an

individual a lot of the organizational

techniques that i learned at the time um

i still use to this day as an sde and

it's just so much more manageable now to

kind of manage my day and my priorities

so i don't lose sight of things um

communication through you know my

youtube channel and um through the role

because you're talking to people so much

that obviously increased and just how to

have empathy for people for your peers

and put yourself in another person's

situation i also learned how to do that

so learned a lot of soft skills there

also invaluable because now i know kind

of what my manager why they are asking

certain questions like i know what they

are looking for when they are asking

certain questions when they ask me like

oh how long is this going to take and

how that feeds into the planning process

and resourcing and how many people we

can hire all that kind of stuff so it i

have a lot of perspective now on what

that role looks like what the manager

role looks like and i can use that to my

advantage because i know the situation

that my manager is in and i can help

them in a way that i know will be

impactful so that's a very very powerful

benefit of this whole experience and

finally

the the final benefit or the best part

is that i learned that i didn't like it

and honestly i i'm glad that i tried it

because now i know that it's not for me

and i don't have to sit on the fence

anymore deciding like do i want to

teeter this way into a management role

for my career do i want to stick as se

now i know the answer conclusively and

i'm glad that i took the opportunity to

try this out and if i didn't i probably

would have regretted it

so that's my experience on being a

manager hopefully you got some insight

if you were kind of trying to decide to

be a manager or an individual

contributor or sd this gave you some

some light into what the role looks like

um if you have any comments or you want

to know more about the experience feel

free to leave a comment in the section

below i'll try to get back to your

answers and thanks so much for watching

and i'll see you next time see ya