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.