I used to think that the world was as good as it could be. That things were this way because nothing better had been invented yet. I felt that progress and technology were a linear scale that all of humanity marched towards equally, stopping only at problems no one had solved.

The reality is that the world is nowhere near as good as it could be.

We live in an age of self-driving cars, and some people still drive stick.

In much of the world, people drive stick because their cars are old and they can't afford to upgrade. Others drive stick for sport, which can be a fun way to learn about engines and experience driving in a new way.

But some people swear driving stick is better. That they have better control of the vehicle, that automatic gear shifting is imprecise, that having one hand on the stick and one foot on the clutch is the only real way to drive. Race cars use paddle shifters. Electric vehicles have no gears at all. Yet people will die on this hill.

You can extend this analogy to pretty much every aspect of society. I see it every day working in financial services, in the stubborn resistance to new payments, lending, and compliance technology. I see it in our cities, where we don't like building new things anymore because it will ruin the 'character' of our neighborhoods. I see it in my own family members, attached to traditions and ideologies completely impractical when it comes to our lives today.

This makes me both happy and sad about the state of AI. The rate of progress and invention will accelerate, and yet the inertia of society will remain. We will have PhDs in our pockets but insist we know better. We will have robots to do our chores but refuse to let them in our homes. We will automate all computer-based work, and yet someone will still write VLOOKUPs in Excel till their dying breath.

On one hand, I'm relieved that the world won't change all at once. On the other, I'm disappointed that we've built the tools for a better world, but may choose not to use them.

I've worked on a lot of software engineering teams over the years, both at massive companies and zero-to-one startups. Some of those teams have been great, and others not so much.

"Great" is a vague and loaded word, so as a more precise definition, I think great engineering teams do two things. First, they have an incredibly (almost magically) high output, productivity, and quality of product shipped, adjusted per engineer. Second, is that they bring out the absolute best in the people on the team. In my experience, great teams tend to be more professionally fulfilling, and also just more fun to be a part of.

In this way great engineering teams are not too different from great sports teams[1]: both are environments where everyone plays their best AND end up winning the game. The current team I'm on definitely falls into this category. When I tell people our team size[2], they are confused, if not skeptical, especially since we've been shipping like this before the wave of AI coding.

I reflected on this, and on other engineering teams I've been a part of, and found some hopefully not-super-obvious insights into what lets teams, and therefore the people within the teams, really shine.

The TLDR is: I think there are 5 characteristics that separate great engineering teams from those that are less great:

1. High trust over process
2. The builder decides
3. Almost too ruthless prioritization
4. Hiring player/coaches
5. Hard work as a default

High trust over process

Any great team trusts each other immensely. As builders, we need to ship things that work well and don't break. One way to do this is to have extremely structured and strict processes, which can grind velocity to a halt. Another way is to trust your teammates at the level that soldiers trust each other with loaded weapons.

You need to trust that your teammates sincerely care about the quality of their work. That they won't ship a bug on a Friday night and then disappear for the weekend. That they will step up and make tough decisions when they need to, but not overpower you when it's your turn to lead. That when you make a mistake they will offer a helping hand. That if they are making a prod DB config change, they have thought about it carefully, and shared appropriate context with the team.

Not to say that all process is bad, but process needs to be thoughtfully added, especially if it's being used as a substitute for trust.

A high trust environment can be scary, but it empowers individuals and brings out their best, rather than settling for the lowest common denominator. It lets people take risks that allow for uncapped upside and lets teams stay small and agile.

I would much rather hire for trust over "experience" or "skills". To keep the sports analogy going: hire someone you're excited to pass the ball to.

The builder decides

This philosophy can be boiled down to: the person doing the work is the one to make the decision. Teams can save thousands of hours of meetings and analysis paralysis with this simple rule.

If you're working on something: you are the default decision maker. It's up to you to decide when a decision should be escalated or when a consensus is needed. However, even in these moments it's your responsibility to be the tiebreaker.

What should this data model look like? The engineer coding it ultimately decides. What should the rate limit on this service be? The engineer coding it ultimately decides. Should we offer this as a one off feature or turn it into a dedicated suite of APIs? The engineer coding it ultimately decides.

This works because the person writing the code usually has the most context on the domain anyways, and if they don't, it's far easier for that person to learn the domain than for a non-engineer to grok the code. Becoming the domain expert should be a baseline expectation for the engineer doing the work.

This can often take some adjustment, since you may be trained to have an escalation path for every single decision (ex, a dedicated product manager, eng director, or other executive)[3]. Maybe in some cases, a lack of escalations can lead to a 10% worse design or outcome. But I believe that that trade-off is worth it since it's better to ship something quickly and get it slightly wrong than to ship something slowly but get it "right". There's no evidence that decisions made by group consensus are better than decisions made by a single owner with all the context anyways.

