13 Tech Career Misconceptions — Things I Wish I'd Learned Earlier
Misunderstandings about performance, promotions, influence, and leadership that most people only realize late in their careers.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific 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!
A week ago, my wife and I went to Oregon to run a 50k (Gorge Waterfalls 50k). I unfortunately made it only 21 miles before I was forced to stop due to stomach issues (it happens!) My wife was able to pick up the pace once I stopped slowing her down, and finished strongly. But anyway, it won’t be my last long run. I figured I’d share a couple of photos from the event today. They’ll be from our phones, since I wasn’t about to run with a DSLR.
I was reading Reddit when I sat down to write this article — because that’s one of the ways I procrastinate from writing.
And you’ll never believe it. There was someone wrong on the internet. Gasp.
At this point, I do assume 90% of the people posting on Reddit are AI bots. However, many comments have been predictably wrong for years. AI doesn’t lower the quality of internet commentary. It just adds volume.
Anyway, I read yet another incorrect comment on one of the computer science related subreddits, and I rolled my eyes. I thought to myself, “Dagnabbit, these people have no idea what they’re talking about.”
And then I remembered that I was supposed to be writing an article. And that felt like a great topic. How people can be entirely wrong about things.
Let’s get started.
1. You’re rewarded for doing hard things.
Engineers are frequently guilty of believing this one. They put great value in solving hard problems.
If you ask an engineer, “What great thing did you do last quarter for our company?” - What do they frequently hear? “What hard thing did you do?”
Example: “I solved that incredibly complex threading issue with our marketplace caching service.”
Except that we all know that businesses don’t hire us to do hard work. We’re hired to do valuable work. We’re rewarded for making our business more valuable, creating more revenue, decreasing costs, etc.
I agree that it would feel great to be rewarded for solving hard problems. Then you could just explain the details of a problem you solved, and you’d get your fair reward. This is the beautiful meritocracy engineers dream about.
Except they’re disappointed to learn that their amazing abilities and accomplishments are too often ignored by their dumb and ignorant managers.
You know what I regularly read? “My manager didn’t understand why what I accomplished was so impressive.” You know what’s more likely? You didn’t understand that what you accomplished was quite possibly too expensive for the value you created.
You’re valued by the problems you solve. If you’re looking for congratulations (or credit), you need to explain the exact value you’ve created. This might require some selling.
Once you’ve explained how this is valuable to the business, you will probably want to make it sound complex. Why? Because people are biased towards rewarding those who worked super hard to create value. Again, value first, but complexity is still rewarded.
In other words, if you told your manager, “I found a million dollars in this corporate bank account we forgot about!” - You’d get a quick congrats, a pat on the back, and everyone would move on.
But if you created some awesome complex bank integration service which saved your company a million dollars, it would sound impressive, and you’d be rewarded.
But the key was the million bucks. Doing an awesome complex bank integration service with no ROI? A waste of time. And I don’t know how many times I’ve had engineers explain their version of a complex bank integration (with no mention of value), and asked why they weren’t getting recognition.
2. Underperformers are bad at their jobs.
Through my years at Amazon, I saw the results of hundreds of internal transfers. Some were to or from my teams. Some peers.
I had people on my team performing poorly, they transferred to another team, and succeeded. Their problem (whatever it was), seemingly disappeared when they joined the new team.
I had people on my team performing poorly, they transferred to another team, and failed in the same way on their next team.
I had people on my team perform great, they transferred to another team, and were soon listed as an underperformer.
I’m not saying that everyone can succeed if they simply switch teams. But I’m absolutely convinced that many things we label as performance issues are team fit issues.
What’s the source of these team fit issues? Here are a few off the top of my head:
Manager and employee personality clash. It’s very hard for me to view someone as a top performer if we fight every time we talk.
Work type differences. I’ve had people who loved quickly hacking up solutions, but they were on a critical infrastructure team. And I’ve had people who loved taking their time to build quality software, but joined a team focused on quick prototyping.
Work skill differences. You might be an expert at mobile development, but you’d fail if you joined a backend Java service team.
My takeaway?
Interviewing and sourcing candidates is expensive. People flagged as underperforming should be given a shot on another team before being walked out the door. I bet you’d find that half your “bad hires” were just on the wrong team.
3. A project is considered successful based on metrics and measurements.
I love this one. And it absolutely helped my career.
Some projects are obviously successful. Everyone knows they’re successful. Big jump in some important numbers for low cost.
Some projects are obviously failures. Zero jump in numbers for high cost.
However, most projects are in the middle. Some things went well for the project, some things went poorly.
Their success or failure is decided by the personalities of those working on the project, talking about the project, and what they all want people to think. Or more accurately, since many people don’t realize their personal marketing power, it’s determined randomly. “I guess this feels like a failure? Right guys?”
I remember our team working on a UX redesign where the results weren’t at all what we wanted. Instead of increasing engagement, our redesign actually decreased engagement. The designer started writing up the “We failed, this was a waste of resources” email.
I stopped them. Why? Because the project is done. The results are what they are. The only thing left is to explain the results. You can explain them in one way and your team is viewed as slightly less competent. Explain them in another way, and your team is seen as slightly more competent.
I announced something like this (better worded):
“We successfully launched our UX test last Friday.
It was originally scheduled to take another two weeks, but the fantastic work by the entire team cut the project timeline.
The results aren’t pretty, engagement in the new treatment dropped by 6.7%.
However, this confirms one of our hypothesis that increasing X on the UX would not positively impact customer engagement. This is a great signal for our next UX test scheduled to start in 7 weeks, where we will create Y. We’re excited to see if this trend continues!
Congratulations again to the entire team!”
Absolutely nothing false. Doesn’t change a single thing. Except that our leadership team can read this, and think “Oh ok. While that didn’t work, it sounds like they still got valuable signal from that project, and they have next steps ready. Great!”
Turning a potential failure into a success (for you and your peers) is a highly valuable skill. Your personal success is highly determined by how you sell your work. Like it or not, you’re responsible for the marketing of your own work.
This applies to announcements (like in my example), but also to how you interact with your manager. In your weekly one-on-one meetings (hopefully you have those), you’ll likely talk about what work you’ve done. You can have a sad face and say that you’re a terrible employee. Or you can have a happy face and excitedly declare that you’ve had yet more success, as usual. Your manager is busy. They’ll likely take your word for it.
4. Employee careers are limited based on the opportunities their managers give them.
I once took over a team with a few SDE-2's (Level 5), and they insisted there wasn't SDE-3 (Level 6) work on the team, so they were unable to be promoted. This was the primary complaint they had when I joined.
Not terribly long after, I had a Principal engineer (Level 7) join the team. You can only imagine the confusion those SDE-2’s expressed when I told them about the new team member. That Principal engineer joined in large part because they saw a number of complex Level 7 opportunities on the team. I explained that their co-workers didn’t believe there were promotion opportunities. That earned an eye roll.
A few weeks in, they gave me a long list of their priorities, and said they’d be busy for at least a couple of years. And they were.
I think in almost all cases, with almost no exception, there is scope worthy of stretching you, and quite possibly moving you towards promotion. You just need to find it. And your inability to find it is why you’re not promoted yet. Because that’s a legitimate leadership skill gap you need to solve first.
A significant number of the critical accomplishments in my Level 6 to Level 7, and Level 7 to Level 8 promotions were things I volunteered for, or that I invented from scratch to work on. We create our own opportunities.