
Unlike Babies, the Best Managers Come with Instructions - vinnyglennon
https://torch.io/unlike-babies-the-best-managers-come-with-instructions/?hss_channel=tw-983379969773420544
======
PragmaticPulp
Manager READMEs start out with good intentions, but every example I've seen is
flawed for multiple reasons:

1) It's manager-centric. Why would you give employees a guide to their manager
when you could give them an "Employee README" that is focused on the new
employee? When I join a company, I want to know what's expected of me so I can
succeed. If the company delivers this in a form of a manager README then I'll
still be missing the big picture goals of the company. Managers - Focus on
your employees, not yourself.

2) Manager READMEs become an aspirational target. Describing yourself in text
is challenging for the ego. I've seen too many manager READMEs that read like
a picture-perfect version of what the manager aspires to be, rather than a
description of how the person actually operates.

3) The self-promotion aspect. When managers post their README all over
internal company chat, public Twitter, their LinkedIn profiles, Medium think
pieces, and the company blog (like this article), the document becomes a
brand-building exercise. This puts even more pressure on managers to only
write down their most perfect, idealized vision for what they want to be. Or
they spin their flaws as some sort of superpower with creative wording. I once
read a public manager README that was nothing like that person's actual
management style, but it read as if that person was a textbook-perfect
manager.

My recommendation: Skip the manager README fad and focus on your employees.
Write an "Employee README" onboarding guide for each of your employees, that
you customize with individual expectations and information for each employee
before they join the company. Keep it in a shared document that you can update
over time to include an up-to-date job description, list of responsibilities,
and key expectations for that employee. Don't try to make management all about
the manager's personal brand.

~~~
blowski
> Why would you give employees a guide to their manager when you could give
> them an "Employee README" that is focused on the new employee?

Why not do both? "Hey folks, here's my README, I'd encourage you to write
something similar and share it with everybody."

~~~
PragmaticPulp
> Why not do both? "Hey folks, here's my README, I'd encourage you to write
> something similar and share it with everybody."

When it comes to team building, I think it's much more valuable to say "this
is how we operate" instead of having everyone write down "this is how _I_
operate". The former is a mutual guidebook for everyone to work together,
while the latter feels like an edict that everyone else needs to work around
you.

~~~
lonelappde
How do you handle the case where two people operate differently but need to
interoperate?

~~~
PragmaticPulp
De-escalate any tension between the two people

Check for any overtly abusive behavior that requires correction. Usually rare,
but worth checking.

Provide basic coaching and suggestions for working together in a healthy
manner.

And most importantly: Let them know that they're expected to figure out how to
operate together on their own like professionals. Managers can't be mediators
for every impedance mismatch between employees.

------
jghn
IMO the best managers learn to change their behaviors based on each report's
needs and doesn't request that their reports conform to the manager's needs.

~~~
troymc
I had to read this sentence twice before understanding that a "report" is a
person. Maybe that has become accepted terminology in some circles. I hope
not. It's terribly dehumanizing.

~~~
jghn
What word would you prefer to use for "person whom a manager manages"? If one
just uses "person" it is unclear if it's any arbitrary person or a person
under a manager's umbrella

~~~
yepthatsreality
“Directs” is another common word I hear used by managers.

~~~
jghn
Which makes sense as the formal phrase is "direct report".

While it was unintentional in my original post, "report" seems to work better
than "direct" here as IMO my statement holds for a manager's indirect reports
as well and thus "report" covers both direct and indirect. But now I'm just
amusing myself with word games :)

------
exactchange
Unpopular opinion:

In Silicon Valley, people managers can easily be a waste of time and money,
and can cause unnecessary drama on your team. Think about the kind of so-
called developer who would rather manage people than write code.

We still need founders, executives, directors, advisors, etc. don't get me
wrong. But has anyone ever come across an engineering manager worth their
salt? Why did we start deploying people managers en masse to engineering
teams? I miss the holy trinity setup: Dev, designer, PM. It worked well IMO.

Our industry is shooting itself in the foot with Engineering Managers. The
ones I've come across are self-obsessed, as evidenced in these cringeworthy
READMEs and this article that was written.

~~~
mharroun
Without (competent) engineering leadership.

\- Whos going to push back and sales and marketing for harassing you directly
or taking direct blame for failures?

\- Who will represent the engineering team in leadship meetings to make sure
policies/decisions are made with their needs in mind?

\- Who's going to fight for your raises and promotions?