Almost too ruthless prioritization

It took me a while to realize that prioritization means pissing some people off. Software is defined by the things the engineers choose not to code.

Not gonna lie, this one takes exceptional leadership from a manager or CEO[4]. Ridiculously effective teams have ridiculous amounts of focus. My people pleasing tendencies would have me hiring more engineers just to throw bodies at what I consider P0 problems. It takes courage to say no to everything but the P0 among P0s.

A nice side effect of this is that nobody ever feels like what they are working on isn't important.

Hiring player/coaches

Hiring should be rare and special. You are bringing someone in to your circle of trust, a cherished environment that you've worked so hard to keep "great". How do you do this? There's no perfect formula here, but one mental model that I think works well is looking for the player/coach[5].

A player/coach is someone that can perform the work on the ground, but also has good instincts on how to lead and manage. This lets them manage themselves and take responsibility in a way that some pure "players" can't. Think about someone that will spend hours looking over crashloop logs in Kubernetes to find a networking bug, but also understands the reasoning behind the Q3 product roadmap. Player/coaches have the ability to zoom in and out and apply their skills for maximal leverage.

A player/coach is more a personality type than it is a specific amount of experience. They tend to be ambitious, but are ok with sharing the spotlight. They want to learn from others, but also value autonomy. They love leadership, but hate micromanagement. You generally want to avoid pure "coaches": people with fancy titles who haven't coded in a decade. These people are often too far away from the problems that the team faces, and as a result can't be trusted (see point 1) to make decisions (see point 2).

As you may imagine, it's very hard to find engineers that fit this mold. But when you do - the payoff is worth it.

Hard work as a default

Great teams work hard by default. As much as I hate to put this here, I can't deny that this is important.

There's a special joy in working super hard together as a team. The intensity and thrill of it is hard to describe, and can be addictive, often to the dismay of our friends and partners. I can often be a lazy person, but when working with a great eng team, that side of me disappears and is replaced with endless stamina and determination.

When you are trying to hit an insane customer deadline to ship a feature, or have a production issue wake you up at 2am, there's no better feeling than seeing one of your teammates log on to help you. Lamenting struggles and celebrating wins is way more fun when you've given it your sincere best effort surrounded by other people that have done the same.[6]

Part of working hard is knowing when not to work hard - taking vacations, switching up projects, caring for each other personally when times are tough. If hard work has to be a default, so does regular rest.

—

These 5 things aren't universal laws, just patterns I find useful[7]. Maybe there are great teams out there where none of this applies. If so, I'd love to learn about them.

I’ve recently been doing a bunch of research into international payments, stablecoins, and the role of the US dollar in the world today. What surprised me when reading the online discourse (the comments section) was how often people seemed to be talking past each other about technologies and systems, mainly because they had a different answer to the question: how much should the government control currency[1]?

I like to think of everyone’s view here as sitting on a sliding scale. The thought experiment is, let’s say you were running a government and its currency and could redefine the rules as you see fit, and had the technology and manpower to enforce them accordingly. When would you step in and prevent me, a citizen of your country, from doing something with your currency?

1. I pay a known enemy of state to fund a terrorist attack on citizens of your country.
2. I buy illegal drugs from a known enemy of state and intend to distribute them in your country.
3. I pay a foreign company to publish misinformation about your government.
4. I buy a stolen car from a local thief.
5. I buy illegal drugs from a friend for personal use.
6. I invest in a foreign company that dislikes your government.
7. I buy a ticket to a comedy show that makes fun of your government.
8. I buy bread from a local baker who attends comedy shows that make fun of your government.

Most reasonable people would agree that 1 clearly requires intervention, and that 8 is too much government control. But other than that political and moral views can put people anywhere on this sliding scale. If I had to put the US government (and US Dollar) on this (totally made up) scale today, I would put it somewhere between a 3–5 depending on the political climate of the moment.

So much of the debate about payments, currency, and financial regulation occurs because people are operating from completely different places on this spectrum of total oversight vs total freedom. The technology and platform and protocol used is secondary, and often downstream of this. For example, in the US, a central bank digital currency (everyone having a bank account at the Fed) is almost certainly “technically” possible, but would be seen politically as “too much government control”.

Currencies are a powerful tool for nations, and therefore powerful weapons. Because of this, all governments implement some level of control over currencies, which shapes the underlying implementation and has tradeoffs just like any other technology: oversight vs privacy, centralization vs decentralization, automation vs manual controls. As builders in this space, we must design for the people we serve and the context they live in—their real spot on the sliding scale, rather than some whiteboarded ideal detached from reality.

But next time you read a post by a thought leader in fintech, crypto, or banking, or are at a dinner party where someone talks about the broken financial system—try and guess where on this scale their perspective lives. It might just make the content a bit more informative or fun.

