Live data from Hacker News

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

news.ycombinator.com

151–160 of 186 posts

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

#151

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 un…

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 wonde…

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.

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

#152

Earlier quoted context omitted.

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

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

#153

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 un…

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.

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

#154

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…

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.

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.

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

#155
post #95

Earlier quoted context omitted.

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…

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

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.

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

#156
post #56

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 st…

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?

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

#157
post #48

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 im…

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.

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

#158
post #48

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 im…

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 s…

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.

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

#159
post #114

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 de…

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.

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

#160
post #141

Earlier quoted context omitted.

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

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 sharin…

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.
Post reply on HN