As a Director at Amazon, I repeatedly saw that big tech career incentives basically guarantee cycles of too much growth, and then layoffs. I just had someone email me, and say that they're worried about their career as a development manager.
🧵
They only had 6 engineers reporting to them, but all their peers had more. Their manager agreed that it might look bad to their leadership team if they couldn't find more headcount for this person to manage. I asked how they were delivering on their projects.
Yes, they'd delivered on multiple important projects. Did they make visible mistakes? No. Did they have trouble earning trust with peers? No. What was their performance issue? Literally, that their team was smaller than their peers.
I know this for a fact: If you ask a random HR Partner if a person is ready for promotion to Director, do you know what they're going to ask first? "How many people are reporting to them?" This system is broken.
A level 6 manager with 20 reports is almost guaranteed a level 7 promotion. A level 6 manager with 8 reports cannot be promoted to level 7. This continues through every level. I was given explicit numbers of headcount I needed to get my promotion approved as a Director.
That number is almost always in the first line or two of any promotion document for managers. When the *most influential* metric available for a manager is "number of people working for them", it means that the strongest incentive for those managers is finding more headcount.
That might be through political infighting (steal someone's organization), pretending a project needs more headcount than it does, requesting / approving a project simply because it gets more headcount allocated to an organization, and so on.
The anti-incentives for cancelling a project are massive. Early in my career, I suggested a few times that my organization could cancel a project as it had low ROI. I quickly learned that it was hugely counterproductive to career growth.
To read more about big tech culture, and how it incentivizes growth (and inevitable layoffs in the future), read on!
It's easier to blame others for not giving you an opportunity, rather than recognize that you had the opportunity all along.
I was once talking to an engineer at Amazon, who wanted to move to my team. I asked her why, because I like to know what motivates people.
She said, “I'm an SDE-2, and there aren't any SDE-3 promotion opportunities on my team. We don't have any SDE-3's here because our work is not complex enough.”
For context, SDE-2 is the first promotion step above college hire, and SDE-3 is a senior software engineering position. In general, a SDE-2 works on a team, and an SDE-3 leads a team from an engineering perspective.
I remember having a skip-level meeting once with a junior engineer, while I was Senior Manager (before my promotion). The engineer, innocently, asks what I do.
"Since engineers do all the work, what do managers do?"
Fair question.
🧵
Considering I was in the middle of some unfortunate 10+ hour days, it seemed like a particularly funny question to ask me at the time.
And it's hard to answer. A manager's job (particularly as they get more senior), is so random.
But there are some consistent parts to it.
People - Issues between folks, and attention for great and poor performers. People take time.
Product - You need to understand what you're building, and why.
Tech - Your existing and new tech needs to be solid.
Project - Everything needs to get done, and properly communicated.
In your career, you'll build some behaviors, and they'll serve you well forever.
Other behaviors may serve you well earlier in your career, but will limit you later.
What's an example of these behaviors?
🧵
Making quick, independent decisions.
As an IC (individual contributor), I found that our team could grind to a stop if our manager didn't make decisions quickly enough. It was one reason I wanted to move into management.
As a manager, I didn't have to put up with that nonsense.
Once I was a manager, I realized that it was a career advantage for me to make decisions quickly. In fact, the quicker, the better.
I learned to recognize open questions as negatives for my team, and I'd aggressively make the decisions as quickly as possible.
Amazon expects a lot out of their engineer managers.
They expect them to run projects, mentor employees, design systems, architect platforms, manage operations, communicate with customers, and evolve products.
But they don't expect them to code.
🧵
Many people (including Twitter's owner) believe otherwise. They say that an engineering manager can't do the job well if they're not an active and skilled individual contributor.
I'll explain why a manager shouldn't code, and other things they should be doing with their time.
How you build something is rarely how you fail.
The worry is that things will go badly if the manager is not monitoring the code the team is writing.
Except that code isn't how projects fail. Projects fail due to bad product or scheduling.