Malte Handbook

Guillermo Rauch posted (with permission) an excerpt of this document on X and there was a lot of demand to see the whole thing. Hence, it is pasted below with no editing. This was originally written in March 2022, but based on a similar document I had used when joining teams at Google before. And that itself was based on a similar doc written by Urs Hölzle.

Background #

Values, Principles, Beliefs #

  • UX > DX > Our difficulty of implementation.
  • Iteration velocity solves all known problems in computer science.
  • Creativity + getting things done
    • These are not independent bullet points.
  • I care deeply about products and cherish the partnership with PM
  • Polish is part of the MVP.
  • The outcomes developers actually achieve matter, not the theoretically achievable best case. Can’t be bad > It can be amazing but typically it’s bad.
  • The top N developers from a diverse hiring pool are better than the top N developers from a bro pool. It’s Math™️
  • Sunk cost fallacy is the root of all evil.
  • Decision quality is the #1 leadership metric.
  • Credit is not a zero-sum game.
  • Impact = usage instances * awesomeness of the thing
  • I like lists.

Engineering style #

  • Software design
    • Design docs
    • Mini design docs
    • API usage is part of software design.
  • Questions I will ask
    • How can we eliminate that trade-off? And if we cannot eliminate it, how can we ever to slightly adjust one requirement to eliminate the trade-off?
      • UX/DX invariants
    • What can we do such that we don’t actually have the problem we are trying to solve?
    • What is our success metric and can we actually measure it and change it?
    • If we are really honest with ourselves, are people actually going to use this?
    • If there is a known unknown that blocks us from making a decision today, what is the worst outcome if we make a decision today and get it wrong? Is that worse than the opportunity cost from not making a decision?
    • Did you consider $CrossCuttingConcern?
  • Scientific web development
    • It is not enough to understand what works. We need to understand why it works the way it does (historical context, actual browser implementation).
    • Empiricism is OK (professionalized trial-and-error)
    • Get good at making predictions about how browsers behave.
    • Browsers are not immutable. We can advocate for change.
  • Empathy
    • Given some API, framework, syntax, programming model I always try to picture the set of possible programs that could be written with it, and try to rank them by likelihood to predict outcomes.
    • The easiest way to build empathy with API users is to build programs with an API.
  • Knowledge
    • Good: Framework, programming models, etc.
    • Good: Web platform
    • Weak: Applied CSS. Future: Hopeless
    • Weak: Infrastructure operations. Future: Teach me

General style #

  • I’m really bad at remembering names.
  • Nobody should ever be blocked on me.
    • I respond to pings quickly.
      • I do not expect reciprocity.
    • I do not mind interruptions from flow.
    • If you need a decision I will make a decision.
  • My style is to observe how orgs behave and adapt rather than force my style of work onto others
    • Expect me to be relatively quiet first and then not be quiet anymore.
  • I have a set of theses as to what Vercel needs to do.
    • I expect them to be wrong, but wrote them down, so I can get better.
    • Very generally, I think we need to do 2 things to make Vercel a 10x business
      • We need to make our customers make 0.X% more revenue than they would have with the competition. Every month, exponentially
      • We need to eliminate entire cost categories from the web development process.
  • My goal for organizations is that absolutely everybody understands why their work is important and how it drives the business forward.
  • I love answering Q&A.
  • I’m more of an early-morning-work person. Sorry Asia.

Stuff I do #

  • Monthly overview of web platform news with behind-the-scenes commentary.

Personal #

  • Alameda, CA!
  • 2 kids (5+8, soon 6+9)
  • Indoor rowing
  • Snowboarding (Alpine Meadows)
  • Electronic music (consuming not making)
  • Home automation
  • Sean M. Carroll fanboy

Published