
Ask HN: Going from Developer to Manager. What should I know or learn? - mseo
After reading (and resonating quite a bit with) &quot;Developer Hegemony&quot; by Erik Dietrich, which was one of the recommended books in  the &quot;what did you read in 2018&quot; posts, I think about steering my career to a manager instead of a developer position.<p>For all those of you who&#x27;ve done the same or planning to do the same: What are the most important skills or what&#x27;s the most needed knowledge in such a position? Where can I learn it? What should I read?
======
tgittos
I made the jump from developer to team lead, and all the advice here is great.
One thing that I wasn't prepared for and that I don't see other people
mentioning (on a cursory glance at the replies) is that your reward function
for job satisfaction changes, and the feedback loop length changes.

By that, I mean that for me personally I derived most of my job satisfaction
from solving tricky problems, fixing bugs and implementing features. I would
get that reward daily, or at least several times a week. When you transition
to management, your job satisfaction has to come from watching your team
members grow, your project mature as bugs are fixed and releases are made. I
would get that reward maybe every month, if not every few months.

I couldn't handle such a long delay in the reward feedback loop - it made me
miserable at work - so I transitioned back to development.

Just something to keep in mind as you contemplate the change.

~~~
stuntkite
The most effective days of management seem to involve so much compromise that
everyone is frustrated with me. It’s got not no real hit for solving problems.
Also it is all fuzzy and human. A lot of devs that are pure engineers find
management maddening. Something that helps me is writing daily. Keeping
personal strike lists and logs. This is private and in a journal, NOT jira or
whatever. I track my daily emotional state and have a matrix for
disappointment, frustration, anger, and stress. 0-4 also noting if its
targeted at a specific person. This helps me evaluate why so I can find a
positive solution and not be irrationally shitty/counterproductive. I review
the last 3 days every morning and go over the previous month on the first.
This helps keep me positive and helped me see that when the real work is being
done it often feels like failure. My year review of logs was actually full of
positive surprises.

~~~
the_greyd
This is super interesting. Something I've started doing on a smaller level.
I've already made good progress on managing my emotional state (thus
productivity) and want to improve the habit. When do you schedule to write or
log? Specific times in a day? If you had a template I'd assume it would
include mood tracking and todo list, anything else? Thanks for sharing this.

~~~
stuntkite
I do all the writing first thing when I sit down in the morning. Before I talk
to anyone. I use a dot journal, kind of like a graph paper moleskin, but a dot
grid. Date the left page and time. Do feelings. I’ll also note the weather, if
it’s a special day or holiday and if people are around, who. Then I review the
last few pages and I start musing. On the right page I title “<project name>
todo:” and start making the list. As I roll over previous day unfinished tasks
I x them out on previous day and see if they need to be reworded or broken
out. Completed tasks get a check. The body of the left page is free space.
Sometimes I’ll write out a conflict I am trying to process. Sometimes just
list house chores. Sometimes I draw out process flow or network layouts. I try
to empty my head of all the things I’m juggling so that before I say a word at
“work” I am a clean slate without too much wonder.

I check things off and add new things during the day, but it’s usually not a
lot of tasking unless there’s a crisis. A year in, crisis seems to be pretty
rare now. No one else I work with does anything similar. It does frequently
appear that I am ahead of risk by weeks before other people start clocking it.
In the beginning the lists were all catch-up, and now they are sometimes about
things coming in the next quarter.

I’ve been work journaling for years but I made this effort to formalize and
structure at the beginning of the last year when moving into a startup with a
lot of internal problems and some huge lifts. Jira was a lie and
accountability was missing on all sides. I knew I wouldn’t survive without
building my own consensus on truth.

I also did tutorials on architect handwriting to improve my clarity. It sounds
silly, but my scribbles would vary a lot and now that structure really helps
the process.

I think it’s had a net positive in all aspects of my life. It’s my favorite
part of the day.

~~~
zrobotics
RE the architect handwriting tutorials: do you have any recommendations? I can
barely read my own scribbles, and I've struggled with poor penmanship forever.
I'd looked for courses/tutorials, but hadn't found anything that resonated.

~~~
stuntkite
I have a few friends that are draftsmen. I asked them and they said they just
gave them a font and graded them on it with homework blueprints.

What I did was just googled architect fonts and downloaded a bunch of examples
then used a field notes pocket dot journal[0] to practice.

I would just try to copy a font exactly, then do drills on problem letters. I
probably drilled on four fonts I found that I liked. Focusing on accuracy
monospacing and staying in the grid. A big thing I learned was that it was ok
to slow down, it gives me more time to think about the thing, the clarity of
the lettering seems to reflect the clarity of the idea. I think previous
attempts to improve my handwriting had failed because I wanted to write as
fast as I type. It's a different thing obviously, but I didn't really realize
the benefits the slower pace has for processing things and concept recall.

I also bought some drafting tools. Angle rulers, protractor, etc. I decided to
overdo a couple network layout projects and work on it in that context. The
end product was so nice that I laminated a bunch and gave them to people and
they’ve been a great reference!

Oh, there is also a tool called an architectural lettering guide[1] that can
be helpful.

It took about three weeks to really kick in. Now I’ve got my own style and it
changes a bit still and I experiment, but the core just adds to the rote
process of the daily exercise. I can see by looking through the journal if I'm
not fully on my game by how much drift there is.

I would probably drill for 10-20 minutes a day for the first week. After that,
it was just here and there if I noticed something just wasn't working. Like
when I decided Ps and Ys got flourishes, but only in some context. Also
changing anything usually meant other letters would start regressing to my
scrawl. It's weird how related the patterns are in your head.

Another thing that helped me was finding a pencil I liked. I ended up with a
super fat 5.6mm HB firm lead on a woodworkers pencil[2]. It sharpens to a fine
point and holds it forever and never breaks. Always using the same tool is
really important to me now. I had to go through a bunch of stuff until I found
a pencil I didn’t hate. It might not be the right one for you. I love them
though and buy extras and hand them out to anyone that likes to write. My
polling seems to agree that they are dope.

Here is a pretty good blog[3].

[0] [https://www.amazon.com/Set-Dotted-Notebook-Travel-
Journal/dp...](https://www.amazon.com/Set-Dotted-Notebook-Travel-
Journal/dp/B072FDGMW1)

