Ask HN: Going from Developer to Manager. What should I know or learn? | Hacker News Reader

Ask HN: Going from Developer to Manager. What should I know or learn?

519 pointsmseo182 comments

After reading (and resonating quite a bit with) "Developer Hegemony" by Erik Dietrich, which was one of the recommended books in the "what did you read in 2018" posts, I think about steering my career to a manager instead of a developer position.

For all those of you who've done the same or planning to do the same: What are the most important skills or what's the most needed knowledge in such a position? Where can I learn it? What should I read?

View on HN

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.

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.

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.

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.

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.

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...

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

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

[2] https://www.google.com/amp/s/artdepartmental.com/2009/10/12/...

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

As a quick note, if you want the dot grid notebook (vs the smaller 3x5 memo books) from Field Notes, it's the Pitch Black Notebook: https://fieldnotesbrand.com/products/pitch-black-note

Just wanted to say - thank you for sharing this! This sounds like an incredible idea and I can't wait to try it out.

I already seem to work better when I write down whatever development tasks I have on paper, but it has never occured to me that management tasks could be handled in a similar fashion.

No problem! It was hard for me moving from dev to management. I think a key difference in the tasks is that the majority of management tasks are personal and cannot be collaborative or even public. They involve peoples feelings and behavior. Sharing them to scrum the problem would shame people for no reason and cause a mutiny. As a manager, my task is to catch chaos and distill it to comforting direction. You can’t write good software if you are aware of the terror of the day to day. Daily terror should be invisible to my team so when real emergencies happen, it’s not stacked on a constant pressure of minor annoyance. Predictability in the day is so critical for engineers to produce amazing shit. Predictability allows for room to experiment.

I think that is why journaling is so effective. If you rely on dev tools and tracking for management tasks without journaling you have no outlet for the real work of the job, sifting human conflict and ambition into a rewarding work environment. Through that, building a cohesive historical narrative that can act in defense of my teammates when shifting goals make engineering look like it failed and giving a concrete foundation for process improvement.

That was so great. I've been journaling for a while now but can't seem to leverage it as much as you have.

I'm especially curious about how it helps you anticipate risks. If you have a way to illustrate this I'd most appreciate it.

I wish I had done something like this. Some of the insane days where you are being pulled in every direction can feel so scattered that they become impossible to recall even a week later.

Hopefully the parent comment here will stay near the top, it is the key thing to keep in mind, the rewards are different.

As a line manager (you manage people doing the work) your #1 goal is to have your team be super good at what they do. That means developing peoples skills in their technical specialty, their ability to understand direction and act on it, their ability to communicate where they are with the rest of the team. You need to learn to recognize when team members are being counter productive (passive aggressive, competing to win), and when they are being under productive (not challenging their own self perceived limitations). You want to average out those behaviors so that your team trusts in the skills of the other members, trust in your willingness and ability to deal with problems, and trust that you will recognize the effort they are putting in to make things work.

> and when they are being under productive (not challenging their own self perceived limitations)

I'm a fairly new manager and I'm working really hard on how to word something like this to my devs. Do you have any advice for that?

Be honest with them, and MUCH more important: Be kind, when discussing this. Something along the lines of 'Hey, I realized that something seems to be off since a while, is there anything I can help or change, because I really want you to be happy and productive' works best for me.

Pretty much everyone wants to be recognized, happy and productive in their lives, and this usually extends in their jobs, so most likely, that person needs help, to recognize or solve the situation.

Sometimes, they just dread for whatever reason the task they have ahead of them, and need someone to talk to. Sometimes it is some time to solve a challenge in their live outside of work - then it might be your job to shield that person to some extent, while also making sure this does not take a toll on your remaining team. Sometimes it is a social problem in your team. Sometimes the assignments for that person dont match what they can and want to do. And of course, sometimes the team, the job, or the company is just no fit, and it is perfectly fine to help there as well.

But again, above all: When talking about this, when trying to help, keep in mind that you are the manager, which always implies a power imbalance, no matter what. Such can easily be perceived as a threat instead of help, and if it is perceived like that, you will make the situation just worse. So be kind, listen, try to coach and help, even if your inner self is annoyed with this. It rarely helps to play the testosterone driven top-down approach, unless, of course, you tried the other ways before with no success.

It is something you have to develop an intuition for.

There are two very different areas that you might find yourself in with performance management, employees that slow down, and ones that never speed up.

