Kate Lovett

Here's the leadership strategy that propelled me to Principal Engineer at Google: "I push rocks down hills." This is the pithiest summary of Principal Engineer-ing that I've come up with, and it's a major part of how I approach exec-level engineering leadership. Moving up the career ladder as an engineer is about finding leverage: ways to produce more value per unit of time. You can grow your skills so you can handle harder projects and finish them faster. You can improve your judgment so you identify opportunities that produce more value for the effort. You can lead teams, so your skills and judgment get magnified across more contributors. One way to magnify your output as a leader is by turning a hard problem into an easy problem. Something I've observed over time is that it's a lot more challenging to start a project than to keep a project moving in the same direction. The first few commits, the project outline, the high-level architecture: these are the hardest and the most consequential challenges. Once the skeleton is in place, it's harder for a project to run off the rails. Starting projects is hard; maintaining that momentum is comparatively easy. This leads to the discipline of pushing rocks down hills. Your goal isn't to drive a project to completion; it's to impart enough momentum to the project that it will cross the finish line even if you stop paying attention to it. The goal is to build teams that don't need you. Don't build teams with yourself at the center: build teams with yourself on the outside. Once a problem is moving under its own momentum, it's no longer a high-leverage place to spend your time. You can move on. It's time to push a different rock down the hill. One consequence is that you will start more projects than you finish. Not because the projects *don't* finish, but because *you're* not the one driving them over the line. You need to have the humility to step back and give credit to the folks who finish the job. Scaling yourself means taking a smaller share of credit for a larger number of projects.

1,537

56 Comments

The biggest career trap isn’t working on the wrong things— It’s working on the 𝘳𝘪𝘨𝘩𝘵 𝘵𝘩𝘪𝘯𝘨𝘴 that don’t really matter. Early in my career I confused being busy with being impactful. I solved problems daily, but never asked myself if they were the 𝘮𝘰𝘴𝘵 important ones. Here are 4 immediate ways to create impact and accelerate your growth: 1/ Dive deeper into the data to size the opportunity 2/ Speak directly to your customers 3/ Pressure-test your priorities with your manager in your next 1:1 4/ Run cheap(er) validations before you commit Not every problem is worth solving. Always start with: “𝗦𝗵𝗼𝘂𝗹𝗱 I solve this?” The top performers I know don’t just work hard. They work on what matters 𝘮𝘰𝘴𝘵. What’s one thing you do before jumping into a task—to make sure it’s worth doing? --- Follow me, tap the (🔔) Omar Halabieh for daily Leadership and Career posts

231

107 Comments

Today's link dump focuses on vibe coding, but also .. on how these agents actually work under the hood. First off is this post [0] by some folks at Hiro on their approach to vibe coding. It's a great starter for folks new to this space. I liked one of the prompting questions in there: "Through discussions with other engineers and leaders at AI startups, we know that we are not alone here. Everyone faces this question of “how much AI coding is okay”. Tab completions are obviously fine, but what about letting agents run amok? What about vibe coding entire features?" Switching from there to one individual's thoughts on the topic [1], I saw an interesting contrast between how people approach this in corporate vs individual settings (and tips and tricks on how to use these more effectively). Knowing exactly what you want is important, otherwise you'll hit this: "True story- at the end of a long session, I asked Claude how my design was. It was effusive in its praise, pointed out all the things we had done for modularity, separation of concerns, etc. Then I exited Claude and restarted, and asked the exact same question, only this time it had no context. It told me that the design needed a lot of work, complained about the stuff it had just praised, etc." At the same time, as pointed out in [2], AI is an unreasonably effective partner in crime when you want to prototype/bounce your ideas off of someone and it's too soon to hit up a human for tips. I mostly found myself nodding along with this piece, though ... I'd disagree with the "surprisingly" at the start of this quote: "Surprisingly, I think that the fact that I need to plan my features carefully before rushing into implementation is making me a better developer overall. This happens simply because it forces me to document the implementation and think it through before jumping into code. I also find myself explaining my reasoning more clearly because I have to write it down for the AI" Beyond using these agents, though, I've found it to be a great learning experience understanding how all of these tools work under the hood. [3] is a great foray into understanding why/how Claude Code works the way it does: "The main takeaway, again, is to keep things simple. Extreme scaffolding frameworks will hurt more than help you." ... and if you'd like to go even further, you can build your own agent in under 300 lines of code if you follow the advice in [4]. I highly recommend that last piece, because it's chock full of advice in addition to just a great tutorial. "In my opinion, any disruption or job loss related to AI is not a result of AI itself, but rather a consequence of a lack of personal development and self-investment. If your coworkers are hopping between multiple agents, chewing on ideas, and running in the background during meetings, and you're not in on that action, then naturally you're just going to fall behind."

36

8 Comments

My fellow principal engineer Arron Bailiss wrote an excellent blog post about the design principles of Strands Agents 🧬, what the agentic "model-driven approach" means, and guidance for how to think about multi-agent architectures. https://lnkd.in/gh5p5UXi

262

3 Comments