Manager's Playbook

Heuristics for effective management.

Principles

Always be aware of what's going on in your team and product.
Know the architecture just as well as anyone else — and stay current with the tech stack.
Schedule 1-1s with your direct reports on a weekly basis. Schedule skip-levels on a monthly basis.
Be customer-focused. Understand how your products are used in the wild. For example, join sales and support calls.
Set aggressive but achievable goals. Work backwards by focusing on the outcomes you want to achieve.
When giving advice or feedback, encourage ownership by asking open questions.
Have a bias for action and decision-making over planning and consensus.
Be the team coach and 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.
Be the example. Only preach what you practice.
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 in 1-1:
See getting more from your one on ones by sbourke for more thoughts on effective one on ones.

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 this 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:
- "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 shows ownership and leadership."
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).
- "I like when you take initiative in cleaning up code because it shows initiative and ownership."
- "It's great to see you teach X about Y so that they're. That's a positive trait of a senior engineer."
Replay instinctive reactions to help frame the conversation:

from The Feedback Fallacy

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 pillars is your team driving and in what way?
What are your team's pain points? How can you move 2x faster?
What "dogs not barking" do you worry about? What are areas in your team 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 always be prioritized. Aim for review SLA of 1 hour.
Automate opinions like style with linting or code formatters like black.

Meetings

Avoid shitty brainstorm sessions. Don’t defer decisions to meetings. Make decisions on the spot, communicate it over long-form writing, and use the meeting to discuss it.
Encourage proposals to be written as Amazon-style "6 pagers" and "2 pagers".
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 asking 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.'" - Horowitz

Hiring

The best programmers are not marginally better than merely good ones. They are an order-of-magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design, or problem-solving ability. – Randall E. Stross

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 and new team members. It ensures team 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 the first day of joining.

Onboarding material:

Team mission
1. How is your team moving the needle for the customer?
Team members
Repositories and services
Documentation:
1. Code contributing guidelines
2. Ticketing process. E.g. label and story pointing guidelines.
3. Glossary of terms.
4. Releasing code.
5. How tos (e.g. migrate database, add secrets)
Getting started:
1. Installation instructions (e.g. Docker, postgres).
2. Getting the right accesses (e.g. PagerDuty).
3. Running your apps locally.
Meeting setups. Who should your new team member meet with?

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 effect?
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.

ews/managers-playbook