How to EM: Be the manager everyone wants

manager , search-featured

Being an engineering manager is hard. Supporting people well is harder. Lessons are hard earned and should be cherished. This post is designed to make explicit, and improve behaviors and practices. It reminds me how to behave and encourages my own continuous improvement.

This post uses the word manager, but many topics apply to all job functions, regardless of seniority or number of direct reports, zero direct reports included.

What does a manager do
Managing and Developing People
Culture
Process and Mechanism
Planning, Roadmaps and Resource Allocation
Hiring
Performance Management
Cross Org Influence
Team Insecurity
- Everyone wants to feel supported
- Maintain perspective
Charters, Re-orgs and Bootstrapping
Personal Motivations
Questions managers get
Product Development and Product Management
Business Acumen and Strategy
Appendix

What does a manager do

What are a manager’s responsibilities

How do you measure their success

What is a manager accountable for

The success of a manager is the success of the team. This manifests in 4 dimensions:

Dimension	Success Means
Business Results	Team delivers business value for our customers and organization. I define success (KPI), and help the team understand and deliver it.
High performance people and teams	Team is well gelled and team members help each other. Everyone has growth plans which fit their needs and they are executing them.
Engineering Efficiency and Process	Engineering systems and protocols ensure a pit of success. Process is automated, and releases have high velocity and minimal risk.
Technical Assets	Systems are extensible in the ways that support the business. Operational burden is minimal (side bar: to help me prioritize I’m on the pages), and technical debt is applied judiciously (take debt if you might be able to write off the asset).

How do you describe your job to people outside the industry

I run a factory which produces widgets and has employees. For those in the industry this translates to:

Dimension	Analog	Metrics and Measures	Success Means
Business Results	Produced Widgets	l20	I work with the business to help figure out the best “widgets we can make”, by understanding what people want to buy and explaining how our factory runs.
High performance people and teams	Factory Workers	l21	Workers in the factory are healthy, learning, want to come to work every day, and getting along with co-workers.
Engineering Efficiency and Process	Operating procedures	l22	The factory is efficient: Production is good and improving. Widgets come out consistently and on schedule. New employees know what to do. Everyone knows what to do during emergencies.
Technical Assets	Factory machines	l23	Machines in the factory adjust quickly for the different types of widgets we build. Machines require minimal maintenance and have high efficiency.

l20
Are wanted by customers
Are produced on time and on budget.

l21
Are happy based on surveys
Are getting promotions frequently
Recommend joining the factory to their friends
Work at the factory for several years

l22
Workers are efficient and safe with minimal effort
Mistakes are learned once, and never repeated?
Continuous improvement is occurring
Variance is low
Over time work is not required

l23
Support a wide range of widgets
Can be extended to build new widgets at low cost
Have high availability
Operate at low cost

Hardest part about being a manager

Firing: People think it’s firing but it’s not, see that section
Personally: Telling team I’m quitting, tears, ride bike, etc.
Actual: When need to surprise folks, abrupt direction change or killing projects.
Likely, but I haven’t done it: Layoffs, when know and can’t tell.

What do you do in the first 90 days

First 90 days is the bible here

Outputs:

Early Win: Figure out the situation, and deliver a win.
Trust: Relationships with team, and peers, and partners.
Knowledge: Know critical parts of business, tech, org.

What do managers do all day

_For non-managers, recall a manager’s purpose is supporting others, not making stuff. As a result they have a manager schedule, not a maker schedule.

In a typical 44 hours week, 24 hours are standing commitments with others, and 20 hours vary based on the time of year, and needs of the team, business, and partners. Vivek Garg has a good post on his manager of manager’s calendar if you want more insights.

Hours	Time Allocation
20	Variable Time - depends on season and team need
8	Team 1:1s - See the 1:1 questions
6	Partner 1:1s - PM, Design, Partner EMs, Other Developers
6	Reviews - Project, Engineering, Staff, Initiative
4	Recruiting/Networking - Coffee chats, sell calls, interviews

Depending on time of year, and experience of my team and partners, I’m doing 1 or 2 of the following with my discretionary time:

People Development:

Stack Ranking/Performance Reviews/Career Growth Plans
Low performers
Complex people situations (more often then you’d expect)
Extra recruiting

Product:

Strategy development
Road mapping
Pitching
Data Analysis

Execution

Escalations
Unblocking the team
Negotiating/Finding win/wins with other teams
Re-balancing projects and engineer allocation
Inter and Intra team conflict.

Tech/Organization

Generating content for a talk/program (e.g. D&I, Recruiting, People Development)
Architecture/Design/Engineering Excellence brainstorming, and review
RCA Analysis

Should managers be technical

Yes they are ultimately responsible for the outcomes of the team and that requires them to understand, confirm and nudge the team and partners. They should ensure the team is making correct architectural decisions and engineering excellence improves due to best practices.

They need to represent the team in technical forums, swag costs, represent laws of physics, bring back best practices, and catch upcoming incompatibilities and challenges.

Attend architecture and design reviews
Be on every page the team gets
Have strong relationships w/technical leaders like principal engineers
Follow major tech trends and product launches (keynotes, major tech blog posts)
Read seminal books on topics (ML, Cloud Native Apps, Data Systems, etc)
Have Side projects in assorted tech and ideas (ML, PWA, FaaS)

They also need to be experts at working with data systems and analysis, as much of their time will be analyzing customer, business, operational, and technical data.

Once developers become managers they have little time to use their technical muscle, and their technical Aptitude declines due to lack of use. Therefore I recommend before switching they are:

