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.

Managers should prioritize resiliency in teams, just like you prioritize resiliency in software.

For example, if the manager always assigns tasks, they're a bottleneck. If employees self-choose tasks, everyone can operate independently.

🧵 If a manager unblocks their team members by talking to their peer teams, that's helpful in the short run.

But the manager is again the bottleneck. If employees are taught how to unblock themselves, they can operate independently.

What it comes down to is a tradeoff.

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.”

As a manager, you'll hopefully end up managing people who are so spectacular at their job, that you can't match their skills.

How can you be a useful manager to them?

🧵 When you're giving feedback to a junior employee, you can provide input related feedback.

"If you code it *this* way, you'll get a better result."

When you're giving feedback to a senior/skilled employee, you can provide outcome related feedback instead.

What does that mean?

I've loved this adventure of moving from Technology Leader to Newsletter Author. I'm so privileged to have this opportunity.

Since I just figured out how to download some analytics, I thought it'd be fun to share the Top 10 Posts which drove the most new paid subscribers.

👉 10. A Couple Decades of Unlearning — Lessons on the Path to Director

Over the couple of decades of my career, I've unlearned quite a few things. I decided to share some beliefs I've since decided were wrong.

scarletink.com/couple-decades…

What do managers do with all their time?

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.

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.

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.

Why is process expensive? Because it means less ownership.

Let's keep things simple for this example. You are hired tomorrow by Andy Jassy to increase the sales of the next Kindle. That's it. You have complete control.

🧵 Ok! Cool! You have ideas! You'll find influencers. You'll create partnerships with some libraries. Maybe you could build some Kindles out of new materials! A pewter Kindle! A porcelain collector's edition Kindle!

Wait, he forgot to tell you the required processes.

If you're a software engineer, your main job is maintaining legacy code.

Why? Because building a system doesn't take long, in comparison to how long code will last, assuming the code/business are successful.

Here are the 10 commandments of maintaining legacy code.

🧵 Commandment One: Thou shalt not complain about the code.

Your co-workers wrote the system. They had good intentions. When you presume that it was built wrong (not knowing their situation), you insult them.

Respect what came before.

If you quit your job due to getting burned out, it's quite likely your fault.

Oh yeah, I bet I've really made some overworked engineers annoyed. Why? Because it's much easier to blame others, rather than recognize the actions you can take to improve your life and career.

🧵 Why does getting better at your job mean you have less time?

You'd hope work gets easier when you're good at your job. Rarely true.

Junior employees deliver value themselves, while Senior employees deliver value through others. That means others always want their time.

Friendly reminder to my Amazon (and other tech) friends out there when wrapping up your taxes.

Topic - RSU Taxation. Income tax vs Capital gains tax vs Cost basis.

FYI - Being *granted* stock which will vest later is not a taxable event. It's just a paperwork thing.

🧵 1. When you vest (receive in your account the sellable stock) RSU's.

You pay income tax on their value at vest time. Get $10k in stock, you pay income tax on $10k (plus your normal salary). Easy. Just double check that your W2 shows the right numbers.

Why are big groups bad at decisions? One reason—Big groups make slow decisions.

Gather 15 friends, and try to decide what to do on the weekend together.

How do you think that'll go?

🧵 One proposes biking. Another suggests bowling. Someone else suggests axe throwing. Yet another person chimes in that axe throwing sounds fun. Someone replies saying that their elbow hurts. They want something without arm movement.

How long will it take to decide what you'll do?

Tenets are powerful.

I must admit, the exercise of discussing tenets feels a little abstract at times. "Let's spend a couple of hours talking about what we value."

However, the value of the output is undeniable for those who have used tenets.

🧵 Tenets are about bringing decision-making back to first principles.

❗ "We all agree that we should do X."

❓ "Why do we feel X should be done? Because of Y."

❓ "Why do we feel Y? Because of Z."

💯 "Why do we feel Z? It is a core value. Let's document it as our tenet.

Getting your first software engineering job is a massive win.

Take advantage of that win. Don't just be ok. Be the best new employee. You want them thrilled that they hired you. Be the very last option for layoffs ;)

Below are 10 things the top junior engineers do.

🧵 One - Get to know your co-workers.

Yes, your main job is to write code. But you're a part of the team. Meet with everyone at least once.

That includes not just your teammates, but your PMs, project managers, and designers.

For important group decisions, make a clear separation between decision helpers, and decision makers.

What's the difference?

🦖 A decision helper provides information and recommendations.
🦖 A decision-maker decides.

🧵 Why is separating information from deciding critical?

Because making decisions in a group is incredibly slow, and error-prone. You don't want 30 voices in a critical decision, you want your best two or three voices. But you don't want them deciding in a vacuum.

"I used to manage 100 people, and now I have a single team!"

If you talk to new employees at companies like Amazon/Facebook/Google, you'll regularly hear from people who feel they were under leveled.

I'll walk through what mistakes they likely made, and how to avoid them.

🧵 General mistake - They focused on the question. Not on their goals.

When they were asked a question, answered with the most relevant answer.

Is your goal to answer the question? No. Your goal is to get hired, and be offered the right level position.

What should you be doing?

12 simple lessons from my time at Amazon.

Each of them seems like obvious wisdom to me now, but I know I didn't fully grok them until I'd been through the school of hard knocks.

I hope that at least one of them will make you think a little.

🧵 1. Don't Deploy on Friday

Be pessimistic with your deployments. Assume something bad will happen, but it won't show up right away. It will be a subtle emergency.

If that emergency shows up tomorrow, you want your whole team ready to go. Make sure tomorrow is not Saturday.

An operational disaster happens.

The site goes down. All hands on deck until it's fixed.

Once it's fixed, the leadership team asks for a COE. What's the way we can stop this from happening again?

This is a 🧵 on doing *something*, and how much that decision can cost you. When you're in a large organization, leaders don't have many levers.

One lever they can pull is to remove ownership from teams, and centralize those decisions. Usually done to reduce risk of poor decisions. What's it called when ownership is moved?

Creating a process.

Why does Amazon favor disagree & commit?

Because making *any* decision in most cases is better than no decision. If you're deciding between A and B for too long, you've essentially chosen C (neither of them).

This means employees need to learn how to decisively move on. How? No revisiting.

You cannot bring up the other options again, unless the situation changes. A decision has been made. Decisions are about making progress, so don't make negative progress.

Why a Meritocracy can't exist

People love the idea of objective measurements by removing bias and measuring people's contributions. While this might be possible if you're connecting bolts in an assembly line, in knowledge work, it feels impossible.

Why? Hitting dates: Meeting dates on tasks or projects is used as a proxy for success. Yet some projects are more complex than others. People can set more conservative dates. Cutting features helps someone hit dates. Resource changes impact dates.

What else?