Boot.dev Team Handbook

Our goal: To make the best place to learn to code. The most effective, the most fun, and the most thorough.

Now, let’s talk about how to succeed with your work at Boot.dev.

How we work 🔗

We work remotely, and asynchronously
We care about how much and how well stuff gets done, not how many hours are spent working
We don’t just care about the work itself, we care more about the positive effects of the work
We care about how responsive and helpful we are to each other, not how many or which hours we’re “online”
Work when it’s most productive for you and your team. Optimize your schedule for productivity, not hours
Take PTO, and be smart about it. Avoid blocking others for long periods of time, missing deadlines, or letting work pile up while you’re gone. Communicate and stay ahead of the important stuff.
We work flexibly, but not less.

We only want to work with the best people (like top 5%). Life’s too short to work with mediocre people. That doesn’t mean the most experienced people. But it does mean people who are really good, who get better fast, and who go hard.
People who own their work. If your project isn’t getting done on time, or it’s not good enough - that’s on you. Own it. We’ll do everything we can to help, but you gotta take responsibility.
If you’re not doing well, we’ll let you know, and we’ll work with you to improve. If it’s still not going well, we’ll part ways. Mediocre people are a cancer to a team, and they turn even the best people into mediocre people over time.

Don’t use corporate language when chatting with students.
Don’t write content that presents facts without some personality. Regurgitating information is not useful in 2024 - information is everywhere.
We’re here to create an incredible experience, and that means every interaction we have with students should surprise and delight them. That means being yourself, and having a lot of fun with it.

Multitasking is a lie and a waste of energy. Work on one thing, and finish that thing, then work on the next. Only switch if you’re blocked, something else becomes more important, or you need a break from the current task (e.g. creative work). In the case of taking a break by working on something else, you should still only have 2-3 things max at a time.
Break projects down into small tasks. You should be completing most tasks in a day or less. If you’re not able to, you’re probably not breaking them down enough.
Optimize for delivery. It’s better to finish a task today than to get 25% of the way through your next one. Fewer things in-flight, higher frequency of completion.

Have an opinion, and fight for it. Change your mind when you’re wrong. If you don’t get your way, support the decision that was made - don’t sabotage. Disagree and commit.
90/10 rule in all things: Perfect is the enemy of done.
That said, quality is more important than quantity - but there are often ways to get 90% of the perceived quality in 10% of the time by understanding what really moves the needle.
Blast radius: If your plan fails, how bad is it really? You’d be surprised how many things have a teensy-tiny blast radius and yet people are scared to just go for it. This goes the other way as well: aim for asymmetrical risk/reward.
Know your numbers. If you’re in product, you should know retention, signups, funnels, difficulty spikes, etc. If you’re in marketing your should know revenue, CPC, CAC, LTV, etc. You should know the important ones by heart, and know how to find the rest quickly.

If you can’t find the answer to a problem, dig more. Don’t give up because you heard a soft no, or because the first couple google searches didn’t yield amazing results. Dig more than you think you should. There is a point where it’s not worth it to dig deeper, but most people give up before that point. Again, 90/10 rule, stop at diminishing returns.
Be really really resourceful. That doesn’t mean you can’t ask questions, but google it first, gippity it first, dig a little. Take unorthodox approaches, and do the weird manual thing. Do the thing that doesn’t scale. If you’re trying to get in contact with someone, don’t just email them, not get a response, and give up. Send them a follow up email. Find them on Twitter or LinkedIn. Find an office phone number. Come up with a better hook to get their attention. See if you know someone who knows them. Think it through and figure it out. People are surprisingly reachable if you’re creative and persistent.
Don’t make your problems someone else’s problems. Do everything you can to make your coworkers’ lives and jobs easier, not harder.

Anything that can be async, should be async. Don’t turn something that should have been a GitHub reply or a Discord message into a meeting or a phone call.
When you owe someone something, push updates to them. I hate having to “poll” people on their project’s status. Let people know when you’re done if they’re waiting on you, and give frequent updates if you’re taking longer than expected.
If something is important, write it down. If it should be shared, take the time to share it well. Update an internal document, write a good GitHub issue, or post a well-thought-out Discord message. A lot of time can be saved by writing well.
Sometimes a quick real-time discussion is best - this tends to be the case when there are a lot of unknown unknowns, the requirements are still unclear. The more anticipated back and forth, the more likely a real-time discussion is best.

It doesn’t matter what your role is at Boot.dev - you should be learning on the platform. There isn’t a single role here that can get away with not knowing a lot about our platform, product, and content.
Along the same lines, you should know our students. The best place for this is via the discord, but there are a lot of ways to get in touch with students - via email, in feature requests, bug tickets, or GitHub issues, on Twitter, in YouTube comments, or on calls with students. Sometimes its tempting to implement a technical solution to a problem, when the better and faster and easier solution is to just talk to the students and deal with it manually.

You should be personally growing and improving faster than Boot.dev is. If you’re not, you’ll get left behind.
You should be reading, watching, listing to talks and podcasts, and generally just learning all the time. Be a part of communities that practically force you to stay up to date. If you need a book or a course, we can get that for you. Don’t expect best practices, great ideas, and experience to just come to you because the time on your resume is ticking up. You’ve got to be curious and genuinely enjoy getting better at what you do.