A very experienced engineer (MSFT L65, AMZN L6, FB E6).
A expert in at multiple languages (for me python, and C#)
An expert in multiple technical domains (for me networking and security).

Should managers code

Managers should read code on specific occasions, but they can’t be on critical path because their time is often needed to deal with urgent situations. Thus, they can only write low importance code usually something you’d assign to an SDE-I. At that point, you have a very expensive priority inversion.

That said, SDMs need to use their product just like their customers do to be able to better understand and meet the customer need. Likewise, SDMs need to use their development tools periodically, which should include the code/test/deploy cycle, so they are better able to understand and meet their team’s (aka other big customer) need.

SDMs should be reading code occasionally:

Spot checking - SDMs should have a good “something is fishy” intuition, and should be able to independently and discreetly prove or disprove their intuition.
Assessing people - Code is a major deliverable for developers and should be inspected as part of people assessment.
Deep dive during major outages - In high risk, time critical situations like outages, you want your best people reviewing the changes, and this includes SDMs. If an SDM can’t understand a high risk time sensitive code change, it can be, and should be simplified.

What engineering efficiency metrics should a manager monitor?

Lots, but these 3 are probably high on the list:

How much time is spent in outages/livesite/maintenance (don’t forget to include time that should be but isn’t due to lack of monitoring).
How often can developers check in?
How long does it take for a change to get to production.

Managing and Developing People

How do you coach

Coaching is a major part of the job, and covered in my coaching post:

Coaching is like midwifery. A midwife can not give birth to the baby, she facilitates the birth. Similarly, a coach can not give a solution, she must give birth to the insight from within the coachee. Coaching is asking questions, guiding, and facilitating understanding, and this post collects my studies on the topic.

What mechanisms do you have to ensure career development

Principles for career development

Peeps have an accurate, clear understanding of their interests, strengths, weakness, and next career steps.
Peeps have a clear understanding of level and role expectations for the current and next career stage.
Peeps understand how their work “ladders up” in impact and career development.
Peeps get frequent feedback on in progress work
Peeps and managers have a consistent understanding of the above.
Manager actually uses the process himself with her own manager.

To achieve these principles there are several tools:

Tool	Time Horizon	Checkin Frequency
Career Growth Plan	6m to 2y	3m
Pre Write Self Assessment	1m to 6m	4w to 8w
Frequent Feedback	Immediate	As Needed
Situational Leadership	Stage Dependant	Stage Dependant

How do you support folks with their career growth plans (CGPs)

CGPs are Forward looking and a good place to discuss what opportunities are required, and what major development areas should be tackled, and what’s required to meet the next career level. I.M.Wright gives some excellent insights

Each employee has a career growth plan (CGP). This is a document with open ended questions like:

What are you most proud of?
What is most draining?
What are your short, medium and long term career goals?
What are the steps to get there?
What are your gaps between now and the next step?

To help with the last two questions, this document has the list of expectations for the current level, and next level. For each expectation, you fill in your self assessment of where you are at on the expectations relative to level, sometimes it’s below, at or above. This is great tool to ensure you and those supporting you are in sync, and that they can best support you.

How do you support folks by pre-writing self assessments

Think through what will be delivered in the next 1-6 months, and how it will be delivered.

Most companies have a performance program - At MSFT it’s connects, at FB it’s PSCs and Amazon it’s Forte. As part of this process, an employee writes a self assessment for the work that happened in the last 6 months - 1 year, and then the manager uses that as a basis of the review they’ll write.

There are several advantages to pre-writing these documents:

The peep and manager can be deliberate about what work is done, and discuss if projects make sense, and if they are the right projects.
The peep and manager understand the impact provided by the work.
The peep has a record of what they’ve done in the performance period, instead of only having a crisp memory of the last few months, and can use that to write the self assessment.
The manager can calibrate the work to be done so there are no scope surprises.

Good self assessments are concise, focus on impact, and then how you delivered the impact. More details at I.M Wright:

[Clearly measurable impact] by [work you’ve done yourself and/or with others].
- Relevant artifacts, or quote from others validating the claim.

Here are some fictitious examples modelled on my own career:

Improved Azure virtual machine boot time from 12 minutes to 2 minutes at P90 by investigating end to end system behavior, understanding end 2 end system operation, creating and driving agreement to all up goal, and then working with teams to estabilish budgets, and holding them accountable to delivering them.
- At first my team was skeptical that the performance improvements could be achieved and were hesitant to invest, but once we saw the organizational support and monthly meetings of progress we found it inspiring and made sure we contributed to the goal.
Drove XXX$ to charities, and increased Alexa Shopping DAU XXX % (XXX to YYY) to by proposing a charity giving feature and implementing it in 5 months. Complexity, 20 eng/months, supporting work from 5 teams, across multiple divisions
Delivered XYZ, required to deliver TLS support on windows phone at very high quality. Complexity 1 engineer, 4 months - however requried ramping up on complex error prone C++ code base, and no bugs found
- Igor’s delivery was on time and of high quality. The feature had no bugs in production, due to high test coverage, which was impressive given the high complexity of the C++ code.
Increased team morale and cross group collaboration by proposing weekly team lunches, and monthly lunches with the broader organization.
- The monthly lunches were great. At one of them, I learned Bob on the other team was building a similar feature to mine and so we collaborated and were able to save 3 weeks of coding time.

You should be observing the key to these self assessments is impact. The goal isn’t motion, it’s impact. If you don’t know the impact, you should ask yourself (and your manager) why you are doing the work. Pre-writing self assessments is a great way to do this.

How do you give fast, frequent, feedback

I aspire to provide immediate observed feedback, for something that is about to happen (like reviewing a document), or a de-brief after a critical meeting or review.

I keep my eyes open for opportunities for feedback from my observations, and from soliciting feedback from peers and partners. I take the feedback and figure out the best way to give it.

My priority is “catching employees doing something right”, so I can re-enforce positive behavior. Even better, with positive behaviors I can provide them in public which not only benefits the employee, but also re-enforces that goodness with the team.

Consider the first 90 days
Ensure you get coffee with everyone on the team
Get them checking in as soon as possible
Get them a mentor

How do you think about situational leadership

More details are in my coaching post. Here’s a preview:

As people learn new skills they experience a learning curve, which requires different support at different points on the curve. Situational leadership describes this in detail, but in a nutshell, while learning new things, people go through this grid from 1 to 4.

Competent/Confident	Confident	Scared
Incompetent	1. Foolish Novice - Thinks they can do it, but really can’t	2. Novice - Knows they can’t do it, and feels bad
Competent	4. Expert - Know they can do it, and they’re right	3. Journey man - Thinks they can’t do it, but actually they can

In each of these stages different support is required.

Competent/Confident	Confident	Scared
Incompetent	1. Instruct and Explain - Tell them what to do	2. Guide and Encourage - Show them how to do it
Competent	4. Empower - Explain Why Not	3. Facilitate - Explain Why.

What are the level specific career expectations and growth strategies

Depends on the skill level (E.g. levels ): SDE-I is a junior developer, SDE-II intermediate, and SDE-III senior and above. Also see my post on the differences between Tech Lead, Architects and Managers.

Level	Approach
Junior	Not a lot of variance. Have a rubric for junior SDE skills and make sure they are getting the opportunity to learn and execute each box. Make sure they have a solid mentor, and opportunity after opportunity to round out their knowledge.
Intermediate	Now it’s about how are you helping the team, growing your contributions. Bigger experiences, maybe out side the org, both to build your skills, and increase your org visibility. Double down on super powers, close red flags and blockers. Very satisfying to watch people “blossom” into leaders.
Senior/Staff	Here you’re getting people that are at a career level and are happy with a lot of what they’re doing. Now it’s helping folks decide how much they want to grow, and where they want to improve. Here it’s finding mentors, and how we want to split responsibility and cover each other. Also opportunities for what they own for the group (30-60+) e.g. security or process or etc.

My approach, and frequent peep questions.

Level	Things I repeat and repeat
Junior	l10
Intermediate	l11
Senior/Staff	l12

l10
We hired you because you’re smart+really good. If you can’t understand something, it’s probably the presenter doesn’t understand it well, as opposed to you not understanding.
You are new, and need to learn and need to spend a bunch of time asking for help and guidance. I have one rule - you must come with a bad idea (which will start becoming good ideas). You fail when you bring nothing, you ace it when you bring a bad idea. We’ll help you develop that bad idea, and help sharpen your thinking skill.
“You have a fresh perspective - If something doesn’t make sense ask, for us, we’re like fish in water, so challenge our assumptions”.
I’m here to help you close gaps, sharpen their understanding by teaching it to you

l11
How do you make the team better?
What are you gonna be known for?
You’re the owner, you’ll do everything and I work for you. What help do you need
Do shadow coaching, where I might be writing/pr-doing work but they do the send/take the credit

l12
Great post on being a staff + level engineer
Are you clear on Tech Lead, Architects and Managers.
What are you driving for our larger organization?
How are you maximizing our benefit?
How do we make sure we compliment each other?

How do you help people switch jobs

My goal is to find people the right job, not the job on my team. I coach a lot of people through this, and here are my most popular posts:

How do you keep people motivated

Classically, motivation is comprised of carrots and sticks, where carrots focus on extrinsic motivation like compensation. Turns out sticks and extrinsic motivations fail for creative tasks. Instead I focus on the following dimensions

Motivation has 2 dimensions, personal experience and team environment. Personal experience is based on the book Drive, and is about encouraging Autonomy, Mastery and Purpose. The team environment is about the culture in which you experience the personal dimension.

Another lens of motivation is satisfaction and dissatisfaction:

Satisfaction (SAT) is not a lack of dissatisfaction (DSAT). SAT and DSAT are orthogonal experiences. DSAT is the reason you can’t sleep well at night, and SAT is reason you set your alarm for 5am so you can get an early start tackling your favorite problems

How to motivate through personal experience

I use Daniel Pink’s DRIVE model. TL;DR: Extrinsic motivation doesn’t work, you need intrinsic motivation, which is driven by Autonomy mastery purpose.

Autonomy: Direct thy self

You choose what you work on (Link: How does resource allocation work)
You are the end to end owner.
You make the decisions, though I’m here to support. Even if I disagree, it’s your call.
We collaborate on the definition of success, and then you choose how it gets done.
I support you in private, by helping you understand success, sharing how I’d do it, helping you see around corners, and bringing up signals and context you may be missing.
I support you in public by re-inforcing your message and needs, and nudging where nudges are required.
You know the team has your back
I protect you from harmful rays of upper management and business
Hack-a-thons

Mastery: Become the best you can be

(Link: Managing and developing people)
I help you brainstorm what skill you want (or need) to master.
I remind you that building mastery is painful, and that’s OK. (Link: Situational Leadership)
I encourage frequent feedback by encouraging sharing small increments, spikes, small diffs, etc
I encourage continuous improvement, retros, and mentorship and menteeship
I’ll push you to 110% of your capacity, but I tell you when you’re at 90,100, or 110.
As you build your skills, I help you find bigger and bigger opportunities and/or Exposure
I am on the lookout for projects that help you find what makes sense for you.

Purpose: Make the world a little bit better

Focus on the why
Call out the impact
Call out the small wins
Share the success with the team
Share success with partners and boss
Remind you putting the team first, and supporting others is a very strong purpose in and of itself

People also care deeply about coaching and career growth:

Catching people doing things right.
110% of capability but clarify doing 110% vs 80%

How to motivate through team environment

I focus significant energy nurturing the team culture:

As a team we all aspire to a culture where coming to work is fun, the team members put the team needs ahead of their own, the team gelled and by people being vulnerable we built a strong sense of psychological safety

I spend significant energy generating Moments:

Of all the places we spend our time, work is the one that dominates. However, when we look back on our lives, work is often the thing we remember least. Why? Because we remember our lives through peak moments, and there are few of those, especially positive peak moments, at work. Luckily, peak moments can be created and leaders can be taught how to create them. This post explores opportunities and techniques to create these moments.

Some moments like:

Constant celebrating people doing stuff
Hack-a-thons
Playing cards for appreciation (Link: Playing cards for appreciation)
Managers making breakfast

How do you give challenging feedback

Why is feedback challenging?

It’s a surprise
Folks don’t want to hear it
Folks don’t think you have their best interests in mind.

Deep diving on what makes conversations hard:

Surprise - see around corners, and bring up anything I see ASAP, and foreshadow. Meet frequently, know what people care about.
Attack the messenger - High Trust, Know how and when the person likes to hear stuff. Address what they care about.
Don’t want to hear it - Self Aware, Think I have their best interest in mind, Put it in terms they want to hear it.
Over dramatize - Anticipate what they’ll care about, pre-address.

Types of tough conversations to flesh out:

Performance, Charter, Re-org, Team mates leaving, Lay Offs.

What’s the point of 1:1s

1:1’s are the highest ROI activity and the most expensive. They take 100% of both parties attention in a non-scalable manner. At the same time:

If on average 1:1s gives an 0.25% performance improvement, you get a 12% per performance improvement per year, which equates to 300% in ten years.
If there isn’t a forum for discussion, many concerns and bottlenecks will be ignored. Those ignored concerns and bottlenecks are lost opportunities in the best case, inefficiency in the median case, and catastrophe in the worst case. (Using an exception handler analogy, the default exception handler is ignore all, and we know how that works out)

My goal for 1:1’s is to:

Build trust and relationships
Coach and be coached strategically and tactically
Teach and Learn context
Have confidential, awkward discussions (part 2)
Allow others to express emotions and let off steam in a safe space

(Again with that programming analogy, the 1:1 is a debugger attached catch all exception handler. This allow all concerns to be discussed, understood, rethrown, reprogrammed or ignored. I know - the analogy needs work, help me make it better)

What do you do in 1:1s

My favorite opening is “What’s on your mind”, then I focus on asking (coaching questions) and end with “what can I do immediately to help you?”

I push for awkward conversations. When my peeps have nothing to talk about I ask some of my favorite prompts A few things I don’t do:

No public status reports I discourage using 1:1 to share the public news and weather “status report” - we can read that offline ourselves. A valuable use of time is the “inner and private stories” on the status - What is hard, what is most fun, where do you want to improve?
No deep dives when I could just do offline homework I think 1:1 off the cuff deep dives are an anti-pattern, an indication that there’s a missing artifact that’d be valuable to a wider audience. I’ll often say can I get a TL;DR and “How would I go about learning X,Y or Z”? If the answer is “ask me”, I’ll often recommend a low quality on paper brain dump we can review together. This lets us efficiently have an async discussion which captures Q&A in a durable form. Once we’ve done the easy async discussion in the doc, we review the comments together with more complex questions, and more private context, and more discussion.

I have less frequent, but extremely important 1:1 types like:

Career discussions A discussion around what we should be focused on for the next 6-18 months.
Promo preparation meetings - Help ensure we’re on the same page about what needs to happen for career trajectory and promo.
Performance Review Feedback
Leadership card evaluation exercise (so good, needs its own post)

Other thoughts:

I aspire to be accessible - I encourage folks to come to me any time (but most don’t).
I “manage by walking around”, just seeing what people are up to and working on.
I group my 1:1’s on the same day (or over 2 days) because 1:1 is a special frame of mind, and it’s hard to stay in that zone.
I wish I used a 1:1 document, as that seems to be a best practice for most domains.
The current norm is 30 minute 1:1’s but I enjoyed the old days when an hour was the norm. I often wonder if we’ve sacrificed effectiveness for efficiency in the 30 minute 1:1 culture.

How do you handle communication problems

High order bits:

Success is not “communication style”, but ability to influence. Influence comes in many forms and mediums.
Some things labelled communication problems, but they are much more serious and need to be handled differently. E.g. Lack of clarity of thought/intellectual horse power and being a jerk.
Focus on strengths is 3x as effective as shoring up weaknesses. Leverage strengths and partner with others to maximize influence.

There are different types of communication problems each needing a different strategy:

Verbal diarrhea
Dominates Conversations
Abrasive communication style
Not listening to others
Unclearn writing (too verbose, not enough context)
Verbal/ESL/Not comfortable with in-person verbal communications
- Pre-write thoughts
- Toast masters
- Use pictures
- Say not great on my feet, follow up with a document
Uncomfortable in group settings

How do you handle promotion preparation (and fever)

Surprises are BAD:
- Haven’t set clear expectations.
- Requires mini RCA
Goal:
- Engineer and Manager shared understanding of promo gaps and plan.
- Engineer feels they came to conclusion himself
- Engineer aspires to get to that level, and feels on track
- Engineer gets new opportunities/support required.
- Engineer doesn’t want to be over leveled
How: Start w assume engineer right - lets look at the criteria together.
- Skim now and deep dive in next 1:1
- Ask for self evaluation
- Review and get on same page, sometimes manager thinks below and above what engineer does.
- Go over with examples together
- Ask “How would you describe your behavior vs someone else’s”
- Ask “What gaps do you see”
How: Create a shared plan create plan to close the gaps
- Projects that stretch in those areas
- Mentors that can help close the gap on those areas
- Training/etc

Promotion fever is my word for engineers that are completely focused on promotions above all else. In general they fall into a few categories: 1) Not Ready, 2) Just hired, and believe under levelled 3) Ready, but didn’t get promo due to bad luck. Regardless, we go through the promotion preparation process.

