Hacker News new | comments | show | ask | jobs | submit login
Ask HN: How to transition from worker to manager?
34 points by thestepafter on Nov 29, 2016 | hide | past | web | favorite | 17 comments
I have been working for the same company for over 10 years now. I have moved up from a support role to developer role and now into a manager role. I'm having a hard time with the manager role transition as I enjoy getting my hands dirty and diving in to solve problems. I don't have enough time to dive in though because I am in too many meetings. I have some really great people working for me but I'm struggling with delegating work, knowing how much information to provide, how much to expect, etc. I consistantly have an internal battle with doing the work myself instead of taking the time to explain and ask someone else to do it. I also have a vast amount of knowledge about the company and I need to convey that somehow so others can do their job and not rely on me.

What advice do you have or resources would you recommend so I can succeed in this new role as developer turned manager?

Please note that I am getting older so I do want to move into a management role. I am just having trouble with the transition.

Yep, you just identified the whole trick.

Takes awhile to get a hang of it. You've already picked up on a couple of the harder challenges, and are aware of your own short comings in these regards: that puts you ahead of 80% of managers! Now try every day to get better. Buy some books, read some websites, and now you are on the manager journey.

Best managers I know, find talent and grow it. So delegate, train, motivate. Strait shooting is better then being passive aggressive or allowing people to fail. Feels worse up front sometimes, but better for all concerned. Can't tell you how many times I've had a dialog in my own head about an under performing employee then eventually confronted them and they said "Oh, that's what you want me to do, sure." And then, by god, they went and did it. Be repetitive. Be helpful to others in the org. Margret Thatcher famously said "Everybody brings me problems, he brings me solutions." Be that guy. .... point is there is a million things like this shit.

Indeed, I can't disagree with anything you say.

But here's something that instead of entirely delegating, that at least for me is "hands on work": teaching (note also huddo121's recommendation that your formally codify your knowledge: https://news.ycombinator.com/item?id=13061109). In fact, I'd say that one of the single most useful things I learned in high schoool, was JROTC's section on teaching, the Army and military in general of course are constantly teaching people things, heck, not all that long after my father got posted to a radar picket ship in the North Atlantic in the mid-50s, he became the junior officer who broke in brand new officers (he was Grand Lakes enlisted->OCS/only in for 4 years; I would have gone SROTC if not for my eyesight). And perhaps I picked up something of how to teach from his deliberate teaching of me and my siblings of how to hunt, fish, shoot and drive.

So look for some opportunities to mentor your more junior developers, and in terms of delegating, look for opportunities there as well. This can be fantastically rewarding, a win-win-win for you, the mentee, and the company, one of my "mentees" remains to this day one of my best friends.

Note also the knowledge transfer can go both ways, in that above case, I was learning C++ for the project, which he helped, and I helped him drop down to C, he'd only done C++ in college, so like the first thing I taught him was C's new is malloc ^_^.

One other thing to try, perhaps, although I've never been a manager position where all my time could be spent on managing, is to make a very specific segregated task that you'll spend a very finite time "hands on" doing, and don't pull rank when you come into conflict with your subordinates as you're acting as one of their peers.

I'd almost certainly put doing that off for some number of months to a year or so, take in your mind an official vacation from "getting your hands dirty" unless faced with an existential threat, and just focus on the managing.

Other things, especially from the military viewpoint: make it your job to keep your "troops" well fed, healthy, protected from your sub-par superiors, etc. Maybe even explcitly look into the officer/non-commissioned officer/grunt distinctions, they provide a model of something that works, albeit imperfectly as all things human, and in our world of high tech you definitely have to avoid certain forms of that. I.e. D-Day no, mission-type tactics perhaps: https://en.wikipedia.org/wiki/Mission-type_tactics