AI coding has made me much more productive—but at a strange cost. I can't listen to music when I code anymore.

What AI coding has taken away is the time where you know exactly what you want to implement and have a rough mental model of how to do it—like what files to modify, what data structures to create, what to test for—and then you put some headphones on and just CODE. There was a beauty and joy to this part that I miss, a flow state you can hit with a nice linear progression, like building Legos or going on a hike.

This process has been replaced by prompt-crafting—writing a blurb that contains the same mental model and letting the AI code it up. Followed by looking at the output, and iterating on the prompt till you get what you want. This part is much more jittery—you can’t course-correct half way through, so you just evaluate outputs and often revert and try again from scratch. It also happens so fast that you have way more code to read and understand. I’ve actually made the font size in my editor smaller since I’m scanning files at a much higher level, rather than diving deep into a specific function. Anecdotally, I feel like I’m using more brain cells now than I did with pre-AI coding, or maybe just different brain cells. Whatever it may be, I can no longer listen to music during this process and get things done.

For me, apples to apples, a 4-hour session of AI coding is more cognitively intense than a 4-hour session of non-AI coding.[1] Is this cognitive load worth it? Absolutely—I feel like I can ship at a crazy velocity now, like I have a team of interns at my disposal to code up my every silly demand.

This makes me realize that programming was never the hard part—it was just another way to express what you want to exist in this world, a medium for thoughts and ideas, not too different from English. As AI models get better, the abstractions we work in will get higher and higher, and my “font size” equivalent will get smaller and smaller. But the challenge of thinking—the mental load of going from foggy thoughts to structured ideas, and then from structured ideas to clear outputs—will remain, and maybe even grow. Overall, I’m super optimistic about this future.

I do miss listening to music though…

I have a lot of friends on the east coast/in NYC that ask for recs when they visit SF. While SF is an amazing place to live, it can be kind of a weird place to visit. Hopefully this lets you cut past the obvious tourist traps and enjoy the city a bit more.

Food

SF definitively beats NYC in 3 cuisines: Chinese, Taquerias (Mexican), and Bakeries.

Some places I like:

Chinese — Z&Y, Dumpling Story, Dragon Beaux. There's tons of options that range from more casual to more fancy. Funnily enough most of the best Chinese food is outside Chinatown (ex, in the Richmond).

Taquerias — Tacos El Patron, La Palma (only open till 4), El Gallo Giro (food truck, weekdays only till about 5), El Farolito (late night). You'll probably be fine at any spot in the Mission, so don't worry too much.

Bakeries — Arsicault, Breadbelly, B Patisserie. The earlier you're willing to get there, the better options you'll have and the shorter the line will be. Use that east coast jetlag to your advantage.

You probably can't go wrong by searching Google or ChatGPT for "best dumplings/croissants/burritos in SF".

The only other food recs I'd give are:

Coffee — SF has an amazing local coffee scene. I could write a whole different post about my favorite espresso beans from the Bay Area. Spots I like: St Franks, Four Barrel, Sightglass, Equator.

"Farm to Table" — All the nicer $ restaurants in SF do a great job of this. You're guaranteed to have ingredients fresher than anything in Manhattan. Veggies so tasty they hardly have to do anything to them. Spots I like: Nopa, Cotogna, the Progress, Sorella, Camino Alto.

Activities

SF is a daytime and outdoorsy city. Unless you have a show/event/concert, nightlife here is quite lame, especially for visitors from bigger cities. The best thing you can do is go to bed early, minimize hangovers, and enjoy your daytime.

Here's a random list of fun things to do that will hopefully give you the vibe.

• Rent bikes around Fishermans Wharf, bike all the way along Crissy Field, across the Golden Gate Bridge, and then down to Sausalito. Grab a drink or bite and then take a ferry back from Sausalito (check timings and plan ahead)
• Grab burritos and then hang out in Dolores Park on a sunny weekend afternoon and people watch
• Hike up Bernal Heights and enjoy the views, then grab tacos
• Lands End followed by Chinese or Korean food in the Richmond

If you are willing to rent a car and drive - that opens up a ton of options outside the city (hiking, Napa/Sonoma).

Other tips

For getting around, if you don't have a car just Waymo or Uber. The public transit can be tricky to figure out and unless you are penny pinching it's not worth the time wasted. Also - Waymos are awesome. Download the app and enjoy the future.

Bring a light jacket if you plan to be outside past 4pm. It's always colder than you think at night.

I have always been scared to put myself out there on the internet. I'm paralyzed by indecision, always crafting, always refining, never hitting send.

I want to change that by writing here more. Maybe I'll share thoughts about work - building fintech companies and scaling software. Maybe I'll share thoughts about books or articles I've read. Maybe I'll even share personal stories or feelings.

It's for no-one in particular, it won't be perfect, and that's kinda the point.