How do you identify and grow potential managers

Engineers that are interested in reading this post make good manager candidates. The path usually start with getting an intern, then being a tech lead with heavy mentoring. Then having them take over as many as people issues as people are comfortable with them tracking.

Help them preview as much as they can - for example

Intern
Mentor
Volunteer to do jobs for the manager
As a technical lead do some proto managing on behalf of the real Manager.

Be a strong IC first

Make sure you’re a senior enough engineer before becoming a manager (AMZN - L6; FB - E6; MSFT - L65). Once you become a manager, your technical skill drops as most of your energy is focused on other tasks. So, if you don’t have a strong enough base, you’ll lose your ability to help assess and provide input on technical tasks.

Read this:

90 days as a manager - Great insights to what’s different and how to assess if it’s right for you.

How do you grow top talent

Recall career is just one part of your life

Often, when folks think of career development, they fixate on their job title and compensation. Those aspects are important, but I encourage folks I support that career is only one aspect of life, and they should look at their life holistically

How do you have a difficult conversation

From Simon Sinek, a great script:

I need to have a difficult conversation
I’m afraid to have this conversation,
I’m afraid to say something wrong, and accidentally trigger someone
I know having this conversation is more important than my fears against it
Please work with me to struggle through this.
Because want us to tackle this subject

Culture

What is your ideal culture

Tough question. I need to put more thinking and polish into this.

Culture has 3 components: The team, The execution model, and the growth mindset

Team: Coming to work is fun, team gelled, and ahead of individuals
- Team gelled, and always helping and growing each other
- People put team ahead of themselves, to support each other.
- Folks have high trust, so can be vulnerable, knowing others want to grow and support them.
- Hanging out with your friends
- Work filled with moments
- Team first, whole greater then the sum of its parts
- Everyone provides kuddos to others
Execution Model: Imagination Executed Sustainably
- Ship as frequently as possible.
- Test cheaply, early and often.
- Always paying down technical debt
- Never be blocked
- I hate the term “bring solutions not problems”, it encourages people to freeze. Instead -
  - “bring ideas, even terrible ones, with your problems”, caring and lead time to fix is most important
Growth Mindset: Continuous improvement, with very open feedback, and desire to improve.
- Career Growth
- Technical Growth
- Retros, but also action item tracking.

How do you help a team gel

Team lunches
Moral Events
Help people see each other as 3 dimensional humans - talk about personal stuff.
Encourage people to think of the team as an entity, and how to improve the team, not themselves.
Encourage people to vocalize their appreciation publicly
Encourage people to ask for help, and get help
Remind people it’s intimidating to ask for help, and they can take a stand to make it happen.
Have the team focus on success of the team, ahead of personal success.
Encourage people to improve the team at every opportunity.

What order would you introduce culture

When I joined FB we were full remote, and started with only 1 30 min team meeting every 2 weeks. Here’s what I worked with the team to establish

1 x week team meeting w/demos
1 x week team meeting
- replaces 1x week demo and team meeting:
2 x week stand up
1 x week tech talk/deep dive
- deep dive sessions, guest speakers, TIL sessions
1 x 2 week demos
1 x 2 week retro
3 x week lunch

How do you make a good culture

Model myself
- On All the Pages
- If team is working I’m working
- When I make mistakes I apologies
- If I drop the ball I make it clear.
- When someone does well I celebrate and call out.
Catch people doings things right
- Coaching stuff
- Put it front and center
- Let team take ownership of it.
- Incite pride and purpose
Repeat/Repeat/Repeat

How do you think about ad-hoc insights/questions from others, even if you’ve already thought of and maybe presented the doc/plan/answer already?

(others == peers, VP, interns, doesn’t matter)

Concise answer: I really, really appreciate it.

