12 Things I Learned in Big Tech

Welcome to my newsletter! I'm Dave Anderson, an ex-Amazon Tech Director and GM. I write this newsletter I've called Scarlet Ink, which is a weekly newsletter on tech industry careers and tactical leadership advice.

Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member. 99% of my articles are intended to be evergreen (readable and valid forever). Some weeks I have fresh content; other weeks I'll update/rewrite something from 4+ years ago because I want to keep the quality of all articles high.

List articles are fun. Instead of needing to organize a single narrative across 3500+ words, I can write something significantly shorter, make my point, and then move onto another topic. I'll admit that it makes me feel a bit lazy, but I think it works.

When I make a list like this, I worry that some points are obvious. Or at least they'll feel obvious. But for every single point I list, I've repeatedly seen people do the wrong thing. So they all feel worth talking about.

Dave: "Don't underestimate your work."

Employee: "I won't... duh."

Dave: "But you're always late. Always. Like 100% of the time."

Employee: "This time I'm being careful."

Time passes.

Dave: "You're late again."

Employee: "But there's no way this could have been predicted."

Yes, this conversation happened essentially verbatim. More than once.

With that intro out of the way, here's the list.

1. Don't deploy on Friday.

This was one of the first things I learned at Amazon. I didn't initially realize how important this policy was.

I was managing my first team, and we had a small project due. Due to some bugs, we were delayed a few days, and everything was finally wrapped up and ready on Friday.

I cheerfully encouraged my engineering team to deploy the code. Thankfully, I had a few jerks (aka people with backbone), who were happy to tell me that I was wrong.

Them: "We don't deploy on Friday."

"Why not?" I ignorantly asked.

Them: "Do you want to be paged on Saturday morning when the new code breaks? Because I don't."

"Oh. Oh, I get it."

I remember that sarcastic reply today. So wonderfully put.

You can feel like an optimist and be excited about your project. But you should always plan like a pessimist. You want everything to go well when you make major changes. However, you assume that things will not go well.

Our teams are made of humans. Well, mostly. Humans and AI both make mistakes. Some percentage of changes will cause problems. A significant percentage of problems don't show up immediately. Partially because we tend to deploy our code when there is light traffic to our products. So our problems show up when all our customers start using our product the next morning.

That next morning when issues show up, some percentage of them will need to be fixed quickly. This could be incorrect marketing text, a strange bug that only shows up during peak traffic, or any other random assortment of things going poorly.

Would you rather the emergency show up the next morning at 9am when your entire organization is sitting at their computers already working? Or when they're sleeping in at home?

Be conservative and safe. Assume that the next day or two after a major change will be a bit of a mess. Don't let that mess land when people are drinking beers on a boat.

Following the spirit of this rule, you should also ensure that no one critical on your team has vacation scheduled for the week or two after a major change. You should also ensure that no projects are planned to start immediately following your change. To add to this point, you might want to assume that your project will launch a week or three late and give yourself an even larger buffer. If you're lucky, things will go fantastically, and your team will figuratively take a deep breath before the next work begins.

This last point is a sore spot for me. Because we always had someone critical plan their vacation for the week after a launch, and we always had people scheduling important projects to start Monday immediately after a major launch. And these two things always caused problems, and we always said, "Gosh, that was dumb. We should have known better." I imagine your workplace isn't much different.

2. You're underestimating your work.

What percentage of the time is your team finishing your work early? What percentage of the time are you finishing late? If you're like most teams, you're almost always on time or late. Very, very rarely early. That's a silly way to plan.

First, before changing anything, figure out why you plan at all. Because planning for the sake of planning makes no sense. There's probably an underlying reason why you set dates and schedules for things.

Almost always, it's to set expectations with other parts of the company. Groups like finance (booking revenue and costs), management (allocating resources), marketing (building marketing launch plans), product management, project managers, peers, or others.

What these groups usually want is a reliable prediction. When the marketing team wants to buy advertising slots somewhere, they don't really care if it's June 15th or July 7th. They just care that they don't need to cancel their marketing buy because someone discovered some random small bug. Not to say that people won't push you for an earlier date. But that's just pressure testing you to deliver as fast as possible, not that they honestly care a lot.

