
Try to see things from a manager's perspective - denzil_correa
http://queue.acm.org/detail.cfm?id=3156692
======
nulagrithom
> While it is true that misery loves company, no one loves working for a
> leader who doesn't portray confidence in the team's trajectory and success.
> People want to be inspired, and as their leader, it is your job to give them
> the motivation and vision to perform.

> This means that even when things are bad, or you feel frustrated, you don't
> let it show. You need to be the person who is positive and who helps
> motivate people to do their best. If you don't, then who will?

I'm not sure how much I agree with that part.

One of the "child" companies of the company I'm working for has run in to some
trouble. There's definitely a culture of "putting on a happy face", as
described above, but it gets tough to believe when you _know_ something is
wrong. None of the C-levels would give details.

Recently the board president showed up at an IT meeting and said "They're in
deep shit guys," and spelled the whole dire situation out for us.

 _That_ was inspiring. Everyone in the room was motivated to "fix" it.

Conversely, I've also been part of a company where leadership did nothing but
talk about how much we're going to grow, all the way up until half the staff
got laid off in one fell swoop. It wasn't motivating or inspiring at all. It
was actually _deeply_ concerning.

I don't think this is as easy to sum up by simply saying "when things are bad,
or you feel frustrated, you don't let it show."

~~~
kelnos
I think the author's point wasn't to suggest leaders should paper over
problems, but that leaders shouldn't stoop to complaining or letting their
frustration show in front of their reports. They can be frank and truthful
with employees, while still remaining confident that the challenges can be
overcome.

~~~
seanmcdirmid
I much prefer leaders who let their anxiety known to me than those that
project absolute confidence that whatever problems can be overcome. I can
trust the former, I can’t trust the latter at all, and it’s super easy to
tell.

------
kelnos
> At the time, I had the impression he was out of touch; the people he
> recognized weren't the ones who had contributed the most code, and the
> features he called out were important but not the ones that had been the
> major engineering challenges.

(The author then goes on to suggest that this is normal, and expected, and
correct, and that the leader wasn't actually out of touch.)

This bit bothered me, and she didn't really justify it all that much.
Obviously "the most code" and "the major engineering challenges" won't
necessarily translate directly to the features that the customers want most,
or that drive the most revenue or sales growth.

But if several people have done some of the most technically challenging work
that was necessary for the product's success, don't they deserve some
recognition? And is it not the fault of their direct managers & middle
management for not floating those accomplishments up the chain? Obviously not
everyone can receive a shout-out, but at the end of the day none of this would
be possible without the people at the bottom actually doing the work of
building.

I feel like this kind of out-of-touch-ness is exactly what causes individual
contributors to feel unappreciated even when they do things that -- at their
level -- are truly difficult and extraordinary.

~~~
humanrebar
I had the same impression.

> ...is it not the fault of their direct managers & middle management for not
> floating those accomplishments up the chain?

If that's the only way upper management gets that info, I guess. But,
especially in software, there are plenty of ways to get that info in addition
to letting subjective takes float up the management chain.

At the dumbest level, you can look at code metrics (still not great), but just
knowing the product (software) and evaluating it yourself is a great idea.
What restaurant manager never eats the food or inspects the walk-in?

------
mcguire
Am I reading this right? "So, when you have a leader who isn't meeting your
expectations", it's because he or she _is_ out of touch? They don't know what
is going on with their team _because they can 't, but even if they did, they
couldn't do anything productive about it anyway?_

(The only things senior managers can do is "Start and stop projects," "Reorg,"
or "Hire, or fire, the leadership team." I've been through all three; the last
isn't done often enough and the first two are some of the reasons I have a
series of failed projects on my resume.)

------
CamTin
TL;DR there's nothing wrong with the way we structure our workplaces that
can't be fixed by suppressing your own feelings and identifying with
management and ownership.

------
yanilkr
For some reason reading this reminded me of this old conversation about
frameworks.
[http://discuss.joelonsoftware.com/default.asp?joel.3.219431....](http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)

In a lot of ways, this Leader, LeaderLeader thing is lot like Factory and
FactoryFactory patterns in java. That FactoryFactory conversation came out
when enterprise java was at its peak and everyone else were preaching that was
the standard way of doing things. Then nodejs, rails and functional
programming entered mainstream and it made java look very very complex and
naturally everyone embraced simplicity and java itself could learn to be
simple. It is possible the same is true for technology management.

There are a lot of underlying assumptions here. Like for e.g. This many layers
are necessary. There is a right way to be a technology Leader or LeaderLeader
and Technology Leader has some awesome supernatural powers to make things
happen.

I am not sure if there is a great recipe for managing successful
products/teams, if there were one, a lot of people with a lot of money would
have done it by themselves with out need for "startups" to innovate. After
some point, companies like Google and Microsoft tend to grow mostly by
acquiring someone else, usually startups and there is very less LeaderLeader
pattern in startups.

I am not too sure how much impactful the LeaderLeader pattern is in tech
world. But as a creator of things for other people to use, it might be a
better approach to see things from your user's perspective. It appears
appealing to that many layers of organization leader hierarchy is a drain on
human creative energy.

------
qntty
> Leadership is hard. None of us comes to work to do a bad job, and there are
> always ways we can be better. So, when you have a leader who isn't meeting
> your expectations, maybe try reframing the situation and looking at things a
> little differently from the top down.

IMO the burden is on the people who's job it is to manage people to _ask_ the
people they manage what their perspective is on an issue. Managers who do a
bad job because they don't care what their employees think have no business
managing people.

~~~
groby_b
It's an issue of scaling.

Can I ask 5 people what their perspective is? Sure. 15? It's getting tough,
but maybe. 50? Not really.

And so you delegate. Which means you get filtered information. Detecting which
filters work well and which don't is tricky. It's not that managers "don't
care", it's that they genuinely don't know and haven't figured out they don't
know yet.

You can short-circuit that by telling them. Sure, getting the info is their
job, but pushing it their way might get them the info faster. Just saying "but
it's their job" is not helpful.

~~~
ZenoArrow
> "Can I ask 5 people what their perspective is? Sure. 15? It's getting tough,
> but maybe. 50? Not really."

Don't make one person in charge of 50 people then (at least, not their direct
line manager).

Management where your only option is delegation is not very effective, in my
experience. You have to be able to choose when to delegate and when to step
in. The only way that works is when the teams are small enough that a single
individual knows enough about what's going on to know when to change their
leadership approach.

Furthermore, of all the managers I've worked under, the most effective ones
all have one thing in common... they're protective of their team. This
protection only seems to work when a manager understands what their team is
going through. Consider a scenario where a management meeting is taking place
and a manager from another department is complaining about how long your team
is taking to complete a task. If your manager doesn't understand what your
team is going through, what's the best answer your manager can give? That
they'll "look into it". That may sound reasonable, but it puts your team on
the back foot from the start.

Effective team protection brings a few key benefits... it builds loyalty, it
reduces stress on team members, it focuses energy on key tasks rather than
trying to do everything all at once. Managers who don't protect their teams
may as well not turn up. If they're just another voice adding to the cacophony
of demands, then they could be doing more harm than good.

~~~
groby_b
> Don't make one person in charge of 50 people then (at least, not their
> direct line manager).