Robot answer: The return on investment (ROI) is fantastic. Let’s do the math.

For the other person - They already thought of something, the cost for them to bring it up is super cheap.
On my side there are two cases:
- I’ve already thought of the answer/insight, explaining it should be super cheap
- I haven’t thought of it, now it’s not cheap, but could be a huge saving down the road, great ROI.
- Bonus: I have thought about it, but explaining it again with the twist brought on by that person adds a new insight and improves my understanding or explanation.

Human Answer: When I get these questions/insights, I don’t feel questioned/seconded guessed, I feel honored. The other person is super busy and has spent their precious energy thinking through an issue I care about, which is essentially caring about my success. The other person has a tonne of experiences and perspective different from my own, and it’s a real gift when they spend their energy on me.

How do you handle Remote Work

I’m writing this stuff my rough outline

What about Work Life Balance

Work Life Balance is so important to me that I wrote a manifesto - the opening paragraph:

I don’t want to die knowing I spent too much time at work and I bet you don’t either. As a result I want to work with people who value a culture encouraging them to balance their family, health, hobbies, and work - aka work-life balance. To make a culture real leaders needs to walk the talk, and I’ll describe how I model a work-life balance, and the mechanisms I use to help team members achieve their own balance.

In the rare event you do want to die knowing you spent too much time at work, try to remember more hours rarely helps. In XKCD format:

Equally important, when folks consider their career, I remind them there are more dimensions to their life, and they should think about their balance. There are some years and halfs where they want to focus on their career, and others where the focus will be family and health.

How do you deal with a team that disagrees with the leadership

Step 1: Believe and deeply understand it. Either I believe in it, or I deeply understand the decision and have disagreed and committed. As part of committing, I’m all in, and will share that.

Step 2: Listen to the team. The team has concerns, hopefully I can predict them ahead of time and be prepared for the easy ones, then truly listen to new concerns, and address them.

Step 3: Focus on the win/win, and talk through a ripcord.

Agency and Psychological Safety

I gave a talk on lies we tell ourselves

Kudos Boards - Appreciations

Both helpful for a short period of time, and for a longer period of time, kuddos boards let the team get together and celebrate what they appreciate from their co-workers. This has many benefits:

People are appreciated for thier contributions
People are reminded how impactful their work is
Good behaviors are recognized and reinforced
The team bonds and grows

A nice format for this is a “clock” with everyone’s name on it, and the center of the clock having great prompts like:

How do you like being questioned/micromanaged?

This applies to me, and I need to think about if this is a good part of culture. I like to tell people:

Never worry, I’ll think you’re “questioning me”. I like sanity checks.

If you already had the thought, it’s free for you to say it. If I’ve already thought about it, it’s free for me to share my reasoning.

Catching a bad assumption on my part, or even more important, something I haven’t thought about - priceless.

How do you transition from mercenaries to missionaries

Mercenary - A hired gun who does exactly what you tell them without question Missionary - A person who believes in the mission and will do what they believe is best

When there’s too much top-down direction, a team can turn into mercenaries. They stop thinking and just do what they are told. Not good.

What you want is missionaries, people that deeply believe in what they are doing.

TBD: TODO add specific things here.

Process and Mechanism

Theory of Process

Why:

Turn input into outputs
Reduce variance and setup a pit of success.
Scale
The human equivalent of great tools (source control, linters, bug management systems)
Don’t waste “mental juice” on solved problems - see (checklist manifesto)

How:

How to measure success of the process, what will you inspect, when will you adjust?
What other process is this similar to, can we co-coalesce with something else?
How will you get buy in from up, out and down?
- (Bright spot, then land and expand)
Who is the owner?
Ownership lifetime, per quarter, or forever.

Thoughts:

The organizational equivalent of habits
Culture vs Process

The dark side of process

The upside of process is that we can do things without thinking. The downside is that we stop paying attention to process cost, small errors, and become resistant to change, which is often positive at a minimum and often required.

This can be especially true when process is created high in the org chart to solve a specific problem in another part of the org chart, and then applied universally, even where the problem does not exist.

The antidote - A review of process is essential to ensure it’s still getting the maximum value with minimum cost.

Toxic process - Bad process will disenfranchise ownership and stifle passion. It’ll slow down things that can be fast. There is nothing more powerful than a motivated engineer, don’t let process take that away.

On Change

There are a few kinds of changes.

One way door changes should start with -100 points because:

There is only so much change a team can handle
Change has unexpected consequences,
Before the change, many problems, most of which you don’t know about, have been solved by evolution, and will re-appear after the change.
Many solutions, are like a 4 sided rug in a 5 sided room, no matter the solution, you still end up with a problem, the devil you know vs the devil you don’t.

Two way door changes are much safer when performed well:

Start with a pilot
Let the larger group adopt it if they feel it has value.
Come up with a criteria to roll back the change
Setup guard rails to monitor to roll back.

That sounds like good intentions - Factories and Artisans

Process vs Good Intentions
Toyota Assembly line vs Artisan
The inconsistency from passionate projects

Never have a human do what a computer can do

Use auto style for code review styles
Gather data from bug systems instead of having humans do it.
Automated tests vs human execution
Multiple copies of the same data

Rich communication - Team meeting

Continuous Learning - Deep Dives, Knowledge Transfer and Guest Speakers

Engineering Excellence - Operational Review and Correction of Errors

There should always be an on-call, an engineering excellence work stream, and a periodic review meeting and a correction of errors process.

How do we know our customer is having a good day?
How do we maximize our velocity
How do we keep our developers happy.
How do we sleep well at night?
How do we get max learning from outages?

By the way, I think a manager should be on all pages and outages. This is a great way to get a strong appreciation for boots on the ground reality.

Write up for all outages, Correction Of Errors for major outages
Maximize value of mistakes, don’t make them twice.
For all customer impacting events, review w/Customer Impact, root cause understood, and commitment when to address.
Observability
- How do we get a page next time?
- How do we see what’s going on?
Testing systems.
- Very high leverage activity

Data Driven - Customer and Business Metric Reviews

Continuous Improvement - Retrospectives

Team Participation and Feedback - Surveys and Polls

It’s very easy to “think” the team is getting what they want, or has gotten what they want. A fast, easy way to validate this is having polls before something happens, and surveys after.

Some examples where we use polls:

Should we move this meeting to another time?
Where should we go for lunch
What questions should we focus our limited time on?

Some examples where we use surveys:

Which meetings are a good use of time (special survey)
How are we doing on XYZ
How helpful was this presentation, what could have gone better (TODO: link to a useful survey)

Pro tip for surveys - use part of a meeting to complete a fast survey. This ensures completion isn’t just another thing that needs to be done.

Quality and Technical Growth Design+Arch Reviews

Really a preview, not a review.
Ensure that tech assets are high quality and require minimal re-work.
Ensure team gets cross trained.
Catch stuff as early as possible
Get developers used to being on the whiteboard

Planning, Roadmaps and Resource Allocation

Defining Success - How does goal setting work

The goal is to maximize the impact of the team.

Small companies and insulated teams can do bottom up goal settings, but as companies get larger, it’s hard to have sufficient insight into the company priorities, and hard to align goals across teams, which lessens the impact.

Larger teams require a top down business strategy intersected with a bottom up execution recommendation.

Ideally Engineering Excellence (EE) is built as part of a feature as it is in part of the feature costs. NOTE: It’s OK to defer some of the engineering tasks till after shipping but it’s not OK to say a project is complete till the engineering excellence costs are paid.

Systems rot over time, so EE should have a standing budget, usually 10%-20% of team capacity. The team should be empowered to spend this budget as required.

For major projects, a large EE project is required (like a technology migration). This should be outside the standing 10-20% EE allocation. Such projects should be agreed to by the business and have explicit goals.

Technical Debt is often a bad thing, but like debt it is a good thing if there is a good chance a project will be abandoned and you won’t need to pay the interest. Examples here are speculative projects which may be rolled back, and bridges to a future technology.

How do you do planning and come up with roadmaps

6 step process

Define Tracks
Find “boulders” in each track
Break boulders into projects, cost and analyze and order by ROI
Determine cut lines
Resource allocate
Execute (It’s 1% inspiration and 99% perception)

The only time when the 5 step process should occur simultaneously across all tracks is when a team is forming, or taking a major pivot. At all other times this series of steps should be occurring continuously and asynchronously.

The full process is expensive and the team should be shielded from some of it but here’s some engagement that should happen:

Product Manager - Fully engaged in every step.
Data Science - Impact analysis and sizing
Projects and costing - Senior and Staff engineers, because they have higher accuracy and this ensures their buy in.
Interested Parties - The process should be transparent, and anyone wants to, including junior engineers, are welcome to see how the process works. However, given they aren’t required for the process, this shouldn’t come at the expense of their day jobs

[TODO Picture]

What makes a great schedule

NOTE: Even though plans tend to be reviewed at a half year cadence, it’s important that the dates below are relative for the health of the team.