\- Who's going to make sure that there is budget for what engineering needs to
do and keeps a proper record to keep finance happy?

Please thing about it... any company that grows to 30-50 people (even
startups) need to have management and processes that eventually lead to (even
unintentional) politics. The other departments will have leaders/managers
defending/supporting them... its foolish to not understand or respect
competent leaders.

~~~
dchichkov
The examples that you've given are political (represent, push back, take
blame, fight), except for the example of keeping records (which is
management).

Managements role, technical leadership role and politician role are different
roles. The required skill sets and experience are different. The outcome of
grabbing a wrong role is usually poor. Not confusing politician, technical
leader and manager roles is probably a good idea to improve outcomes. As
checking for required experience, to take the role.

~~~
mharroun
Management is full of politics... sorry but its true. A true leader must have
all the skills needed to properly benefit and support the team.

You look at my examples as negatives... its the wrong way to look at it...
thoes other managers of other departments? Are the bad people? No... but they
have a job and responsibility to represent their departments and do from their
point of view whats best for their team and the company.

I feel like there is a segment of workers in engineering has this weird self
damaging hatred for leaders/managers other departments do not have... then
thoes same people get pissed when they dont have a leader and their department
is glossed over because no one represents them when/where some of the most
important decisions are made.

~~~
dchichkov
Notice, there was nothing said about roles being bad. There was nothing said
about impossibility of combining multiple roles.

------
nlh
To build on what another commenter said, the idea of manager READMEs made
perfect sense when they started out a few years ago - here are my quirks,
here’s how I operate, etc.

The problem is they’ve turned into something that justifies bad behavior more
often than not. So many of them have this undercurrent of “I’m an asshole -
don’t take it personally!” which is just totally not OK. The solution isn’t to
proudly broadcast and justify that you’re an asshole and expect others to
adapt — the solution is to not be an asshole.

That being said, things like “I tend to work late so if I email you on the
weekend, I don’t expect you to reply until Monday” are totally reasonable and
I think, on the whole, a good thing.

~~~
freedomben
Very much agree with your analysis here. It's like many, many good ideas that
have come up in SV (agile/scrum, OKRs, etc), when looked at as a useful tool
for the individual that should be utilized on an individualized basis, they
are incredibly useful. When made standard and forced into use-cases and
personality types they don't work for, they can be mediocre or even counter-
productive. They will also be used in ways not entirely desired, such as for
self-promotion, self-justification, gaming things, etc. Managers also tend to
get overly prescriptive about how to use the tool (usually a sentence that
starts with, "here's how we do $TOOL at $COMPANY" is often heading there).

I've used OKRs, Kanban/agile and many other tools for me at an individual
level and loved them. I've had the exact same tools at companies become a
waste of time, a point of contention, and only be a "value add" for
management.

------
mharroun
Ugh as someone with 12 years of experience and about 8 ish in a teach
lead/management role. This seems super weird to me.

An Engineering Manger/Director/VP/CTO's main job is 2 things.

\- To be the over arching intermediate between engineering and other business
units (note: this does not mean walling off engineering, engineers SHOULD
understand and work with business units when it makes sense).

\- To support, mentor, shield, and basically do what ever is necessary for
their team/department/org to be as successful as possible.

This sounds VERY self centered and I honestly believe product and engineering
managers need to be to most selfless people possible to actually be effective.
I would call it backwards even... a leader/manager needs to tailor himself and
his approach to both his people and his cross-department equals in order to be
the most successful.

------
astura
This is the silliest, most ridiculous, and self absorbed thing I've read in a
while. So much so that I suspect it's actually satire. If it's not then
silicon valley sounds like another planet, in my 2+ decades of employment I've
never had any sort of issues with management. If I have any questions, I ask,
if I have any feedback, I give it. That clears up any ambiguity.

~~~
kingbirdy
> in my 2+ decades of employment I've never had any sort of issues with
> management

Then you're incredibly fortunate. I've had to deal with management issues at
multiple companies in a shorter span of time.

~~~
astura
Sure, but a README doesn't magically fix shitty management, if anything it
just a justification for it.

Not to mention people are just horrifying bad at seeing themselves as others
see them. I think of the scene in A Christmas Story when the kid expects to
get a glowing review of his paper but instead got a D grade. It actually
reminded me of a family member of mine who got called into his boss's office.
He was bragging that he was going to get a bonus or promotion and instead he
got a demotion due to poor performance and bad work ethic.