[1] [https://www.dickblick.com/products/alvin-ames-lettering-
guid...](https://www.dickblick.com/products/alvin-ames-lettering-guide)

[1] [https://www.woodcraft.com/products/woodcraft-woodworkers-
pen...](https://www.woodcraft.com/products/woodcraft-woodworkers-pencil)

[2]
[https://www.google.com/amp/s/artdepartmental.com/2009/10/12/...](https://www.google.com/amp/s/artdepartmental.com/2009/10/12/learning-
architectural-lettering/amp/)

~~~
MarvelousWololo
Even though I was not able to understand 100% of it (non native speaker) it
was a fantastic read. Thanks for sharing that!

------
davismwfl
Most important thing to me, learn the difference between leadership and
management. A long time ago I was mentored by some great leaders who taught me
the difference, and also taught me when to manage situations or specific
people. Management isn't a bad word, but applied the way it is most places it
should be.

My goal with teams is to inspire them to make good choices, show them the
right paths and help them succeed. A leader serves his team, and doesn't stand
over them demanding progress reports daily. A good leader gets updates from
his team daily because he talks to his team daily, but doesn't do so because
he needs status reports. Managers need status reports and many times use them
to justify their job, or to throw Johnny under the bus because he is behind. A
leader knows Johnny is behind because he talks to him nearly daily and has
been helping him get back on track already. If Johnny can't get back on track
the leader is looking for a way to make Johnny successful even if that means
he moves him off the team or to another role. The leader turns to his
superiors and takes responsibility for the team, but never hides behind Jonny
for being behind.

Another key, always vent up, but communicate in all directions. What I mean by
this, is always find a mentor at your same level or higher that will listen to
you, who will let you vent some frustration and help you if you need guidance.
Sometimes this isn't someone in the company, that's fine. Never vent to your
team or other teams. Communication however, should never stop and be happening
at all levels.

Last point I guess. Hierarchy isn't evil, it gives people boundaries so they
know who to go to for what and when/why. Flat organizations sound awesome, but
are sometimes a nightmare to be in because there is too little structure to
give good guidance to people. Flat organizations that are successful are so
because people are given boundaries and generally have good documentation or
rules/values they can turn to and use as a guide. You are not a good
leader/manager by giving total free rein, having boundaries is critical to
success for everyone (same goes for parenting when you have kids, give them
opportunities to take chances, make mistakes but have boundaries in place).

~~~
paulie_a
I honestly don't believe flat organizations exist. They claim to be but there
is always an informal heirachy. Which is trickier to navigate then just having
a bit of structure. No need to go overboard but at least formalize what exists
but unsaid.

~~~
davismwfl
I would agree, people call it flat but in reality there are always some
structures, processes etc either known or not. But I do see that there are
quality organizations that call themselves flat, when in reality they are more
like an open door, open culture workplace. But they still have a structure and
organization on how you do things. e.g. you can talk to the CEO, but you are
not to use that access to manipulate the team dynamics or direction by
skipping the middle leadership.

~~~
paulie_a
This is dead on. You could approach directly but it's probably better to bring
up issues with someone else first then escalate to the CEO if necessary. Flat
organization means you can go directly, but you probably shouldn't. So the
structure exists.

------
mharroun
In the past 13 years have gone from dev -> tech lead -> manager -> director ->
VP/CTO at startups (50-250 people).

Here are my tips:

\- Your job is to provide effective technical solutions to business problems
via managing a team(s) of engineers, everything else is an extension to that.

\- Managing is nothing like coding and requires a completely different mindset
and skill set.

\- Authority comes through respect and understanding, not rank/title.

\- When you are pressured or stress reverting to what you know (coding) is
almost always the wrong answer.

\- You should take all the blame but distribute all the credit to those under
you.

\- Code quality in itself is meaningless, you must learn to balance quality
and hitting deliverables.

\- Say no / only agree to what you know your team can deliver on... and always
double your estimate. In the long-term reliability is valued over
agreeableness.

\- Culture above all, a team that likes working together and takes pride in
the product they work on can overcome most obstacles/issues/failures.

\- At least once in your career, you will face a direct who is very smart and
very productive... but is a complete toxic asshole to everyone around him.
Fire them... by the time you have seen the true damage they have done its too
late.

\- Managing people is hard, each person is unique and you need to tailor your
approach in a case by case situation. You will get a lot more out of people if
you understand them and they trust/respect you.

\- You should always allow your team(s) to grow/learn/try new things. However,
engineers are always looking to learn the latest fad/tech to grow their
resume. Building things with tools your team does not understand is a risk,
attempt to minimize that risk.

~~~
shadowwolf007
To be honest a lot of your suggestions are probably very solid but come off
like the "Find a mechanic you can trust" solution.

By that I mean the advice of "find a mechanic you can trust" only is
applicable to someone already familiar enough to know how to determine if a
mechanic is trustworthy.

A lot of your advice is probably 100% valuable, but as someone working through
a lot of these same concerns I'm stuck wondering "Well, how do I know I'm
actually doing that?" It leads me to wonder if I'm actually successful at any
of this or just Dunning–Kruger-ing my way through it.

~~~
mikekchar
Our mechanic was ripping us off. There's this scam where they overtighten the
screws on the oil pan and crack the gasket. Oil leaks out very slowly and in
some cars ends up on the leads to the battery. This corrodes the leads. They
then charge you for a new battery and tell you that there is a electrical
problem in your car that will cost thousands of dollars, etc, etc. Luckily I
knew about this scam and when our car started losing oil directly after an oil
change and the mechanics refused to do anything about it, I was able to tell
my wife what was about to happen. This convinced her that the mechanics were
scamming us.

So the question became, who do we send the car to. There was a young guy down
the street. He was taking apart cars and putting them back together again. His
friends were all into racing and while he had previously worked at a
dealership, he quit to live the dream of repairing racing cars. Of course he
was broke. I told my wife to wander over and see if he wouldn't mind looking
after our car. Great mechanic and saved us thousands compared to what the
swindlers were doing. Previously the car was breaking down all the time. After
we switched it never had a problem. When we replaced our car recently, we gave
him our old car as a thank you. Good mechanics are worth keeping happy :-)

It's not really a science for finding people who are good at what they do.
There is not a thing that you can pinpoint and say, "That person is definitely
good and that person is not". But I think if you start with the proxy of,
"That person loves what they do and sacrifices a lot in order to do it", I
think you are more likely to find someone good. Not 100%, but you've got a
much better shot at it.

Edit: I misinterpreted your post and assumed you meant that you were looking
for a good lieutenant to help you. I need more sleep! But either way, work at
being that good mechanic in the same way -- love what you do and work hard at
it. You'll definitely make progress, so don't worry about it.

~~~
shadowwolf007
I'm really glad you were able to avoid that scam. That's super scummy.

I built this premise because I do read a lot of car forums and, quite
frequently, people would ask "Hey my car is doing XYZ" and a lot of responses
would be "Take your car to a mechanic you can trust." To me this is basically
telling them "Already know the answer to your question."

One time a guy answered basically saying "Hey, go find a guy who has a car in
his driveway he works on every weekend, bring a 6 pack, and ask him for an
opinion." It totally opened my eyes to how different types of advice really
change people's perspective.

I believe that the value is in explaining what a person who loves what they do
actually looks like.

------
CameronBanga
I've been working on a similar transition starting six months ago, in a very
large organization (240k employees). There's an endless amount of reading you
could do, podcasts to listen to, etc. I'll be short and sweet and focus on a
single point that has worked well for me so far.

Focus first and foremost on helping coach and improve the
performance/productivity of the people on your team, each and every day.

If you're a good engineer/employee in general, this will be very hard for you.
Mostly because, it will make you feel much less productive and as if you
aren't contributing. You won't be able to commit as much code, perform as many
code reviews, etc. You will at times worry that you are falling behind, or at
times even as if your team members are outperforming you.

Don't worry about your personal productivity, just worry about the improved
productivity of those on your team. No one will ever fault you as a manager if
you are known for consistently making the people below you better, regardless
of where they currently sit with respect to position, skillset, etc. And an
improve team will lead to an improved product, even if you aren't the one
committing the most code or new features to that product.

------
bryanmillstein
During my college job as a cashier I made the transition to a lead position.
About ten years later I went from developer to manager.

I found both transitions to be remarkably similar. My focus shifted from
performing tasks to building trust and learning how to motivate.

My main advice: I cannot stress enough the importance of consistent and
considered 1:1s. Many in the software industry view these meetings as
unimportant status updates and often neglect them. This is a missed
opportunity and you would be wise to give them the proper prioritization.

Take advantage of these private sessions to go beyond the projects they are
working on. Explore what motivates them and dig deep to uncover their true
passion. It will take time for them to open up but you can accelerate this
process by sharing personal feelings and putting yourself in a vulnerable
position.

I had six direct reports and met with each of them weekly for a one hour
session. This is a substantial time commitment and can be emotionally
exhausting. In my first few months these meetings intimidated me and it felt
like I wasn't making progress. Eventually they became my favorite hours of the
week and energized me in a way that software development never had.

~~~
throwaway5752
Came to say the exact same thing about 1:1s. The key is to realize your work
product is the efficiency and productivity of your team, so investing in them
(accounting for their personal preferences) is critical.

------
hobonumber1
I went from a Software Engineer to an Engineering Manager about 1.5 years ago.
Here are some of the things I've learned:

\- Engineering and Management are very different. When writing code, there's
an obvious end goal. There is no such end goal in Management. Your job is to
remove obstacles to allow other people to do their best work.

\- Get used to interruptions. your job will be interruption-driven. When
coding, you want as much heads-down time as possible. In Management, you will
be interrupted as problems come up and people look to you for solutions. And
these problems dont always have obvious solutions as they are people problems.

\- You will code less. Get used to giving up the "interesting" parts of the
codebase to engineers. Your role now is not to code, but to provide the right
environment to allow other people to be happy and productive.

\- Learn how to give feedback. Different people on your team will take your
feedback in different ways. You may have to be direct with some people, and
more delicate with others. You have to learn how these people react to
different types of feedback and deliver news appropriately.

\- Understand who on your team is a "superstar" (a person wants to work on
latest code, wants to move up the corporate ladder, may only be on your team
for a year), and who on your team is a rockstar (the "rock" of your team,
someone who doesn't want to move up because they are perfectly happy doing
what they are doing). One is not better than the other. People switch between
one and the other in different stages of their lives. You have to treat them
appropriately in terms of projects, feedback, expectations.

One of the books that helped me a lot was Radical Candor
[https://www.radicalcandor.com/](https://www.radicalcandor.com/)

~~~
mseo
Thank you for the insights!

Giving feedback seems to me especially challenging - I'll definitely read
Radical Candor.

------
Mojah
I've made the transition from Developer to Manager and now realize it was a
mistake for my personal happiness and will return to a Developer role. Here's
what I learned as a manager;

\- Communication is top priority: be explicit in what you want & what your
goals are. Don't give tasks, give directions. Always make sure people
understand the _why_, not just the _what_.

\- Don't take things personal. As a Manager, you'll be on the receiving end of
complaints, frustrations and internal debates. Separate work from private and
don't take that stuff home. The old saying "shit rolls uphill" is very true
for a Management position.

\- Stay technical. Allocate some of your time to do small dev work yourself,
or you'll quickly lose focus and touch with what is happening.

\- Remove friction. As a Manager, your goal is to make sure your team can work
and not be distracted. Make sure you deal with the small interruptions and the
hassle, keep your team focussed.

------
brennanm
Couple recommendations that are popular with people who've been managing for a
while:

\- Managing Humans by Michael Lopp

\- The Managers Path by Camille Fournier

\- Radical Candor by Kim Scott

I think the netflix culture deck is also helpful:
[https://igormroz.com/documents/netflix_culture.pdf](https://igormroz.com/documents/netflix_culture.pdf)

And if you want to peak at how other managers manage check this out:
[https://hackernoon.com/12-manager-readmes-from-silicon-
valle...](https://hackernoon.com/12-manager-readmes-from-silicon-valleys-top-
tech-companies-26588a660afe)

Or check out this podcast on the topic:
[https://anchor.fm/soapbox/episodes/6-Melissa-and-
Johnathan-N...](https://anchor.fm/soapbox/episodes/6-Melissa-and-Johnathan-
Nightingale-of-Raw-Signal-Group-on-being-better-bosses-e1c6gt/a-a4aa71)

~~~
sasper
I highly recommend 'The Managers Path' as well. It really helped me wrap my
head around the changes I needed to make for my transition to Engineering
Manager, and also the types of things I need to work on for the next move to a
Manager of Managers.

Reading every path also helped me build empathy in what difficulties my boss
(VP) and boss's boss (CTO) are going through. Easy ready, highly recommended.

------
rmrm
My results from several years, from a team lead, to post acquisition large
company middle manager:

1.) It can be much more stressful and unpleasant working through other people
than being an individual contributor. You must be able to deal with this in a
way that doesn't cause too much unhappiness.

2.) You must be a strong distiller of information. You need to be able to
understand what information is important and what is not as you will need to
distill a very messy situation below you into something coherent to those
above you. Developers can often get away with massive detail dumps that lack
any sort of narrative. You will not.

3.) Your job is always to make the project successful. You need to have the
confidence and leadership ability to make changes as needed on the fly, and
explain them in ways so that everyone understands why what is happening is
happening.