The first is an employee who was getting lots done and always could be counted on that becomes slower and less reliable. If you have developed trust with your employees then they will be more likely to share with you something going on that has changed or otherwise effected their work effectiveness. I have experienced situations where spouses have become quite ill and needed more attention, and people who have had their teenage kids take a hard turn down an unproductive, if not destructive path. If it is situational then you work with your employee to rebalance their needs, they may need to take some time off to find a new equilibrium or get things into a new normal. Give them the space, and let them find their new groove. If on the other hand it isn't a situational thing, perhaps they just don't like what they are doing any more or, as one of my reports discovered, they like doing something else better (in this case music), the right thing to do is to help them move on to that new activity. That can be really hard if they are hoping the can work part time on a full time salary while pursuing this new passion of theirs, at the end of the day you need people who are as committed to working for you as you are in managing them to be successful in their job.

The other situation is someone who is exhibits potential but keeps holding themselves back. Intel used "managing by objectives" and their mantra was if you met all of your objectives you probably had not set a high enough bar. The tool here is to talk with them about what needs to be done and when, push them out of their comfort zone, and then watch closely how that works out. Keep in mind that the goal isn't to get someone to work 60 hrs a week (this will burn them out), the goal is to work with them so that they can make as much of the time at work productive. I really only have seen this reliably in new college graduates. They have study skills but not "design" skills.

A session might be like this; Start by giving them a task and a deadline, ask them to identify as many different series of steps (plans) that they think will get them from today to done. Then ask them how they might recognize that a plan isn't working. Once they have that in their head they can go forward on the chosen route, and ideally let you know if they discover it was a dead end. If it was, talk about how it ended up becoming blocked and think about some ways you might test at the beginning if that was going to be the case. All of this hand holding at first is to train someone to think about solving problems where there isn't a "known solution" sitting in some grading manual somewhere. Engineers need to develop an intuition about the "design space" things can be pushed and things that can't, and how those freedoms or constraints are going to make it easier or harder to get done what they need to get done. These are the kinds of things you will end up talking with them about in your 1:1's.

Always remember, that because we're talking about people here and not machines, they all respond a bit differently, have different reasons for being there, and different definitions of success or failure. Your job as their manager is to translate things the company needs to get done, into requests that your team can deliver.

And this trend continues. The further you get from development, the vaguer the terms are and the longer and more imprecise the feedback loops. (In fact, I'd argue your job consists of creating useful and lightweight feedback loops)

This can be quite frustrating if you're not prepared for it.

I keep returning to dev projects exactly for this.

To the OP, do not underestimate this.

Yep, I definitely remember this. If you're a developer, the feedback loop is immediate -- you ship a bugfix or new feature and it works or it doesn't.

When you're in management, your successes and failures become a bit murkier, or the feedback is heavily delayed. You sort of need to learn to become highly self-critical and introspective about your choices and learn from the moves you make, both good and bad.

I want to go back. I'm not enjoying the change (or at least my company's implementation of management). It's not even that the feedback loop's length is different, it's just that there isn't any. If my team performs better, the expectations are just upped and we're still "needing improvement". Other managers here have said the same thing.

I feel like I am not a leader; I am not positively impacting people's careers or lives. I feel like I'm asking people to update their tickets and telling PMs we "can't just" add something else.

I'm not happy, and I'm getting to the point at the job where when I wake up, I linger in bed for a bit, thinking/negotiating on whether I should go in.

You don’t happen to work for a digital agency by any chance? I’ve seen multiple agencies botch implementing “management” after growing and needing to shift from a flat structure

No, I work at a product company in the video games space.

One thing you can do that's useful is making sure you can still compile and run the code. The occasional minor off-critical-path edit could also be enough to give you that hit you need as a developer.

I used to make a point of submitting a minor contribution to every project's code. I used to (part jokingly) liken it to Alfred Hitchock making a cameo in most of his own films. The stated reason was to make sure I had the dev tools and env set up so if there was ever an emergency I'd be all ready to help out, and the unspoken reason was to help gain the confidence of the team. I think it was a good idea, but unfortunately the approach doesn't scale to work across large numbers of projects.

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).

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.

It's a double-edge sword. Inherent hierarchies develop, but without being stated and defined, political types are less able to fully exploit them. But when they do, it's less obvious to the non-political types.

I think you're right, and so do a lot of other people.

https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...

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.

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.

Wasn't Valve who had a record of flat organizations? Their employee book leaked/was published and sounds good or perhaps work for them...