I would start by kicking off the process of codifying your knowledge. I've used confluence for this, and it's a real art to sit down and work out how to structure your information, the level of detail required, and what should be documented in the first place. I've found that the people I've worked with the went from a technical to managerial role were mostly relied on for that vast technical and organisational knowledge that they had built up over the years.

I'm not sure if you're managing a project, product or divisional team structure, but I would say that no matter what level you're attempting to manage, set some sort of vision for your team to align themselves with. This can cover things such as technical aspirations, or organisational strategic goals.

Trust your team. It doesn't sound like there is any mistrust in your team, but I understand the difficulty in getting over that initial knowledge hump when introducing people to a new domain, especially as an "expert" in the area. Documenting knowledge in clear and concise ways, and making different members of your team experts in certain areas of your knowledge will help them to become more self-sufficient in their quest for knowledge and answers. Consider this an investment.

As a general piece of advice, not aimed at any particular part of your post, you were in the same position as your team members are now not long ago, think about the pain points you had and try to learn from them.

Read this: https://www.nczonline.net/blog/2013/10/15/the-best-career-ad...

I took to heart one sentence from this blog post in particular: "I made sure I only went to meetings that needed me to participate and then I would participate." IE, if you aren't useful to the meeting in a major way, then don't go. That will likely free you up for other things.

Here's a perspective from having progressed into management from technical roles, managing engineers and now back to doing engineering.

My employees used to call me 'meeting attender' since that was what they saw me do day-to-day. That was a big part of it - attending meetings with other teams, departments, etc. that want work done. Then prioritizing that work, and figuring out who on the team can get it done. Distilling large bodies of work into smaller chunks is key, but leave room for implementation details to be decided by your team.

The delegation aspect is most important when transitioning. Setup a feedback loop after assigning work that is short enough to make sure an employee is on the path towards completion but not too short that you are micro-managing. Get out of their way and let them do work.

Your best bet for staying hands on is to pick tasks nobody wants to do that are not on a critical timeline (probably the opposite of what you are thinking right now). Your role's primary contribution is organizing and managing work, building relationships with other teams and your customers (internal or otherwise).

Managing engineers is a different job than engineering. Once you get a handle on delegation, coaching your team comes into play (which helps with delegation later).

I strongly recommend you join the Rands leadership Slack: http://randsinrepose.com/welcome-to-rands-leadership-slack/ where you'll find (and hopefully contribute to) a motherlode of goodness and peer advice.

This question comes up fairly regularly on HN. Here are a couple of old discussions that have some interesting perspectives:

- What are common mistakes that new or inexperienced managers make?


- What do technical managers do, anyway?


Here's a comment I made a few years ago in the "common mistakes" thread, which I still think is true:


One rule to remember is that your time is more valuable than any of the people working for you. So any task that you are doing that could be done by someone in your team should be delegated to the team. Spend your time doing what only you can do. Such as setting priorities, making big calls on the technology for future projects and so forth.

I would also recommend that meeting your team members once per week is about right. More than that and your starting to micro manage and you remember as an engineer how annoying that is. More than a week and things can go too far off track before you can pull it back into line again.

> One rule to remember is that your time is more valuable than any of the people working for you.

If that is the case where you work it should be the first item on your agenda to change.

Otherwise your best tech people just become managers which is pretty much the last thing you want to encourage.

Making key tech choices is also not the domain of management.

So I guess my advice is work out what is expected of you as a "manager". At some companies this can be a fairly random combination of tech leadership, architecture, project management, and people management. In others these are all seperate roles.

In a lot technolgy companies. Programmers can earn a lot more than managers.

wat... "your time is more valuable than any of the people".. i couldn't disagree with this more... but the concept of using time where best placed I agree with.

From a simple dollars and cents POV, the manager usually makes more money than any of their workers.

I've seen many senior engineers earn more than their manager.. especially with geo-separated teams. I don't think the pay argument holds true...but 'do your job' is a better argument.

The statement is an issue with me, it implies that managers are not workers themselves.

