Leadership

Ever since Paul Graham’s Founder Mode came out, I’ve been trying to find a definition for another term I’ve been thinking about: Founder Aura. Yesterday, I was speaking with a friend of mine. I’ll keep names and companies vague to maintain anonymity. He’s a high-caliber researcher at one of the world’s leading companies. A well-known engineering founder, leader and executive joined the meeting. My friend felt the need to mention it. He felt the need to say that the executive appreciated his thoughts and ideas. He felt the need to say that the executive was “just like us.” ...

A Read Through On Venting I have a close friend to whom I vent every once in a while. He recently shared a post he wrote called On Venting. I immediately understood why he responds to all of my non-venting messages and pretends as if the vents never happened: When folks interact with me, I often skip past the emotional complaints. I like to think I do the following, but it’s probably only true half the time—at best: ...

Founders create problems. Operators solve them. I’ve met a lot of executives and CTOs who resonate with two things: They like to solve puzzles. They like to be given an end goal and just make it happen. The job of a founder is to identify opportunities (i.e. problems), set a vision for what a solution looks like, and build a team that’s enabled to get there. That idea, of course, comes with plenty of qualifiers and caveats. It simply defines a founder’s end goal, not their day-to-day. ...

Last week, Amazon quietly hosted a private open house for senior engineering leaders at its Seattle headquarters. About fifty people gathered to discuss how Amazon makes technical decisions at scale-the kind you don’t hear about in press releases or leadership books. I didn’t know what to expect, but who would say no to dinner with smart people and deep conversations in the Seattle Spheres?¹ This is my version of a great night out 🥂. ...

Onboarding engineers is hard. You need to set up your development environment, build context, navigate the codebase, navigate the organization, understand the system, the product — and the list goes on. I used to believe that the best way to onboard an engineer on day one is to make sure they: Get their development environment set up Make a pull request to the codebase Merge and deploy to production You get an immediate hit of dopamine and experience the end-to-end flow of shipping a feature or fixing a bug. ...