Notes for new hires

Posted on July 07, 2024 · 8 mins read

I’m onboarding new engineers at Vori, and finally took some time to write a few ideas I’ve been kicking around and sharing internally. I have personally found these practices helpful over the past few years, and think others might, as well. This isn’t applicable to only junior engineers, or new hires (despite the title). I didn’t learn some of these lessons until I was eight years into my career as a tech lead at edX, or a couple years later at Stripe.

Don’t struggle in silence

If you get stuck, see what you can figure out in 15-30 minutes (up to you to decide if you’re making progress). Ask for help if/when you hit a wall. I’d rather you interrupt me multiple times daily than be blocked for hours for fear of “bothering” me. My goal is to get you ramped up as quickly as possible, so I’ve already planned to spend more time mentoring you and less time on other work.

Ask “why?”

You’re here because we think you’re smart and can help us build a better product and team. You need to understand why decisions were made in the past so you can help us make better decisions in the future. You learn that by asking, “why?”…a lot. Hopefully, we have a good answer and explanation, but that may not always be the case. Sometimes, we simply needed to move quickly so incurred technical/organizational debt. We should be reducing the number of “that’s how we’ve always done it” answers over time.

In addition to helping improve decision making, understanding why some things are as they are will help you avoid falling into the trap of trying to refactor or “improve” something that should simply be left alone. This post on Chesterton’s Fence explains these ideas further.

Maintain a friction log

I learned about friction logs during my time at Stripe, but didn’t truly appreciate them until I joined Vori. The idea is simple: take note of all the things—not just product-related—that are causing you trouble. You focus on internal process, in addition to product run-throughs, because we are still working on these internal processes and scaling them as the team scales. This is all quite subjective and could include anything from a README missing a step to some process simply taking too long. We’ve all been here a while, and have either gotten used to the friction or have not taken time to prioritize reducing it.

I will share mine with you, but your own log doesn’t have to be public. I kept mine semi-private (anyone could find it if they knew what to look for) with a disclaimer that the contents should not be interpreted as criticisms. I fixed some items—migrations used to take 2 minutes to generate!—added some to the backlog, and others have been ignored as we’ve evolved.

This blog post on a “WTF Notebook” offers a similar v iewpoint and deeper example of using what is essentially a friction log.

Keep a brag doc

Brag docs helped me keep track of my accomplishments over the year to prepare for mid-year and full-year reviews at Stripe. Julia Evans, a former Stripe, has an amazing post on brag docs that you should read right now.

We don’t have an annual review process at Vori, but you should still maintain a brag doc to track your own progress and as a source of content for your résumé (not that you’re leaving anytime soon…right!?). Admittedly, I haven’t done a great job of keeping mine up-to-date, but I’ll use commit history and Linear comments to update it soon. My brag doc is also a nice little ego boost when I’m feeling low.

Here are some items I think are worth the time to read, or at least skim. I have found that the “soft” skills are some of the hardest to master, and the most important. Yes, technical skills matter; however, engineering is about problem solving, which requires communication and relationship building.

These are items have made the greatest impact on me. I consistently reference them. Prioritize reading them if nothing else.

⭐️ What Got You Here Won’t Get You There: How Successful People Become Even More Successful

Kudos to my edX manager, Zach, for recommending this to me. I used to be a terrible teammate. I focused too much on “clean” code at the expense of people. I tried to take on large tasks to meet artificial deadlines, instead of working with my team. This book helped me understand how my bad habits were negatively impacting me, and showed me how to avoid them.

⭐️ Accelerate: Building and Scaling High Performing Technology Organizations

I picked this up at Stripe during a book club led by Will Larson. I recall thinking, “duh,” as I read it because I had practiced many of the “key capabilities” the book recommends. I’m due for a re-read to refresh, especially now that I’m at a startup (and cannot rely on expertise spread across a larger organization).

The Wikipedia page offers a good summary of the key capabilities and metrics.

Designing Data-Intensive Applications

This is recommended by many folks online. It’s meant to serve as more of a reference than to be read cover-to-cover. I’ve read a few chapters, and find it good for getting exposure to concepts I have not necessarily dealt with hands-on.

The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change

Read this if you’re considering becoming a manager, or simply want to better understand what a manager does (or should do).

The 5 Love Languages

We have relationships with the folks we work with. These relationships may not be romantic, but they still need to be maintained. Learn more about what makes people tick to better understand how you can work with them. My love languages are, “acts of service” and “quality time”. My most quality time is at home, away from work, so the best way you can reach me is probably by taking a task off my plate.

Influence: The Psychology of Persuasion

I read this during my Managerial Psychology course at MIT. This is about the only book I recall reading from my time there. The thought of influencing or persuading someone sounds a bit underhanded/two-faced. It doesn’t have to be. You can use the power for good! This has helped me make more-compelling arguments when trying to convince folks to, for example, change a technical architecture.


This series of blog posts/interviews created by Will Larson morphed into a book and podcast. This is great material for learning how staff engineers operate at other organizations, and what is expected at that level. Note that “staff” means different things at different organizations. Make sure you chat with your manager (and maybe their manager) to fully understand (a) what’s expected at that level, and (b) what you can do to get there.


This was a magazine printed by Stripe. Publication has ended but the digital site remains. I suggest you at least skim through each issue to see what sticks out to you. You can (almost) never have too much testing!