Which is, literally, delegation. Yes, front-line managers should have some
understanding of what their people go through, and have direct lines with all
of them. But the article didn't refer to frontline managers only. In fact, the
opening example was about a VP. (I'd argue that it's mostly _not_ about
frontline managers - the title is badly chosen)

But even when you're a frontline manager, "step in" is not really a good
option. Unless your team is tiny, inserting yourself into actual execution
means you just created a huge schedule hazard for your team.

For better or worse, as a manager, you work through others. Your direct impact
is very limited - your main job is allowing others to have maximum impact.
(Protecting your team falls under that rubric - shield people from
administrative noise, so they can do their actual job)

~~~
tensor
And in the end it really is "their job." It may not be helpful but it's
reality. It's why your job is hard and it's something you need to accept and
deal with in a way that doesn't demean, marginalize and slow down the people
you serve.

~~~
groby_b
It is, if you look on externally.

If you are the employee wondering "why don't they act on this", that's still
not a helpful take. Neither for you - nothing will change - nor for the
manager, who might miss out on critical info.

Which is why good managers usually make sure that people are aware what the
escalation paths are, and how to use them.

And why they keep hammering on the point that "not my job" is not helpful -
because they (should) know that they operate on necessarily incomplete
information, and that they make mistakes they're not aware of that are
_immediately_ obvious to people on the front lines.

The conundrum of management. It's your job, but you can't do it all by
yourself.

------
humanrebar
> """ Generally, this is done in three ways: • Start and stop projects. •
> Reorg. • Hire, or fire, the leadership team """

I would hope some management tools would be unique to the industry of the
product. These could be applied to literally any organization.

In software, you could, for example, pick an item from the Joel Test and
provide carrots and sticks to encourage success in this. And there are plenty
of other strategic technical goals you can encourage, like deterministic
deployments or engagement with key open source projects.

~~~
slgeorge
It's a question of abstraction, at the start of the article she notes that
she's run teams of up to 400 people. At that size there are layer-on-layer of
people whose job it is manage divisions/groups/teams of people. The person at
higher levels of some pyramid has to think very carefully about dropping down
into the detail and consequently side-lining some levels of their management
chain.

------
hashmal
I'm a bit wary of articles making no distinction between management and
leadership.

------
gaius
A manager's perspective:

1) you are a resource, nothing more

It's a short list

