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
- Disconnect!
- Work less