Welcome to On Deck Product Engineering!

This playbook is designed for all new members to the Product Engineering org. It is a living document that will evolve over time.

We're excited to have you on board

Product Engineering Team Overview

Company Overview

The On Deck product is an invaluable part of the experience, but also has break-out potential as a potential LinkedIn competitor. - On Deck Series A Memo

Who we are

(Agency) Tasman.ai - Data Engineering Team Abhishek Anirudhan - Senior Data Analyst Egor Zaitsev - Sr. Software Engineer Flo Bühringer - Systems Lead Ilia Schelokov - Sr. Software Engineer Lauris Skraucis - Software Engineer Lorenzo Castro - No-Code Lead (Product Lead) Max Nussenbaum - Sr. Product Manager (Product Lead) Olga Stogova - Sr. Software Engineer Pawel Cebula - Software Engineer Pierrick d’Annoville - No-Code Architect Rachel Farley - Associate Software Engineer Rishi Tripathy - Product Manager (Product Lead) Sean Moran - Director of Product Stef Lewandowski - Director of Product Engineering Steven Schmatz - Engineering Manager Yanel Bottini - Lead Product Designer (Agency) Tasman.ai - Data Engineering Team

Principles

The values we look for in people

• Empathy and wanting to enable others
• Relentless agency and ownership
• Gives a shit
• Executional horsepower
• Don't take themselves too seriously

We hire people with good decision-making skills

• You are an adult, we trust you
  • You understand risk and get opinions of others when needed
  • You work transparently (Slack, GitHub PRs, Linear, etc.) in small steps so that people can follow along if they are interested
• All coordination and process we do is to enable you
  • If it's not enabling you let's fix it
• We'd rather fire people with bad decision-making skills than micromanage them

Opinions vs Decisions

• The rule is
  • You either make decisions or you only add opinions
    • No exceptions
• What does this mean?
  • Decisions
    • In every project (or anything else), it needs to be clear who is the lead
      • This person ensures decisions get made
        • Either by making or delegating them
    • Whenever possible the lead should be one of the people who do the work
      • It's better to fix a wrong decision if it was your own
      • They usually have most of the context
      • This also allows people like product managers to parallelize or lead a (for them) crucial project
  • Opinions
    • Everyone else (even the CEO) just adds opinions
      • It's good practice to listen to opinions
        • Also it's good to address concerns (ideally before they come up)
    • People you report to have an emergency handbrake
      • e.g. the Eng lead can override a Project lead
        • This should be used sparingly
        • It removes the authority from the person
  • Tricks
    • If you are unsure if you can go ahead even if you are lead
      • You don't need consensus
      • Always have a default path as decision maker
        • This is the path you will go with unless someone raises concerns
      • Communicate it transparently (slack or notion)
        • If it's a complex topic make sure to address concerns
        • Ensure people have transparency into your decisions and can add opinions or pull handbrakes
    • If you are someone with a handbrake
      • Make sure people understand if something is a soft #fyi or hard #plea
        • use #fyi tags
        • If you need to use a #plea tag to make it clear that this is a thing you might pull an emergency handbrake on
    • As lead encourage team decisions
      • Whenever possible delegate decisions
        • Ideally to people who do the work
        • Aim for consensus
          • If there is no consensus the lead makes the decisions
      • Always make sure that decisions are explicitly stated, transparently communicated and documented
    • We hire people with good decision making skills – let's leverage that

Avoiding burnout

• Backstory from Keith
  • Started coding at 12. Wrote code for any and everything.
  • Felt the need to prove myself at new job out of college.
  • Passion for writing code constantly turned into coding 12-14 hours a day for years.
  • Would take a month off between starting new jobs thinking it could help but to no avail because the same routine continued with working excessively.
  • Started losing creativity and eventually ended up barely being able to open VS Code without having a sense of dread.
  • Thought I may never want to code again.
• Why we want to avoid it?
  • Takes a passion one has (e.g. programming) and turns it into a negative
  • Leads to a lack of motivation
  • Can turn into a vicious cycle where little work is produced. Bad for you. Bad for the team.
• Tips for avoiding it
  • Listen to the red flags
    • If you start noticing your motivation is suffering, your output is going down or you simply feel dread when opening your computer, take note of this.
    • Mention these red flags to someone you trust to help you through the process.
    • If you are comfortable sharing, inform your teammates. Giving them context of how you are doing can help a lot.
  • Disconnect!
    • As a remote team, there can be a sense of guilt if you disconnect and miss out on something or are not available when someone reaches out.
    • The reality is always being connected contributes to the burnout problem.
    • Also, work will never end. Attempting to handle or see every single thing as it comes up is a battle we won't win. There's always tomorrow.
  • Work less
    • This sounds obvious but we feel guilty when we work less, making this hard.
    • The reality is working less when nearing burnout can actually be more productive than working a "normal full day".
    • Work when you feel motivated, not based on dedicated times. You'll do your best work when your mind is active and you feel motivated to do the work.
    • Don't force it.

Our goal is not "speed" but "momentum"

• You get speed through momentum
• You increase momentum through confidence

Our goal as an engineering team is to "increase confidence"

• This can mean
  • Improving infrastructure to have a more stable system
  • Constantly making small changes and improvements to the codebase
  • Supporting colleagues so that they can ship faster and more confident
  • Automate everything we can automate
    • Linters, Autoformat, Best practices, CI, tests

Explicit > Implicit

• Explicit is always better than implicit unless explicit is redundant
• Communicate clearly
  • Use distinct terms
    • Avoid ambiguous meanings whenever possible
• Legacy-Prefix deprecated modules and leave comments what is to use instead
• Comments explain why not what
  • Overdo comments - "Leave a big f***ng note"

We have as few as possible explicit process rules

• Pull Requests reviews every morning