
Manager's Playbook: Heuristics for effective management - nielka
https://github.com/ksindi/managers-playbook
======
santiagobasulto
Everybody bashing 1-on-1s, but they're really important. A 1on1 doesn't need
to last half an hour and be full of red tape. The best managers I've had do a
5 minute check, but ONLY WITH YOU: hey, how are you doing? everything alright?
Any issues (personal or professional)? And off you go to keep on working. But
you know what? You feel _they care and they listen_. In these quick 1on1s
we've learned multiple important things. For example, the "what do you think
is a big time waster" question is usually brought up here, and it's very
useful to have the point of view of the dev team.

We're all devs and we love to live isolated: we thrive sitting in a corner
with our headphones and coding. But remember we can't escape our human nature.
Having someone that listens to you exclusively for 5 minutes, once per week is
very valauble.

~~~
ashtonkem
As a manager, I don’t do 1-1s for my sake. They’re exhausting affairs, the end
of my 1-1 days end in me basically losing all the energy required to work.

I do 1-1s because they’re one of the most effective tools in my toolbox to
check in on my team, get early warning on problems, and maintain quality
relationships with everyone.

~~~
nogabebop23
>> the end of my 1-1 days end in me basically losing all the energy required
to work.

aren't 1:1s a big part of your required work?

~~~
ashtonkem
Yes, and they’re the last thing I do that day, because I’m drained afterwards.

I wouldn’t call them a big part of my job, depending on how we’re measuring
“big”. They’re important, but they’re not the largest amount of time on my
calendar by a long shot.

------
OliverJones
I would add this:

The three Ps: pay, promotion, perks. People perceive you, their manager, as
all-knowing and all-powerful about them. You aren't. But you'll never convince
your team that you aren't. So:

1\. People never forget what you say about the three Ps. Never, ever, even
once, make jokes or offhand remarks about them.

2\. Don't say anything that might sound like a promise unless you are CERTAIN
you can keep that promise. NO: "I'll give you a raise IF I can get the budget
for it" YES: "It's budget planning time."

And this:

Layoffs suck. If you have to lay people off, do it promptly once you've
decided who. Don't wait. Don't dither. Get it done. Pending layoffs generate
rumors and anxiety that can make your company a horrible place to work. It's
always hard to get a team back on track after a layoff. Don't make it harder
by your indecision and delay.

------
volent
> PRs should always be prioritized. Aim for review SLA of 1 hour.

I don't agree with this. For the sake of the argument let's agree that a
review takes _less than 1 hour_ (which is definitely not always the case).
That would mean that an Engineer needs to check his emails / notification more
than once an hour to meet this SLA.

This is totally unproductive IMO.

I like most of the other points though, nice list.

~~~
bjterry
If you have a PR review that takes over 1 hour, it's very unlikely that the
reviewer will be applying the kind of focus that it takes to really review.
For the typical Silicon Valley style development role.

1 hour _SLA_ would be astonishingly, irresponsibly fast. In the real world, in
small teams that put in a concerted effort, the outlier best average review
times are like 6 hours based on real data. Ideally you would want to be within
a work day, but if you are under 24 hours you are doing better than 90% of
teams working at random BigCos the world over, I bet.

~~~
devo-x-lie
This all really depends on the maturity of the organisation and the team.

"1 hour SLA would be astonishingly, irresponsibly fast". Yes this can be true
for a lot of cases, but at the same time it's nothing 'astonishing' or
'irresponsible'. Again it just depends in what state and maturity level the
team and organisation are at.

Also, I think you are talking more from dev side of things? Would that be a
good assumption to make? If that's the case then your points are very valid,
but don't forget a lot of ops-like-teams work on code bases significantly
smaller than coding projects and as such that SLA is totally fine.

Let's also remember that an 'SLA' for a review should be a guideline, not a
factor to be always meet. There are always factors that will influence this.

~~~
bjterry
Yes, I was referring to the context "For the typical Silicon Valley style
development role" I mentioned.

Part of this may be that we are using different definitions of SLA. Normally
when people around me say SLA, they mean something that is an upper bound
pretty much always expected to be met (or else there are consequences of some
sort). If you are referring to a softer agreement than that, it could make
sense. If you were holding 1 hour as an SLA by my definition, that would mean
you pretty much need to always have someone on deck to immediately review all
PRs, to be safe.

I mostly posted because I don't want people who are less experienced to get
the impression that 1 hour average review turnaround is normal or necessary in
a typical development environment. In specialist roles, sure. For example, if
you told me your work was responding to support tickets created by customers,
and it sometimes resulted in PRs to modify your infrastructure-as-code, I
could see the team working out a system to always get reviews within an hour.

------
demarq
> 1:1 Most teammates value it

lmaof not at any company where I've worked. Everyone has hated it just hated
it

Here is why:

\- Its awkward because you often have little or nothing to discuss.

\- The person you are speaking to is pretty much powerless should you need
something to change

