• As an engineering leader, my job usually has three components:
  • Build the thing. Sometimes we know what the thing is, sometimes we don't.
  • Tell leadership about what we learned building the thing to inform organizational strategy.
  • Develop my team and grow their careers.
• The biggest lever for our success is what I call enduring advantages. Instead of relying on our "natural talents," we commit to doing things that others won't or can't. The source of our success cannot be that we are the smartest or the hardest working. Rather, we seek to create structural advantages that persist in the face of competition and adversity. I will routinely ask how we can be more ambitious.
• Our biggest opportunity to create enduring advantages is through AI adoption and novel tooling. Any team I'm on must commit to staying on the bleeding edge. My principles of working with AI and agents:
  • The best use of AI is not to replace, but to empower.
  • We will not become slop cannons.
  • Experiment wildly, revert frequently.
  • AI is not universally appropriate.
• Alignment is a superpower. We are most effective when we all agree on a shared vision and are free to use our creativity and skills to realize it.
• A healthy team is a productive team. An unhealthy team is a time bomb. Any time I push us out of the sustainability zone, it comes with a cost, borrowing from tomorrow to get more today. That time debt can either be repaid by rest or by regretted attrition. Whenever possible, I choose to pay with rest.

• Every team has its own operating system. It's our job to tweak it based on the nature of the work and size and personality of the team. But without additional context, here are my usual defaults:
  • Weekly one-on-ones with directs. We might adjust the cadence to biweekly if we routinely don't have enough material to cover. We create a shared doc that we can both drop things into. I love to take these meetings on a walk
  • Biweekly planning meetings with the dev team
  • Biweekly retro meetings with the dev team where we actively tweak and improve our process and collaboration
  • Daily dev team stand-ups on all days without a planning or retro
  • Weekly cross-functional meetings with project stakeholders (marketing, finance, etc.)
• The biggest lesson I've learned from working in startups and hypergrowth companies is that what works today will not work tomorrow as you scale. Meeting formats, reporting structures, everything needs to change as the company evolves.
• If it's not written down, it doesn't exist. Particularly action items. They always get written down and they always have an owner.
• In general, decisions should be made by those with the most context. Usually that's the IC who owns the feature, but sometimes it's the manager or executive who has broader business insight.
  • If we disagree, I might try to determine if we're disagreeing on facts or priorities. Disagreements on facts can frequently be resolved with low-effort experiments or more data. Priority or value differences come down to business strategy.
  • Regardless of the situation, I'll always do my best to explain my reasoning and give you as much context as I can.

• Building is a sensing activity. Every week we learn things (about users, costs, feasibility, etc.) that the company can't learn any other way. It's my job to make sure those learnings escape the team and change decisions.
• Bad news travels fastest. If we've discovered something that breaks an assumption the roadmap depends on, leadership hears it immediately. They get the ground truth, not the sanitized version.
• I will make your strong work legible upstairs. Great work deserves to be highlighted. If you found the thing, your name is on the finding.

• When you own something, it's your responsibility to deliver. There's a difference between something slipping and renegotiating a deadline.
• Delivery does not mean "the code is done." Depending on the team, it may mean something like:
  • The ticket has been built
  • The code has been reviewed and merged
  • The feature is live in production
  • We've measured its customer impact and it's working
• You will continue to learn, read, and adapt your workflows. This is not an era for staying complacent.
• You'll share what you learn with me and your teammates.
  • Information is coming too fast for any of us to keep up on our own. We need to work together to make sure we're all taking advantage of the latest breakthroughs.
• Be rigorous in your thinking. Don't treat symptoms, look for root causes.
• Generally, one-on-ones are your meeting, not mine. I'll plan on sharing feedback and give you any organizational info you need to know, but my purpose is to make myself available to you for your benefit. This is not a status meeting.

• I want to know what's going on with you. I DO want to hear about your veganism and your marathon training. Work is important, but it's also only a piece of who we are.
• I care a lot about your career development! I found this to be one of the most confusing processes early in my career. I've run calibrations and releveled engineers, and I'll be transparent with you about how these systems actually work from the inside (what criteria matter, do we use summoning circles or ouija boards, etc.).
• I want to work with you to help understand your career goals and your place in the org chart. This is a great use of our one-on-one time. I want to help you get to that next promotion!
• If you have an urgent need, I will make time for you. I may not be able to solve it, but I will do everything I can to make sure you're heard and work together with you to route or escalate to the right channel.
• I may push you to get stronger, but I will never exploit you or vulture your work to steal credit.
• I love celebrating our wins. If we're winning early and often, that is a good thing.
• You'll always know where you stand with me. If there's a problem we need to work through, I'll have that conversation directly and be prepared to figure out a way forward. If you're exceeding expectations, I'll brainstorm with you to figure out how we can keep raising the bar.
• It's ok to cry in one-on-ones. I have!

• I am most responsive on Slack and try to get to inbox zero every day.
• I read all emails eventually, but generally I consider them lower priority than other channels. I tend to get to inbox zero on Fridays, but some items may slip a few days during the rest of the week.
• I love architecture diagrams! On the whiteboard or in Miro/design tool of choice.
• I tend to systematize everything. I think in terms of queues, interfaces, incentives, and probabilities. I will likely inflict this language upon you.

• Email is not my strong suit. Feel free to ping me or follow up if I'm delayed in getting back to you.
• Because I tend to systematize everything, sometimes people who don't think in systems the way I do don't buy in. This is not their failure, but mine for putting the wrong process in place for the wrong group of people. Please let me know when something isn't working and I'll try to fix it.
• Working on the bleeding edge of AI has a tax. We'll likely have a lot of tool and process churn in our experimentation. If there's something we try that you don't like, I want you to tell me. But if it's good, please shout it from the rooftops.

This doc is my inherently biased view of how I work. If working with me contradicts it, let me know and we'll update it. The doc or me.