Leadership: doing the right thing

Management: doing things right

Peter Drucker

Another way of putting this is that leaders determine the best destination and managers determine the best route there.

Sounds like (from my non-military perspective) the difference between officers and sergeants.

Leaders are declarative and managers are procedural?

Agreed. Redefining the word "manager" to mean "degenerate leader" seems awfully short-sighted.

You manage systems, you lead people.

Steven Covey

One metric I've found true about recognizing leadership is that a leader is someone you would follow. It seems trite but the thing to recognize is it's a property not defined by some quality of the leader but by all of the followers.

At first I thought that you were talking about the people management track vs technical leadership track. I guess "management" and "leadership" are overloaded terms.

> Never vent to your team or other teams.

Could you elaborate on this, why not ?

It colors the team member's view of other people or other teams, whoever is being vented about. It's contagious and establishes a culture of complaining. It gives those vented to the notion that you might vent to others about them, which you probably do.

I have seen this take over many teams and it always starts from the top of the team.

Totally this.

I'd also add that venting to the team makes the team nervous, if you are saying X to them, what aren't you saying. Your job isn't to deceive the team, in fact if things are going bad you should be honest but show a path forward. Lying will cause people to lose their respect for you and hence stop following your lead. So you have to be honest, be humble but show the path forward to the team. And it is ok to not have a path at first, just be up front and give some options so they don't think things are at a loss.

Not OP, but direct management venting to the team can have a really negative impact on morale, motivation, and inter-team relationships.

Managers who have a tendency toward complaining and negativity can really hurt a team.

Fantastic comment, wish I could up vote it multiple times.

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.

"- 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."

Early in my career I read that X (almost) __always__ takes twice as long and cost twice as much as you typically estimate.

I can't count the number of times that's been true. It's also universally true. e.g. Wanna hang a picture. Piece of cake, right? Until you have to find the stud. Likely get a tape measure to get the height right, etc.

Perhaps an over-implied example, but once you start to keep track in your head of your estimate vs actual, the 2x Rule pans out quite a bit.

That sounds like a good example when getting pushback on estimates: "Here's a 24x36 picture in a wooden frame, how long will it take you to hang it on that wall over there?"

After getting an estimate ("15 minutes?") come back with "OK, let's plan it out. Does the picture have hanging hardware on the back or are you going to need to get some screw eyes and wire and install some? That's a pretty heavy frame, do you have good enough wall anchors? Are you going to need to drill to put them in? Do you need to be going into studs, and do you have a stud finder? How high are we going to put this? What if I decide I want it 4 inches higher? If I come back in 15 minutes and ask why it's not up are you going to want to punch me?"

"That's why an off-the-cuff estimate isn't reliable and why we need to do some review before giving a good one. Even with that review, there's a good chance we're going to miss something at first (like the steel support beam that runs down the interior of that wall)."

See also Yak Shaving and the intro of Malcolm in the Middle Season 3 Episode 6 "Health Scare"

My suggestion is when asked off the cuff always toss an estimate that is astronomically bigger then what you expect it to be. Then come back a day or 2 later and claim after further research we can do it in (2x your real estimate).

Agree. __Always__ start high and then you've "reserved the right" to adjust down. Else, most people will think you're trying to rip them off.

One of my TODOs for 2019 is to come up with a checklist (for building websites / basic web-based applications). There's no sense assuming the client is thinking of all the things I'm thinking of, and vice versa.

The little things always add up. For example, does the client expect 1 hour or 3 hours of edu on using the CMS?

Great answer. I transitioned to a lead role recently, on a small but growing engineering team. Agree about being conservative on estimates, trading off code quality. I did jump in and code during a stressful situation, not ideal. Any tips about how to report to higher management? And how to tell if things are going well/bad on the team, esp in a startup?

This is hard... like your directs you need to manage your manager as well and try to understand them.

For your manager, you should have (or try to force) at least meetings every 2-4 weeks where you can ask what you can improve on or what they feel is missing/lacking in your team/department. Always come back next meeting with ways you have improved or reacted to their comments. If they are a decent boss they will always be honest with you.

As for how to tell if things are going well internally...

- does your team(s) feel happy/proud on what they delivered? - does your team(s) seem happy and enjoy working with each other? - do they focus on deliverables/value and not get caught up on petty issues?

are some questions to ask.

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.

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.

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.