4.) You must be a strong communicator. You should feel like you are over
communicating. I fail here most often, typically you will know it in real
time. Do your best to correct it.

5.) You will have more interruptions and starts and stops in your thinking.
Organization helps here.

6.) You will go long periods without feeling like you are doing a good job, or
feeling like you arent adding anything. You are. Being a manager and a leader
is large time periods of being a servant, most often to those below you.

7.) Focus on putting your team in good spots. Find what people are best at,
help them excel. Give good people space to grow. Be on the lookout for your
next manager below you. Try to help them along and hopefully beyond you.

8.) Large parts of it are just showing up. Asking the dumb questions.
Listening. Saying that sounds good, go do it. Holding people accountable. Keep
things fun whenever possible.

9.) Largely, it sucks. I do it because I havent found someone else I think
could do better for the team yet. If they show up Id gladly get out of it.

------
iamNumber4
Learn to delegate through stewardship. Set clear expectations for outcomes.
Your job is to remove obstacles to allow others to do their job, and direct
traffic so the right people are working on the right things. Don’t
micromanage. 90% of the job is setting expectations so you can convey that to
your team, and up the chain of where things are.

So... you’ll need to develop ways to gather daily progress reports and monitor
work is progressing. When it is not progressing you have to remove the road
blocks if possible while also communicating up any roadblocks that might be
causing delays to keep your bosses expectations inline with the current state
of the projects progress.

You will also need to start thinking about the process in which people work,
and make adjustments to the current process as problems show up. I have a
Wednesday meeting with my leads/senior team to sync up and address pain
points, I call this meeting “What’s working Wednesday” with the main topic to
specifically look at and adress what is not working. So that my team and I can
adjust our way of working. This allows me to get in front of problems when
there small, and have knowledge of frustration/pain points.

~~~
kingkool68
Shouldn't it be called “What’s NOT working Wednesday”?

------
mathattack
A basic podcast that I’ve found useful is Manager Tooks. It contains a lot of
good habits and tools. Listen to it on your commute for a month or two and
you’ll get the gist of it.

The Effective Executive by Drucker is a great intro to leadership. He puts the
role in the context of getting results.

A couple other thoughts:

1 - Communicate the same message over and over. Do it verbally and in writing.

2 - Have weekly 1 on 1s with all your reports. They should own the first 20
mins. You own the last 10. Take notes.

3 - Make sure Meeting notes go out for every meeting.

4 - Talent is your job, not HRs. It’s up to you to hire and train the good,
and nudge out the bad.

5 - Assume you only get your best people for 1-2 years. Plan for succession.

6 - A good relationship is “My top 20% will work for me again” and not
“Everyone is my buddy”

7 - Be careful about off work socializing. If you go to a happy hour with
subordinates, disappear after the first round. Don’t make these events
mandatory.

8 - Keep performance discussions between you and your reports. Don’t belittle
anyone to their peers.

~~~
BrissyCoder
Weekly 1 on 1s with all reports is not useful or feasible. If you have 8
reports that's 10% of your work week swallowed.

~~~
billbrown
I did weekly 1 on 1s with 8 direct reports. I made them all on the same day
and I didn't budget them for an hour each. I found it extremely valuable and I
left it up to the employee to drive the meeting. If they needed to cancel the
1:1, then that was fine but I never would without rescheduling. It really
reinforces that people are #1.

This is all Manager Tools basics. I think it's the best set of guidelines they
offer. (The Hard Thing about Hard Things also emphasizes weekly 1:1s as does
Managing Humans.)

~~~
mathattack
Exactly. It’s best if they’re prescheduled. That way they can be moved but not
accidentally forgotten.

I try to spread mine between slower days.

------
balls187
Workplace toxicity's impact on your career increases the higher your title
gets.

Never assume your manager peers will do you a favor for free. No good deed
will go unpunished.

If your role will include hiring and firing people on your team, start having
regular 1:1's with your direct reports. Make it clear 1:1 time is for your
direct reports to talk to you about whatever they want, and for you to listen.
Not your time talk about their tasks.

If you have to give critical feedback, give it sooner, rather than wait for a
1:1. The absolute worst time to provide feedback is during a performance
review.

For folks who struggle, make sure the performance bar is clearly defined for
them and let them know you are there to help them, but it's their
responsibility to meet that bar.

Develop your team. You'll have your all-stars, your role-players, and your
under performers. A majority of your time naturally goes towards your best and
worst people. Your goal is to move everyone on your team to the all-star
category. That means not short-changing time with the people who are
performing.

When you get promoted to the next level (managing managers) you'll be glad you
can tap that bench of all-stars to take on additional responsibilities
allowing you to take on bigger challenges.

Under performance is typically a motivation issue or a communication issue.
Make sure you are doing your part to address your deficiencies in each (trust
me).

Learn to delegate, but not just the crappy work.

People leave companies because of bad managers. Remember that. No matter how
great of a manager you think you are, someone will ultimately lump you in as a
bad manager.

It's easy to deal with under performers if they also have personality clashes.
Dealing with under performers who you personally enjoy working with is a lot
harder. I have no advice on how to deal with this. Firing people you have a
personal connection with is tough, and it comes with the job.

Communicate often. My rule was no company news hit my team through the rumor
mill before I got a chance to speak to them. The moment I had news I could
share, I would share it.

Here is the top tip I can tell you to engender loyalty: talk to your team
about promotions and career growth. Rarely ever do managers talk to their
teams about career growth. Take an interest in the individuals on your team,
and it will pay off immensely.

Source: My experience having built the 5 top performing software engineering
teams at my last company.

------
trestletech
The biggest piece of advice I'd give is to focus on practicing leadership in
your current role. Develop a reputation as the person who ensures that work
gets done properly, leads out in process improvements for the team, and
demonstrates good judgment. Once you've done that, it will be a no-brainer to
give you more leadership and/or management opportunities. Note that none of
these practices require that you get a promotion first nor that you be the
strongest programmer in the room.