Great schedules and roadmaps can solve many problems, based on people’s levels and the time granularity.

Team feels inspired knowing they’re doing great things, and senior folks see career opportunities
- By having a roadmap that stretches out at very course low precision/accuracy projects for +6-12 months
Intermediate folks feels career opportunities by seeing opportunities that interest them.
- By having a roadmap with lightly scoped projects for +2-6 months
Team feels comfortable re-jiggering ordering and ownership by knowing hard vs soft deadlines
- By having a roadmap with clear deliverables and dependencies for 0-3 months
Junior folks (and senior) build their estimation muscles and has a sense of their own personal velocity by creating and reviewing granular estimates
- (The more senior folks help junior folks do this, and also build their coarse estimation muscles)
- By having granular estimates down to he 1-2 weeks, and having someone help create and review the estimates

How does resource allocation work

Resource allocation is maximizing the intersection in the Venn diagram - “Personal Preference”, “Business Need” and “Probability of Success” for the business, team and individuals.

The success metric for a manager is supporting the team so that they know the constraints, and can self organize to maximize the business, team and individual Venn diagram coverage.

This process gets harder then it sounds based on the state and ambiguity of the tracks, balancing juniors and seniors, career development desires, and future hires and business ambiguity and reorgs.

There are some more concepts I need to flesh out:

Personal growth and career development People should strive for projects that stretch them and make them grow. This is always a business priority (to make the team better), and usually a personal preference. There are times when people have other things going on, and don’t want to grow, and that must be honored at a high priority.

Opportunity cost - If a senior developer is doing something a junior developer is doing, then you have turned your senior developer into a junior developer and no-one is doing the work of a senior developer. This is also why teams need a blend of junior, intermediate and senior developers.

Right sizing projects, and support When people are growing, stuff is going to be hard, and it’s important they don’t take on more then they can chew (see ability to succeed), even when the project is the right size, it’s important the person has the dynamic support and mentorship they need.

Keeping slack in the system Anxiety is the difference between reality and expectations. Slack is the tool that helps us better model reality, and keep stress under control.

The road building analogy to software development roles

Imagine we want to build a new road.

Start of time: PM figures out there’s a market for a road, and the needs of the customer, and comes up with a rough idea of where the road needs to be between.
Slightly After: EM starts surveying broadly, and discovers can’t go some places because there’s a giant mountain, or somewhere else as other folks have tried digging there, but fell through, and that someone has started making a path from the other side, so if we meet at the middle it’ll be cheaper.
After: Senior Engineers come in and start figuring out where they’ll build, what’s the safest path, and what’s a realistic schedule
After: Intermediate dev’s are assigned a chunk of the road and start building it.
After: Junior devs are given very clear tasks, and start doing them.

Prioritize Ruthlessly

A great mantra for life, individual contributors, and especially folks supporting more junior folks. A great article that deep dives into the topic here.

How to provide coarse estimates SWAG/T-Shirt size

T-Shirt size - This is a word for creating coarse cost estimates that use sizes (S, M, L, XL) to correspond with cost. T-Shirt sizes don’t have a standardized map to time units so I recommend using actual time units. To avoid “false precision”, limit yourself to a small set of coarse time units e.g. (1 quarter, 2 quarter, 4 quarter, 4+ quarter).
SWAG (Scientific Wild Ass Guess) - This is another word for cost estimation. In this context, it’s synonymous with T-Shirt size.

When asked to provide a SWAG, the main goal is to stack rank projects. This is done by computing the return on investment (ROI), where the Return is based on DS Impact Sizing, and the Investment is based on the Engineering cost.

For half-level planning, we’ll estimate the cost in a coarse manner (in engineering quarters) to understand two things:

If we have enough capacity, which is calculated by multiplying the number of engineers by the number of quarters.
The fastest possible shipment time, calculated by the critical path assuming all engineers are available from the start.

For example:

Suppose it takes 1 quarter for backend, 1 for Android, and 3 for iOS, but the tasks need to be completed n series (one after another). This would have a t-shirt size of 5 engineering quarters (a swag of 4+). With the critical path, or the longest sequence of tasks, being 3 quarters.

Hiring

What are you looking for when you recruit

Most companies have their “competencies” they test for. But I abstract it down to:

Smart (Can code, understands, sees critical paths)
- Teach me something you deeply understand
- Walk through X, and Y, how do you, explain the tradeoffs.
Get things done (wants to ship, owns it):
- What matters to you?
- Tell me something hard you did?
- Tell me your favorite parts?
EQ: (Not an asshole, Continuous Learning, Sees impact off his action, self aware, Team First )
- Tell me a time you got in a fight
- Tell me the hardest feedback you received
- Tell me the hardest feedback you gave

Do they prefer to hire only experienced folks

I need a pipeline of developers for mentorship, fan out, and succession planning.

Need a Principal per 30 people.

Ratio Senior: SDE-II: SDE-I (1,2,2) => ten person team: 2, 4, 4.

Everyone grows by learning and teaching.
A crappy job for an SDE Level-X is a growth opportunity for SDE Level-(X-1).
SDE-IIIs want to think hard and lead.
SDE-IIs do the bulk of the work, and are fully independent.
SDE-I bring energy and excitement, but still dependent.

(Bad analogy) A team is like a “conveyor belt”, people continually improve and mature and want larger scope, requiring a constant flow of incoming college hires.

Are they more comfortable with generalists or specialists

Generalists - 99% of time

Industry changes too much.
Mostly about Architecture/Design and SDL and coding, domain and language are easy to learn.

Specialist - 1% on very specific teams.

File system
Distributed system transaction processing
Firmware engineers

Want full stack teams:

FE -> Learn the customer empathy through user interactions
BE -> Learn the tech chops of complex system.

How do you think about hiring

My priority list:

A full blown site outage where the product is hard down and I’m actively getting it back online.
Recruiting
Everything else

Recruiting is ultimately product sales, where you’re selling the team you support. Sales breaks down into the following:

Meeting the candidate’s needs: Great salespeople don’t sell their product, they understand and solve their customer’s needs. Start by understanding what the candidate values and needs. If that’s on your team, fantastic, if not help them find the team that’s right for them.
Your solution: The product you’re building, the culture and people on the team, and yourself.
The Funnel: Inbound Marketing, Referrals, high touch, post sales support (see next question)

How do you think about the hiring funnel

Before even thinking of funnels
- Strive to be a class act and do your best.
- It’s a small world. People will learn what you value, and how you work
- Create public artifacts
Top of Funnel
- Interview events
- Internal Talks
- LinkedIn Posts
- LinkedIn Appreciation
- LinkedIn Articles
- Always help recruiting
- Connect to warm candidates
- Go grab coffee with them
- Mentorship of folks, volunteer for mentorship
- Intern Talk
Mid Funnel
- Post interview - magic trick, after interview lets make time to chat
- Push to get interviews done ASAP
- Push to get results to candidate ASAP
- Walk out of interview connect on LinkedIn and chat with them
Bottom of the Funnel
- Focus on the needs of the candidate, then talk about how job can solve their needs
- Beer/Coffee/Call
- Share artifacts, and evidence of my team’s operations
- Invite them to talk with the team I support
- Invite them to have lunch with the team
- Help them build and evaluate their dream job, and job switching decision making matrix.

What about structured vs free form interview loops

External Structured
- Leadership skills - most important
- Self aware - a critical part of being a leader
- Design
- Coding
Internal, Structured but Different
- Review internal code/design/documentation artifacts. Ask candidate for artifacts they’re proud of.
- Go on a whiteboard to have them explain one of their systems, or help you on yours. No need for the candidate to practice, this is just them doing their day job.
- Talk about hard situations they’ve had. Listen for the criteria smart/gets things done/emotionally intelligent

What are better kinds of interviews

I’ve heard the tech interview model described as the second worst kind of assessment strategy, it’s only better than everything else we know.

That might be true, but I’ve also seen some novel ideas for interviews (Indeed uses these), and I’d be interested to try using them:

Do a code review
Do a mock interview + debrief
Review their public work (like Github)

What do you do when someone says they are quitting

I always start with “Happy for you, sad for us”. My goal is to find the right role for an employee, not to have them on the team. Ask if you want me to talk you out of it or to reinforce your choice. Help you think through decisions. TODO: Add story of Neha Teams should be like rivers, not lakes. Rivers are fresh and move, lakes are stagnant which is bad.

What is a tribe?

Rarely you’ll find a group of folks that follows each other even as they change organizations and companies. Usually a senior person will show up in a new place, and before you know it much of the organization will have joined her. I’ll call this a tribe. If you find a tribe you gel with, I strongly recommend following the tribe.

Tribes are awesome because

How to form a tribe: - TBD

What to do if a tribe appears around you: - Decide if you are aligned with the head of the tribe, if you’re not, you probably want to go.

How to join a tribe: - TBD

Performance Management

