As my career has progressed over the years, I’ve noticed that the challenges I deal with are less about writing the best code possible and more about creating clarity, leverage, and alignment for my teams. The work itself has shifted from solving problems directly to building systems (technical and organizational) that allow engineers to solve problems well without constant intervention.

These leadership principles are the result of that shift. They reflect how I think about engineering leadership today: how decisions get made, how teams scale, and how responsibility should be distributed as organizations grow. They aren’t hard rules per se, but operating guidelines I use to stay consistent as scope increases and complexity rises.

Ever since agents made it into the mainstream, I’ve been really interested in how they work. I’ve always wanted my own personal Jarvis, and now I feel like I have the chance to build one myself. At its score, it’s mechanics: a loop that observes input, decides what to do, acts, and repeats. At scale, things get much more complex, especially for user-facing products like ChatGPT or other AI coding assistants. What lies in between is a lot of lessons, techniques, and mechanics.

Engineering leads working at startups can often find themselves in the position of needing to translate an engineer’s “this will take three days” into “this will be done by next Thursday.” Ideally, engineers would only work on one thing at a time to reduce the amount of work-in-progress, but a more common scenario looks like them juggling multiple tasks at once that are all high priority. If there is no PM on the team currently and you’re needed to fill that void, that translation can feel more like guesswork than planning. The good news: you can create a lightweight, repeatable process to do it well.

Over the past few weeks, I’ve been tasked with developing a strategy to track and measure AI usage within my engineering team. As an AI-curious leader, I expected to focus on tools and dashboards—but what I quickly realized is that successful measurement starts with asking the right questions.

Along the way, I leaned on a few resources that helped shape my thinking:

• Pete Hodgson blog post: Leading Your Engineers to an AI-Assisted Future: A practical framework for rolling out AI in phases - starting with experimentation, then adoption, then impact.
• The Pragmatic Engineer blog post: A New Way to Measure Developer Productivity: An interview with the creators of a new framework, DevEx.
• The Pragmatic Engineer YouTube Interview: Measuring the Impact of AI on Software Engineering with DX CTO Laura Tacho: Insight into measuring developer productivity and how to add AI to the mix.

These perspectives, combined with what I’ve observed within my own team, have led me to a few early takeaways about measuring and leading AI adoption in engineering.

Thought I’d share some of my favorite resources that helped shape my knowledge of the payments domain early on. Enjoy!

• Scaling Airbnb’s Payment Platform
• Unified Payments Data Read At Airbnb
• Rebuilding Payment Orchestration at Airbnb
• Engineering Uber’s Next-Gen Payments Platform
• Designing A Payments System - The Pragmatic Engineer
• Accounting For Developers - Modern Treasury

Ok, so let’s say you have an HTTP client where you need to get information from the request and response calls for logging or debugging reasons. One way to do this is to create a custom RoundTripper to handle said logging.

What is a RoundTripper?

A RoundTripper is an interface that implements the RoundTrip function which makes the HTTP request and response on behalf of the http.Client, within the client’s Do() function. There is a field on the client called Transport that holds the implementation. Go will use the default version if no custom RoundTripper is provided.