I was recently recommended a couple books called "Extreme Ownership" and "The Dichotomy of Leadership". They tackle the idea of how to be a leader and what that means in the day to day.

They break down the communication with your team into a principle you want to strive for. Then you're shown an example of how that happens in the real world.

Once you've seen the patterns, you notice them everywhere, and you begin to unravel the issues, one hurdle at a time. It's like seeing a great design pattern, seeing where it fits and how to apply it, except now you're doing it with communication instead of code.

I think this might help you "find a mechanic you can trust" and get to the heart of what it takes to lead your team.

That is a fair criticism, my tips were just a list of the top notes I could think of to help. I could dive extensively into each and every bullet.

I will say if you constantly questioning whether you are doing a good job and if you can do better... you are probably above average at least.

A struggle I've had is I'm used to casing performance in terms of errors or negative feedback. So far the feedback I've had is almost all positive (team is far above previous performance, flight risk is far lower than other departments, etc) but I don't feel like that's helping me improve cuz I don't know how to actually deal with positive feedback.

Some personal introspective criticism I've been wrestling with.

How do you define 'toxic'? How often do you fire workers for being 'toxic'?

Toxic examples:

- "This is stupid" or other negative comments in code reviews (aka non-constructive criticism)

- Yelling or cursing at people because they question you and your decisions.

- talking bad about the company or other teammates to people behind their back.

- throwing a "temper tantrum" when you don't get your way when it comes to some architectural decision.

- refusing to work with certain people or only willing to work with certain people.

- Making large-scale decisions and changes without documentation, discussion, and buy-in from engineering leadership and your peers.

I agree with these points, however some level of quirkiness is defined as a hallmark of very effective workers here [1] I wonder if it might be possible to misconstrue behavior and label off such an individual as toxic.

[1] https://www.inc.com/jeff-haden/8-signs-an-employee-is-except...

Thanks for the answer. I hope all firms have a formal HR process where they state expectations and confront the individual before he is labelled as toxic. I think everyone should have a chance!

Well, for truly toxic individuals, warnings or confrontations are useless (I’ve learned this the hard way, and not for lack of trying). It is impossible to get them to understand that they have a problem; anything you say, no matter how clearly articulated, fact-based, and objective, will be rationalized away. These individuals cannot accept that they may be wrong.

Since no one else has answered this I, a lowly developer IC, will give it a shot.

Start by writing up a detailed employee handbook and code of conduct. Have a conversation with new reports about how these inevitably jargon-laden documents translate to expectations in human terms. You don't need to use the word "toxic", but talk about assuming good intent, communicating respectfully and clearly with others, and sharing credit and responsibility with teammates.

Create a sense that serious feedback about teammates' behavior given to you, the manager, about teammates' behavior will be taken seriously and kept confidential. Do this by handling the smaller stuff competently.

Give feedback to employees who are creating bad team dynamics early and often. Allow them opportunities to reflect and improve. Emphasize if necessary that their behavior is not just problematic at an interpersonal level, but it's (presumably) disrupting the company at a business level as well.

Work with HR to keep a paper trail and document conversations so that when the time comes to fire an employee who is irredeemably "toxic", there is a rich timeline of unpleasant behavior, feedback and warnings, and a failure to sufficiently improve over time. Ideally only someone with their head all the way up their ass wouldn't see how the patterns of behavior relate to documented expectations and to termination, but unfortunately that's who you're dealing with.

I suppose all of this only works to immunize against "toxicity" in a work environment that isn't already toxic.

I think these are very good ideas, actually I don't recall to have seen an employee handbook that states expectations explicitly, even while working for very big firms. Well, at IBM they probably have something like that, I may be wrong about that.

There is a quote I once heard “Good teams are usually great for the same reasons, bad teams are almost always bad for different reasons”. This is the much the same for people. Generally speaking, the best people you have worked with are very similar in terms of what they provided that made you really happy to be with them. Example “good” traits:

- honestly - dependability - integrity - intelligence - humility - excellence - generosity - proactivity

Toxicity happens when people exhibit the opposite of any of those. A favorite example is folks who constantly bad mouth other people on the team. Well, if you work with that person, you just know they are complaining about you behind your back as well.

I think that quote comes from Tolstoy when he was writing about families in Anna Karenina. " All happy families are alike; each unhappy family is unhappy in its own way"

I am not sure he was right here, different people may have different ideas of happiness.

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.

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.

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.

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/

Thank you for the insights!

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

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.

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