Performance Reveiws: Calibrations PSC, OLR, Connections

Performance reviews exist at most companies (I’ve been through Connects at MSFT, OLR at AMZN and PSC at FB), and for good reason they:

Ensure performance is evaluated consistently and
Force feedback
Distribute compensation in accordance to impact
Validate growth plans and find opportunities across the organization
Assess bottom performers and ensure action is taken

Best Practices For Performance Reviews

Before Calibrations:
- Continue seeking feedback for team members, and anonymizing and providing feedback
- Continue explaining how tracking is occurring
- Do mid-point checkins and peer manager review for hard situations (e.g. bottom performers and pending promotions)
- Consistent presentation template - this makes it easy for everyone to assess the presentation of people
- Remind engineers you might find new data late, and what you do that could change their assessment
At the start of every calibration session. Reminder that:
- Confidentiality is critical - Amazon says breaking confidentiality is a firing offense, which is great.
- Reminder of the importance of catching unconscious bias.
- Point is to calibrate the assessment process so it’s fair.
- Include senior engineers - this helps the engineers trust the process is fair, and provides critical input.
After Calibrations:
- No surprises to the engineers, they should already be aware of their rating as it’s been provided consistently.
- Provide as much feedback to engineers after the process, owning the message.
- Focus on growth plans (see above sections)

Your role when representing people:

Gather data on what happened through the evaluation period. Gather more data on things that surprise you (like peer feedback, or accomplishments you wer enot aware of)
Present it as well as possible
Ensure the presentation is evaluated fairly by seeking feedback and focusing on fairness.
Calibrate yourself to ensure

a post on preparing for calibrations

The pain and the suffering of performance reviews

I’m calling Performance reviews PSCs below, translate to your own company’s process

For managers, PSCs are the super bowl, tight timelines, high stress, and high stakes. This leads to pain and suffering. First, a quick note on pain and suffering. Pain is a signal telling you need to act/pay attention. Suffering is the story you tell yourself, with such unhelpful attributes like practicing failure in advance and judging yourself from the past.

The pains of the PSC - Pain is a good thing, it tells you to pay attention, and act

Take a lot of time to write
Have very high consequences for the individuals involved
One slip can cause big issues

The things I suffer about during PSCs - Suffering is unhelpful, try to avoid it

Someone gets a bad outcome because I :
- didn’t give them the right opportunity or sufficient feedback
- missed something critical during the year that I should have caught
- wrote the packet poorly, or presented the packet poorly (or both)
- found new information while presenting the packet
- procrastinated and didn’t get everything done
As a result I am:
- screwing over the people who trust me most
- bad manager
- getting a well deserved bad review

How to reduce pain and suffering. Have no confusion, I rarely do these, but I wish I did

Treat your own packet, just like those of your employees.
- Yes, that means you’re writing your own review.
- Leave place holders that you’ll fill in when you get data from what the folks you support did.
- It helps your boss know what you did, present it easier, and see expectations miss matches (likely needing more data from you).
- All the rules below also apply.
Update packets through the year. No wordsmithing.
- At least quarterly, monthly is better.
- Otherwise you won’t remember.
- Quickly course correct.
- Include feedback you’re getting.
- Bonus point for including what you plan to do.
Block your calender at work, and tell your family you’re working nights and weekends
- Set expectation this will take 110% of your energy.
- Ensure your family knows and can support you.
- Remove all other stressors from your life at this time.
Prioritize packets by difficulty and impact
- Don’t spend much time on mid-band no debate packets.
- Spend a lot of time on borderline packets.
- Spend a lot of time on promo packets, especially at the higher levels.
- Spend lots of time when there are misses.
Only think about a person’s packet and calibrations when writing their packet.
- You can lose so much energy by ruminating on the suffering above.
- It’s super hard, but if you catch yourself, tell yourself if I want to think about packets, I need to have my editor open and looking at a packet. Otherwise I need to think about something else.
Only work on one packet at a time
- Need to have a sense of progress/completion.
- No switching mid section/person.
- Only work on one section at a time.
- You are allowed to copy good sections from other packets.
Do 3 versions of a packet
- Need to have a sense of progress/completion.
- Spinning on wording early is pointless. And it’s stressful.
- Wordsmithing something you won’t keep is just procrastination.
- First version gather all the evidence, relevant ideas, ask folks you support for more evidence here.
- Second version: put it into rough sentences; go over it with another manager.
- Third version: make this one good. It’s near final. Get a final review with other managers.
Make a very granular schedule, including when you’re talking to people
- I schedule 3 blocks a day, including who’s packet, what section and what draft.
- I schedule time to get feedback from the people you support.
- I schedule time to get feedback from other providers.
- I schedule time to review with tech leads.
- I schedule time to do mock calibrations.
Get support from other EMs
- Everyone can see our situations better then we can.
- It helps make us objective
- It gets us over some things we’re stuck on by drawing out our reasoning and correcting our faultly logic.
- It’ll remind you of your responsibilities and the employee’s contibutions to situations

Some definitions for low performers

You’ll often find the following words used in these discussions.

Performance Mangement - the general process of ensuring the team is high performing. Usually refers to having no low performers on the team.
Managing out - Going through the PIP process with an employee.
Up or Out - The term indicating the employee either improves, or will be managed out.
URA - UnRegretted Attrition. A person who is no longer at the company, and that’s not regrettable
PIP - Process improvement plan. The formal final process of performance management. Performance expectations are clearly documented for employee and manager, and if the employee does not improve, they will be terminated.

Performance Management for low performers

TL;DR: Performance Management is a good thing. There is a natural percent of people who are URA, and left to their own discretion many managers will not let go the full set of these people. At a large scale (100’s of employees), and for periods of time (like during times of massive hiring), setting a URA ratio is a good thing. The key is enforcing it at a large scale, and having guard rails to make it objectively fair, and giving employees the ability to improve.

And now the long version for non-managers

If you’ve ever worked with a low performer who couldn’t do their job, it’s draining. They drag down the team due to missing commitments, and needing to be bailed out as unexpected work from the team. It’s even a drag on the low performer as doing poorly in your job is a miserable experience, and they’ll feel way better off in a place they are successful.

All of this is to say managing out lower performers is a good thing.

And so the question becomes who should be managed out? Given career expectations it should be clear when someone is not meeting expectations, and thus who managers should manage out and when. It also turns out at large numbers statistics can help.

At the scale of 100’s of employees there will be low performers unable to do their job. The exact value varies depending on how aggressive companies hire and deal with low performers, but I’d guess 1%-5%.

For a while, Amazon was getting terrible press, so they got rid of URA ratios. You know what happened? Way less than 1% of people were fired, meaning the manager’s good judgment wasn’t working well enough.

As a result Amazon re-instated its URA ratios.

The types of URA

I’ve observed two categories of URA, those with a skill gap, and those with consistency gap.

Skill Gaps are usually the result of a mis hire, an over leveled hire, or a premature promotion (the reason promos should be lagging not leading). Skill gaps often manifest as a lack of a core competency, lack of communication skill, lack of collaboration skill, or a quality gap.

These problems usually show up quickly, and can be assessed looking at artifacts objectively, and are the easier performance management case. You explain expectations, provide coaching/mentoring/opportunity and if improvement is not seen the PIP will be very straight forward.

Consistency is the harder PIP for a few reasons. First, the employee will have periods of acceptable performance, sometimes above expectations, and then they’ll have misses, so the PIP needs to capture a time period when there is a performance gap. Simultaneously, it can be difficult to root cause inconsistencies, is it really an employment consistency issue, or is it a structural/situational issue.

The who and how of performance management

Three “Players” in this situation:

The struggling employee
- Remember being in the wrong role SUCKS. Employee is going home after long day, and feeling like shit (rinse and repeat)
- Once in right role - will feel great. Seen lots of times this happens.
- Let employee ‘self discover’ gaps and judge, but you must set down the truth.
- Should not be a surprise. Should have already gone through role guidelines and gaps.
- Clear set of gaps, and expectation for required improvement.
- Progressively lay out process, so they know where they’re at and what happens next.
- Help them know it’s the wrong role, but they have lots of strengths (look we hired you), and you’ll be well loved elsewhere.
- Help them with how to find change, mock interview, job changing guidance
The team
- Weak performer means others on team have to cover both in mentoring, and picking up dropped ball.
- Sets a bad example for the team
- Team knows the weak, and dislikes it.
- Need to mitigate impact of weak employee.
The manager.
- Emotionally draining. But you own giving them an opportunity not their success.
- When they’re in the wrong role, best thing that can happen is getting them to a place where they are successful.
- Can be time and energy intensive, robs the team and good employees of your energy.
- Ensure criteria for demonstrating employees recovery is sufficient. Get pre-agreement on criteria with your organizational leaders.
- Remember, all employees getting into this process will improve because they are being chased. Ensure their improvement isn’t temporary

Most companies have a well laid out process, that you follow.