Further, becoming a manager just because of age is the wrong approach. There is nothing wrong with being a senior engineer (in both age and experience!).

However, i'd thoroughly recommend reading up about servitude management. That is where the raison d'ĂȘtre for management is to enable engineers to be able to do their job. I really respect that model.

I highly recommend taking courses at Harrison Metal. The general management class is 3 days from 10-2pm and they have great electives as well.

I spent some number of years as a consultant helping startup founders do exactly that, and would be happy to chat directly about your situation -- email is in the profile if you're interested.

In terms of general must-have knowledge, I recommend reading "Drive" by Dan Pink, "Tribal Leadership" by Dave Logan, and "How To Make Sense Of Any Mess" by Abby Covert.

You are identifying and acknowledging some limitations, which as others have said, is a great first step. I have also followed a similar path to you, and moved into a management role a while back. I've put together a few thoughts and my attempts at keeping this comment short hasn't been successful, nevertheless, I hope it helps you in some way.

One of the things that helped me greatly was recalling behaviours of managers that I thought highly of and emulating them, as well as thinking about poor management practices I have been on the receiving end of and making sure that it doesn't happen again. The idea of this exercise is for you to have a clear vision of who you want to be as a manager. This can be as shallow as how you want to be perceived, or go as deep as how you want to act every day.

Once you understand the type of manager you want to be, you can now decide how you want to evolve that idea of yourself based on your experiences and everything you learn. How you communicate your growth as a manager is also something that you should consider. I have worked with management lecturers that advocated authentic leadership, and it is something I try to live by.

Being an authentic leader for me meant being honest with my team when I don't know something, when I'm wrong, and when I'm making a serious attempt to change how I operate as a manager. As an additional consideration though, I manager I respect gave me the advise that such actions can be seen as weakness by other managers and used against me; I made a conscious decision to continue the practice, but you need to decide whether your environment will be receptive to how you want to operate.

This leads to one of the first points you raised, where you wrote "I'm having a hard time with the manager role transition as I enjoy getting my hands dirty and diving in to solve problems." I think it's important to understand that as a manager, you no longer have a single responsibility/obligation to the manager you are reporting to. As a manager your dual responsibilities are to ensure your team are working optimally whilst making sure your manager and the greater organisation know about it. I cannot stress enough that this is more than a full time job.

What changed my perspective about meetings is the following thought - do I want my most productive team members to be in meetings, or do I want to be the filter that ensures only the most useful information goes through. Being a filter can take many forms. It may mean sitting in on exploratory meetings to determine how serious the organisation is about a new task/project, and throwing in a business analyst to further test the waters. Or it may mean immediately pulling your top engineer of their current task to help the company with an incident.

In regards to your comment about "knowing how much information to provide, how much to expect", I think it's best to discuss this with your team. I tend to have a general rule that if I can't imagine myself developing a solution based on the knowledge I have about the problem, then I need to continue dialogue with stakeholders before shifting the focus of my team. Although as you mentioned, being hands-off means you become detached to the realities (read challenges) of implementing working solutions in your environment. This is why I would recommend identifying a technical lead that is basically your 2IC and someone that keeps you technically grounded.

To shorten this comment, I will just conclude by saying that my view of management is that you can still play either a developer, or administrator role, but the system you are working on is the system of organisation that makes up your company, rather than code and servers. As a developer it means you are constantly looking for ways to improve products, ensuring people with the right skills are being utilised or promoted so that they can contribute towards outcomes that benefit all. As an administrator, your role will be to ensure business continuity, by ensuring knowledge is passed on and successions can occur with minimal disruption. All principles that apply to building and maintaining scalable systems all apply to your company, such as redundancy, reliability, efficiency, etc.

My final bit of advice is that you should be honest with yourself about whether the role is right for you. I've seen some people take to management like a new lease on life, while myself I have gone back to a development role with desires of being no more than technical lead or a technical founder, which is a completely different goal altogether.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact