ksindi / managers-playbook

пятница, 12 июня 2020 г. в 00:23:02

https://github.com/ksindi/managers-playbook

📖 Heuristics for effective management

Manager's Playbook

Heuristics for effective management.

Principles

Have a bias for action and decision-making over planning and consensus.
Favor writing over meeting.
Understand how your products are used in the wild. For example, join sales and support calls.
Work backwards by focusing on the outcomes you want to achieve.
Encourage ownership by asking open questions.
Be the cheerleader. Celebrate success often and reinforce positive behavior.
Know how to differentiate between reversible and irreversible decisions.
Ensure every report is aware of the top priorities of the team, organization and company.
No task is beneath a manager. Get your hands dirty even if it's not coding:

One on ones

Never skip one on ones. It's the best platform for receiving and giving feedback. Most teammates value it and usually when they don't it's because they haven't seen one conducted well.
Aim for weekly one on ones.
Focus on 5 topics:
- Predictability: create routine, set expectations, normalize change.
- Ownership: offer options, clarify ownership, give more responsibilities.
- Purpose: clarify the big picture value and importance of their tasks.
- Progress: create milestones, share wins, celebrate progress.
- Belonging: team culture and management.
Questions to help frame each topic. "On a scale of 1-10 how would you rate:..."
- Predictability: How clear do you feel about what's expected of you?
- Ownership: Your satisfaction with decision power and direction?
- Purpose: How much your work makes a difference for the team?
- Progress: The sense of progression each week?
- Belonging: Your feeling of connection to the team?
Additional questions to ask on a less frequent basis:
1. Motivators:
  1. Which part of your work is most fun?
  2. What's not fun about working here?
  3. What are the biggest time wasters for you each week?
2. Long term goals:
  1. What skills do you want to improve?
  2. What career path are you looking for?
  3. Who in the company would you be excited to learn more from?
  4. What parts of the business would you like to be more involved in?
3. Organization awareness:
  1. What don't you like about the product?
  2. What's the biggest opportunity that we're missing out on?
  3. What do you see as your top 3 priorities this quarter? The team’s? The org's?
  4. If you were CEO, what would you do differently?
4. Manager's role:
  1. What could I do to support you better?
  2. If you were me, what are 1 to 3 things you would change?
  3. How do you feel about the amount of feedback you are getting?
  4. I need feedback. What are two things that I can do differently?
  5. What's one thing we could do to improve our way of collaborating?
5. Priorities:
  1. What are your top priorities this week?
  2. What will success look like?
  3. What are obstacles?
Encourage your direct reports to bring up topics:
See Getting more from your one on ones for more thoughts on effective one on ones.
There isn't one best management style. Figure out how someone wants to be managed in your initial one on one:
1. What did you like about your previous manager? What didn't you like?
2. What do you like to see from a manager?
One on ones where the report is also a manager are typically more "business" where the focus is on strategy, team health and project alignment.

Coaching

Default to open questions: ask questions starting with what, how, who instead of closed-ended ones like do, have, is to invite conversation and give ownership over a problem.
- "What questions do you have?" is better than "Do you have any questions?".
- "Why do you think this is the right approach?" is better than "Is this a good idea?".
- Respond with "What are your thoughts so far?" when asked "What should I do?"
Summarize what the person is saying so you're both on the same page and are pinpointing the problem.
- "It sounds like there are two issues, x and y. Which should we focus on first?"
Figure out how to make the meeting productive:
- "What's the next step?"
- "How should we track this?"

Feedback

Be prompt, ideally providing feedback the same day of the event that prompted it.
Get buy-in about providing feedback and reduce mystery by giving context:
- "Do you have 10 minutes?" ⛔️
- "Do you have 10 minutes to talk about this morning's stand up?"
- "Can I share some thoughts with you about how we've been working together?"
Don't pad negative feedback by beginning with compliments; it gives mixed signals.
Be specific even if it's positive feedback.
- "Good job!" ⛔️
- "I like the initiative you took to reduce the service's memory footprint. It encourages me to give you more ownership so that I can focus elsewhere."
Focus on data and not behavior:
- "I noticed you didn't address any of the comments made in your last three PRs"
- "I noticed that you didn't pick up the ticket I asked you to do"
- "I noticed your last feature release didn't have any tests"
- "Your code is buggy" ⛔️
- "You are always late" ⛔️
Talk about why this matters and who it's affecting:
- "I mention it because it's important we work as a team"
- "I mention it because the ticket I assigned you is critical to this quarter's roadmap"
Figure out together how to fix the problem:
- "What do you think of our process?"
- "How do you see it?"
Agree on an action plan:
- "How do we ensure we don't miss a ticket due date next time?"
- "What are a couple of actions you could take right now?"
- "What are our action items?"
Highlight positive patterns (remember to be specific).
- "It's great to see you teach X about Y so that they're as proficient as you. That's a trait of a senior engineer."
Replay instinctive reactions to help frame the conversation:
- "My initial reaction to your proposal is..."
- "Here's what I would do" is better than "Here's what you should do"
- "When you did X, I felt Y"