Remember the famous saying: Under-promise, and over-deliver? Yeah. That's a real thing.

Now that we recognize that you're always late, let's see if there are patterns in the reasons. And learn from your mistakes. Many teams repeatedly miss their dates because they are repeatedly surprised at having to fix bugs for a couple of weeks after a major deployment. See point #1 above.

I remember one team in particular had two retrospectives in a row, where their number one surprise was, "We had bugs after launch." Shocker. As if anyone should have been surprised. What was their proposed solution for this surprise that happened twice? Test more. As if you can test your way into having zero bugs at a launch.

Spoiler alert. You can't test your way into a perfect launch.

Don't be like that team. Learn from your mistakes.

But critically, you should also create your plan based on past events. If you have historically needed two weeks to fix bugs after launch, just plan for it! When you've proven that you don't actually need those two weeks, that's when you can update your planning process.

When someone pressures you to cut that time, you can honestly respond that you'd love for your planning to be wrong. You're simply planning based on experience, and your whole team is working very hard to improve things in the future.

3. Speak up.

Your VP says that she likes the new homepage design, but she'd like the logo to be larger and centered at the top of the page.

You pause and wait for everyone to disagree. No one says anything. A few people nod, and the designer takes notes. You're confused. This is the first time the VP is seeing this UI, but you've been in multiple of these design sessions, and there were excellent reasons the logo was smaller and on the left side.

Are you in crazy land? You see all the other senior folk sitting there quietly, and no one is objecting.

This is incredibly common. We're herd animals. No one wants to be singled out by disagreeing with the herd decision or the decision of the senior leader. People frequently avoid sticking out their neck when it's easier to go along with the flow. And then, if no one is talking, doesn't it feel strange to be the one to say something?

Forget that nonsense. Speak up.

"Hey VP, we did discuss having the logo larger at the top. That was one of our design options. However, we moved it to the bottom for a few good reasons. Sashka, could you explain how we got to this design?"

Why is it important you speak up? Because it's darn hard for senior folk to get people to speak up. I absolutely noticed fewer and fewer disagreements as I became more senior in my roles. It was exceedingly difficult to get people to speak up, particularly when I mistakenly stated my opinion a bit too strongly.