\- Its yet another meeting you have to attend

~~~
driverdan
> The person you are speaking to is pretty much powerless should you need
> something to change

Only if your company is terrible. Anyone in the company should be able to
recommend a change. If it makes sense it should happen. Full stop.

If there's something in your company that prevents change from the bottom up
it's very poorly run.

I say this having been a regular employee, manager, and founder.

~~~
eatbitseveryday
>> The person you are speaking to is pretty much powerless should you need
something to change

> Only if your company is terrible. Anyone in the company should be able to
> recommend a change. If it makes sense it should happen. Full stop.

On the whole this makes sense but in my experience at large companies this
isn’t how it always works. Often politics get in the way, or priorities limit
the actions available. Also depends on the suggestion itself. I’ve had
difficulties getting my suggestions heard.

~~~
nogabebop23
even small-mid companies (< 500) have this problem. Of the 3 complaints the GP
stated, it's the only one the manager can't fix easily

------
runj__
I don't think I've ever left a 1:1 feeling like I didn't waste my time, both
as a manager and team member. The structure of a 1-1 (as described by the
playbook) forces you to see problems where there are none. They are forced and
contrived.

A natural check-in every once in a while is much preferred in my book, I trust
my team members to bring up actual problems as soon as they see them. A
leading question forcing some reflection is fine but forced meetings for the
sake of the meeting is wrong.

~~~
replyguy912
I'm a big believer and user of 1:1s and don't think they're a waste of time,
because if there are no problems it gives me a chance to get a coffee, go for
a walk, get to know my direct reports - how is that a waste?

The challenge with natural check-ins is everything else in our world is
scheduled and it will eat all time not allocated. I block off the time and the
schedule tells my team mate "This time is for you".

I trust my teamm members too, but it's not their job to proactively bring up
every problem in a timely manner:

Some people/cultures will not do this but they will respond to empathetic,
well thought out lines of questioning.

some problems are very sensitive and scary and don't need the added burden of
"going to the boss to ask for some time to talk"

Some problems are not apparent and the 1-1 gives you a forum to discover them

Some very serious problems are not viewed as problems by your team members. A
huge part of a manager's job is to identify them early.

I do a lot of the casual and emerging management stuff as well; 1-1s are not
mutually exclusive. There are bad 1-1s too: right now with everyone remote I
think the quality has gone down because we can't capitalize on the personal
aspects. You learn that the 1-1 process is the easy part; actually giving a
shit and working at building relationships is the hard part.

------
IAmEveryone
This is written by a coder, for people like him. It's therefore no wonder that
people are eating it up: it's telling them what they already "know", or
believe to know, or hope to be true.

Does anyone still believe in that 10x coder cliché? I thought we had decided
to only use that idea sarcastically years ago? And, even worse, do they all
still believe (against basic principles of statistics and logic) that they are
uniquely able to identify and hire these übermenschen?

The one distinctly managerial thing it does imitate extremely well is to be
both superficial and contradictory: "Set aggressive but achievable goals".
Yeah, no shit! "Be customer-focused." Who would'a thunk? Additionally: do
weekly one-on-ones, write documentation, sit in on sales and marketing, do
whatever "upskilling" may be[0], recognise that hiring is your most important
job, and know as much about your software as anyone not doing any of those
things.

But, in all fairness, some typical managerial cruft has been cut. Or, maybe,
one of the introductory lessons of management at least in the US has so far
eluded the author: to at least pay lip service to issues like diversity in
hiring or enabling work-life-balance.

If you've seen some of the more successful companies from the inside, you know
they have gone through the motions so long they ended up actually believing
it, and are now reaping the rewards that come with teams that include people
from different walks of life, in both productivity and enjoyment.

Considering we've seen some startups almost disintegrate due to blind spots
with regards to privacy, security, or ethical considerations of selling
surveillance equipment to dictators or AI to drone fetishists, these larger-
than-the-next-release issues certainly seem to deserve mention, as well.

[0]: not killing your higher-ups, hopefully, but also not teaching, because it
would be silly to forgo such a common word, wouldn't it?

------
usrme
I am currently reading Michael Lopp's book "Managing Humans" and
wholeheartedly recommend it to anyone who wants more breadth on this topic.
It's a really easy read with some rather poignant examples.

------
jf22
Knowing the architecture and tech stack should be a stretch goal.

Depending on the people and the size of the team, people management and
communication can take more than 40 hours a week.

------
KeepTalking
The most interesting aspect of this playbook IMO is the cartoon. Using 1-1 to
bring up promotions.

When employees ask for promotions:

good managers know how to harness this ask with clear, manageable, attainable
goal setting and delivering on the promise. Most employees are also not beyond
solid transparent reasoning. Average managers get into a defensive mode

If anything good managers are like high-performance coaches, they understand
your motivations and channel your energy. The reality is most companies
promote people into management roles by picking people like them.

