12 Things I Learned in Big Tech
12 Things I Learned in Big Tech
A list of 12 things which stood out to me as things I didn't originally understand before working at big tech.
Hey all! Posting from Portugal. Lovely place. Have you had Pork Lagarto? Fantastic stuff! Have a great day!
The below are twelve things I've learned over the years as I grew into a Director/GM role at Amazon. Why 12 things? Because I realized this article was getting really long, and I was at 12 things, which meant it was time to stop.
I think many of these seem obvious. However, they're the type of obvious where people still stumble on the wrong decisions regularly.
"Don't underestimate your work."
"I won't... duh."
"But you're always late. Always."
"This time I'm being careful."
Time passes.
"You're late again."
"But there's no way this could have been predicted."
And yes, that conversation essentially happened verbatim more than once. See #2 below.
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 realize the brilliance behind this policy.
I was running my first team, and we had a small project due. Due to some bugs, we were delayed a few days, and everything was wrapped up on Friday.
I cheerfully encouraged my engineering team to deploy their code. Thankfully, I had a few jerks (aka people with backbone), who were happy to tell me that I was entirely wrong.
"We don't deploy on Friday."
"Why not?" I ignorantly asked.
"Do you want to be paged on Saturday morning when the new code breaks? Because I don't."
"Oh. Oh, I get it."
Feel like an optimist, but 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. Humans make mistakes. Some percentage of changes will cause problems. Some of those will not show up immediately, but instead show up the following day. Once they 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 working? Or when they're sleeping in at home?
Be conservative and safe. Assume the next day or two after a major change will be a mess. Don't let that mess land when people are drinking beers on a boat.
Along with this rule, you should also ensure that no one critical on your team has vacation scheduled for the week or even two after a major change. You should also ensure that no projects are planned to start immediately following your change. If you're lucky, things will go fantastically, and you'll all be able to take a deep breath before the next work begins. I probably understated this paragraph because we always had someone critical plan vacation for the week after a launch, and we always had people trying to schedule projects to start the Monday after a major launch the previous week. 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 rarely early. That's a silly way to plan.
First, figure out why you plan at all. Almost always, it's to set expectations with others, such as finance, management, product management, project managers, peers, or others. Remember the saying, under-promise, and over-deliver? Yeah. That's a real thing.
See if there are patterns in why you're always late. 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. I remember one team in particular had two retrospectives in a row, where their number one surprise was "we had bugs after launch." 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.
Don't be like that team. Learn from your mistakes. Don't plan optimistically, plan based on past events. If you usually need two weeks to fix bugs after launch, just plan for it. When you've proven that you can do things faster, that's when you update your planning.
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, want to explain how we got here?"
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 something as a fact, when it was actually just an opinion I had.
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.
This is true for a variety of situations. It's not always about people being afraid to speak against their management team.
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?"
Occasionally, you'll be the only person who doesn't understand. More typically, you'll just be the one brave enough to speak up. Again, that's how leaders act.
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.
4. Have a point of view.
This one is courtesy of Stefan Haney, who reminded me of this on a call recently.
Take a look at these seemingly innocent bits of communication.
"Hey boss, should we do X or Y?"
"We have these 3 options available..."
"Here are some thoughts about potential projects we could kick off next year.."
When we're discussing options with people who have decision-making powers (your boss, senior leadership, the interviewer, your spouse, etc), people are often capable of outlining those options.
The most common failing is that people dump those options in the lap of the decider, and then wait. They wait for the decision, having provided the relevant details of the available options. But they didn't provide their opinion. They had zero points of view on the matter.
That has two major problems with it.
It drives deciders crazy. It's upwards/outwards delegation. You're giving the problem to them to figure out.
You're giving away all of your power. All your ability to direct the next step has been delegated away.
What should you do instead?
Have a point of view! Have an opinion! In 99.9% of cases, if you're communicating options to someone (anyone!), provide your opinion with those 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. Here is the list of projects we looked into, and decided not to work on."
"I'm planning on making Chili today, but I could order Chinese if you'd prefer."
Deciders often have a lot on their mind. They have their own problems to figure out. You know what the easiest response to a prompt is?
"Ok. Sounds good."
"Ok" gives you power! It lets you do what you want! And I know decision-making is stressful, but it's 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. It was just easier (for a variety of reasons) to go along with them. And the number of people who asked me to make a choice, and acted disappointed when I didn't choose the option they favored.
5. Be right eventually.
We want people on our teams with good instincts who frequently make correct judgements. However, it's more critical that our teams are right eventually, rather than immediately.
How do you ensure that you're right eventually?
Disagree and commit - If you think your idea is better, fine, explain it. Perhaps choose it. If another option is selected, lean in wholeheartedly. Try your best to be successful, regardless of who came up with the idea. It becomes your success. If you find yourself hoping this idea fails, you're not leading properly.
Learn and be curious - If things are going well, a good leader worries that they're in a horror movie. They keep looking around doors to see what's going to eat them. To be less dramatic, you should look at your data, and always ask, "If I was wrong, what would that look like?" Then you can be the person who recognizes that your current path isn't going to work. Even if you picked that path in the first place.
Lose the ego - Insist to yourself that you're a confident leader, and you're not afraid of being wrong. The worst thing you can do is feel nervous about being wrong because you'll be tempted to defend your position, instead of keeping an open mind.
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. When you come up with a beautiful but complex system, it should likely be admired, and discarded, unless it's the only solution to the problem.
Human interactions are simple as well. When you're choosing to interpret someone's actions as either sneaky malice or ignorance, assume ignorance. It's the simple answer. Did they purposefully leave you out of the meeting, or did they just not think of you? The simple answer is that they didn't think of you. Did they purposefully claim ownership over that success, or did they mistakenly not share the credit? Forgetting to share credit is simpler. You'll be a better leader if you assume the simple answers, and good intentions from your co-workers.
A simple process is the best one. It will be easier to understand, document, remember, follow, cheaper to monitor, faster to update, and simplest to remove. Processes are expensive. Keep them as simple as possible.
Simpler technology is generally better. It's not as awesome as the new language, or the newly launched AWS service. However, the failure cases are known. The scaling is known. There is public documentation. Your teammates quite possibly know how it works already. It's rare that newer / fancier technology is better for the business than the existing tech. It's boring, but true.