Thinking strategically

What would you do with one more person?
How is your team moving the needle? Are you focusing on the right things? How do you know the features you're building will benefit the customer?
What are your product's mission and tenets?
What are the company's top priorities this year? Where should the company be three years from now?
What are your "rocks" and "pebble" projects this quarter?
What company annual goals is your team driving and in what way?
If you were to get promoted, who from your team would take your place? What skills or experience does this person need to acquire?
What are your team's pain points? How can you move 2x faster?
What "dogs not barking" do you worry about?

Making decisions

Determine if the decision is reversible vs. irreversible.
- Reversible decisions can easily be changed. Examples: changing stand up time, contributing guidelines.
- Irreversible decisions cannot be changed without significant rework. These decisions should take longer and be documented and discussed. Examples: architecture changes, language decision, data models.
- A rubric on technology decisions by Sam Newman:
Whenever there is disagreement, focus on the intended outcome of the decision and make sure the team is aware of your reasoning.
- "While database X is better, I want us to standardize on one stack so that it's easier to maintain."
If someone disagrees with a reversible decision, set a date to revisit that decision with the team. Ideally you also have metrics to define the success of that decision.
- "I understand your concerns. Let's revisit this in a month and see where we stand."
- "We're tracking X now, let's revisit next quarter if it improves with these changes."
If someone disagrees with an irreversible decision, give them the opportunity to present their case. Regardless, everyone should be aware the decision is ultimately yours and the team needs to disagree and commit wholly to the decision made.
Document your decisions so that you can refer to why they were made and the tradeoffs your team faced.

Coding

Avoid coding in the critical path. Tips from Charity Majors:

Authoring a feature? ⛔️
Covering on-call when someone needs a break? ✅
Diving on the biggest project after a postmortem? ⛔️
Code reviews? ✅
Picking up a p2 bug that's annoying but never seems to become top priority? ✅
Insisting that all commits be gated on their approval? ⛔️
Cleaning up the monitoring checks and writing a library to generate coverage? ✅

Ticket and PR process

Set contributing guidelines for the team.
PRs should small enough to be properly reviewed in under an hour.
Prioritize PRs to unblock tickets.
Automate opinions like style with linting or code formatters like black.

Communicating

Writing

Favor long-form writing for proposals over presentations. Writing forces the author to think about the details and tradeoffs.
Favor enumerated lists over bullet list; they're are a lot easier to reference.
Encourage Amazon-style "6 pagers" and "2 pagers".

Email

Prefix the subject with [Action Required] if you expect the reader to take action.
Structure your email in the following way (from 7 Tips for Better Executive Communication):
1. First Paragraph — no more than 2 sentences. This would be the headline and critical information
2. Second paragraph — 3–7 bullets. The more bullets, the lower line length. Aim to not wrap sentences.
3. Third (final) paragraph — no more than 2–3 sentences focused on the action needed, follow up, and timelines.

Meetings

Avoid shitty brainstorm sessions by encouraging proposals written before having a meeting.

"Don’t defer decisions to meetings. Make decisions on the spot, communicate it over long-form writing, and use the meeting to discuss it." – Erik Bernhardsson
Avoid sync or recurring meetings with no standing agenda.
Always end a meeting with actions, owners and timing, so it's clear what next steps are.
For staff meetings, go around the table and ask reports what their biggest concerns are.

Many managers want to attend executive staff meetings, as it makes them feel needed and puts them in the know. I made use of this desire by setting a price of admission to the meeting: you had to fess up to at least one thing that was 'on fire.'" – Ben Horowitz
It's worth occasionally asking the meeting attendees whether the meeting is productive or how can it improve.
Before sending an invite, ask yourself why this meeting can't be communicated over email.

