careers¶

The First 90 Days for a New Engineer

I don't quite know of a book/essay which covers this yet sticks to the question. So I am writing one for him.

The First 90 Days for a New Engineer

I expect each step to take roughly between 10 and 30 days, depending on the pace of your project + size of the team. Do them in order i.e. 1 before 2, and 2 before 3.

1. Study the Ecosystem

Get a very nuanced understanding of what the team considers as high quality in that context. Sometimes it's scale, sometimes it's speed or something else altogether. There are usually at most 1-2 things which every engineering team does to their best.

Get seen by your senior engineering teammates. Not only your manager.

Get super comfy with all docs, codebases, APIs and people who work on those projects.

For every repo/codebase that you study: Add comments, docstrings, setup instructions, make small improvements e.g. unit tests.

Write notes for every meeting and share with the right people. Setup Zoom coffees at the very least.

Shadow and track 2-3 recent support tickets to see how the on-call system works. And then, if possible, shadow someone for a week of on-call. Could be formal or volunteer to help.

Schedule a recurring 1-1 with your manager. Ask them to write down/describe explicit expectations from you. If they don't write, you write it down and email it to them -- and then follow up 90 days later.

Note that you need to know the team's perspective on their strengths and not just the manager's. There can be some gap between the two.

These are the things and people who'll be able to help when you get stuck in a technical problem later. They'll know that you are not an incompetent prick, and have done your homework. This trust is cheap to earn and surprisingly sticky when done early -- but hard to earn after first 90 days.

2. Quick Loud Win

This is more for early career folk and less for senior folk. Do something which is a big, tricky, much talked about the project and then do it fast. Doing it perfect is kind of less important. Why? Because no one expects early-career people to get it perfectly right anyway.

My hack for this has been to pick a project with some well understood technical risk. But! But! Pick where expectations are clear. For instance, towards the tail end of a big project which needs a small feature to be complete and closed.

If you can, pick a task which is closer to your technical strengths. E.g. I've done enough text classification in my short career that I can prototype one in 6-8 hours.

The point of a quick "loud" win(s) is to ensure that you get a steady stream of projects to pick from -- forever.

Good projects should chase you, instead of vice versa. A loud project, well done, will make you attractive to other project owners. Not just quick: Quick loud win.

I hope these help when you join a new gig as an engineer.

All the Best,

Natkhat Nirant

PS: For more senior people on the Engineering Management track, I recommend reading this instead: https://lethain.com/first-ninety-days-cto-vpe/

Talent Cooling

Talent Cooling Kills Startup Growth

Evaporative Cooling of talent occurs when the most high-value contributors to a community realize that the community is no longer serving their needs anymore and, therefore, leave.

Then something remarkably interesting happens:

When that happens, it drops the general quality of the community down such that the next most high-value contributors now find the community underwhelming. Each layer of disappearances slowly reduces the average quality of the group until such a point that you reach the people who are so unskilled and unaware of it that they’re unable to tell that they’re part of a mediocre group.

This applies to startups trying to scale/grow as well. For small teams, as little as 1-2 resignations can open a dam of exits.

Best Engineers are a Guild

A useful mental model to have is this: Engineering is a Guild.

Makers, and particularly software engineers are loosely defined guilds. The guild-like behaviour emerges partially because the best engineers are ~within 3 degrees of each other at any particular given point in time. The guild decides which companies and offices it wants to support.

Most entrepreneurs and business folks e.g. product managers do not seem to mentally acknowledge the tacit existence of this guild early enough.

Recognizing Mediocrity

Here is one version of how this story plays out:

As you scale, you hire some amazing technology people. Build an engineering team. You build something useful together. 1-2 people quit.But you’re okay. You’ve promoted the people who trained under the expert. That is how you grow “your people”. You’re hiring some senior external talent too!

After a while, your tech team is unable to ship fast enough and sometimes even your basic hygiene factors like uptime are suffering. “Refactoring” becomes a rallying cry instead of shipped.

Product is blaming tech, and within tech, different functions e.g. front end vs backend work with varying degrees of distrust.

Here is where things get truly interesting. You’re now actively fighting the Fiery Demon of Talent Cooling.

The new engineering manager instils a bunch of processes, hires some amazing people and shows a lot of movement. But when you look back 1-2 quarters later, you’re again at the same place: there is no fire in your shipping engine.

Why? Because it’s extremely hard for mediocre people to realize that they’re in a mediocrity.

---

Sources/Further Reading: 1. https://web.archive.org/web/20190328104722/http://blog.bumblebeelabs.com/?p=1207 2. https://medriscoll-com.cdn.ampproject.org/c/s/medriscoll.com/post/9117396231/the-guild-of-silicon-valley/amp 3. If you’re interested in avoiding losing your best tech talent to discomfort and boredom, this is an excellent starting point, written by a practitioner: https://randsinrepose.com/archives/bored-people-quit/

Standing Out at Work

In my short career, I've seen some amazing young people stand out at work.

Here is what they did, organized by 5 themes:

1. Unlock Knowledge

2. Automate Boring Stuff

3. Write Widely

4. Solve Open Problems

5. Outside-Visible Work

Unlock Knowledge

Expertise and know-how stay trapped in emails, docs and codebases. Unlock this for everyone else.

Get your Star Salesman on an internal podcast to spill their secrets. Do email interviews with your tech leaders and PMs. Publish as internal docs on best practices of your teammates.

Build a repo of this over the years.

Automating Boring Stuff

You can get noticed quickly by writing Excel macros for the analysis your boss does manually every week.

Or improve build-deploy speeds for devs. In design, make a theme for Sales Decks and Internal meetings. PMs can templatize repeated docs that they write, like updates or shipped emails.

Write Widely

Write team/company-wide docs. E.g. Setting up your machine, in-jokes, internal dictionaries etc. Make the codebase navigable by adding docs and README.

Take notes in a meeting. Email them to everyone later. It helped Chris get into Google and become a VC.

Outside-Visible work

In some teams, the culture will prevent you from taking initiative.

In those cases, get visible outside your company first. Participate in hackathons, meetups and do open source work, or write blogs.

This is what I've used the most and perfected to an art form. I got more projects for my Deep Learning skills at my work once Hindi2vec and Awesome-NLP went viral. My skills had not changed at all.

Solve Open Problems

Most teams have 1 or 2 important problems which are parked for later.

Research them

You can do primary user interviews, Twitter polls and Google Form surveys on WhatsApp. Get macro-estimates from Google Searches. Compile into a crisp video/written report. Share widely. Add recommendations by asking experts.

To re-iterate, all of this builds on the most fundamental principle: Doing your job well.

When you promise something, get it done. Nothing stands out more than initiative and accountability.

What have you seen amazing people around you do that you’d want others to do as well? Do reply and share your experiences.

That is all for tonight!

Natkhat, Nirant