As a counter test, watch out to see if a newly promoted manager starts talking
and acting (in subtle nonconscious ways) like their manager or the real power
in the organization. Examples include - Working hours, decision making,
predictable agreeability and even hobbies etc.

~~~
ashtonkem
As a manager, it’s your job to grow your directs until they’re ready for a
promotion. It’s also your job to make sure that they _want_ whatever that
promotion entails. Typically speaking the crossover from IC to management is a
pretty common trouble point for engineers, and you should make sure that
nobody gets put into management who doesn’t want to go there. You’d also be
surprised about the number of engineers that are actually interested in
leadership too, fwiw.

As a manager myself, I actually keep a private sheet of the internal career
ladder and progress for each of my directs, with notes and an unambiguous
“meets expectations, exceeds expectations, or needs improvement” across each
category that company has set for their role. This helps me keep my feedback
to them consistent, clear, and focused.

------
acconrad
This is a great resource! More of a reference / bulleted list rather than a
playbook. I wrote something similar for my new front-line managers who were
playing with the idea of transitioning from IC to management[1].

The big things really are all about 1-1s, feedback, coaching, and delegation.
From everyone I've talked to the hardest part is the delegation piece. It's so
easy to fall back on our original skills as developers. And yet, it's more
important than ever to delegate those responsibilities whenever possible

[1] [https://adamconrad.dev/blog/technical-lead-
management/](https://adamconrad.dev/blog/technical-lead-management/)

------
paulie_a
I was really excited to see coaching listed and it was on target of good
advice. But it was generic also. I didn't see any related to permission based
questions. And I'll admit I didn't study the material heavily yet but I plan
to and hopefully be involved to expand on it. That being said I think this is
a great project! I look forward to seeing managers adopt whatever they can

I worked in that industry for a good chunk of time and there is a lot more to
it.

I'm no expert. But I strongly believe 1 on 1 are a complete waste of time.
I've never seen them be productive.

And don't get me started on 360s. They basically mean you hate your employees

------
jzer0cool
4 hours later and no comments. I think this deserves more comments. So I am
putting one here to take this initiative. This has good content.

Edit: and one day ..., when I'm hired as a manager for the first time I can
adjust to some things I like here.

~~~
enos_feedler
Agree this is good even for ICs. I am going to take some of these themes into
my manager 1:1’s now.

I especially like “purpose” since I need to find meaning in my work otherwise
I can detach or become disengaged. I work for a big company and its easy for
the meaning of tasks to get lost.

~~~
jzer0cool
Perhaps there is a way to find more meaning in the work? A new way to do
something, or automate, etc?

~~~
enos_feedler
Hmmm not meaningful enough. I can automate anything, at any company. I mean
deeeeeep meaning. Why does this company exist? How do I serve this meaning. It
needs to connect with the outside world. Impact people.

~~~
jzer0cool
I am in the same boat. To find myself how I can impact the world or people in
a positive way. Deep meaning. Purpose. Right now I fail to get hired at a
company I would be so very passionate about at this level. And I must earn my
living so that one day I can sustain running a company.

------
mikehollinger
If you like this, check out [https://www.manager-
tools.com/](https://www.manager-tools.com/) .

They’ve put together a pretty comprehensive list of topics from basics like
how to give feedback, or how to be effective with various types of
communicators, to more nuanced stuff like how to deal with a merger, layoffs,
or even how to handle personal scent issues.

I highly recommend checking out the site, their COVID19 series, and their map
of the universe.

------
CawCawCaw
This looks like a well curated collection. Kudos to the author.

------
chrisquinnr
This is a great collection. Lots of useful approaches, some of which I haven't
seen before. Sure, some stuff wouldn't work for us, but that doesn't mean it's
not useful to know about. Further reading section is also A++.

------
sharker8
I think I disagree on the "managers don't author features" part. This is
leadership 101. Don't ask anyone on your team to do anything you wouldn't (or
couldn't) do yourself. Maybe you have 10 years of experience authoring
features other places and now you're above that. But what if the place you are
now in charge of is so broken features couldn't get released even if you knew
how to build them? You're basically going to blame your subordinate individual
contributors' skill set or motivation or something. Without trying it
yourself, you won't see how broken it actually is.

~~~
ashtonkem
This is complicated, and depends both on the strength of the team and the
history of the manager.

On one hand, in many teams the manager is still in a semi-engineering role,
and might be the most experienced member of the team. On top of that knowledge
of the roadmap is quite the advantage when coding, since you have a lot more
context around requirements.

On the other hand, there’s a lot of systemic risk in managers deciding which
stories they themselves are going to execute on. There is a nasty temptation
for the most interesting and/or difficult tasks to get self-assigned to the
manager, which creates a silo and stifles team growth.

Personally I do much more hands on early during my time with the team, and
during swarms. But in general I tend to stay a bit more hands out and focus on
the things that only I can do for the team.

