
Ask HN: Developers who became engineering managers, how was the experience? - 6ak74rfy
How was the new role challenging? What skill-sets from earlier were important in the transition?
======
yawz
I've been in software development for more than 20 years. Here are my 2 cents:

\- Training, training, training! Without exception, all the technical managers
that I've worked with had arrived where they were at based on technical
merits. However, being a manager, especially being a leader have nothing to do
with technical knowledge. Therefore _management and leadership training_ is a
must. This doesn't necessarily need to be an organized class, but being
coached and mentored would be an amazing start.

\- Management and Leadership are different skills. This goes back to my #1.
One needs to develop both.

\- Ideally, you become a servant of the team. You're there to help them become
highly productive. Your first job is not to solve the technical problems
yourself, not to micromanage everyone, not to command and control. You're
there to create a self-managing team that can, ironically, work without a
manager.

\- You are there to ensure that their motivation and engagement are at a high
level. One can be motivated by not engaged. You need to know the differences
and the ways to increase them.

\- You need empathy to become a good leader.

\- You need to be a good communicator. And transparency is a great tool.

\- You have to ensure that your team members become good enough to be able to
leave your company and find plenty of jobs anywhere else, but also ensure that
they wouldn't want to leave.

~~~
mceachen
I bet you read "Training, training training" and thought "yeah, but I'm pretty
good. I'll skip that bit."

Do not underestimate the differences between being an effective individual
contributor and an effective engineering manager.

A lot of the concepts a good manager is driven by are counter-intuitive. For
example, technical "leadership" as a manager can be repellant, especially to
the more senior of your team, and interpreted as evidence of lack of trust.

The political environment of the company will also dictate your success. Half
your job is to be the team coach/servant. The other half is making sure the
rest of the company understands that what your team is doing is high-value
(and making sure that actually is true).

The OP asked "what skill-sets from earlier were important in the transition."
Surprisingly little. One of the team's biggest jobs (which you should try to
delegate, by the way), is breaking down a problem into smaller, doable chunks.
You'll have done this on smaller scales as a coder, and finding reasonable
separations of concern can make or break projects. At the same time, you
shouldn't be doing all this work yourself. The more responsibility (not just
tasks, but decision-making) you can delegate to your team, the more they will
own their work and feel responsible for their own success.

These are very different jobs, but training and spending time in those roles
can help you on both sides.

------
elcapitan
I'm in a role as manager/lead dev, so it's kind of mixed. The transition to
the managerial part was pretty rough back then and I wished I had gotten more
support, many companies don't know how to do that well.

With a developer mindset, what helped me was this (no particular order)

* Go about it as a problem solving task. This can be as complex and fun as building a new system - you are building organization and culture. The way you treat them will mirror in how they treat each other and your customers.

* Don't assume too much what a manager should do or what you have seen, but see your new job as an enabler of other people and find out what the particular needs there are. You're the user interface for other people to get things done in the company.

* The hardest thing is probably to stop solving implementation problems yourself. That's again an enabling position. All the stuff you were the expert in before you now need to transfer to other people. Don't just quickly solve their new problems because you know it better.

* One thing about micromanagement - If there's something that appears to be micromanagement, it's often a problem of too little actual management and not enough. That sounds weird, but the reason is that management interferes with people's work directly, where they actually should have given them the tools and the knowledge to do it themselves. So when you start hearing or sensing that notion, don't stop managing, but try to find out where you really need to help.

~~~
ddebernardy
Good tips. A few more:

* Resist all tasks that you and your team can't figure out next step for. (They're not actionable.)

* Find the maximum task length you're comfortable with doing yourself; try to delegate anything that you expect will take you longer. Keep this number very low (e.g. 15 min or 5 min).

* To balance the latter, find the maximum hours you're comfortable with having someone else do work you'd do in an hour. Keep this number high (e.g. 8 hours or 20 hours), and step in to do things yourself only when delegating will make you over it.

(Edit: Also, there are good lessons learned from the past; don't forget to
read books books, like PeopleWare.)

~~~
mikehollinger
Go have a listen to this excellent podcast on delegation [1] from Manager
Tools. They hit the same notes you’re hitting, but provide some additional
actionable tips and tricks for figuring out when things are going well, about
to go wrong, or going wrong.

