
Ask HN: Engineer manager? What is your management style? - shubidubi
Would love to hear other managers&#x27; philosophy for managing engineers.
======
amirathi
I am not a manager. But I will list down a few traits of one of the best
manager I have had:

\- Shield the team from all the churn that happens from manager upwards. There
can be so much shift in priorities, uncertainty in the upper management that
it's mind boggling. "Shielding" team means - Providing a sense of stability,
making sure the engineers are working on problems that are important for
company now & will be important 6 months from now.

\- Team succeeds: Attribute everything to people working for you. Publicly
recognise folks who have gone above & beyond to achieve an impossible
milestone/project.

\- Team failed: Take the blame on you/process. Confront with engineers in
private but at an organization level you bite the bullet

\- Know everyone's interest & goals, like really know. On a longer horizon,
try hard to align projects that matches individual's passion & challenges her
skill level.

~~~
matt_s
Former manager, back to engineer checking in.

I tried to practice the above, to an extent where possible. Sometimes upper
management or other teams have a way of interrupting engineers with stuff that
isn't a priority. It happens. Most engineers "aren't bothered" but it does
impede on current workloads.

Another thing I practiced was only taking on low priority, or menial
engineering tasks. I have seen some managers want to be directly involved with
higher priority and larger efforts when really that isn't their role. Its good
to keep hands on work, but don't take that away from your team.

------
matt_the_bass
I think the depends a lot on big company vs small company.

At a small company, here are a few bullet points I find helpful/effective:

1\. Lead by example: others will follow you if they believe in you. Manager
has be willing to do and seen to do any and all tasks that they delegate. This
does not mean that the manager has to be the best one at it or do it the most.
But they should do some of those tasks that no one really wants to do.

2\. Be sure to acknowledge success of others. Do this both directly and
indirectly. One great way is to tell person B how good a job person A did when
in a place/situation that person A can hear. This could be in passing or
explicitly complimenting them in a group. Don’t do this for every single task
but do do it for both large and small tasks. People want to know that their
work has been acknowledged and valued.

3\. Ask questions of your team. Don’t be afraid to get opinions. Don’t be
afraid to not know the answer. Do be clear if you change you mind/approach if
you learn new facts. If someone helps you find the answer/path acknowledge
(see #2)

4\. Think before you speak.

5\. Share the Why not just the What.

6\. Be excited about your goals. Explain where to want to go and why. You are
your teams link to upper management and customers. A good team member may be
able to find the path better than you if they understand the destination.

7\. Don’t overwork your team. This will enable you to call on them for they
extra job/extra hours the few times it is really needed. (See #1)

These are by no means the only items. But certainly some items I’ve found
useful.

Note, they do not apply only to programming. They do not apply only to
engineering. I think they apply to all disciplines.

------
lacker
There's a lot to it, you can't really sum it up as a brief philosophy. It's
like asking people "what's your philosophy for programming".

That said, here's some philosophy. As a manager you are responsible for two
things - you are responsible for making sure your team gets things done, and
you are responsible for making sure each of your team members is happy in
their job. The precise ways of making sure your team gets things done, well
that depends on what you're getting done. And the precise ways of making sure
each of your team members is happy, well that depends on why they are or are
not happy.

From there it gets less "philosophical" and more "practical".

------
muzani
Managers are basically information routers:

1\. They make sure info goes from one place to another with minimum delay. If
the team needs tool X, they get them tool X as fast as possible.

2\. They work on a lower level, closer to the team, to discover any issues the
team has before it's too late.

3\. They understand their team better than any seniors, and can give a good
estimate of how much resources are needed and how much the team can output.

Managers also work out of the team. They work on it like it's a machine. If
one part breaks, they don't simply fix the part, but tweak the process so it
doesn't happen again.

------
ecesena
I’m not a manager, but what I like about mine is:

1) He’s expecting from me directions on what to do. Take this statement with a
grain of salt, of course the entire team still works together and with
coherence, but what I want to say is that he’s empowering me to make real
decisions.

2) He unblocks me, by connecting me with the right people, helping and
escalating when necessary.

3) He’s a member of the team, we have lunch together, dm on slack, grab a
beer... on a personal level it doesn’t feel he’s on a “higher” level.

------
jlengrand
Some additional ideas (though @amirathi has summarized it in an amazing
manner)

* Make it so things roll the same if you're not here.

* Help them finding solutions but do not fix things for them.

* Get their respect not through fear and or forcing them, but by doing the boring things and showing them that you care about what they do.

* Do your best to make them shine, let them know how much value they create.

Once thing I experience at my current job and that I love is that I am both
the 'manager' of the team and a developer inside the team. I love this, even
though it needs that you know exactly (and make known) when you wear which
cap, is that you can achieve the above points easier. I love being able to
show them that I can design, code and work. That makes it easier for them to
respect me.

------
raven105x
Top-down direction (feedback) can only be effective when grounded in reality,
and to do this you must be approachable to your direct reports, hence fairly
hands-off during day to day operations so that your presence in a meeting
impacts it minimally - only then can you gather accurate information to give
effective direction and feedback.

Team directives are "here are our goals, what's the best way to make them
happen?, alas at the individual level, "management style" doesn't fly. Your
team will be full of people each of whom take feedback differently and must be
approached differently if you want to be as effective as possible.

Your goals as a manager are almost always best met by enabling your team via
reducing their stress levels and providing them with the tools they need.

Do this, and they will meet whatever (usually pointless) goals or KPI's the
brass uses to evaluate your performance.

------
jayec
I'm only new to management, but I try to be fairly hands off unless someone
needs something from me. My reasoning for this is, I'm the one who hired this
person and if I did my job correctly in hiring the best person, they shouldn't
need to be micromanaged.

~~~
rishirishi
I too am hands off with respect to managing. I am of the opinion that if you
need to actively manage your directs, then you have not hired well. I am a
point of escalation when there are incidents or when mediation is required;
otherwise I trust individuals to make decisions and be accountable for them.
They will mistakes and you should not protect them from it; they need those
experiences to grow. For decisions that are irreversible (or really hard to
undo), I encourage them to solicit input from me and peers outside the
immediate team.

For individual career growth, I try to align interest with opportunities that
arise. I give timely feedback, I recognize their successes with new challenges
and increases in compensation.

As it concerns project planning, I help with ballpark estimates so as to
inform resourcing decisions. I negotiate the scope of projects with
product/business leaders.

------
blooberr
I was once asked what my philosophy was by a more senior manager. Didn't give
him a good answer.

The interaction lead me to think about what I was doing as a manager. Over
time I've been working on developing and explaining my own style.

Today I try to balance across 3 things: people, business, and technology.

I wrote about it here if you're curious: [https://www.mrbluebear.com/triforce-
of-engineering-managemen...](https://www.mrbluebear.com/triforce-of-
engineering-management-a-developing-philosophy/)

------
SirLJ
Laid back, do your job and don't lye to me and you'll have glowing reviews...

Don't ask people to do stuff you won't do personally...

You can work from home, office, the other side of the world as long as it is
legal and you are available during business hours/on call...

If you have my back, I'll have yours in front of upper management..

We work to play/live and not live to work in my team...