Hiring

If you can 'hire tough,' you can 'manage easy' – Sue Tetzlaff, The Employee Experience

Hiring is the most important decision a manager makes.

What to look for in senior engineers:

Owner. Takes ownership of a problem even when it's not 100% their responsibility; understands the why.
1. "Tell me about a time when you took on something significant outside of your area of responsibility. Why was it important? What was the outcome?"
2. "Tell me about a time when you made a hard decision to sacrifice short term gain for a longer term goal."
Handles ambiguity
1. "Can you tell me about a time when you had to solve an ambitious problem? Why was the problem important?"
2. "Can you tell me about a time when you had to make a decision without complete information? What was the situation? What risks did you take? Why did you make the decision you made?"
Team player. Takes feedback well.
Communicator. Can articulate ideas at different levels.
1. "Describe to me something you know well."
2. "You mentioned X in your resume. Explain it to me as if I've never come across it?"
Teacher. Enjoys growing other engineers. Especially important for senior-level engineers.
1. "Tell me of a time where you helped someone in your team grow."
Deep diver. Digs a level deeper to understand what's happening under the hood.
1. "Tell me about a time you were trying to understand a problem on your team and you had to go down several layers to figure it out."
Simplifier. Simplifies problems instead of just hacks at things and adds tech debt. Does the person have a build vs. buy mentality.
1. "Tell me a about a complex problem that you solved with a simple solution."
Missionary. Interested in company's mission or technology.
1. "Explain to me what your current company does and why it's important."
2. "What interests you working at [COMPANY]?"

What to watch out for:

Short tenure at companies. If a candidate typically stays at companies for less than a year, ask them why. There might be perfectly valid reasons or it might indicate a pattern that the person is difficult to work with.
1. Why did you only work at X for less than 1 year?
Menu of technologies. Resumes that just list technologies used instead of problems solved may indicate person may not be thinking big picture. Also a typical trait of junior engineers.
Long resumes. More than 2 pages may indicate the person has difficulty distilling what's important. That being said, there can be culture reasons for long resumes. For example, in some European countries, resumes are encouraged to be long.

Onboarding

Having a good onboarding process is crucial to the success of your team. It ensures new members are contributing as early as possible and are assimilated into your processes and culture.

An onboarding process is successful if your new team member can contribute a bug fix on their first day of joining.

Onboarding material:

Team mission
1. How is your team moving the needle for the customer?
Team members
1. Include: name, role/title, email, slack username, github username
Repositories and services
How to communicate within the team
1. Slack channels
2. Keeping yourself informed
3. Communication protocols during and outside of business hours
Documentation
1. Code contributing guidelines
2. PR review process
3. Ticketing process
4. Glossary of terms
5. Releasing code
6. How tos (e.g. migrate database, add secrets)
Getting started
1. Installation instructions (e.g. Docker, postgres).
2. A checklist of all accesses expected (e.g. AWS, PagerDuty)
3. Running your apps locally
4. Deploying your first bug fix
Meetings. Who should your new team member meet with?

Managing up

Make sure you and your manager are on the same page by sharing a document listing your project priorities, timelines and confidence levels.
Your manager also needs to manage up. Proactively update your manager on project timeline changes with brief answers to the following questions:
1. What is the new timeline?
2. Why did the timeline update?
3. How confident are you with the new timeline?
Nobody cares for blame and excuses. Own mistakes and document corrective actions you will take to mitigate them.

Managing sideways

Get buy in by presenting the problem and not the solution.
1. "What is the best way for us to do feature X?"
2. "I need you to do X and here's how" ⛔️
Ask for timelines to hold your peer accountable on delivery dates.
If you disagree on an approach, document your concerns. Having an audit trail improves accountability.
Create project kickoffs and standups to make sure you are aware of the other team's status and priorities.

Announcing change

Examples of change: promotions, reshuffles, restructuring.
Acknowledge the difficulty or opportunity of the change.
Appeal to emotions by using narrative to explain the why.
1. Why is this change important now for the company?
2. Who does this change affect?
Appeal to logic by using facts.
1. What metrics will this change achieve?
Socialize the change to get buy in.
1. Start with the people who it affects the most.
Examples:
1. Carta's covid-19 layoff