Dave
@scarletink.com
Newsletter author at http://scarletink.com Ex. GM and Tech Director at Amazon. Ex. CTO at Bezos Academy. This is me: http://linkedin.com/in/scarletink/
So while suck it up buttercup isn't particularly nice, it's more catchy than "Focus on your goals, and what you can do to achieve them."
Love you all. For more, read on!
https://buff.ly/3Zp3tMe
Love you all. For more, read on!
https://buff.ly/3Zp3tMe
But It's Not Fair! How to Deal With Irritating Situations.
Numerous things in life aren't fair. However, complaining about it won't fix things. Let's focus on fixing things.
buff.ly
January 31, 2025 at 2:24 PM
So while suck it up buttercup isn't particularly nice, it's more catchy than "Focus on your goals, and what you can do to achieve them."
Love you all. For more, read on!
https://buff.ly/3Zp3tMe
Love you all. For more, read on!
https://buff.ly/3Zp3tMe
When you focus on what other people are doing, you're spending your energy on something you can't change. When you focus on what you can do, you're spending your mental energy on finding paths to success, opportunities, or choices you can make.
But It's Not Fair! How to Deal With Irritating Situations.
Numerous things in life aren't fair. However, complaining about it won't fix things. Let's focus on fixing things.
buff.ly
January 31, 2025 at 2:24 PM
When you focus on what other people are doing, you're spending your energy on something you can't change. When you focus on what you can do, you're spending your mental energy on finding paths to success, opportunities, or choices you can make.
Two - Maintain an internal locus of control. Identify what you can do, not what others should do.
Instead of: "My boss should recognize I do better work!" try "What can I do so that my work is recognized?"
Instead of: "My boss should recognize I do better work!" try "What can I do so that my work is recognized?"
But It's Not Fair! How to Deal With Irritating Situations.
Numerous things in life aren't fair. However, complaining about it won't fix things. Let's focus on fixing things.
buff.ly
January 31, 2025 at 2:24 PM
Two - Maintain an internal locus of control. Identify what you can do, not what others should do.
Instead of: "My boss should recognize I do better work!" try "What can I do so that my work is recognized?"
Instead of: "My boss should recognize I do better work!" try "What can I do so that my work is recognized?"
One - Focus on what you want, not what happened.
Instead of: "It's unfair my co-worker is paid more!" try "How can I increase my pay?"
It feels obvious, but I don't know how many times I've heard rant sessions from people who weren't taking the simplest steps to achieve their goals.
Instead of: "It's unfair my co-worker is paid more!" try "How can I increase my pay?"
It feels obvious, but I don't know how many times I've heard rant sessions from people who weren't taking the simplest steps to achieve their goals.
But It's Not Fair! How to Deal With Irritating Situations.
Numerous things in life aren't fair. However, complaining about it won't fix things. Let's focus on fixing things.
buff.ly
January 31, 2025 at 2:24 PM
One - Focus on what you want, not what happened.
Instead of: "It's unfair my co-worker is paid more!" try "How can I increase my pay?"
It feels obvious, but I don't know how many times I've heard rant sessions from people who weren't taking the simplest steps to achieve their goals.
Instead of: "It's unfair my co-worker is paid more!" try "How can I increase my pay?"
It feels obvious, but I don't know how many times I've heard rant sessions from people who weren't taking the simplest steps to achieve their goals.
When you try to verify what others believe are facts, you're slowing them down. You get pushback and dragging feet. What you also find is that things are not at all what they seem to be.
For some great anecdotes from Amazon on this topic, read on!
https://buff.ly/4f0pjeP
For some great anecdotes from Amazon on this topic, read on!
https://buff.ly/4f0pjeP
Be Skeptical: Challenging the Beliefs Underlying Everything
We blindly trust a lot at our companies. We trust that our metrics are telling us a truthful story. We trust that our processes are giving us the value we need. We trust that our assumptions are…
buff.ly
January 29, 2025 at 2:24 PM
When you try to verify what others believe are facts, you're slowing them down. You get pushback and dragging feet. What you also find is that things are not at all what they seem to be.
For some great anecdotes from Amazon on this topic, read on!
https://buff.ly/4f0pjeP
For some great anecdotes from Amazon on this topic, read on!
https://buff.ly/4f0pjeP
However, everyone is so busy. The easiest thing is to just trust and skip the verification step. I believe those metrics are telling us the right story, so we should do X. I'll just execute on our processes to achieve Y. I'll assume these few things, so I can make progress on Z project.
Be Skeptical: Challenging the Beliefs Underlying Everything
We blindly trust a lot at our companies. We trust that our metrics are telling us a truthful story. We trust that our processes are giving us the value we need. We trust that our assumptions are…
buff.ly
January 29, 2025 at 2:24 PM
However, everyone is so busy. The easiest thing is to just trust and skip the verification step. I believe those metrics are telling us the right story, so we should do X. I'll just execute on our processes to achieve Y. I'll assume these few things, so I can make progress on Z project.
5. Significant disagreements rarely revolve around code.
Managers are there to make a group of individuals a team. If anything, being deep in the technical details would make you less capable of being an impartial leader.
I love this topic. For more, read on!
https://buff.ly/4f1ZuuP
Managers are there to make a group of individuals a team. If anything, being deep in the technical details would make you less capable of being an impartial leader.
I love this topic. For more, read on!
https://buff.ly/4f1ZuuP
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
5. Significant disagreements rarely revolve around code.
Managers are there to make a group of individuals a team. If anything, being deep in the technical details would make you less capable of being an impartial leader.
I love this topic. For more, read on!
https://buff.ly/4f1ZuuP
Managers are there to make a group of individuals a team. If anything, being deep in the technical details would make you less capable of being an impartial leader.
I love this topic. For more, read on!
https://buff.ly/4f1ZuuP
4. The manager needs to be the interface between engineers and the business.
Managers need to create the highest business value with their team. They translate product and engineering requirements to find the optimal value. Hard to be an arbiter if you're working on implementation details.
Managers need to create the highest business value with their team. They translate product and engineering requirements to find the optimal value. Hard to be an arbiter if you're working on implementation details.
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
4. The manager needs to be the interface between engineers and the business.
Managers need to create the highest business value with their team. They translate product and engineering requirements to find the optimal value. Hard to be an arbiter if you're working on implementation details.
Managers need to create the highest business value with their team. They translate product and engineering requirements to find the optimal value. Hard to be an arbiter if you're working on implementation details.
3. What you build is more important than how you build it.
It's hard for managers to focus on both execution and the why. Those managers overly focused on detailed engineering are the ones without the time to ask critical questions.
It's hard for managers to focus on both execution and the why. Those managers overly focused on detailed engineering are the ones without the time to ask critical questions.
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
3. What you build is more important than how you build it.
It's hard for managers to focus on both execution and the why. Those managers overly focused on detailed engineering are the ones without the time to ask critical questions.
It's hard for managers to focus on both execution and the why. Those managers overly focused on detailed engineering are the ones without the time to ask critical questions.
2. Managers must grow their team members.
If the manager is leading implementation, what do the senior engineers on the team lead? How do they grow?
If the manager is leading implementation, what do the senior engineers on the team lead? How do they grow?
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
2. Managers must grow their team members.
If the manager is leading implementation, what do the senior engineers on the team lead? How do they grow?
If the manager is leading implementation, what do the senior engineers on the team lead? How do they grow?
1. How you build something is rarely how you fail.
How do projects fail? They misunderstand customer needs, or they fall drastically behind schedule. This isn't due to coding speed, it's due to leadership issues.
How do projects fail? They misunderstand customer needs, or they fall drastically behind schedule. This isn't due to coding speed, it's due to leadership issues.
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
1. How you build something is rarely how you fail.
How do projects fail? They misunderstand customer needs, or they fall drastically behind schedule. This isn't due to coding speed, it's due to leadership issues.
How do projects fail? They misunderstand customer needs, or they fall drastically behind schedule. This isn't due to coding speed, it's due to leadership issues.
As a junior manager said to me at Facebook, "How could you earn the respect of your team if you weren't the best coder on the team?" That alone should be a warning sign.
Why shouldn't managers code?
Why shouldn't managers code?
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
As a junior manager said to me at Facebook, "How could you earn the respect of your team if you weren't the best coder on the team?" That alone should be a warning sign.
Why shouldn't managers code?
Why shouldn't managers code?
When I interviewed at Facebook / Meta years ago, I had to take a coding test as a part of the hiring process. Thankfully my rusty coding skills didn't prevent me from getting an offer.
But the idea persists in places that engineering managers should code.
But the idea persists in places that engineering managers should code.
"Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
An explanation of why managers do not need to code, and probably shouldn't.
buff.ly
January 24, 2025 at 2:24 PM
When I interviewed at Facebook / Meta years ago, I had to take a coding test as a part of the hiring process. Thankfully my rusty coding skills didn't prevent me from getting an offer.
But the idea persists in places that engineering managers should code.
But the idea persists in places that engineering managers should code.
Instead, unravel the complexity and find root fixes which solve the root causes of the issue.
For more, read on!
https://buff.ly/4f2vRcZ
For more, read on!
https://buff.ly/4f2vRcZ
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
Instead, unravel the complexity and find root fixes which solve the root causes of the issue.
For more, read on!
https://buff.ly/4f2vRcZ
For more, read on!
https://buff.ly/4f2vRcZ
If customers aren't notified about a security event, the issue is not with a single person who worked on the event, it's with your reporting processes.
Every time a process or system relies on a single human not making a mistake, you've designed a fragile system.
Every time a process or system relies on a single human not making a mistake, you've designed a fragile system.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
If customers aren't notified about a security event, the issue is not with a single person who worked on the event, it's with your reporting processes.
Every time a process or system relies on a single human not making a mistake, you've designed a fragile system.
Every time a process or system relies on a single human not making a mistake, you've designed a fragile system.
If a junior engineer can take down your product, the issue is not with your junior engineer. The issue is with your system being fragile.
If a bug is released in your code, and it causes customers to be double charged, the issue is with your QA process, not with the engineer who wrote the code.
If a bug is released in your code, and it causes customers to be double charged, the issue is with your QA process, not with the engineer who wrote the code.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
If a junior engineer can take down your product, the issue is not with your junior engineer. The issue is with your system being fragile.
If a bug is released in your code, and it causes customers to be double charged, the issue is with your QA process, not with the engineer who wrote the code.
If a bug is released in your code, and it causes customers to be double charged, the issue is with your QA process, not with the engineer who wrote the code.
"Bob screwed that up" doesn't have a real fix because even if you fire Bob, his replacement Joe is likely to do the same thing.
Almost always, if the main culprit listed for an operational event is a person, you've found an excuse / explanation, not a true root fix.
Almost always, if the main culprit listed for an operational event is a person, you've found an excuse / explanation, not a true root fix.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
"Bob screwed that up" doesn't have a real fix because even if you fire Bob, his replacement Joe is likely to do the same thing.
Almost always, if the main culprit listed for an operational event is a person, you've found an excuse / explanation, not a true root fix.
Almost always, if the main culprit listed for an operational event is a person, you've found an excuse / explanation, not a true root fix.
However, that single simple explanation is almost always a fiction story. It's not the full coverage of what happened. It's a convenient explanation which avoids the complex (but valuable) steps of identifying everywhere that things could have gone better.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
However, that single simple explanation is almost always a fiction story. It's not the full coverage of what happened. It's a convenient explanation which avoids the complex (but valuable) steps of identifying everywhere that things could have gone better.
2. Simple is easier. It is mentally exhausting to understand a big, complex project. Where did things go south? But you're saying that it failed because we didn't do user testing? Ok, that makes sense! Big mistake! We'll do user testing next time. Let's move on.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
2. Simple is easier. It is mentally exhausting to understand a big, complex project. Where did things go south? But you're saying that it failed because we didn't do user testing? Ok, that makes sense! Big mistake! We'll do user testing next time. Let's move on.
1. Blame is avoided with singular explanations. Even if your company is understanding of mistakes, no one enjoys the feeling of admitting a mistake. If you point at a single simple explanation, chances are that most people are then blameless. Our ego appreciates it when we dodge responsibility.
Finding an Explanation vs. Permanent Resolution of Issues
If we're not careful, we default into defensiveness when issues arise. And everyone involved will be tempted to avoid blame, and keep things simple. Don't fall for that trap.
buff.ly
January 22, 2025 at 2:24 PM
1. Blame is avoided with singular explanations. Even if your company is understanding of mistakes, no one enjoys the feeling of admitting a mistake. If you point at a single simple explanation, chances are that most people are then blameless. Our ego appreciates it when we dodge responsibility.