And if you want to peak at how other managers manage check this out: https://hackernoon.com/12-manager-readmes-from-silicon-valle...

Or check out this podcast on the topic: https://anchor.fm/soapbox/episodes/6-Melissa-and-Johnathan-N...

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.

Camille’s book is great.

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.

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

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.

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.

I will second the podcast recommendation. I listened to it religiously when I first started in management and I continued its suggestions with modification until I went back to development. It was a great crutch to lean on until I got my bearings:

https://www.manager-tools.com/

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.

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.)

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.

Welcome to managing a team of eight people.

Even if it takes 50% of your time, this is like coding for a dev - it's your primary job and you can't skip it. Andy Grove had a rule of thumb on how much time to spend on what in his book High Output Management. Summary here: https://getlighthouse.com/blog/high-output-management/

More than that when you consider the To Dos and followups. That’s why it’s hard to stay active as an individual contributor when you have a large team.

If you don’t invest the time in advance, you pay it more with fighting fires later.

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.

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... 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.

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

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

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-...

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.

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.

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.

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.

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.

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.

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'.

I agree. You have to be prone to optimize for others, rather than yourself. Also if you have the ability of good judgement, others will come to you for advice, somehow pushing you up.

I remember that in one of those "How to start and start up" videos, the presenter (CEO of an startup, do not remember which) was asked "How do find your generals in your team?".

His answer was something like "You look at the room and they are often surrounded by people at their place who came for advice".

I would also add (maybe this is #3+#4): networking is important and might come harder to some developers stuck in their own world.

Understand the needs and goals of your manager peers / team members / boss (360 degrees) so that you can come to mutually beneficial [financial] decisions.

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.

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.

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.

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.

So let's say you have 5 product managers, 5 project managers, 5 architects. Do you think they should all report directly to the CEO? Or should they report to a... Manager?

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.

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.

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.

Is this some management 101 "best practice"? My manager does this and it is annoying. Facial expressions are an important part of communication and acting like an emotionless robot does not help in times of need.

Not to be an emotionless robot, that is bad, and I really hate that too. I mean more in the communicate what you want not what you don't want. Friendly, confident, happy are good; angry, surprised, despair are not so good.

You are correct that its communication, just don't say stupid things with your face.

Rabbi Hillel famously is quoted as saying "Don't say anything that ought not be heard -- not even in the strictest confidence -- for ultimately it will be heard." This is one of the ways that it will be heard, heh.

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)

* 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/...

[2] https://www.amazon.com/Challenges-Managers-Face-Step-Step/dp...

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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...

+100 on that book.

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...

In short, I would recommend subscribing to http://randsinrepose.com and 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.

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....

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.

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.

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.

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.

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.

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...

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 :)

I keep a list of all the resources that have inspired and helped me here: 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.

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

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.

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.

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!!

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.

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

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...

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.

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.

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.

Read this: https://www.ribbonfarm.com/the-gervais-principle/

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.

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...

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.

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.

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

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

+ Yes, I suggest reading his book 5 times:

[0] https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...

I interviewed Michael Lopp a few months ago. You can watch it here. https://www.crowdcast.io/e/michael-lopp-engineering-culture

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.

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

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 )

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...

Take a look at 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.

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.

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.

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.

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

Science says: https://www.sciencedaily.com/releases/2018/12/181203150505.h...

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.

A short but interesting post on becoming a manager in engineering

https://zef.me/so-you-want-to-be-an-engineering-manager-bcdd...

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.

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

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.

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.

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?

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!

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

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.

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/

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

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.

As I see management

Developer -> do work

Manager -> help others do work

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

Here is the main thing you need to know:

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

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

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

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/...

* 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...

* How to Win Friends & Influence People: Dale Carnegie: 8937485909400: Amazon.com: Books || https://www.amazon.com/How-Win-Friends-Influence-People/dp/0...

A few articles I've written on this topic:

1. https://hackernoon.com/the-wrong-section-of-the-bookstore-96...

2. https://hackernoon.com/the-real-work-of-software-management-...

3. https://hackernoon.com/i-started-wondering-if-being-a-team-l...

4. https://hackernoon.com/joyful-technical-leadership-6f4fb8bd7...

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://en.wikipedia.org/wiki/Triarchy_%28theory%29

Shameless plug -> https://www.linkedin.com/pulse/moving-management-mahesh-guru... . 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.

Reply on news.ycombinator.com