I've had five software jobs and five unskilled jobs.

~~~
kingbirdy
Oh, certainly. I think a README could've been helpful from good managers, but
it could just as easily make bad managers worse.

------
teddyh
See also _The Manager FAQ_ by Peter Seebach:

[http://www.seebs.net/faqs/manager.html](http://www.seebs.net/faqs/manager.html)

~~~
sihox
Thanks for this one! Reading his Hacker Faq already...

------
11thEarlOfMar
I wrote one for myself that is yet to be published. Will give it a 2nd
thought.

The reason I thought it would be helpful is that I am not a high feedback
person. I seldom praise (need to work on that), I am not expressive, I've been
told I 'play my cards close to the vest.' by someone who directly reported to
me. That really got me thinking that maybe the circumstances where I am not
getting what I want is because my staff really cannot figure out what I'm
looking for in general. So I wrote up a 'read me', before I knew there was
this trend.

I included self-deprecating statements about things like assigning a task to
multiple people because I forgot it had already been assigned 'Don't take it
personally, just let me know and I'll fix it.' And, if they need me to attend
a meeting, make sure it's on my calendar, or, no chance I'll remember.

In the end, it's only going to be as helpful as it is 'correct' and clearly
described. That depends on each manager's level of self-awareness, combined
with their sense of self confidence. You'd hope managers would have both
qualities, but if not, this can really be a red herring, or even be used as a
dark pattern.

~~~
munchbunny
> The reason I thought it would be helpful is that I am not a high feedback
> person. I seldom praise (need to work on that)

The reason I would be afraid to standardize manager READMEs is specifically
that I do not trust the average manager to publicly acknowledge and privately
work on flaws like that. For managers who do that, I’m not that concerned
about the exercise because it’s more likely to produce something useful for
the employees. For the other type of manager, I’d be afraid of accidentally
creating the expectation that the employee needs to adopt the manager’s style,
which I would privately recommend to any employee, but which I would
vehemently oppose as anything resembling an official expectation.

------
Zenst
Tangent here - saw Torch and nostalgia of
[http://www.computinghistory.org.uk/det/1039/Torch-
Computers-...](http://www.computinghistory.org.uk/det/1039/Torch-Computers-
Ltd/) came a flooding.

------
sysbin
I'm wondering if anyone has been in a manager-less team. I would like to think
that's possible and if so what was the experience like?

~~~
convolvatron
it works fine as long as everyone is extremely reasonable, and everyone's
primary motivation is the success of the project.

unfortunately, this is very unlikely to be true. and increasingly less so as
the team size increases.

one confounding factor here is the heavy use of religion to guide technical
decisions. the decisions we make now about the direction of the product and
the attributes of the codebase are largely subjective. there are arguments on
all sides of a position.

a good team, properly enculturated, understands the process. when the issue is
important enough to justify digging in and when its just a personal bias. a
good team helps all of its members stay on the path and not end up in giant
ratholes. a good team uses its experience to inform future decisions rather
than create artificial strictures. a good team has enough time and maturity to
interact constructively with the rest of the business and the customers.

I shouldn't say 'good' team, I should say 'perfect'

good management greases all of these points of potential friction. but I think
at the end of the day management is there to address the last point. its
natural and expected for engineers to keep a narrow focus on the technical
aspects of the project itself. someone's got to make sure its evolving in a
direction that's meaningful in an external context.

~~~
lonelappde
Yes, teams don't need managers unless they have people that need managing.
Also, teams don't need developers if they don't have any code that needs
writing. Ignorant dismissal of the value of other kinds of work besides their
own, combined with a lashing out against suggestion that they might not be
perfect, is one of (a vocal portion of? HN's nasty vices.

------
aj7
This started out well.

------
jasoncartwright
Perhaps it's cultural (I'm from the UK), but I can't imagine writing something
so painfully self-absorbed - and then expecting people to read it.

~~~
pnine
When I read the hn title I thought the direct reports wrote a readme about the
manager. That made a whole lot more sense to me. How many coffees does
(he/she) need to drink before it’s ok to approach their desk. How much detail
do they require when explaining an issue. These are the features I’d like
documented for new hires.

------
Havoc
IT people really love these kind of forced parallels. Can't really think of
another sector that does this. Maybe it's all that "Uber/Airbnb but for X"
thinking.

Unless your surname is .exe I don't think you need a readme file. You could do
the human thing though and discuss expectations with your team though...