First there’s a “zone of concern”, when the manager focuses carefully on the employee, without scaring the employee with the seriousness of the situation:

Set employee up for max success
Ensure clear expectations
Get mentorship
Explain to employee you believe in them.

Then there’s an official pre-PIP. Which is the same as above, but really clear with employee.

Document everything, and share with the employee so there is no miscommunication
Ensure clear criteria for PIP removal.
Ensure org agrees removal criteria is sufficient
Meet weekly for formal review.

Then there’s a formal PIP. Depends on your company but very similar to above, but with clear legal terminology.

How do you coach employee back to success

Really depends on the employee
Generally:
- Re-enforce the person is good.
- Remind person the team is there to help them
- Clarify expectations
- Provide a short term lowering of expectations
- Consider LOA or accommodations as appropriate

How do handle poor communication, ESL, ineffective communication in some modalities

Poor communication is often quoted as a performance gap, but requires a deep dive. Is the issue frustrating employees/being a jerk, having a thick accent, having good written but poor spoken communication.

Being a jerk is not a communication gap, it’s a toxic behavior that needs to be addressed immediately.

The other communication issues need to be examined carefully. The question is not do they have a clear accent, or do they engage vocally in meetings, the question is can the employee influence to the expectations for their level. If they can great! If not, there are many alternative communication methods/coaching to improve.

Some tools I’ve seen used:

Examples for employees who don’t like being vocal in a meeting can be to provide feedback before/after the meeting.

For folks who can get flustered representing their work in standups, pre-write their updates and read them during the meeting.

Cross Org Influence

Through process build relationships and earn trust
“Start with why” and seek first to understand,
- As many touch points as possible EM/PM/TLS
- Maintain EM/EM ad-hoc channel for risks and concerns
- Periodic meetings with key players, tell them you want to listen
Next up “What” - Win/Win or No deal, Getting to Yes
- Balance short and long term goals
- Find growth opportunities for folks executing from both teams
- Agree on shared goals -Common Currency
Agree on Shared Goals
Exec Buy-In on Shared Goals
How, When, and Who (in that order) - Approach, Dates, People allocation
All plans change when you’re punched in the face
- Execution Tracking
- Flex funding cross org

Team Insecurity

Very common situation
Team feels nothing they/EM can do about - but that’s completely wrong!

Everyone wants to feel supported

Happiness is a choice!

Every day I walk past a beggar. He only has 1 leg, and like 6 teeth, but he’s always smiling. Whether it’s wet or dry, snow or sun, always a toothless smile. One day I asked him “Hey man, I gotta ask, why are you always so positive?” And he answered:

“Look, every day I have a choice, I can be happy or miserable - why would I choose miserable?”

As a team, we want to support each other, so let be help each other by reminding each other of these things and the importance of choosing happiness.

Maintain perspective

When there’s mental pain, our time bound shrinks, as does everything else
Share all the good stuff and big pictures.
Extra focus on appreciation.
Increase time ranges.
Be patient.

Charters, Re-orgs and Bootstrapping

Reorgs have two dimensions, staffing and charter, both of these need to be addressed and communicated.

There are several types of reorgs. Here are some of the ones I’ve executed:

The genesis: When you start from scratch

Building a team from a greenfield of 0 has two aspects: hiring from 0 to staffed and building out a new charter and vision.

In an ideal world, you’d execute the following hiring plan:

Start with a high level view of the business
Put in places the senior developers to build out the architecture and process
Start working by getting your SDE-IIs and SDE-Is

In the real world, you’ll most likely:

Have a vague idea
Add people as you find them (hard stop when too many juniors - see below)
Pick some easy wins, and get those started, ready to pick up debt to see what we can do.

Note: It’s usually easy to hire junior people, and when there’s pressure to start, you’ll be tempted to just keep adding junior folks. However, there’s a world of hurt here. If you’re planning on starting with too many junior folks (or getting pressured to) borrow more experienced folks from other teams. Ideally borrow them full time for a few quarters, but at least borrow them for brainstorming, design, architecture and mentorship.

Hopefully, early in your hiring process, you’ve been thinking about your charter. Charters and such are hard. Here’s the strategy I tackle:

Come up with a north star vision.
Start your first experiments in tech and market.
Find the first wins to be able to inspire the team, excite the investors, and really partners.
Build out an early roadmap and products.
Keep learning and improving as people join.

Telling the team

Assume this will be very hard on the team. It’s critical they hear it from you first. It shows respect, and lets you reduce the largest anxieties. This will be emotional for a lot of people, and the team will be deeply influenced by your emotions. While you should acknowledge the loss, and the potential uncertainty and upcoming bumpiness, you must be positive about the future.

To ensure everyone hears from you first I recommend the following:

The days before:

Write an FAQ for the questions you expect.
Practice your story the day before with people you trust, review and tune your FAQ

The day of:

Clear your day of all meetings.
Schedule team meeting at the end of the day.
Make a list of everyone on the team and when you’ll be telling them:
- Check your timing to make sure you can get everyone done, taking into consideration when people come in.
- Write out what you think their top concerns will be, to ensure you focus on them
- After every meeting take notes about their concerns, and good talking points for future meetings.
Meet folks ad-hoc first starting first thing in the morning to have enough time.
Plan to grab people ad-hoc, and give them as much time as they need. This ensures - You’ll be on time to this high impact meeting. - You’ll not be in a rush, you can give people as much time as they need. - You have time to take notes after the meetings and tune your message, and re-charge your positivity
When deciding the order, start with the folks that’ll take it best.
- This will let you have some “easier sessions” to tune your message
- This will give you new talking points, and get new questions
When talking to people
- Make sure you have high energy reserves, but keep your energy low and caring, talk slowly like this is the first time you’ve told anyone.
- Warn people it’s gonna be a big surprise
- Remind people they matter and that’s why you made sure they heard it from you first.
- Let them know who you’ve told and who they can talk to.
- Remind them it’s essential not to talk to anyone else till the team meeting so everyone hears it from you.
- If they are in shock, and don’t know what to talk about, ask them if they’d like you to tell them about your experience, and common questions others have
- Tell them they’ll have lots more questions, you’ll talk through them at the team meeting, and they’ll have more questions in the coming days, and that you’ll book time with them over the next few days.
- Make a note of how they took it, and if you get more talking points
- Tell the people that are more positive how they can help make it easier on the team, think about when they can jump in during the team meeting.
- Use silence to let people digest and come up with questions
In the team meeting
- Tell people you’ll recap what you talked about, and give a more complete story
- Hit all your FAQs, including the hard ones
- Prompt the people that can add positive ideas (who you already asked) to share the positive parts
- Be available after the meeting, and offer to talk to anyone
- Remind people you don’t have all the answers yet but you’ll figure them out together.
- Give people as much autonomy as possible, tell them they should tell you the best way to wrap up their projects.
In the next few days:
- Be around a lot, offer to talk to anyone anytime.
- Schedule meetings with everyone in case they have more questions. If they don’t, you can leave early.

The FAQ

How does this impact my review?
How long till we stabilize?
Why did this happen?
Did we do something wrong
What choices do we have? Can we follow the re-org
What happens to my existing/ongoing project
How is their existing work evidence of greatness
Is it just gonna happen again in 6 months
What are the exciting opportunities, and why are they better then the old ones
Why is this re-org designed the way it, why would you have done the re-org this way.
Will more people be hired
Answer how to motivate them:
- Autonomy - Let them recommend the transition plan.
- Mastery - Remind them how good they are and how the team will succeed on the next project
- Purpose - Remind them of the continuity of purpose and
- Motivation Deep Dive
What am I working on next
How long till we have more clarity
Why is this a good thing (people, tech, purpose)
How long have you known
How long till you felt good about it
Domain specific questions

The split: When a team outgrows a manager

The merge or you leaving the team: When a manager leaves

Splitting Horizontally vs Vertically

When you have multiple teams, and multiple user scenarios you decide to organize horizontally (each team owns tech solutions, spanning multiple user scenarios), or vertically (each team owns user scenarios, spanning tech solutions).

This is hard, a few thoughts I’ve gathered:

Deciding if you split horizontally vs vertically is at the highest level asking what you want care more about:

customer metrics vs engineering metrics and efficiency.
what’s best for the customer vs what’s best for the platform.

Depending on how much tech needs to be build and how much specialization is required you will need horizontal teams. For example, the operating system, the networking stack, the hardware are all horizontals.

TODO: Table of pros and cons

The flip: When charter changes

There are two categories of flips: A) Flip to new domain (genesis) or B) Flip to take over another teams space. Genesis is mostly covered above, so here we’ll focus on taking over another teams, or another teams partial charter.

In general when this happens there are a few common reactions

The new charter is too small

A common reason for this is the old team that had the charter, likely only planned out for 120% of there engineers. So, if they had 2 engineers available, they planned for 3 engineers of work. A new incoming team having 10 people, will think there’s only work for 3 people, and be sad.

