
Ask HN: How to transition from worker to manager? - thestepafter
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&#x27;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&#x27;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&#x27;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.<p>What advice do you have or resources would you recommend so I can succeed in this new role as developer turned manager?<p>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.
======
jpeg_hero
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.

~~~
hga
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](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](https://en.wikipedia.org/wiki/Mission-type_tactics)

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

------
rbrcurtis
Read this: [https://www.nczonline.net/blog/2013/10/15/the-best-career-
ad...](https://www.nczonline.net/blog/2013/10/15/the-best-career-advice-ive-
received/)

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.

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

------
michaelhoney
I strongly recommend you join the Rands leadership Slack:
[http://randsinrepose.com/welcome-to-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.

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

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

\- What do technical managers do, anyway?

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

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

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

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

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

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

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

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

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

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

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

