22 Somewhat Random Bits of (Mostly Tech Career) Advice From Dave

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.

If you get a good mentor someday, I advise that you enter that meeting with a few specific topics. It doesn't need to be a precise question, but at least some direction is useful. For example, "I feel like I have a lot of work piled up, and I need some advice on how to organize it and get out from beneath it."

That's a great starting point because they can talk about prioritization, work/life balance, and a variety of other fun topics.

But what frequently happened in my experience is that after getting my approval to be my mentee, they'd walk into my office and sit down for their first meeting.

"Ok! So this is our first mentorship meeting!" I said. "What do you want to discuss?"

Cue slightly confused and panicked look.

"Well, um, I'd like to hear your thoughts on what I should do better, and how to advance in my career."

My first advice was usually a prescriptive description of how someone asking for mentorship should come prepared with a list of questions, because that would make the experience more valuable.

But after that, as I jokingly said to a few mentees, "I'm comfortable just rambling, so I'll do that."

And that's what I'd do. I'd give advice and thoughts on a variety of topics, and they'd write things down, and at least pretend that it was a valuable use of their time.

That's what I'm doing today. I decided to just write what came into my mind. And I did that, twenty-two times.

I hope you enjoy!

One

I'm suspicious (and not sure how to feel about it) that a significant portion of my success over the years was due to my emotional intelligence.

• I knew when to question a senior leader and impress them and when to keep my head down and shut up.
• I could congratulate someone without being condescending.
• I knew what phrasing to use with an important person to make them happy with our progress (even if our progress wasn't great).
• I knew that most projects could be neglected safely. But also could identify the few which needed to be watched over like a hawk in a way that my leadership team could see that I cared.

A significant portion of all of these was about reading people, and anticipating what mattered to the important people, and what didn't.

Two

If you're building something fancy and complex and exciting, 80% of the time you're overbuilding. There's probably a wildly simpler or easier solution that will get you 90% of the expected value. Even better, that simpler/easier solution is almost certainly cheaper to maintain.

Three

If you're an awesome engineer on my team, I will surely lean on you to do the most technically complex projects.

If you're a moderately (at least) talented engineer with great communication skills, I will surely lean on you to do the most organizationally complex projects because those require a lot of cross-team discussions.

Sometimes this leads to the moderately talented engineer with communication skills to be promoted first, because they worked on the big visible projects. They're also frequently turned into managers when needed, which is another potential path to career growth.

Decent engineers with great communication skills were just as rare as an engineer with great technical skills, and they're equivalently valuable for career growth.

Four

Understanding process is a good thing. You should (at a high level) understand the basics of what Agile and Waterfall and Scrum and Kanban do for an organization. What they optimize for. Their downsides. If you get obsessed over the nitty gritty specific details of any process, you're probably optimizing for process far more than for results. The why behind the process is the key thing you need to understand.

For example, it's critically important to set your sprint commitment based on actual velocity, not your estimates. You need to understand why that difference is the linchpin for a successful agile process. I was amazed at how many people tried to implement a variety of agile without understanding this point.

Five

Early career folk should care less about their current income, and more about tech exposure. In the careerspan of a software engineer, you'll advance far more (and make far more) if you learn a variety of popular technologies. Those engineers who were hired (at good pay perhaps) to work on custom internal tech only used by one company? They have serious career problems in the long run.

If your tech isn't widely used across the industry, you probably need to find another job. I feel so bad for those people I interviewed who continually used acronyms and tech solutions that were internal only to their current company. Unless they were brilliant, changing companies was like starting their career over.