The new charter is much simpler then expected The new charter isn’t as interesting

It’s common to oversimplify from a distance. Once the team gets into the details, they’ll either see it’s true, and they’ll find new good stuff to do, or, far more likely they’ll find much more nuance, subtlety and ambiguity in the new space.

Playbook and antidotes

This is pretty similar to the whole team getting a new job, and the first 90 days applies:

Early Win: Figure out the situation, and deliver a win.
Trust: Relationships with team, and peers, and partners.
Knowledge: Know critical parts of business, tech, org.

A great way to do this is set the team up to do spikes on the major work items, this will overcome the above concerns, building knowledge and motivating the early wins.

Insufficient progress - Double down or pivot

When progress is insufficient, there are two situations, both painful, with overlapping symptoms, and some shared requirements.

1/ You believe the charter can still be successful, but needs more time due to execution gaps/insufficient progress/insufficient resources.

2/ You no longer believe the space can be successful.

Both 1/ and 2/ can be subjective, and there can be disagreement, but an objective criteria can help establish this.

Symptoms:

1/ Progress towards goals is slower than expected. 2/ Team is demotivated - the team knows the goals, and they know they aren’t making progress.

Communications:

1/ Surprises are bad - you need a plan, and to let your leadership and partners know what is going on, and time till you’ll have a plan. 2/ You need to let the team know what is going on, and that a plan of action is happening to make it right.

Space can be successful, just hasn’t yet - hold the course

This is often a result of execution difficulties, or underestimating the difficulties of progress in a space. Action depends on the situation.

If there are sufficient resources, and there is high probability success is likely - this section is in roadmapping and execution.

If there are insufficient resources, or resources are blocked - consider the space can not be successful playbook.

Space can not be successful, or can’t be successful in a reasonable time frame

This will be a painful situation. The team has invested significantly: emotionally and through their work and a drastic change is required. The team and the manager will have a desire for wishful thinking, but that must be avoided as additional investment is waste of resources, often the sunk cost fallacy.

In these situations, you need to “declare success”, wrap up the work and move on.

In the best case, this decision will be made as part of the normal rhythm of business with sufficient lead time so a clear set of new projects to transition onto are found, and the team can wrap up their current work, and switch to the new work on their roadmap without any disruption except for feeling bad their previous work didn’t work out as well as they had hoped.

In a common case, the decision will be sudden, often with an edict from leadership to take immediate action. In this case, the priorities are:

Manage comms with the team - decide when to tell folks, see some of the re-org discussions
Negotiate a transition period with leadership.
Figure out an interim roadmap till longer term work can be found
Figure out how to wrap up work, and ensure fair credit attributed to work in progress.
This is a highly emotional situation support the team, and yourself.

NOTES: - How to know if you’re in a dip or a cul-de-sac for the project.

Layoffs

(Some of this is copied from Ashish )

Before:

Be careful about telling people you don’t know anything; at some point, you will, and you can and will be trapped in a lie. (I don’t know the best thing to do here).
Remind people if they can’t control something, don’t focus on it. Focus on what they can influence.
Do not tell people they will not be laid off. Unless you know, don’t.

Day Of:

Life suddenly seems to have slapped you hard and slowed down the day you find out your team is impacted. These are folks you have worked with in some cases for years; they came over to your team because they believed in you and your vision. The news makes you feel so small and helpless. While your heart is sinking and you are still trying to convince yourself that this is really happening, you are still expected to run the show, business as usual.

The folks you support still trust you and want you to help them navigate through the situation, get them the answers they are looking for, and you may not have any clue of what to do next.

Get up early and get ready.
This will be a very emotionally draining day.
Excellent chance you won’t know what’s going on.
Remind people it’s a tough day and take care of themselves.
Discourage people from speculating what and why.

Next days:

Mental health experts recommend against group meetings. Keep everything 1:1.
Reduced productivity for days.
Possible re-org, with potential for lots of uncertainty.
It’s easy to “mourn” the people who were impacted. However, they are not dead.
Ask impacted folks if they’d like to get together; it probably means a lot to them to get closure.

General

If your team/other people aren’t directly impacted, remind them it can be a very hard day for others, so be empathetic.
There will be pain; people may say negative stuff from a place of deep emotions, and that’s a function of pain.
Some people need to make jokes to relieve pressure (I’m one of them). Remind them, and yourself, to be respectful of others at the same time.
Everyone processes this differently; offer to meet folks and have 1:1s privately, some will want them, others will not, honor their wishes.

Personal Motivations

I guess the whole post is personal, as these are my opinions. The questions below can’t be “evaluated” as they deal with internal motivations, however they can be questioned to determine if these are really my motivations, and if I”m being consistent between my actions and motivations.

Why do you find management attractive

Few things make me prouder then this public feedback on LinkedIn from people who worked with me over several years.

On my deathbed, the product I will be most proud of is the people who I watched blossom and grow. It’s cliche, but when you love your people they know it, they thrive, and do their best work. It’s not just about the work, I want to make sure people think of their lives as well, because, well, that’s even more important.

I’m also energized by getting shit done. The thought of shipping, clearing roadblocks, and never being blocked puts a smile on my face.

Speaking of smiling, nothing brings me back up like reading this kind of feedback that I got when I left a team.

Goodbye Igor! Thank you for helping me reach the next level both physically and mentally. I cherish the moments when we ground through challenges like peak days, when I was in trouble and you said “That’s why I’m here, give it to me I’ll make it happen”, and of course, when you show your magic at happy hour! You are a great boss and great teacher.

Lastly, I love understanding what is going on, coming up with win/win solutions, and framing those solutions into a meaningful story that people rally behind and deliver. Some more words that bring me up.

Igor - Your passion, energy, intellect, and sheer force of will – so intense, so inspiring, so powerful we still feel it 3 years after you left the team.

What is your dream job

Loading (/job)

What are your career aspirations

Loading (/being-a-great-manager)

Why do you think you’re a good coach

When I explained to someone coaching it the most important aspect of management, they asked why I thought I was a good coach. Took me a while to answer, but here you go:

I believe you can’t be efficient with people, you can only be effective. And it always pays off.
People are not ‘resources’, they are 3 dimensional humans, with lives outside work, emotions(like pride), and desires.
I’ve read and digested slews of self help books which while often mocked, are filled with great models.
I actively study and practice coaching and effective decision making

Why do you prefer being a manager to an IC

I think as a manager, the day to day sucks. People problems, managing by spreadsheet, fire fighting, policy violations, etc. But, those days when you look at the team, and see them helping each other, and growing, and when you catch people after a few years and they tell you how impactful you were to their career, and how working on the team was the most fun they ever had - it feels superb.

As an IC, it’s almost backwards, the day to day is fun. Coding, design, debugging, even fire fighting an outage trying to get the site back up, it’s very satisfying in the moment. But, as an IC, when you look at the software you built, and you realize it’s long deprecated, and replaced by something better, it’s a pretty meh feeling.

So, in a nutshell, for me those moments of intense satisfaction make it worth the loss of the day to day joy of being an engineer.

At each stage of road productions things go wrong and we learn new stuff. TODO Come up with more examples

Questions managers get

What do you do all day

See the manager’s schedule section.

What’s the best/worst part of your job

See what do managers do section.

How do you get anything done with all of those meetings

The majority of the things I do are about amplifying, de-risking, and unblocking people. Much of that works best when there’s someone else in the room. Furthermore, many of those meetings, especially 1:1s and small groups energize me, making me able to tackle the rest of my work with gusto.

For tasks that require me to be heads down and write/think, I try to get that done crazy early in the morning when I have zero interruptions and maximum intellectual horsepower.

What do you think developers do

What can engineers do to make manager’s jobs easier

Realize you and the team are a domain expert

Due to positional authority, manager’s statements can be overweighted. However, managers by not being immersed in the problem know the least. Remind the team, and yourself, that the manager knows the least about the tech, and their words should not be overweighted.

No surprises

If stuff goes wrong, share it ASAP, the manager would love to do the same
Discuss what you want and need, and if you’re getting it

Give insight into places manager has no visibility

When people are upset/demoralized/angry, often ICs know before managers as people don’t tell managers. Sharing this with a manager is great so they can take action.
Give feedback, especially hard feedback.

Maximize your impact, and the team’s impact

The evaluation criteria for a manager are the success of the team, maximize your impact (and that of the team), and that’s the best way to help your manager.

Why do managers always say coding is part of their job but we all know it isn’t

I don’t think managers should code with a minor exception (More details). A related question might be:

Why do we assess manager’s ability to code - no clue, but a few enlightened companies do not.

Product Development and Product Management

My notes on Product, often the domain of the prodcut manager, but EMs wear many hats

Loading (/product)

Business Acumen and Strategy

My notes on Strategy, including the strategic positions of various companies:

Loading (/strategy)

Appendix

Loading (/manager-book-appendix)