I went through a similar transition years ago and I've started working on
writing up some of my advice here. It's still quite incomplete, but might give
you some ideas: [https://app.tettra.co/teams/rstudio/pages/technical-
leadersh...](https://app.tettra.co/teams/rstudio/pages/technical-leadership-
resources#) In particular, I'd say the "Technical Team Lead" role is what I'd
target as your next step.

Aside: if any of this advice resonates with you, we are hiring and I'd love to
chat about helping you go through this transition with us.

------
klenwell
Whenever this topic comes up or managing generally, I point to this Ask HN on
the same topic from the end of 2011. I think it's gold and has served me well
in my career:

[https://news.ycombinator.com/item?id=3407643](https://news.ycombinator.com/item?id=3407643)

Especially jbob24's comment:

 _Forget about all that "leadership" and "management" bullshit. Seriously.
When you have direct reports your primary function is to serve them. I'm not
kidding - I know it sounds all squishy and kumbaya-ish but if you think about
what it means to serve somebody else you'll have a really good compass to
guide you through your day._

[https://news.ycombinator.com/item?id=3408082](https://news.ycombinator.com/item?id=3408082)

I would also add to this: do 1-on-1's and do them well. I recommend reading
through this post:

[https://workplace.stackexchange.com/questions/32765/what-
is-...](https://workplace.stackexchange.com/questions/32765/what-is-the-
purpose-of-1-on-1-meetings-with-your-direct-leader-boss)

For me, a lot of what I have seen as failures of management (and organizations
more broadly) seemed to boil down to manager insecurity and posturing. A
manager thinking, "I have to look like a leader right now even though I'm not
really sure at the moment what the right move is here," when they should be
saying, "Hey, team, how can we solve this problem? What can I do to help you?"

P.S. It would be interesting to learn how things turned out for endymi0n all
these years later and whether that post was helpful.

------
shmat
I wish you luck. There's a lot of good advice in this thread, but if I were
talking to my younger self I would say DON"T DO IT!!!!! I became a manager the
first time when I was 28 and I was very excited about the opportunity. I found
very quickly that I hated it. If you really love coding and solving problems,
you will never find being a manager satisfying even if your team is
successful. So I transitioned back to developer. Fast forward 12 years at a
different company, and I was talked into being a manager (bad sign) again. I
told myself that I'd approach it differently and focus on being a mentor, etc.
Same exact result. I hated it, and transitioned back. You have to know
yourself and what you find rewarding. Unfortunately, there are a lot of
terrible managers in technical fields, and I've always thought it's because
most of those people in their heart of hearts don't want to be managers.

~~~
eeeeeeeeeeeee
Definitely an important lesson. In the beginning when I moved to management,
it was hard for me to detach myself from the technical side. I would even take
on side projects that only I worked on so I wouldn't slow the other devs down
in a team project because my availability was all over the place. I soon
realized that I wasn't doing my job by focusing on development.

------
cdnsteve
Empathy. Protect your team, even from themselves. If someone new makes a
mistake don't tar and feather them. Instead look at what processes you can fix
and how to prevent it from happening to others. We all make mistakes, that's
part of the journey.

Build a culture that isn't afraid to think outside the box, learn, try new
things. You can't do that when people are scared they will break something and
get penalized for it. Set some guidance and boundaries but let them create.

Spend time on work relationships, face time with those outside of your direct
team. Business people, BAs, QAs, PMs, VPs, get to know them, laugh with them
and learn what they are trying to do and figure out how to help them get to
that destination.

------
halbritt
I started in tech as a network engineer. Eventually I ended up in a management
position and thought I was doing pretty well simply because I was the most
talented and knowledgeable person on the team, the team liked me, and I was
able to mentor each of them. In truth, I wasn't doing much of a job at all,
acting little more than a technical lead.

The second management role I took, I inherited a team of low performers. I had
no idea what to do other than to demand better work from them eventually doing
most of it myself and causing them to feel that they were incapable of being
successful. I was a failure as a manager.

Following that I tucked my tail and moved into an IC role for a while. I read
every management book I could find and eventually made my way back into
management once I came to the conclusion that management, in and of itself, is
a job that must be one's first priority. Getting work done becomes secondary.

I know I'm really echoing other comments already in this thread but it's worth
repeating. Management is a skill that must be learned. It is entirely about
doing what's necessary to make other people successful and often has very
little to do with the practice of actually doing work.

------
bsvalley
Great advice from people here but I'm gonna try to provide as much value as I
can on top of that. Read books, listen to others, get a mentor, blablabla. Do
that for sure because it is the bare minimum. Unfortunately, this is not
enough. Here is how an individual gets into management and becomes a great
engineering manager (the "great" part is essential):

1- The individual would grab the most annoying task no one else wants to work
on and would close it while staying positive

2- The individual is often used as the go-to person when a decision has to be
made, or critical information is missing in a project

3- The individual has a great relationship with most of the people around
(known as a friendly and respectful person)

4- The individual is wiling to help others behind the scene and doesn't look
for any gratification other than making sure people learned something while
being helped

5- The individual has made multiple decisions that appear to be great decision
after all (probably the most important point).

If you fall into all this categories, you'll be just fine. It is a constant
learning process as opposed to being an engineer. Why? because the process
changes constantly, there's actually no process at all. If you learn a
pattern, a language or a framework once, you can re-apply the same process for
the new upcoming stuff. As a manager, every day is a new day. If you're a
shark who produces a lot of output and burns a lot of relationships along the
way, chances are, you'll most likely get promoted, but you'll fall into the
large pool of bad managers. There are more bad managers than good managers out
there. If you don't have the 5 qualities mentioned above, work on that prior
to switching to management. That's my best advice.

~~~
dominotw
I've seen managers who become clueless as to what is happening in the industry
and how things can be done better. They create a world where they are central
figure and become highly resistant to change that would make them powerless.
Managers who think their job is to "assign" task to ppl in JIRA. This creates
a vicious cycle where motivated devs just leave the team and manager goes on
to hire more 'yes men' until project dies and manager moves onto to a new
company.

I've seen this happen so many times in my career. Ppl need to promote
technically inclined ppl into managerial positions instead of focusing on
solely 'ppl skills'.

------
acroback
As someone who went through this couple of months ago.

1\. Code by writing utilities to help your engineers.

2\. Never code something which is critical for the release, you will end up
blocking everyone.

3\. Let engineers make mistakes( which are not critical) without blaming them.

4\. Facilitate communication not lone wolf culture.

5\. Avoid taking decisions without consulting your team, which invloves them.

6\. Keep practicing leetcode or puzzles or programming or whatever you do,
because you will be replaced sooner or later.

7\. Don't get emotionally attached to people, it's not your company. Work hard
and fair. But look out for yourself.

8\. Manage expectations clearly with upper management, don't let team feel
unnecessary pressure from hyperactive product teams.

9\. Clearly set expectations, chalk out a plan and work towards it with each
Engineer.

10\. Relax, it is not a 1 week task, it will take years if not months to see
some visible change.

------
hn_throwaway_99
I say this in complete seriousness, but group therapy was probably the most
important helpful training in my transition from developer to manager.

Group therapy is especially helpful because it makes you realize that, as
"crazy" as some other people may seem, everyone looks at the world through
their own emotional filter based on their background of personal experiences.
Thus, if your job is motivating and growing the skills of people on your team,
being able to truly empathize with them, and to understand what drives their
motivation, is hugely valuable.

------
wppick
I think this is one of the most illogical aspects of the software industry --
the transition from developer to manager. In order to be a developer you need
to spend years learning, studying, and practicing software development, but a
lot of times becoming a manager is just some magical title change where
suddenly you're qualified to take on some new role which you most likely have
no training or experience in, and stop doing the role which you are qualified
for, experienced in, and were hired for. Suddenly there is no way to measure
or evaluate you (how do you evaluate a manager?), and you really don't have to
do anything difficult; you can delegate anything hard or laborious. I've seen
time and time again managers who don't do anything at all. They just fill
their schedule with meetings upon meetings, and through some mental gymnastics
and leaps of logic claim to have an essential impact on the work that is being
done by others. The feedback in many comments in this thread seem to echo the
same things: communicate, be a force multiplier, increase productivity, don't
write code, coach. It seems like a bunch of unaccountable b.s. to me, but
maybe I am missing something. I think instead there should be clear roles like
Project Manager, Product Manager, Software Architect, Senior Software
Developer, where the people in those roles can be actually evaluated,
accountable, and hired specifically for the role that they will be doing.

~~~
indigochill
I see a good manager like a good interface. It's probably unnecessary on a
small project, but on a large project you'll be thankful for that piece of the
machine that keeps the signal-to-noise ratio high and transparently lets you
do the things that need to be done.

For example, I develop tools for internal customers. Those people may have
feedback/feature requests/etc which they want to send me. But I'm busy working
on something else, and although input is good, we need to prioritize. So my
manager takes on the task of processing and prioritizing input, leaving me
free to develop.

My manager also has a role in shaping the broader roadmap, advocating for the
team's priorities and leading us to a position to deliver on whatever the end
result it, which may for instance involve prioritizing space for developers to
learn new skills if they're going to be important to the roadmap.

So all that to say, I think there's a role that involves personal development
of developers more than project management, and it makes things go a lot
better when it's done right (and conversely, makes things worse if not).

As for quantifying it, I think technical debt (specifically, the variety that
is actively hampering a team's development work rather than just "this could
be better") can serve as an approximation. The team I'm now in had been poorly
managed for a long time and was constantly buried in technical debt. We got a
good manager, and those issues are drying up as we get the space allotted to
solve the problems amid other feature work.

------
protomyth
It might sound odd, but you can save yourself a whole lot of trouble by
learning to keep your facial expression neutral no matter what you hear or
see. Communication occurs in a variety of ways and not communicating the wrong
thing is important. Its hard to communicate confidence to your team when your
immediate reaction to some news is a facial expressions that tells your team
something else.

Your a manager now, everything is on a stage and deliberate no matter if its
email, phone, text, posture, or your face.

~~~
davnicwil
This advice is dangerous to take too literally though. I understand what
you're trying to say but when it comes down to it, people work best with a
manager they relate to and respect on a personal level.

Being completely stoic at all times risks losing that personal, human
connection with your teammates (yes, teammates, not team. To be an effective
leader you must be a member of the team, not a separate entity above it). You
need to be a human.

~~~
protomyth
Most advise is dangerous if taken way too literally. People just need to
understand than they are conveying a message with their face, posture, and
hand movements. Don't communicate a bad one or worse, one you don't intend to
communicate. Managers sometimes have to deliver bad news that they might not
be on board with. Don't make a bad situation worse by saying one thing and
having your face betray you. I remember a training video I was forced to watch
that had an actor say the exact same words three times with totally different
meanings because of the signal their non-verbal communication was making.

Being stoic all the time communicates quite a lot and not in a good way.

------
acconrad
Been an EM for a few years. A few quick tips since a lot of people have
covered stuff:

* D E L E G A T E => Your job is to keep your people productive and effective. Doing that starts with yourself - do the things only YOU can do and delegate the rest to the people who are better served to handle that.

* Check out the Manager Tools podcast and focus on the basics ([https://www.manager-tools.com/manager-tools-basics](https://www.manager-tools.com/manager-tools-basics))

* The 2 books I got solid, actionable advice from were "The First 90 Days" [1] and "The 27 Challenges Managers Face" [2]

[1] [https://www.amazon.com/First-90-Days-Strategies-
Expanded/dp/...](https://www.amazon.com/First-90-Days-Strategies-
Expanded/dp/1422188612/ref=sr_1_1?ie=UTF8&qid=1546614786&sr=8-1&keywords=the+first+90+days)

[2] [https://www.amazon.com/Challenges-Managers-Face-Step-
Step/dp...](https://www.amazon.com/Challenges-Managers-Face-Step-
Step/dp/111872559X/ref=sr_1_fkmr2_1?ie=UTF8&qid=1546614819&sr=8-1-fkmr2&keywords=37+challenges+managers+face)

------
chucky
One thing that took me a while to "get" fully (and muster the courage to try)
is that as an engineering manager it is perfectly ok to at times hand over
stuff you might consider "your job" to members on your team. If you do, you
should of course offer extra supervision if they feel like they need it.

There are a few great reasons for doing this. It makes your team less
dependent on you, and it makes them feel empowered in that way. They learn
your job is nothing magical and that they, too, can solve problems that they
might otherwise just say "management needs to solve this". It erodes the "us
vs them" dichotomy of management vs workers which has never been helpful in my
view.

Another reason is that junior developers might not really know or fully
understand what their manager does, and thus might not be considering it a
valid career path for them.

Finally, it frees up some of your time, which you will find when you become a
manager, suddenly becomes a lot more precious. With that freed up time, maybe
you can spend some time coding, so you don't become too detached from what
your team is doing.

------
president
I always laugh when I see advice in posts like these as it assumes an
altruistic working environment. In most of the companies I've worked at in the
SF Bay Area, how a manager behaves in an organization is based on how his
manager behaves. It is all top-down all the way from the CEO. If your CEO is
an asshole, your 4th-level manager down the line will most likely be one too.

------
siddhant
I’ve been working on collecting a list of interviews that answer exactly this
question.

Here’s a link - [https://devtomanager.com](https://devtomanager.com) . Hope
you find it helpful!

------
maxxxxx
One thing I had to learn when I was manager was that things are not always
harmonious. Sometimes an unpleasant situation needs to be addressed and it's
the manager's job to do that. Allowing someone on the team to underperform or
behave badly or bad guidance from upper management demoralizes the whole team
so the manager has to rectify it quickly.

~~~
TadaScientist
I have to agree on this point. Shit will happen, it's how you handle it that
matters.

Maybe a younger developer is brilliant but arrogant and dismissive of others.

Maybe a senior team member lays low not producing and piggybacking off of what
others are doing

My biggest issue was feeling comfortable enough to directly ask people to work
on specific projects / pieces of work.

------
kopos
Please spend reading High Output Management by Andy S Grove - the best
reference book for would be managers.

The biggest difference from developer to manager is understanding the value of
leverage. As a developer, the biggest feedback / dopamine hit is the
completion of tasks ... while being a manager is about the feedback +
monitoring + productivity cycle.

I’ve been a CTO cum TL cum Manager all at the same time and I’m sure that
reading the book might have helped me focus correctly on the getting thr best
leverage.

------
everdev
As you transition to management don't stop coding. You might not have time at
work, but make time (20hrs/month) after work or weekends to learn the basics
of a new skill relevant to your work.

IMO, developers get annoyed at having to report to someone who doesn't
understand at least the basics of what they're working on our who can't
provide recommendations in a pinch.

The respect you'll have with your developers makes managing them infinitely
easier in my experience.

~~~
kabdib
Don't stop coding BUT don't take on engineering responsibilities that will
diminish your value as a manager.

All too often I see the developer to manager transition treated as if
management were merely an additional responsibility. The new manager keeps
trying to write code, works late hours doing both jobs. The result is usually
a bunch of not very good code, usually late, and a bunch of unhappy direct
reports who can't schedule time to talk to their boss (and are wondering why
their reviews are never on time).

The worst managers I've had have had 6-7 reports and tried to hold onto a
coding job as well. _This does not work_. Keep your engineering skills up, but
don't expect to write code for a living.

~~~
lojack
Knowing when to code and what types of work are acceptable to do is extremely
important. My transition to management wasn't immediate, there was a 4 month
period where I was taking on more responsibilities as a manager. Initially
contributing to projects was easy, but as I took on more responsibilities it
became more and more difficult. At a certain point during the transition there
was a pull request that I got 80% of the way through and then just sat there
incomplete because I was too busy. Ended up handing this work over to one of
the developers, and treating it as a sign that I was no longer a developer.

I still do some work from time to time, but I make sure its work I'm doing for
my own personal reasons and no other work depends on that being completed. I
also keep my technical skills sharp by pairing with team members, directing
them on technical decisions, and doing code reviews. You've got to be careful
with code reviews because they can come off as micromanagement to some people.
Sometimes developers will specifically request a code review from me, and I'll
take those. Sometimes I'll chime in if a decision needs to be made. Otherwise
I try to only code review if I see something glaring that needs to change.

------
khendron
I attempted to make this change a few years back, and failed miserably.

What went wrong? For me, personally, the problem was still having too many
developer duties. I had a full schedule of management duties to attend to, and
a full schedule of development duties to attend to. I quickly began to burn
out, and did a poor job on both. Although I excelled at some of my management
duties, others were critically neglected due to lack of time. Specifically, at
the manager level inter-team communication is important and I did a shitty job
of it.

In hindsight, I should have dropped my developer duties completely. I didn't
because my team didn't have the employee resources to meet its objectives. But
attempting to take on critical-path development duties in order to fix the
problem was the wrong thing to do. I did me no favours, nor did it help the
company. Maybe I did it because I was more comfortable doing development than
with the inter-team communications duties I was neglecting. In any case, we
would all have been better off if I had spent more time paying attention to my
team's place in the rest of the company, and simply pushed back on schedule
and resources.

~~~
dmak
I don't think it's easy to manage and program. In my experience, you have to
delegate. Programming, I at least want to agree on a technical design and then
delegate it off to a member of my team.

------
ptero
This is a hard switch that requires you to focus _much_ more on personal /
people challenges and much less on technical challenges. I recommend you
completely throw out your developer hat. Your role on technical issues should
be limited to making decisions when necessary.

Otherwise I would focus on three things:

1\. Estimating project time. It will now be _your_ problem when things are not
on schedule. Nothing happens quite as planned, but knowing when _your_ team
can realistically deliver X is priceless. Successful mastery means most
projects get completed in line with your internal predictions (which do not
have to match whatever your own management expects or claims).

2\. Keeping team happy. Knowing each team member strengths and interests,
understanding and resolving interpersonal problems. And keeping them shielded
from your own management. Successful mastery means your team respects you.

3\. Firing (and to a much less extent hiring). Learn when you should let
someone go and how to do it. Success means you have to do it rarely and when
you do you do not lose team's respect. They may grumble, but deep inside will
know that this is the right decision.

------
pm24601
High Output Management by Andy Grove manager-tools.com has a bunch of good
podcasts I ran across platohq.com which is building a site for people like
yourself to get mentorship.

As more my own personal advice... Recognize that you will have to:

1\. fire people you like.

2\. give up the option to work directly on code

3\. spend more times in meetings

4\. budget time more carefully

5\. be careful what you say (things get misinterpreted)

....

so much more

The skills that make you a good developer are only 20% of the skills needed to
be a good manager.

------
philk10
I've read and re-read Becoming a Technical Leader - An Organic Problem Solving
Approach by Jerry Weinberg - [https://www.amazon.com/Becoming-Technical-
Leader-Problem-Sol...](https://www.amazon.com/Becoming-Technical-Leader-
Problem-Solving-Approach/dp/0932633021)

~~~
marcuscreo
+100 on that book.

------
skyzyx
I've been collecting a list of things to read about managing humans over the
past decade, and finally made the move to engineering manager in 2018. Here's
my list:

[https://github.com/skyzyx/managing-
humans/blob/master/README...](https://github.com/skyzyx/managing-
humans/blob/master/README.md)

In short, I would recommend subscribing to
[http://randsinrepose.com](http://randsinrepose.com) and
[https://blog.knowyourcompany.com](https://blog.knowyourcompany.com) and
reading (and understanding) every single post. Even if you want to tweak
things and go your own way, these are successful engineering leaders that you
will want to learn from.

Managing humans is a very different job from managing code or managing
machines.

------
karma_fountain
I did the transition and made mistakes on the way. I'm probably not that great
a leader so you can take this with a pinch of salt. What would have helped me
at the time was:

You will probably be a bit incompetent at first but that is part of the
process. Maybe keep a diary of interactions you have with the team so that at
the end of each day you can reflect on what you might have done differently.
It's ok as long as your always striving to improve.

One of my main goals as tech leader is it get people to stay at the company!
To do this you should know what your direct reports personal aspirations are,
and have a clear future plan you have both decided on to get them there. You
should both be reviewing this all the time.

Don't assume things about people, just ask. Some people actually like being
micro-managed! Although, try to give your good people freedom within
boundaries/budgets/constraints, get them to come to you if they want to go
outside those boundaries. Give your bad people explicit tasks, set appropriate
deadlines for them, coach them to be good people.

Try and delegate everything that you think can be handled by a team member
(and they want to do it) and isn't personal development. Don't be laissez
faire about it, if you delegate to someone write it down and check-in with
them at an appropriate time about the task. Be disappointed when they don't
complete the task in the agreed time.

You might think you have to be the charismatic leader who can inspire people
to eat shit all the time but that is just not true. There are many different
styles of leadership. In sales for example you can go far with contingent
reward. There is also a lot of bollocks written about leadership so try and
stick to facts when learning. I thought this was a good overview but YMMV
[https://www.amazon.co.uk/Science-Leadership-Lessons-
Research...](https://www.amazon.co.uk/Science-Leadership-Lessons-Research-
Organizational/dp/0199757011).

------
dustinl
I moved from engineer to manager around 3 years ago at an SF based "unicorn"
and moved up the ranks into senior management. I tend to break it down into
three areas: managing up, down, and across. Up: understand your audience and
learn to connect your work to the broader picture/business value without all
of the engineering detail. Across: manage your capacity (resources on your
team), learn how to say "no" with justification, get better at "business" and
speaking to non-technical folks, be good at cross functional communication.
Down: servant leadership, align engineers interests with their work at the
company, help them grow their careers, be firm in ensuring everyone is treated
fairly, and stay technical so you can align on the technical direction from
others.

------
rb808
Two main things 1) You should think & ask about what the goals you really want
for you. 2) You have to fight for resources

1- Do you want a team that works really hard and produces a lot? Or has good
quality of life? Technically strongest or business focused? Grow new junior
people or stick with those who know what you're doing? Usually people just
take one day at a time and at the end of year disappointed where they end up.
Will you get paid more if you choose which one of those choices? Or maybe you
care more about love of your team, or professional accomplishments than money.
Think about that.

2- When there is more and more work I tend to come in on weekends and work
longer hours. Other teams just say they can't do it without more resources. I
wish I was like the other teams.

------
carusooneliner
Managers have to communicate both up and down while developers only need to
communicate up. When I made the jump from a developer to a manager I had to
learn how to properly communicate issues and risks to upper management. If
there's an issue related to your team, you should be the first to escalate it.
If management hears about your team's issues from a different source, you'll
look bad. As manager, my number one job was staying on top of risks and
issues, which meant getting up to date information from my reports and
communicating the exact magnitude and priority of the risk/issue. If you
develop a reputation as someone who can communicate and handle risks and
issues well, that'll set you on good footing.

------
cusack
A nuance I felt -- when you're an IC the 'I'm being productive' feedback loop
is really quick and thus satisfying. You can come in the morning and have
measurable problems you solved by the end of the day. As a manager, feedback
cycle gets longer -- you're investing in trying to make your team more
effective over the long-term. The things you work on on a given day might not
be measurable as 'working' or 'productive' until several weeks or months
later.

I found this feedback cycle image helpful to keep in mind when I'd get
frustrated as a manager feeling i'm "not as productive as I used to be". Also
helpful for prioritizing what gets worked on.

------
fixermark
Assuming you're in the software space, management is still writing software,
but your language is people, not machines.

People are not machines. They're extremely heterogeneous, they have emotions,
they wear out, they burn out, life happens and they can't dedicate themselves
to the tasks you care about as much as you might want them to. But the
advantage is they have all the creativity and brilliance of a human mind, and
can make things machines can't. Often times, I find the task of a manager
looks less like scripting and a lot more like environment creation: build a
space where your best and brightest can be happy and motivated, and you can
trust them to fill that space.

------
taurusismysign
Your team should see you as a leader who is available, dependable and is
providing them space.

You shouldn't see yourself as a "manager" right from day one but gradually in
your mind shift into a managerial mode.

Shameless plug - I got obsessed on how great teams get built and run. I
started a podcast and the very first episode I got recorded was "How to
transition from Individual Contributor to a Manager".

Would appreciate feedback and also any names to the ones I can approach for a
guest

[https://podcast.nurture.team/episode-01-how-to-transition-
fr...](https://podcast.nurture.team/episode-01-how-to-transition-from-
individual-contributor-to-a-manager/)

------
NikolaNovak
1\. Make sure you understand what role you are striving for. People rarely
agree what is difference between "Manager" and "Leader", but ensure you
understand your own definition and what your preferences are. (for myself: a
Team Lead is also a subject area expert, and may spend time both guiding their
team to success, coaching, mentoring, and interfacing with other teams and
upper management; as well as performing design/architecture, assignment,
troubleshooting and maybe even some hands-on work themselves. They are the
person other team members turn to guidance. Scariest sentence I heard in my
university years was "A good manager needs not be a subject area expert", but
I now understand it better: they understand the company, business, strategic
imperatives, processes and frameworks, deadlines and pressures, stakeholders
and environment; and ideally should work to remove obstacles from team
members, ensure the team is working at high efficiency and in the right
direction, and interface at high level with client and senior leadership.

Team leads have more fun, but that statement is relative :)

If going into management-proper: 2\. Make sure you are prepared to give up the
hands-on. Absolutely the hardest part for most technical people I've ever met.

3\. Make sure you're prepared not to be the SME anymore. You simply won't have
the time to be up-to-date on either every detail that's going on with the
system or systems you're managing, or industry standards and movements.

4\. Learn about people as voraciously as you would have about technical items.
Communication is a hard skill to learn and cannot be acquired alone.
Aggressively seek mentors and feedback. Run post-mortems: What happened in
that meeting and why? Did we reach our goals? Why or why not?

5\. Absolutely most importantly: take care of your people. Enable and support
and coach them to success. This can be the least externally but most
internally satisfying and gratifying part of the job. Depending on your
workplace, you may or may not be recognized for developing your team, but this
should be your #1 priority, and if you gain personal satisfaction from seeing
your team members soar and take flight, you should do OK :)

------
charlax
I keep a list of all the resources that have inspired and helped me here:
[https://github.com/charlax/engineering-
management](https://github.com/charlax/engineering-management)

It starts with a few high-level book recommendations, and blog articles for
more specific topics.

My favorite book, which has not been listed in this thread, is: Turn the Ship
Around!: A True Story of Turning Followers into Leaders. David Marquet, who
used to command a nuclear submarine, explains how he achieved high levels of
motivation and output thanks to empowering his team.

------
andersthue
I would recommend these two books that will give you the people and
communication skills that is paramount to suceed as a manager.

It is those books I have learned most from and helped me the most.

Leadership and Self Deception And Crucial Comversations

------
hypesafe
I am a new manager. I made the developer to manager transition 14 months back.
Educating yourself with books and podcasts is nice, however do not spend too
much time on these resources too soon. Without appropriate breadth of
experience a lot of the advice might not seem actionable. My advice would be
to aim to become a great _new_ manager first. Becoming a great leader and
manager is a function of experience and will come with time and patience.

My advice for a _new_ manager would be:

1\. Bootstrap by emulating your manager. As a new manager now is not the time
to demonstrate your grasp of modern management literature. Pitching too many
new management ideas too soon will slow you down. Start by emulating your
manager. Copy her 1-on-1 cadence. Copy her team meeting cadence. Parrot her
words in your own team meetings. Her style might not be the best - but it the
style she is most familiar with and it gives her an opportunity to work with
something familiar and hence comforting. Once you have a semblance of a track
record - start evolving your own style.

2\. Prioritize the tactical vs the strategic. The first 6-12 months are about
building your credibility as a manager. You will build credibility by
executing on the immediate needs of the org. So first 6 months should be about
tactical execution - once your team starts getting better at executing dial
down and delegate the tactical and start focusing on the strategic.

3\. Try not to expand too fast. As a new manager it might be tempting to grab
all the head count that comes your way. However without scalable processes in
place you are likely to have a large but miserable team. Ensure that you have
appropriate automation for tracking individual + project progress on a daily /
weekly basis. Ensure that you are competent enough to derive high signal-to-
noise ratio in your 1-on-1's with your directs.

4\. Treat administrative / HR tasks with great seriousness. As an individual
contributor your engineering tasks took priority. Do not be that manager who
forgets to approve expenses, approve PTOs etc. Have a rock solid understanding
of compensation and bonus structures, criteria for salary raises etc. Saying
"Why don't you reach out to HR" is a great way for your directs to lose
confidence in you.

------
stuff4ben
Actually just did this myself last month. My team is colocated between India
and the US, but I'm remote in the US to all of them. That's been the biggest
challenge for me. I'm more of a visual person when delegating and encouraging.
Very difficult to do that over messaging or email. Video conferencing helps,
but not the same as actually being there in person. Had I known this was going
to be the case, I probably would have postponed the promotion. But I'm going
to stick it out and get through this because that's what I do.

------
Vaslo
Be willing to step in and get your hands dirty as you will earn great respect
that way. Nothing is more despairing than a boss who never opens a PC for
anything but email, and then leaves as 5 while the rest of the team is there
struggling with an issue until 9PM. At the same time as others say, don't be
afraid to delegate a lot of your detail work. Oh, and you earned the right to
delegate so if there are things you hate to do, don't feel bad about
delegating to others. Someday they will earn that right too! GOOD LUCK AND
CONGRATS!!

------
finaliteration
Speaking from my own experience: Be easy on yourself at first. Moving from a
technical role to a management role is difficult and you may feel like you
aren’t doing a good job or you’re doing and saying all the wrong things at
first. Give yourself some time to adjust and don’t expect to be awesome at it
right out of the gate.

If you’re at all a perfectionist like I am realize that it’s even more
impossible to achieve perfect solutions when you’re dealing with relationships
and people rather than software. Be kind to yourself as you learn and grow.

------
LloydPickering
The hardest bit you are going to have to overcome is the ursge to step in and
do the job yourself. Up until now your career has been built on your ability
to get things done. From now on, your career will be built on your ability to
help others get things over the line themselves.

This is not to say you should down tools and never touch code again, far from
it, but you should strictly cap the time you spend coding for at least
12months as it's too easy to fall back into the habit of feeling productive
becase you have your IDE open. If you spend too much time coding, you are
avoiding your real job. I generally pick up bugs, scut work or the occasional
prototype. I also enjoy clearing up some technical debt from time to time.
Either choose quick tasks that no one is relying on, or longer term items that
wont cause any blocks if you are delayed.

Related to the above - as manager, you are no longer in the best place to
decide on a technical solution. It is your job to make sure that the best
technical approach is decided on. In fact you can generalise this to
management as a whole - its not your job to make decisions, its your job to
make sure decisions get made.

You fail if your team fails, you succeed if your team succeeds. Therefore do
everything you can to remove impediments, and shield your team from shit that
distracts them wherever it comes from. Encourage them to speak out when they
think something is wrong. Play the role of facilitator in meetings to make
sure every option is heard and discussed. Have regular informal one to ones
with your staff with no fixed agenda - just ask them how they are getting on
and how they think things are going. If you have a good connection with them,
then you can ask them what you personally should be doing better to help them.
If there is little to no trust, then expect them to clam up and say all is
great and you are awesome even if you are not.

I loved the transition to dev manager because I was able to make a bigger
difference to productivity than if I was doing coding myself. Bigger longer
term impact, more strategic but less of an instant 'sugar hit' from tech
related fun.

One final piece of advice that I was given by a CTO. He asked me who my team
was. I replied with the developers and QA who worked for me. He told me I was
wrong, they were my 2nd team. My 1st team was my peers. The other dev
managers, QA manager, support team manager, product manager, project manager
and ops manager were my team. We needed to start working more closely together
as a team rather than in our own little 2nd team silos. What a difference that
made to my perspective.

edit:some spelling

------
sjg007
Be kind, be nice, be fair, help people succeed. Sometimes you are the shield
who protects your team from upstream. You translate higher level objectives
into specific team actions. Build relationships with other managers and higher
ups. Find comfort in uncertainty.

You are now the direct report of your manager and you now have a team that
acts as a force multiplier to get more things done or more complex things
accomplished than you did alone. Your job is to use that effectively and also
inform your higher ups of what is realistic etc...

------
vageli
You must internalize the fact that you can get things done just by talking to
people. These days I rarely commit code but influence the direction of code
with 1:1s and coaching. My biggest suggestion would be to shift your focus to
the broader picture. Think of process improvement as your primary job. You now
have the power to remove toil from the lives of your direct reports' day to
day so seek out ways to do so and you will have increased the productivity of
your team by a large multiple even with a small improvement.

------
evadne
The most important thing in my opinion is to thoroughly understand people,
those who report to you, and who you are responsible for: their biases, fears,
motivations, habits, and strengths. Upon this basis you can form a cohesive
strategy for any task at hand, while at the same time ensuring that the team
grows with you during the temporary alliance they have formed with the firm.

At the end of the day, code has to work, and it might be easy to lose sight of
this in a myopic and cacophonous world.

------
ryan-allen
You may like it, you may not like it. I personally found that being a manager
required a lot more motivation to maintain interest compared to coding,
architecture, design type work that had been very intrinsically rewarding for
a long time (it's what got me to where I was in retrospect, it never felt
'hard').

It may mean that you have to develop skills you are not interested in, but are
essential. I've known a handful of developers who transitioned and really
enjoy it, so YMMV.

------
ninjakeyboard
The biggest challenge I find is code. If I'm trying to deliver, I can't give
myself the thinking time to identify challenges and produce solutions. I can't
orchestrate people if I'm under duress to deliver. So really try to separate
code and management and move your focus from one to the other. Seek mentorship
and guidance in managing this balance from inside the organization - it's the
killer of anyone who would hope to be a decent lead.

------
dandare
The most valuable book about "management" that I read back as a developer.
Very thin - high information density. (The author later wrote a much thicker
book with basically the same info).

I bought a second copy on my way to a job interview when I misplaced the first
one :).

[https://www.amazon.com/Mobile-MBA-Skills-Further-
Faster/dp/0...](https://www.amazon.com/Mobile-MBA-Skills-Further-
Faster/dp/0273750216)

------
vmlinuz
I don't have an answer, but I appear to be accidentally (and for now,
hopefully only partially) making that transition right now...

I am an 'older' engineer (in my 40s) who just came off a decade-long stint
doing solo freelancing, mostly for one rather laid-back client - so it's
pretty much been a career progression break. Started a 'real job' about 6
months ago, as an IC, in a local (long way from US) startup with approximately
60 people in tech department. Did a simple project to familiarise myself with
the code base and tools - then started working on a larger, multi-team
project...

Then was person-in-charge for the project within my team...

With one, then two (and now three) of my teammates working on the project
'under me'...

Then was committer/deployer-to-prod of project for my team...

Then another teammate decided (AFAIK it was his choice) to move teams, and I
agreed to take his deputy-team-lead and code-owner responsibilities - in
February when his move is done...

Then a bunch of other teams got involved in the project, many of them
committing to my team's repo - so now I'm mostly reviewing, commenting,
advising, coordinating...

Then team lead goes on New Year holiday, now I'm running stand-ups, approving
early leave for Christmas/New Year's Eve...

I am now (while TL is on holiday) apparently reporting directly to VP of
Engineering, who is Austrian and a bit of a hierarchy guy, and who has barely
spoken to me before this week...

In the course of about 3 months I've got from engineer to at least temporary
team lead and code/project owner. Although things have gone a little Mythical
Man Month with me as the bottleneck, I'm winging it for now. I'm trying to be
fairly strict with code quality - although that's weakened as deadlines
approach and pass - but I'm probably a little soft on people management, which
I instinctively don't really want to do, so it's easier to say yes.

It's more, and different, stress from what I've been used to in the past, and
it's not necessarily bad, just new. I am expecting to speak to someone fairly
soon about increased compensation for increased responsibility, which is
noticeably something that has not come up at any point so far.

------
abrookins
You can start on the path right away. Before work every day, imagine your
teammates and the things you like about them. Then ask, what would you need to
know and do today to help keep the team safe and successful? What’s going on
in the world of this particular team? What are the commitments, what are the
threats (from inside and outside the team), etc.? Dwelling in that mindset
every day is a good first step.

------
mystickphoenix
As a developer, I'd love to see more managers read and try to follow the
advice that makes sense for their company/position from Michael Lopp, aka
Rands: [http://randsinrepose.com](http://randsinrepose.com)

From my perspective, it's a how-to guide for managing information workers,
keeping them happy, and keeping yourself sane.

~~~
ransom1538
\+ Yes, I suggest reading his book 5 times:

[0] [https://www.amazon.com/Managing-Humans-Humorous-Software-
Eng...](https://www.amazon.com/Managing-Humans-Humorous-Software-
Engineering/dp/1484221575)

------
jressey
There are no books to read or videos to watch that will teach you this. It is
about being your best self and being above average at every competency on a
product delivery team.

Here's my approach, it is very simple: Embody the principles you believe in,
encourage trusting and respectful relationships, and focus on doing what you
can to let others excel in their areas of expertise.

------
lifeisstillgood
The cynicism and negative attitude towards managers in the "Developer
Hegemony" book is at dramatic odds with the many positive comments here - so
much so that Insuspext the books main thrust (managers are complicit in
holding "delivering" developers to impossible timescales and enforcing
hierarchy needs on devs top down) is even more correct

------
tmaly
I have taken on a role of a programming manager of my team over the last two
years. I still have some programming responsibilities, but I do about 95%
management work now.

Pg had that essay about maker time and manager time that is spot on.
Transitioning to a manager role is a different skill set.

I would highly recommend the following two books

The Coaching Habit by Stanier

and

Extreme Ownership by Willink and Babin ( audio version is amazing )

------
jamietanna
I'd recommend a watch of Ramez Hanna's talk at DevOpsDays London 2018 -
"Managing people and other horror stories"
[https://youtube.com/watch?index=10&list=PLuEbc43fHqLg3WvWvcP...](https://youtube.com/watch?index=10&list=PLuEbc43fHqLg3WvWvcPpzcI7PVAkuJvWm&v=7m49scWq9sM)

------
TheBill
Take a look at
[https://www.harrisonmetal.com/](https://www.harrisonmetal.com/) \- even if
you're not in the bay area.

I had a chance to sit in on a dinner of General Management students from a
~dozen companies. The vast majority were going from individual contributor to
management roles.

------
rb808
Forget about reading books at this stage. Tell you manager or higher ups you
want to start doing management stuff. They will likely be thrilled as its
rare. Start doing and getting their feedback & that of other managers. Only
after a year or two is it worth reading to get new ideas.

------
mbrodersen
You work for the team. You are there to remove obstacles, make sure everybody
knows what the objective is etc. You are not there to take away developer time
with meeting after meeting. The more you can stay out of the way, and take
care of external (to the team) obstacles, the better.

------
johnkchow
The hardest part during the transition is to give up doing what you love and
excel at (coding) and instead doing something foreign and way more nebulous.
But every time you feel that urge to go back to writing code, you need to
remind yourself that as a manager, your primary goal is to have a
multiplicative effect in the organization, and that starts with not only
improving your team’s productivity, but coaching each and every member on your
team to have great judgement and make the right decisions that balances the
technical and business needs. And to have your team make the right decisions,
you as the manager need to equip them with as much business context as
possible and empower them to run as fast as they can.

I highly recommend reading High Output Management by Andy Grove. It’s written
decades ago for the chip business, but it’s personally one of the most
impactful books and really cemented for me the ideas I’ve laid out above.

I wish you luck! It’s not an easy process, but with work it can be incredibly
rewarding to see people succeed and grow under your watch.

------
mbirch39
I would reflect on your worst boss and learn what not to do.

Science says:
[https://www.sciencedaily.com/releases/2018/12/181203150505.h...](https://www.sciencedaily.com/releases/2018/12/181203150505.htm)

------
Spooky23
Take care of your people.

Know the difference between being a boss and a leader - becoming a manager
doesn't mean you know better.

Negativity is like a virus. If you're a cynical engineer, figure out how to
not project that cynicism.

Focus on outcomes. Whatever the day to day drama is, move towards your goals.

------
chris_melman
A short but interesting post on becoming a manager in engineering

[https://zef.me/so-you-want-to-be-an-engineering-manager-
bcdd...](https://zef.me/so-you-want-to-be-an-engineering-manager-bcddaf302938)

------
matt_morgan
That the chief function of management is making it more possible for your
staff to succeed in their jobs. Supporting your staff in a way that makes your
department help the business meet its goals is your primary measure of success
now.

------
elbrujohalcon
I gave a talk about this subject in particular. Here are the slides:
[https://slides.com/elbrujohalcon/deck-2-7](https://slides.com/elbrujohalcon/deck-2-7)

------
alanzhong
many good answers here, but i would like to highlight one thing - like
programmer to take care of the code, as lead or manager, you need to take care
of your team members. You need to respect there are different team members -
different characteristics, different strength, different background. People
has different emotion from time to time. People have different expectations.
These are very unique to human being and manager need to address human
problems while a developer/programmer addresses mainly coding/technical
problems.

------
avi990
Managerial positions need more of understanding humans rather than data.
Balancing a team, showing a path, leading teamwork are some of the many
attributes one should possess to be a manager.

------
jcslzr
Read this: [https://www.ribbonfarm.com/the-gervais-
principle/](https://www.ribbonfarm.com/the-gervais-principle/)

------
balaji1
Does becoming a manager usually mean more recruiting/interviews also? Any tips
about how to recruit, internally or externally? How to add to or complement
the current team?

------
known
[https://en.wikipedia.org/wiki/Triarchy_%28theory%29](https://en.wikipedia.org/wiki/Triarchy_%28theory%29)

------
pharaohgeek
I'm actually doing the exact same thing. I started my managerial role on 1/1,
so I'm definitely interested in the advice presented here. Thanks!

------
drugme
Developer: you go in with dreams of building new systems but you end up ...
debugging code

Manager: instead of either of the above you end up... debugging people

------
lukethomas
The level of management book B.S is off the charts, but I would strongly
recommend you pick up High Output Management, by Andy Grove. Use this as a
foundation.

Next, I would recommend a few things:

\- hold 1-1s with each person on your team on a regular basis. This is by far
the best way to build good relationships with each person on your team. You
will also get a lot more insights too.

\- Ask each person on your team what their goals are in the next X
months/years. Then do everything you can to help them reach it.

\- Constantly be soliciting feedback about where you can improve.

------
durzagott
I transitioned from dev into management about eight years ago and haven't
looked back since.

\- You have to really like working with people and I mean all kinds of people,
not just those you identify with. You'll have to build strong relationships
with people from a diverse range of backgrounds, personalities, experience
levels and cultures. You'll discover unconscious biases you didn't even know
you had and it will be your job to mitigate against them (they don't just go
away).

\- People are messy and you will be in a privileged position to see behind the
mask. They will bring their problems to you and these won't always be directly
work related. You'll be expected to help in some way, but most of the time you
won't have a clue what you're supposed to do or say. _Don 't try to bullshit
your way around them_. Learn how to listen and develop good coaching skills.
If the problem is more practical, make sure you have a solid relationship with
HR and other managers. You might need their help to resolve the situation.

\- Schedule regular one-to-ones with your direct reports and don't bump them
_ever_. What this really means is when something comes up (vacation, sickness,
conferences, workshops, etc) reschedule at the next earliest, convenient time
or _mutually_ agree to skip it. Send a clear signal that you value this time
together and only exceptional circumstances will move it (being remote isn't
exceptional). When it comes to the actual one-to-one, do some research on how
to get the most out of them and adapt it to the individual. There's a ton of
material out there.

\- Not everyone is going to like you, get used to it. Sometimes it's a
mismatch in personality types, sometimes it because of something you did and
sometimes it's just because you're a manager and you represent the company;
the reasons are infinite. Most humans crave acceptance and have a deep need to
be liked. You have to learn how to dampen this instinct and intuit other ways
of evaluating your performance. I'm not saying being a jerk is ok, but
learning how to be resilient is important.

\- Never stop learning. When you're a developer there's always a new language,
or paradigm or technique; the field is constantly evolving and management is
no different. It's every bit as much of a craft as programming. Read books,
listen to podcasts, go to conferences, learn, learn, learn. You'll start off
being Unconsciously Incompetent and will need to progress into fluency and
mastery. If you only do on-the-job learning your development will be slow and
there'll be a cap on your experience. You'll no doubt receive a ton of
recommendation in this thread, but I'll link to a couple meta-resources I've
found useful [1][2]

\- Management and leadership are two very different things. You can be great
at one, but suck at the other. When I first moved from being a developer to a
manager I focused all my energy on the management side of things (coordinating
work, removing obstacles, administration, hiring and firing... getting shit
done). I was a great manager, but a lousy leader. People want to work for
someone who's competent, of course, but they also want someone who inspires
them, who challenges them, and who understands their needs. Learn what it
means to be great at both and focus your development accordingly.

\- If you're managing developers, or people in any technical field, you may
need to be able to have conversations about their work. Opinions are massively
divided about this, but I personally believe staying on top of industry
trends, and maintaining a technical mindset, is important to maintaining
credibility and empathy with your direct reports. Let's be honest though, if
you stay as a manager you will probably never be at their level again, and as
the years roll by you will become increasingly incapable of doing their job.
This freaks a lot of new managers out and I've seen them either try to hold on
to their former status (and fail) or they abandon management after a few
years.

\- Impostor syndrome is real. You will probably get it. A lot.

[1] Podcast (personal favorite) - Coaching for Leaders:
[https://coachingforleaders.com/](https://coachingforleaders.com/)

[2] Podcast - Manager Tools: [https://www.manager-
tools.com/podcasts](https://www.manager-tools.com/podcasts)

------
winrid
Learn to optimize moreso than manage.

Learn how to give context without accusing or instructing.

Learn about the different types of management.

Read: First, Break All The Rules.

------
_Codemonkeyism
As I see management

Developer -> do work

Manager -> help others do work

Manager of Managers -> help others help others do work (hard)

------
koonsolo
Here is the main thing you need to know:

You are at the service of your team, not the other way around.

------
rntksi
"The Dictator's Handbook" will be a nice read for managing roles.

------
wolco
To let go of the reins and understand you are not[a developer anymore.

------
dbg31415
Fundamentally being a manager is been more about building relationships than
code. It's a very different role than a software developer, which generally
has a tangible output.

You will likely need to beef up communication skills. Get better at writing
short but punchy emails, writing actionable meeting notes, know how to build
PowerPoint decks that tell a good story, and can talk confidently in front of
a crowd. Communication skills will help you further your agenda by getting
others, especially non-technical folks, to align with you.

You need to focus more on your reputation in the company. This means being
visible to other teams, taking as many opportunities as you can to meet new
people in your organization, and ensuring that you get credited for the wins
you bring about. (It also helps to just be more presentable, take this as an
opportunity to class up your wardrobe. "Treat every day like it's a potential
first date and you'll be fine," was the advice I got with my first manager
position -- it was more criticism for wearing shorts and a soccer jersey like
I had when I was a dev.)

You need to figure out who your key stakeholders are (it's not always as clear
as just following your org chart), and understand the priorities of your
company. Actively trying to understand other departments' KPIs will go a long
way.

You need to figure out how to work with the people on your team. Determine who
the high performers are, what they want, and how to keep them happy. Also have
a game plan for correcting behavior you don't like.

If your company offers training in negotiation, even if you can grab some time
with a successful sales person, try and take them up on that. Your ability to
hire talent, give performance reviews, and haggling over scope with other
teams will all benefit.

As a manager you'll likely have a bit more stress as you're acting as a shit
shield for your team, and are ultimately on the hook for delivering a lot
more. Finding ways to de-stress are key. Make sure you have a good gym
routine, set up time to regularly speak with your shrink or career coach, and
make sure you're taking the time to do whatever it is you need to do to stay
healthy and energized.

This is far from a complete list, but here are 3 books that I think are good
books I'd recommend for anyone moving into a leadership role.

* The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter, Updated and Expanded: Michael D. Watkins: 8601200550153: Amazon.com: Books || [https://www.amazon.com/First-90-Days-Strategies-Expanded/dp/...](https://www.amazon.com/First-90-Days-Strategies-Expanded/dp/1422188612/ref=sr_1_1)

* What They Teach You at Harvard Business School: My Two Years Inside the Cauldron of Capitalism: By (author) Philip Delves Broughton: 9780141046488: Amazon.com: Books || [https://www.amazon.com/What-Teach-Harvard-Business-School/dp...](https://www.amazon.com/What-Teach-Harvard-Business-School/dp/0141046481)

* How to Win Friends & Influence People: Dale Carnegie: 8937485909400: Amazon.com: Books || [https://www.amazon.com/How-Win-Friends-Influence-People/dp/0...](https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034/ref=sr_1_1)

------
marcuscreo
A few articles I've written on this topic:

1\. [https://hackernoon.com/the-wrong-section-of-the-
bookstore-96...](https://hackernoon.com/the-wrong-section-of-the-
bookstore-96812873617f)

2\. [https://hackernoon.com/the-real-work-of-software-
management-...](https://hackernoon.com/the-real-work-of-software-management-
part-1-ac44cb2e129)

3\. [https://hackernoon.com/i-started-wondering-if-being-a-
team-l...](https://hackernoon.com/i-started-wondering-if-being-a-team-lead-
was-for-me-19322eab4d10)

4\. [https://hackernoon.com/joyful-technical-
leadership-6f4fb8bd7...](https://hackernoon.com/joyful-technical-
leadership-6f4fb8bd7d01)

------
marcuscreo
I've written hundreds of articles on this very topic - it can be a tough
transition. #ShamelessPlug - Join my list to become as good a manager as you
are a coder.

[https://marcusblankenship.com/](https://marcusblankenship.com/)

------
mahesh_gkumar
Shameless plug -> [https://www.linkedin.com/pulse/moving-management-mahesh-
guru...](https://www.linkedin.com/pulse/moving-management-mahesh-guruswamy/) .
I use this with everyone on my team who wants to explore the management path.
Happy to chat more if you want concrete examples about how I transitioned
people over.

