How we work

The overarching goal of Paper Instruments is to create white collar intelligence with tremendous craft.

There are many kinds of durable businesses:

• Distribution forward: Snowflake, Eleven
• Mission forward: Anthropic, Palantir
• Craft forward: Apple, Stripe

There's no single choice for the kind of company you want to build, but if you aren't world class in at least one dimension, you will fall flat in the market. Everything we put out is done with the intention of it being the absolute best, bar none, of its category, and every decision we make is in service of the craft.

We believe that the market will reward tasteful, differentiated intelligence, and our job as a team is to be stewards of that craft.

One of the benefits of a small company is that there is very little hierarchy - we have no real teams or bosses or bureaucracy. That can also be a risk since bureaucracy often serves as a quality control mechanism. To solve for this, we are sharing a few principles to hold ourselves to such that we can all maintain the benefits and joys of self-directed meaningful work without rigid bureaucracy. These principles are demanding, but I hope they communicate the weight and responsibility tied to world class craftsmanship.

Values

Ownership

Early stage teams live and die by the work done by individuals

• The most important thing to internalize as a member of this team is that your work will get shipped and you must defend every choice in the work product. Your mindset is to create work with zero defects – of course everyone makes mistakes, and your first drafts of work will have mistakes, but before you sign off on something your default posture should be to review, re-review, test and re-test everything so you're confident you solved the problem you set out to solve without hidden errors.
• This also applies to timelines and triaging - the counterweight to craft is speed, and we have to be aggressively prioritizing and keeping track of time, so at all times you should be asking yourself "is this a good use of my and the team's time?" and "is someone blocking me and how can I help unblock them?" and "did I communicate the right timelines, and am I giving updates on changes to estimates?"
• Ownership is ongoing - when you put a PR, after you merge, after it's in production and you notice something weeks later and so on. We're all collectively building something and everything you touch is in some way "yours" to be a steward of, and proactively fixing or returning to things is a good way to maintain a relationship with your work.

Courage

What has to be overcome is not difficulty of the intellect but of the will.

• We are open to anything at all being true - even the things that may conflict with our prior assumptions or what we want to be true. Oftentimes in business the hardest decisions aren't those that require a lot of intelligence but require a lot of willpower.
• It's cheap to be ambitious - anyone can say they want to build a billion dollar business. It's expensive and difficult to choose to do so in a way that violates priors and faces risk. We choose courage, not ambition, when it serves our craft (e.g. training models, forking our own doc manipulation packages, when most small startups choose not to).

First-Principles Thinking

Always double-click and look one level lower

• First-principles thinking is the simplest path to better craft, and it can be terribly difficult to exercise.
• It's easy to ask Claude or GPT to think for you, or to defer to some prior art or something that another company did. However, it is extremely hard and sometimes agonizing to learn what's underneath the current level of abstraction you're at – You may move from something you understand and have a mental model of to something you simply have no clue about (e.g. from PyTorch to CUDA). However, the insight is always in the details, and refusing to face the mental strain of going lower is the reason companies fail.
• If you have a disagreement or uncertainty, it's almost always resolvable by going a click lower.
• Like the first two values, I can't emphasize enough that the blocker here is not an intellectual choice but an emotional choice. "First-principles" is often framed as a "smart" or abstractly difficult way to think, but the reason we often fail to think in that way has nothing to do with intellectual complexity and everything to do with how it feels to confront the idea that we don't know something. It often is uncomfortable to acknowledge ignorance, but it is precisely the right place to express willpower and face that ignorance and learn something new about the problem you're solving.

Operating Principles

• Leadership
  • One of the benefits of a small team is no bureaucracy. Treat everyone in the group as a resource to learn from and, when needed, a way to reify expectations into something concrete. The goal should be to uphold craft and speed for your own sake, so that you walk away from your work proud of it.
  • Decision making should rest with the person who holds the most context on the problem.
• Quality
  • Take the concept of zero-defect seriously. You should review, re-review, validate and smoke test every piece of work (i.e. cross t's and dot i's). If it becomes tiresome you should build systems to automate this process.
• Speed
  • Share and escalate blockers and complexity early. It is completely okay to be stuck or not know what you're doing, but it's incredibly important to proactively communicate that and ask for help and feedback.
  • There are 2 kinds of decisions: one way and two way decisions. The first is hard to reverse, and the second is easy. One way decisions are usually things that go out in major version releases or to a customer or are foundational design/schema decisions. Agonize over one way decisions and decide after ample, exhaustive research and deliberation, for two way decisions just make a call and move on. Exhaustive research is for example: cataloging how every harness in the market approached that decision and comparing it to your approach.
    • In some cases, the work product might be disposable (internal testing, scripts, etc.) and not meant for public consumption (this is expressly a two way decision). In these cases, ownership means you adjust the quality bar as necessary for speed (knowing how to calibrate this bar is itself an essential skill).
• Teamwork
  • Not all work products are done solo. If you are working with someone, do not just hand off and "trust that things will be fine." There is no offense to double checking others work and no concept of "stepping on toes." Review their work, give early feedback, and most importantly do not let anyone be a bottleneck.
  • If you are blocked on something that is not a reason to stop progress, you should be checking in on whoever is blocking you multiple times a day to make sure that upstream work is getting done quickly and well.
  • Similarly, you should always assume that you are someone else's bottleneck, so you should never sign off for the day without giving an update in the relevant channel about exactly what's done and what's left.
  • This model of teamwork is not original to Paper Instruments. See: Paul Graham on Brian Chesky on Founder Mode, Mr. Beast on Production, and The Last Dance.
• Education
  • We are doing work that in many cases no one has ever done before. There is no manual, and there is no guide. However, that is not an excuse to not know what you are doing. Every single thing you work on should be front-loaded with education - it's your job to read the docs, read the code, understand the model architecture and so on. Everyone should have a basic understanding of how LLMs work and generate tokens whether or not you are working on training code.
  • At all times you should be reading papers, asking questions, digging deeper. If there's an important concept relevant to your work (let's say TITO), you cannot sit on that lack of knowledge for more than a few weeks - working through the ignorance for months is not acceptable and likely to result in bugs or poor design choices. Carve out time to fill in your knowledge gaps.
  • The pace of things is dizzying, and what you learned in grad school or in your previous job has a very short half life of utility. It does not matter what you know today inasmuch as what you will know by the time you deliver your work.
• AI usage
  • You can use AI to do work, but you shouldn't use it to outsource your thoughts, especially when communicating with others. If you aren't sure and are moving quickly, you can share the AI response in a markdown file and assume the recipient will not read it but also just hand it to their agent (sometimes this is good for fast agent-to-agent comms). In this way, AI generated content is a bag of information that can be used, but never point to an AI response as your own thoughts.