You might be wrong, but hopefully, you are right often enough. In general, the person who speaks up (and isn't wrong all the time) will earn respect for being open and honest. This behavior (not being afraid to speak up) was absolutely one of the major factors in how I recognized future leaders in our groups. And I'm positive that my inability to keep my mouth shut was a large factor in getting good ratings and promotions.

People are afraid to speak up when they don't understand something.

"When you say that our stock vests over 3 years, could you explain exactly what vesting means, and the schedule for the vesting?"

I've had to ask these types of dumb questions repeatedly.

Occasionally, you'll be the only person who doesn't understand. Fine. You have aired your ignorance.

More typically, you're stating what plenty of other people were thinking. Except you were the brave one willing to speak up. That's how leaders act. People notice.

People are afraid to speak up against the group consensus.

"Sounds like we all agree, let's launch on friday."

"Sorry, hold on a moment. I'm not on board. I'm still worried about the marketing schedule we mentioned earlier. If the marketing team can't get their work done by Wednesday, I feel we should slip the date."

It can feel confrontational to disagree with the group consensus, and there is often a subtle or not subtle encouragement to get on board with the group's plan. There are times to commit to a decision, but disagreeing first is critical as well.

What you'll find is that groups frequently have false consensus, either purposefully (someone trying to bulldoze their way to a decision) or accidentally (people not speaking up). It's your job as a leader to speak up until it feels like all important points have been made and given adequate attention.

4. Have an opinion.

Take a look at these seemingly innocent bits of communication.

"Hey boss, should we do X or Y?"

"Senior leadership, we have these 3 options available..."

"Hey manager, here are some thoughts about potential projects we could kick off next year.."

When you are expected to bring options to a decision maker (your boss, senior leadership, etc), I think most people are decent at brainstorming options.

However, many people fail by simply dumping those options into the lap of the decider. And then they wait. They wait for the decision, because they feel like they've done the job expected of them.

That has two major problems with it.

1. It drives deciders crazy. This is essentially upwards and outwards delegation. You're explaining the complexity of a problem, and then you're letting them figure things out.
2. You're giving away all of your power. You're not just delegating the complexity of the problem, but you're also giving away your ability to influence the next step.

What should you do instead?

Have an opinion! In 99.9% of cases, if you're communicating options to someone, you should add your opinion to that list of options.

"Hey boss, I'd like to do X, but Y is also an option if you'd like to discuss it further."

"We have these 3 options available. We prefer option #1, and plan to go with it if you don't object."

"Here are some projects we plan to kick off next year. We've also made a list of the projects we considered and decided not to work on."

"I'm planning on making Chili today, but I could order Chinese if you'd prefer."

Yes, I understand that this person has the power to make the final decision. This might be your boss, your wife, or your VP. But deciders also have a lot on their mind. Having the final say in a decision doesn't mean you should be deciding it alone. Steve Jobs had the final say on the iPhone design, but he certainly didn't design it all himself.

When the decider has to do their job of deciding, do you know what the easiest response is?

"Ok. Sounds good."

This is what gives you power! "Ok" being the easiest answer means that you will often be, essentially, the decider! This power lets you do exactly what you want. And while I understand that stating your opinion can make things more stressful, it's certainly best for everyone involved.

As a leader of a relatively large group at Amazon, I was amused by the percentage of time I happily said "Ok" to people's plans, even if I wouldn't necessarily have chosen that plan. Why? Because momentum is behind the choice that my team picked.

And similarly, I repeatedly had people ask me to make a choice, and then acted disappointed when I didn't choose the option they favored.

"Should we do plan A or B?"

"Hmm, considering all the info I just read, I choose plan B."

"Oh. Well. Ok."

You are guaranteed to fail your leadership team by not giving an opinion. If you give an opinion, you might be wrong. Choose to have some agency over your life and always give your opinion with options.

5. Be right eventually.

We certainly want people on our teams with good instincts, and these people frequently make the right decision.

However, everyone is wrong at times. So it's more critical that our people are right eventually.

How are you right eventually?

Disagree and commit

If you think your idea is better, fine, explain it. Argue for it. But if another option is selected, lean in wholeheartedly. Try your best to make it successful. Even if you hate the person who came up with the idea, and you strongly disagreed with it.

Because if you help it become a success, it is your success. If you find yourself hoping this idea fails, you're not leading.

Learn and be curious

If things are going well, a good leader worries that they're in a horror movie. They keep looking behind doors (figuratively) to see what's going to eat them. You should always look at the situation you're in and ask yourself, "If I was wrong, what would that look like?"

Then you can be the person who identifies that your current path isn't actually going to lead to success. This should be true even if you were the one who picked that path in the first place.

Lose the ego

You need to act like a confident leader. A confident leader is not afraid of being wrong. The worst thing you can do to your career is to feel nervous about being wrong, because then you'll be tempted to defend your decisions, despite them being wrong.

A confident leader has no ego about their initial opinion. Their only wish is to be right eventually. And that's precisely the type of person we want leading.

6. Simpler is better.

The simple design is usually the right one. It will be easier to support. It will be easier to extend. It will be faster to build. It will have fewer errors. It will require less experienced employees to modify it. It will make more sense to customers.

A simple process is the best one. It will be easier to understand, document, remember, and follow; cheaper to monitor; faster to update; and simplest to remove. Processes are expensive. Keep them as simple as possible.

Simpler technology is frequently better. It's not as fun as using a new language, or using that newly launched AI service. However, the failure cases are known. The scaling is known. There is public documentation. Your teammates quite possibly know how it works already. Your AI model has been trained on 10k examples of how this technology is used. It is very rare that the newest and fanciest technology solves problems better for the business than the existing tech. It's boring, but true.

Human interactions can be simplified as well. When someone says something that you could interpret as sneakily malicious or ignorant, simply assume ignorance. It's the simplest answer, and causes less damage.

Were you purposefully left out of a meeting, or did they simply forget to invite you? Let's just stick with the simple answer that they forgot you.

Did they purposefully claim ownership over that project without crediting you, or did they make a simple mistake? Forgetting to share credit is a simpler explanation.

You're a better employee and better leader if you assume the simple answer, which is that most people have good intentions, but make mistakes.