[1] [https://www.manager-tools.com/2005/08/the-art-of-
delegation](https://www.manager-tools.com/2005/08/the-art-of-delegation)

~~~
tome
This is a great episode about their "balls in boxes" model of delegation. If
you delegate it's probably worth your while to listen to it. If you are
delegated _to_ then it's probably also worth your while!

------
mikehollinger
I’m a senior technical staff member on my team. This means that I occasionally
get to write code, spend lots of time debugging integration problems, and (as
I see it) matching up people and problems that come in to the team. I don’t
have direct reports, but I provide feedback to managers, am a team member,
lead my own team, and lead / mentor team leaders of other teams.

Delegation and Motivation are most difficult by far. I can think of several
occasions where I’ve said or done something the wrong way, causing friction,
heartache and strife. I’be gotten better at recognizing different
communication styles and matching the message to the recipient however.

Soft skills are key. Go look at Manager Tools[1], a podcast focused on
improving the quality of management in the workforce. Every podcast they’ve
ever produced is online, going back to 2005, and covers all of the unspoken
stuff like how to communicate effectively, how to have good 1:1’s, how to give
feedback, how to handle “steel cage death match” meetings, and even how to
handle personal scent issues.

They organize the podcasts into a “map of the universe” and also have a “hall
of fame.”

I’d say start with the map of the universe (it has a “start here” which covers
a couple of foundational topics, like I mentioned above. Once you’ve gotten a
feel for it, search around and find something relevant (eg performance reviews
might be a good idea given that we’re in q4).

[1] [https://www.manager-tools.com/map-of-the-universe](https://www.manager-
tools.com/map-of-the-universe)

------
ianhowson
Random thoughts:

* The priorities of developers are _very_ different from those of managers and the greater business. Your goal is to serve the business, but neglecting the needs of your developers has obvious long-term consequences.

* Politics, obviously. I didn't expect to spend my entire working week literally _arguing_ with people.

* Technical skills are still super important. It's not like you give up coding and just manage. You have to be able to do both.

* Buy a Bluetooth headset that you love. I have a Plantronics Voyager Edge. If you're going to spend hours on the phone each day, you might as well be able to type and walk around. (Remember to mute the mic when you flush the toilet.)

* Block out time in your calendar for 'getting work done' \-- focus time. Make yourself unavailable. One employer had single-person meeting rooms, which I loved -- I could be found if necessary, but was a lot less likely to be interrupted.

Being a manager for a while helped me to understand why my managers behaved
the way that they did, and helps me now (as an individual contributor) to
direct my managers to where I think I need to be.

I love the 'bigger picture' thinking, and I love designing larger systems with
others. Negotiating about subsystem boundaries and "whose job is it" is
challenging, but useful.

I'm happy to leave the fiddly details to others. This is possibly the hardest
thing to adapt to -- if other people are coding on your project, they're going
to do things the way that they want to. It won't be the way that you want it,
and it'll frustrate everyone if you try to force them into doing it your way.
You just have to take that massive leap of faith that everything will be
alright.

You can never overcommunicate. Learn to love PowerPoint. Write a lot of
emails. Document _everything_ on your company wiki.

~~~
brabel
> You just have to take that massive leap of faith that everything will be
> alright.

To let your employees do their jobs is taking a massive leap of faith for you?
Looks like you should learn to trust them a little bit more. If they cannot be
trusted due to lack of competence, perhaps you should invest in training and a
better process.

~~~
volundr-
That's not really what he's saying. As a developer, it is up to you to make
things go. As a manager, your job is to support engineers and believe that
they will make things go.

That is indeed a leap, and a very different mindset.

------
ninegunpi
Answer from a different side of the fence:

As an executive who elected senior engineers into engineering managers three
time in different companies, there are three challenging areas for even the
most fit for the job engineers:

\- understanding that soft skills and understanding company politics now
matter not as much, but more than detailed technical skills. focusing on
eliminating weaknesses in this area is that pareto-ean 20% of effort that
makes the rest 10x easier. \- it's now about eliminating weaknesses, not
growing strengths: what you tolerate slows down and makes everything toxic,
while what you preach is a second-order problem for a while. it evens out, and
later on you can focus on growing strengths, but only after a while. \- you
own consistency of engineering culture, not your piece of code and
responsibility, now. which makes figuring out internal feeling of "I'm doing
it right" twice as hard.

~~~
wruza
I’ve read first two -points about four times, but still have no idea what
these are about (usual thing when talking to completely “other side of fence”
minded people). Can I ask for some examples in context?

~~~
ninegunpi
Sorry, English is not my primary language, so the grammar constructions might
get odd from time to time, this might have been the cause.

Point 1. Good engineer should know how to code, and how to cooperate with
fellow engineers well. This means healthy balance of "hard" (engineering) and
"soft" (communication) skills. When engineer becomes tech lead or engineering
manager, being able to communicate, understand other people's behavior, lead
them, communicate situation up and down the chain,- soft skills start to
matter way more. If there are serious skill gaps in soft skills (and all ex-
engineers have ones when they start to grow in this area), addressing them is
more important for engineering manager's career than addressing lack of up-to-
date-ness in latest technology.

Point 1, Example: when I first got to manage a small team, me not
understanding power distribution between younger and more experienced
engineers (I came from latter category) led to mass extinction of juniors: the
way important decisions were made (with more contribution from senior
engineers) was good for the company, but the way it was presented (We The
Elders Made Crucial Decision) pissed youngsters off, made them feel incapable
of making valuable contributions and they quickly left. After understanding
the reason (which took hours of mentoring from CTO, a very experienced
manager), I had to really work hard on creating the atmosphere where, even
when the decisions were made by seniors, the ownership and responsibility for
actual implementation of these decisions was distributed among the teams and
everybody could contribute to mutual success.

Point 2, with examples already: It kinda continues point 1, but bridges from
personal scale to team scale. Process is as good as it's bottleneck. Team is
as fast/writes as quality code, as it's weakest members. If you tolerate them,
they constrain the process. Your goal is to spot weaker people / weaker
engineering decisions and put reasonable amount of effort to either make them
better or make them live. As an engineering manager (e.g. manager that comes
from engineering, not from fancy MBA factory), you actually can tell the
slacker from person who wasn't properly integrated into the process. As an
engineering manager, you can tell that the decision to make blocking tests
stop CI on the first failure is a poor decision and having a proper failure
log of all tests is crucial for speed of bug fixes, not fixing them faster or
with better method. Basically you are responsible for the failure (even if
you're formally not), because you're the focal point of knowledge and power
that can prevent them, put slower people to speed, put processes to full
power.

~~~
wruza
Thanks for detailed explanation, it delivered a sense to me and is in great
touch with my own leading experience. I even stumbled on point 2, and it took
me a month to clearly understand that it’s better to let employee go. But
before that I made dead sure I’m objective and not elitist (evaluated task-
times, insighted into persons thoughts and knowledge, investigated virtually
everything I was aware of in situation). That was pretty stressful and
happened few weeks right after my assignment, but later I got few hints from
team members that it was an obvious thing to do.

------
betageek
I didn't like it, and after about a decade I went back to being a developer.

Management may suit you but, as mentioned elsewhere in this thread, even if
you're at a 'good' company you'll probably spend a lot of your time neck deep
in politics. For me this just wasn't enjoyable or fulfilling, I could do it,
my soft skills are ok, but it just wasn't for me. Arguing the toss with Sales
or other non-technical people for 40 hours a week was not how I wanted to
spend the rest of my working life.

Going back to being a dev was the best thing I ever did, I make the same money
as I made in management without the hassle. I still manage dev teams
sometimes, but make sure to keep away from the board room. I'm not ruling out
ever going back into management but it would have to be a team and an idea I
really cared about.

------
speedplane
As a developer, I found that much of the programming I was doing was not very
challenging or interesting. Hooking one API to another, optimizing some
database routines, converting data efficiently... It felt more like "building"
than "designing". Not sure it counts as pure management, but I've moved more
into product design roll that needs to understand the business, what can be
done in a given time, and set expectations. It's been far more challenging and
interesting to me.

It's not exactly management roll, and it still requires a degree of tech
skills, but it's another type of career move option you can make.

~~~
mi100hael
I think you could generally classify that sort of role as an "Architect,"
which is usually a senior/lead engineer who works directly with business
analysts/PMs to design the product and also "manage up" to set expectations
with the business.

------
j_s
Ask HN: Just made Director, now what? |
[https://news.ycombinator.com/item?id=14937290](https://news.ycombinator.com/item?id=14937290)
(Aug 2017, only 38 comments)

Book recommendations:

>gtf21: _Would recommend very highly: (1) Andrew Grove 's "High Output
Management"_ (controversial recommendation)
[https://amzn.com/dp/B015VACHOK/](https://amzn.com/dp/B015VACHOK/) $13.99
2015;4+stars;153 reviews

>killjoywashere: _I like Lazlo Bock 's book, Work Rules!_
[https://amzn.com/dp/B00MEMMVB8/](https://amzn.com/dp/B00MEMMVB8/) $16.99
2015;4+stars;295 reviews

>helper: _Maybe read "The Manager's Path" by Camille Fournier_.
[https://amzn.com/dp/B06XP3GJ7F/](https://amzn.com/dp/B06XP3GJ7F/) $16.19
2017;4+stars;30 reviews

>simonhamp: _I 'd highly recommend reading Radical Candor by Kim Scott._
[https://www.amazon.com/dp/B01KTIEFEE/](https://www.amazon.com/dp/B01KTIEFEE/)
$12.99 2017;4+stars;138 reviews

Podcast recomendation:

>gtf21: _Manager Tools "Basics" podcasts, especially on 1x1s and feedback_
[https://www.manager-tools.com/manager-tools-basics](https://www.manager-
tools.com/manager-tools-basics)

~~~
kal444
great list of books

------
latigidigital
The new role itself was not challenging, per se, except getting used to
approaching unrealistic demands by non-technical people who have a say in the
project. (There is a near constant influx of requests that are made without
appreciation for the difference between ones that take 60 minutes versus 600
hours, and explaining such things tactfully and in human terms is an important
highlight.)

That said, the thing I would personally place emphasis on is not letting
yourself fall behind in the development world, both because (1) it's easy to
let happen as you get busy, and (2) maintaining a solid understanding of what
you're doing is crucial to efficiency in this capacity.

Disclaimer: personal experience derives from contract work

~~~
blablabla123
I'm working as developer, now since approx 8 years. At my first job I had a
boss with Engineering background but he worked a long time in Management as
well. So this was quite nice and when he asked me implement things that would
take a long time or would be risky to build, I'd tell him and he would prefer
me doing other things. At other jobs this changed, I had to talk to more
people but doing the programming mostly alone. Although I sometimes got help
from other technical people. Ever since on a regular base I'm confronted with
this 60 minutes vs 600 hours problem. Just that it's my problem to write these
things myself. But I don't really see myself as anything close to Management.

~~~
humanrebar
Managers are allowed to delegate parts of their job. A good manager will allow
engineers with interest and potential to get some experience in this sort of
thing. Individual contributors should be able to give feedback to the manager
if they aren't equipped or prepared to take care of those sorts of tasks.
Similarly, if the manager is missing something (like making a mistake on a
ballpark estimate), an individual contributor should feel able to bring this
up and be taken seriously.

------
karlmdavis
One side note I'll offer: don't view the change as a permanent one. I've
bounced back and forth over the 10+ years of my career, and that's been a
surprisingly good idea.

As an engineer, I have a better understanding of team dynamics, business
needs, and other "big picture" items. As a manager, I don't have to worry as
much about "losing my edge" technically -- I'll be back into code 6 months or
a few years from now.

Best of both worlds.

------
allwein
I'd highly recommend reading The Manager's Path by Camille Fournier.
([http://amzn.com/1491973897](http://amzn.com/1491973897)) It covers the
entire career path for a developer from developer to lead to manager to CTO. I
found it incredibly insightful as a roadmap for what skills I'd need and
challenges I'd face while laddering up. I also found it useful in
understanding the challenges that my current manager is facing and how I could
help learn to "manage up".

------
SOLAR_FIELDS
Learning to limit scope from both engineers “wouldn’t this cool new feature be
great” and end users “we want this new feature we never talked about after
agreeing on the MVP” has been a learning experience.

Also learning to explain how and why one feature is stupidly simple and
another is exceedingly impossible has been an interesting challenge.

Otherwise nothing particularly revelatory, you will hear all of the typical
“learning the people skills” stuff from me. Also people complain privately to
their managers way more than you would think.

~~~
philipov
What's an MVP? Is that like an SoW?

~~~
cbcoutinho
I read MVP as: Minimum Viable Product.

Essentially, the first draft of a product that does what it needs to do to
show capabilities to others. Similar to a proof of principle

EDIT: Thanks for the clarification @kweinber, an MVP is put into production
whereas a PoC/PoP is not

~~~
philipov
Ah, thank you. Couldn't get past the "Most Valuable Player" association; it is
called a Proof of Concept in my industry.

~~~
kweinber
An MVP is actually released to production and is not a PoC It was popularized
by Eric Ries in his book _The Lean Startup_.

------
gvajravelu
The biggest challenge of being a manager compared to a developer is this:
Computers do what you tell them to, people do not.

It's definitely a different skill set. Being an engineer is more fun from a
day to day perspective. You get to sit down at your desk and build something.

As a manager, you are in the middle of your boss's goals and trying to keep
your direct reports happy. Those things don't always align.

You'll need to improve your soft skills. Learn to manage conflict, learn to
lead others, and learn to trust your direct reports to do their work without
micromanaging. More on that here: [https://www.climbuptheladder.com/how-to-be-
a-great-manager/](https://www.climbuptheladder.com/how-to-be-a-great-
manager/).

But life as a manager isn't all bad. You get to learn more about the business.
I find the most fulfilling part to be helping my direct reports improve their
software skills (particularly the new hires from college).

------
RickJWag
Many years ago, one of my mentors was a senior programmer who had gone from
programmer to manager back to programmer again.

At the time, I couldn't imagine why anyone would leave the management track--
wasn't that the logical career progression for a programmer? So I asked my
friend.

His response: "Because in management, they nip at you from the top and they
nip at you from the bottom." Meaning that you have to answer to those above
you, and also deal with flak from those below you. It's a constant struggle.

His words (like many other words given to me by others) have proven true.

------
mikehollinger
I’m a senior technical staff member on my team. This means that I occasionally
get to write code, spend lots of time debugging integration problems, and (as
I see it) matching up people and problems that come in to the team. I don’t
have direct reports, but I provide feedback to managers, am a team member,
lead my own team, and lead / mentor team leaders of other teams.

Delegation and Motivation are most difficult by far. I can think of several
occasions where I’ve said or done something the wrong way, causing friction,
heartache and strife. I’be gotten better at recognizing different
communication styles and matching the message to the recipient however.

Soft skills are key. Go look at Manager Tools[1], a podcast focused on
improving the quality of management in the workforce. Every podcast they’ve
ever produced is online, going back to 2005, and covers all of the unspoken
stuff like how to communicate effectively, how to have good 1:1’s, how to give
feedback, how to handle “steel cage death match” meetings, and even how to
handle personal scent issues.

They organize the podcasts into a “map of the universe” and also have a “hall
of fame.”

I’d say start with the map of the universe (it has a “start here” which covers
a couple of foundational topics, like I mentioned above. Once you’ve gotten a
feel for it, search around and find something relevant (eg performance reviews
might be a good idea given that we’re in q4).

[1]

~~~
positr0n
Missing link (I assume) [https://www.manager-tools.com/](https://www.manager-
tools.com/) :)

~~~
mikehollinger
Yep. :-) of course, I double posted which you can see with the correct link,
then couldn’t edit the post thanks to turning on the “anti distraction”
features in HN. ;)

------
KirinDave
I was pushed into the role due to an acquisition from the position of a
technical contributor CTO.

My experience: It's brutally hard and utterly unrewarding. A good manager is
evaluated by the performance of their team and the happiness of their team,
but most companies do not even _collect_ metrics on team satisfaction other
than the mostly discarded of "peer evaluations". This tends to create a toxic
environment where abusive managers who exploit their employees rise to the top
and equitable and compassionate managers are forced out or given no real
opportunity.

I've also never been offered, and in fact have been refused, any engineering
management training. I asked, and folks say it's "too expensive." They offer
some books (the wrong ones, usually), but I think they (subconsciously or
consciously, idk) recognize that performance of the team is a lot more
important.

The final thing is even if you do it for awhile and start to get better at it
(as has been the case for me), it begins to infect people's expectations of
you in the technical world. Everyone assumes you'll start to do it. In some
part because you train yourself to adopt a manager's attitude of calm and
promote the idea that "yes, this is fixable we don't need to panic."

Once you do it, it will follow you around.

------
WesBrownSQL
I have seen fantastic developers promoted to horrible managers. As others have
stated management isn't coding. Leadership isn't management. Understand that
it is your job to guide and lead your team not write every line of code or
decide that every line written isn't what you would do. You must build trust
both up to your management and down to your team. This can be very difficult
to juggle as the impedance miss match can tear you apart. be honest and
transparent, this doesn't mean be a unfiltered asshole to everyone. Understand
not every decision made is binary there are shades of grey. If you find that
"politics" is everywhere and you are constantly in an episode of Days of Our
Lives then find another job or move back down to development. I personally
don't deal with politics or like where everyone has an agenda but I will help
solve problems for both my team and for the company and I will help forward
ideas I think are good and get behind the decisions made above me and do my
best to execute on those decisions.

------
ChuckMcM
Its very different, few skill sets carry over from engineering, at first it
seemed like I wasn't doing anything useful at all.

The challenge is not going back and doing technical work that someone on the
team can do because it feels good to 'get something done', and it isn't
possible to just edit some code in an engineer reporting to you and recompile
them so that they work 20% faster than they did before.

There are a lot of bad managers. You'll hear all sorts of horror stories. But
there isn't a book that explains good management, there are 100's of books and
they are all different because how management makes sense to a person is
unique to that person. When I first started managing I would read books that
people recommended. Sometimes there was something useful, sometimes it was
opaque. Some assumed you had no understanding of others emotions, others
assumed that what others were feeling was as clear to you as if they had an
emotional status monitor hanging over their head.

Three things emerged from the mess;

1) There are always two people in a manager/employee relationship and that
pair is unique, and the tools need to be appropriate for that pair.

2) People who work for you, are notoriously bad at telling you that you suck.
Try to cultivate relationships outside of your group that can give you a
different perspective of how things are going.

3) At the end of the day respect, responsibility, and a clear understanding of
what is expected is the most effective way to keep people happy and
productive.

So to summarize, yes the new role was challenging and what was more,
frustrating, in part because the tools I had learned for developing new
engineering skills were not applicable. It isn't a job for everyone, this is
for sure.

------
alistairSH
Communication. Both up the ladder and down. Up the ladder, you have to be able
to sell yourself, your ideas, and your team to other leaders within the
organization. Down the ladder, you need to manage the expectations of your
direct reports, keep them happy, challenged, and moving forward in their own
careers.

Delegation. As a project manager, I was able to spend a fair amount of time
keeping up on tech skills, coding, etc. As soon as I took on personnel
responsibilities (as a software development manager), I've found very little
time to write code. Some, here and there, but it tends to be in short spurts
between meetings or other tasks. I had to learn to trust my team to make good
decisions. And also learn how to spot when they are about to make a bad one
(and intervene without killing morale, efficiency, etc).

Management is much more of a balancing act. As a developer, you really have
one goal - write quality software. As a manager, you have two - fulfill the
needs of the executive team while also fulfilling the needs of your team.

------
Bahamut
I have about 9 months of experience as an engineering manager after a little
under 4 years of experience as a developer. I found it a mostly
straightforward transition, but perhaps I had a background that prepared me
better than a lot of people have.

Good leadership is paramount I found - it makes the difference between a team
that is focused on executing and one that is mired in other issues. As a
Marine, I strongly believe in the Marine Corps leadership principles [1] and
applied them with great success in improving the work experience for the
engineers I was managing in a dysfunctional environment - I have been told
that I was the best manager some of these people had as a result, one engineer
with over 20 years of experience in the industry.

Anything you are not able to accomplish to make people's lives better at work
makes their lives harder, so you must use that as motivation to do the best
you can to give them the tools and environment to succeed.

Trust in your engineers to make the right decision & the judgment of the team
as a collective - your job is not to handle the technical stuff in general.

Keep eyes and ears open for stuff coming down the pipeline and its effect on
the team (people might be interested in certain projects, or it might even
affect technical design sometimes).

Keep listening for the things each team member may need/want. Actively probe,
and take action wherever possible to help accomplish it.

The list of things that one may want to know is endless. An ability to learn &
adapt is very important for a good manager. Seek advice from above and below
constantly.

[1]
[http://www.au.af.mil/au/awc/awcgate/usmc/leadership.htm](http://www.au.af.mil/au/awc/awcgate/usmc/leadership.htm)

------
OliverT
Depends on the company but here's what I have been through:

* Good dev team doesn't need "managing" but instead you become some kind of BS umbrella to protect them from arbitrary disruptions.

* Don't expect every developer to be as communicative as you expect. They may be unhappy but may not let you know directly. 1 on 1s are really important.

* Much less coding. Less than I am comfortable with.

------
maxxxxx
The first time I was promoted to a a manager position I had no idea what this
means and nobody told me. Mistakes I made:

\- Didn't take charge of hiring. My VP pushed people on me I didn't trust.
Also had to deal with an offshore team that didn't deliver. Should have said
"No" both times.

\- Didn't have the final say on raises and promotions. Should have taken
charge

\- Stayed involved too much in coding. Should have let go

\- Didn't get rid of people who didn't fit with the team. Should have made
tough decisions

\- Had to follow a process that didn't work and caused a lot of overhead.
Should have refused

Things I did right:

\- Brought things to quick decisions to reduce uncertainty for devs.

\- Let people be autonomous and make decisions for themselves

In short, when you are manager, take charge and take responsibility! You are
the boss now, so lead, don't just transmit orders from higher up.

~~~
anotheryou
A pushed "offshore team that didn't deliver". I really don't know when to pull
the plug here myself...

------
alaaf
I asked a similar question some time ago:
[https://news.ycombinator.com/item?id=13284742](https://news.ycombinator.com/item?id=13284742)
not about the experience, but more about what to keep in mind when switching.
Hope it helps.

~~~
6ak74rfy
The role of project management is very different from that of engineering
management. For e.g., the former doesn't have any people management, whereas
the latter does.

~~~
twobyfour
That's not exactly true. A project manager in some ways has a more difficult
people management job than an engineering manager does. They're held
accountable for the coordination and performance of people over whom they hold
no actual authority. That takes some major diplomatic skills.

------
ggm
I made this jump from researcher to network engineering to applications and
systems management to tech group management. I sucked at people and project
and process management and I was very lucky to escape back to research and
technical communication. Tech management required skills I lack and now, I
report to a professional technical manager who is wonderful, a kind, humane
and also appropriately critical man. What I sucked at most was giving negative
feedback. That and time management. Good managers manage expectations upward
and downward, keep blame, share recognition and do not excuse failure but
reward admitting mistakes. Don't ever be tempted to lie, and don't shaft
people. Don't keep dud hires unless you can find the role they don't suck at.
Don't allow bullies to triumph.

Tech management should be more like an anarchist collective of mutuality but I
tried, and it doesn't work well in a hierarchical reward structured
environment.

Tech management can be learnt but I now understand not everyone can apply it,
and you need to be open to the possibility it's not for you. On one management
course I was told that if you find yourself in conflict with the goals you're
being asked to deliver you may be getting a signal to move. As a wage slave
with no reports it's possible to compromise on this but in a leadership role,
its untenable to command outcomes you cannot adhere to. Don't do it.

------
dboreham
Honestly it is a pretty thankless role and unless you are being paid very well
to do it I'd recommend avoiding. Jump to being the business owner instead.

Edit: ok, perhaps it is ok in a situation where you are "earning your chops"
as part of a plan for future world domination. Also in specific circumstances
and the right company it could be a fulfilling challenge.

------
lo_fye
I found the daily interactions and increased participation in strategy to be
great... BUT I never felt productive. As a dev, it was easy to know when I was
productive. I could FEEL productive. As a manager? Not so much. There was
nothing tangible. Just meetings and documents, and comments from direct
reports. After 2.5 years, I just went back to development.

------
paradygm
Can't stress training enough. If your company offers training take advantage
of it. If it does not you have to consider if they take your success as a
manager seriously, and if you are willing to invest a lot of your own time and
energy into bettering yourself while being responsible for other people. I had
a bit of training but also was fortunate to have worked for great managers I
considered my mentors and found that to be an invaluable resource to fall back
on.

It isn't clear exactly what your role entails, but in my opinion it is pretty
much impossible to be a great manager and continue in a role as a technical
contributor. To me that's more a technical lead than a manager, so if you
still like writing code you need to think about that long and hard. Your #1
responsibility is the success of your team and they need to know you are there
for them 100%, and not busy buried in code. There are times when you may be
able to get your hands dirty but you can be nowhere near the critical path of
the project.

You also have to remember you are not only managing your direct reports but
who you report to and whomever is relying on your team. In my case, I reported
to a VP but I also had to work laterally with other development managers, and
in particular project managers that weren't always technical. Just like as an
individual contributor you need to maintain a healthy relationship with those
you work with directly because you need to balance what they need and want
from your team with what your team needs and wants.

That being said, I lasted in management for a little over a year, mostly
because the role evolved and due to some changes at the top where I didn't
feel I was enabled to be an effective manager. Still, I found the experience
invaluable as it gave me more insight into how to better work with people of
all stripes. Like any role, technical or otherwise, you have to constantly
evaluate what you are getting out of it, if you enjoy it, and if you want to
continue bettering yourself in the craft.

------
johnwheeler
I made the transition after 12 years as a developer.

One of the issues I had was mistakenly assuming all the people working with me
would be easy to get along with and hard working, which was how I behaved and
is a factor in my becoming a manager.

It's not that way at all. You see the 80/20 rule play out, where you have a
few A+ players who do most everything, a few people who do decent work, and
then a handful of duds. Attitude-wise, the harder people work, the more
pleasant they tend to be. The duds can be indifferent towards you or even
hostile.

Being a developer and being used to controlling my work product, I had to make
a shift to trusting other people blindly and that wasn't easy for me. Over
time, I realized it was the most effective way to get people to do their best
work though - trust that they'll give good results until they repeatedly prove
otherwise.

------
muzani
I've made the mistake of being a "tech lead". The term usually means some who
plays a sort of CTO role but is also a key programmer. It's really tempting
because you get a star player salary, but also make full use of your technical
skills.

A programmer needs a lot of deep, focused work to do their job, whereas a
manager needs to be available.

Managers are the spine and nervous system of a company. They need to transfer
information from one part to another quickly. They need to communicate a lot,
make decisions quickly. They train newbies, manage project progress, deal with
issues.

A manager who wants to do technical work should probably limit himself to more
shallow tasks like bug triaging or maybe setting up a checklist of things for
the other programmers to do.

------
bsvalley
These are all the minimum requirements for an engineering manager. If I hire a
new software engineer I’d excpect to see someone capable of building awesome
products. Same for a manager, being good at managing a dev team is for me the
minimum requirement. If I were to push the boundaries further, I’d say that
you have to be likable, friendly, inspiring, extremely adaptable to different
personalities and totally transparent. Be straightforward whenever you can,
cut the BS when it comes to career growth. Put yourself at risk and become
friends with all your direct reports. The further you stand the harder it is
to maintain a healthy relationship. Get your hands dirty. That’s how you
seperate an awesome eng manager from the pack.

------
kr2
F*cking awful. I'm a great engineer. I'm not a good manager. There is a big
difference, and most of the other replies have done a great job laying out the
differences. All I want to do is sit in my corner and build stuff.

/end cathartic outburst

------
dandare
I always felt my only chance to stay relevant in the IT industry is to move to
a more managerial position because there are so many smarter developers than
me, especially the sort that codes in their free time or has a formal
education in CS. Essentially I felt that almost everyone is smarter than me.
After being a self-thought developer for 15 years I made a transition to
Product and I boost the title of Senior Technical Product Manager. Here are
some of my thoughts:

\- The variety of companies and cultures is way more heterogeneous than I ever
thought. I worked as a dev for mediocre companies where I was one of the
weakest in the team and I worked as a PM for NASDAQ companies where I was a
probably better developer than the average.

\- As a developer I was often frustrated by the inefficiencies in the system
that I could not change. AS a manager I am often frustrated by the
inefficiencies in the system that I can not change.

\- You can learn social skills same as you can learn swimming or dancing.
Regardless of how much of a neckbeard you are, if you commit to it, you can
learn to be a people person. Use your analytical skills as an advantage to
filter out bullshit and follow evidence-based advice. Giving a compliment
works 99% of the time.

\- The recruitment process for managers is a sham. You must know to recite all
the hippest theories but in the actual job you will often fight to fix the
most obvious inefficiencies.

\- I have less stress and higher salary as a manager. This may not apply
universally, but as a manager I will never cause production outage or P0
defect.

\- My technical background is a huge advantage, still, there are managers with
much better people skills, negotiation skills, business intuition etc. Many
others just hide behind buzzwords and fake smiles. Listen and learn.

\- Manager or not, I highly recommend this gem of condensed, practical advice:
[https://www.amazon.co.uk/Mobile-MBA-Skills-Further-
Faster/dp...](https://www.amazon.co.uk/Mobile-MBA-Skills-Further-
Faster/dp/0273750216) (based on the success of the book Jo Owen diluted the
same content in much longer book The Death of Modern Management)

------
pouzy
I'm editing the blog [http://cto.pizza](http://cto.pizza) that relates
challenges of CTOs, VPs, engineering directors... you might get some insights
on what it is like on the blog

------
kasiratnam
Agreed. I found that books were good for learning the language and theory of
management, but the important stuff -- interacting with, influencing and
negotiating with people -- that only comes from practice and reflection.

------
known
Managing requirements vs Managing expectations need different set of skills

------
e3Yw2HjDrjsRVi
I was a Sr. Developer. My boss refused to relocate, and I was offered the job.
We have the following leadership roles on a team: Scrum Master, Technical
Lead, Product Owner and HR Manager. Originally I was Technical Lead and HR
Manager. Later I was TL, PO and HR.

I gave up TL to someone but retained PO. I was just too busy to do all three
and decided that Power of the Pen trumped Power of the Code Review, though I
still do CRs.

It's hard to let go of the technical leadership, not just for me, but also for
everyone else who is used to coming to me.

The people management role is the least rewarding and the most challenging.
Hiring can be rewarding, but unless you work somewhere where you're always
hiring, you quickly hire some decent or great folks, and then you're done with
that. Like really done -- letting people go can take a long time in a big
company.

I still write code, but it tends to be emergency fixes or prototypes, not the
type of code that requires days on end of focus, because it is impossible to
be left alone for any length of time, and not have to do a million simple but
important tasks.

Being somebody's boss typically carries a lot of weight, as long as you have
their respect, and I find it challenging not to suck the technical oxygen out
of our team by doing the research while writing the requirements and taking
that fun phase away from developers, thereby limiting their satisfaction and
growth. I mean, a good developer will still do their own research even if you
hand them something on a silver platter.

Also, you have to learn how each team member works and communicates. Some
people are very focused on dry facts, and others on feelings. If you don't
speak their language, you'll never be on the same page with them and your
relationship will be constantly frustrated.

Some people work fast, and others more slowly. When people seem to be working
slowly, you need to consider why. Are they on the wrong path? Did you not give
them all the info they need, and they're hesitant to admit they don't
understand. Maybe they just the real thorough type? Find a way to get people
into their zone quicker, and leverage their individual strengths.

Finally, there is the whole issue of what role do you play. You may have been
friend/peer to people who now report to you. If you notice they are slacking
off, it's a bit more challenging to get them back on track, but not that hard.
Just ask for a detailed status update, take a few notes, and then do it again
a few days later, and compare what they've done, or schedule a demo.

Larger or less flat organizations will have a dedicated people manager for 1-3
teams, and their full time job is to manage people, foster moral, etc. That
may be rewarding for some folks, but I tend to think the majority of
engineering types would hate it.

