Levi Malott

When I first became a VP of Engineering, I had no idea what I was doing (sorry @dsaezgil) The next three years were full of trial and error, Imposter’s Syndrome, and whole lot of self-reflection. I could write a book solely on the mistakes I made. I tried reading management books, seek out mentors, and listening to podcasts. Everything I could to try to stumble my way to being a good leader and steer the organization. In the process, I realized that I lost my own voice and questioned all my intuitions. The result was a watered-down version of myself that made me a much less effective technical leader. I bought into the Big Tech wisdom that managers needed to stay out of technical decision making. That was for ICs. I bought into the role of a manager is to focus on career growth for an individual. I bought into things that ultimately led me to being a bad manager for a long time and let to a quagmire of technical complexity that was unnecessary. When I joined @weave_bio, I steeled myself and was focused on making an incredible team that was lean and razor sharp. I cast out all advice I had received and went back to first principles. What is a manager? Why is management needed? What is leadership? How is technical management different from other disciplines? What I discovered through this process is that you can achieve so much more with a lot less compared to if you followed off-the-shelf management advice. You can inspire more by being authentic. You can lead better by diving deep into the details of the work. You make better decisions the closer you are to the work. You build better relationships the closer you are to work and people doing the work. I’m thankful leaders like @bchesky and @elonmusk are being more outspoken about this. I’ve observed the power of it during my tenure at @SpaceX. As a manager, you don’t get to excuse yourself from doing the hard work. Especially, in a startup. You’re signing up for doing even more work. If things are broken, you’re accountable for getting them fixed. If you’re going down the wrong path, you’re accountable for getting back on the right path. If your organization is stagnant, you’re responsible for the vision. Now as a CTO, I don’t question myself. I don’t avoid getting into the details. I don’t obsess over org structure. The only thing that matters is if we are building a successful product. I find peers going through similar struggles when they first transition into a technical leadership role. There are a lot of management resources but often contain poor, even dangerous, advice in technical fields. My goal is to start filling this void by helping technical leaders at startups. The bottleneck of innovation isn’t capital. It’s really good leaders.

I’ve stopped letting AI code my tests. AMA

This is the key to being able to move quickly. You can’t have a culture of risk taking in safety critical domains without a huge investment in testing. That investment enables identifying if things even have a chance of working before you end up on the test pad. Imagine you’re building a geo-sync spacecraft. You traditional would spend 10 years working on that. Everything has to be successful in one shot. So obviously you have to invest in ways to increase your confidence before you’re in Mission Control. Most organizations stop there. As a result, once you have something that works you wouldn’t want to change it. The culture degrades into avoid changing things to avoid breaking things. You use the same parts, same processes, and same frameworks. To do that, you must be able to continue to take risks while delivering high quality products. No detail is too small to obsess over and optimize/eliminate. For example, at SpaceX the goal was always rapid reuse and reflight. Hundreds of rockets being built and flown a year. Traditional radiation hardened electronics were hundreds of thousands of dollars, decades old, and produce in very small quantities with long lead times. Good luck buying a thousand rad-hardened microcontrollers at a time. So SpaceX chose consumer-grade microcontrollers and components. They also chose to invest in thorough and automated testing that could be repeated rather than a one-time qualification. You want to be able to incorporate newer versions of components as they become available. Rather than change being seen as a risk, it’s seen as a necessity. This thinking is repeated and multiplied across every part and piece of software. All of those small things aggregate into a company that can move extremely swift and seemingly impossible ideas. @elonmusk’s under appreciated skill is his ability to imagine a future, understand the key bottlenecks to try there, and extract value from the market while solving the bottlenecks one by one. Innovation isn’t separate from execution. Innovation is ruthless execution compounded over a long period on the path of a future vision.

Increasing context windows were eye candy. I thought “agents” were overhyped. Now I see tool calling + loops as the only viable path to production grade LLM use for complex domains. Trying to manage context and one-shot tasks is a losing battle.

Me: I’m going to get up at 4:30am and work out Wife: I bet you can’t eat the rest of this bunny cake from Easter. Me: I must defend my honor

The most terrifying thing about building enterprise SaaS is it makes you want to use Windows. Maybe try on that button up in the back of the closet. The things I do to get into the mind of the customer…

I’m coding without AI today. Just to feel something

just imagine how much better LLMs will get when we stop giving them ayahausca

Most conventional wisdom you encounter during managing or starting a company or building product were created by people no smarter than you. Don’t blindly follow someone else’s principles unless you truly understand them. To understand them, question them. You can apply the bits and pieces that are useful and make sense. Question everything, be unrelenting in truth seeking, and commit fully on decisions.

Who is building LLM chips with unified memory? I want to run big local models without upgrading my GPU and memory.

One of my favorite use cases for gen AI is prototyping. Often the “how am I going to solve this” requires a creative exploration in understanding a given problem more intimately. For me, that’s always been using code. Where I differ from the crowd is that I throw away my prototypes. I have no problem redoing something once I understand the problem more fully and see the simpler path. Gen AI tools have made that process much faster. While Gen AI can make things work, it still has a hard time making things simple. But it gets me to a place where I can see the simple thing much faster.

Someone please tell me how to keep my AirPods case clean

Building enterprise SaaS is a commitment to build out a stable, robust product. Enterprise customers won’t tolerate broken features. Enterprises won’t tolerate lack of security and data privacy. Some won’t even tolerate you running the instance in your own cloud. Expect that you will need to raise more initially to compete for B2B SaaS. Even if you initially don’t go after the enterprise. There’s more table stakes things that must be implemented (e.g permissions, billing, authN, integrations). AND you typically need hands-on support to iron out issues when they do pop up. I don’t expect the acceleration of AI coding tools to change this much. The consequences of getting core pieces wrong are much higher than accelerated productivity and lack of ownership over the resulting code. Leaking customer info could be the death sentence for your startup. That doesn’t mean you can shouldn’t use AI coding tools but it does mean you need to wield them responsibly. It requires discipline to not be reckless.

Raising kids can teach you a lot about managing a team. For example, take this interaction with my 2yr old this morning. Me: do you want to wear your leopard or unicorn pants? 2yr old at the top of her lungs: I want to wear my leprechaun pants! Me: no I said “leopard” or “uni-corn”. Not leprechaun. 2 yr old: I want my leprechaun pants!! Which was followed by 90 minutes of rolling around on the ground with continued demands for leprechaun pants. A simple misunderstanding turned into 90 minutes of tears, fists, and convulsions. Actually I’m not sure I learned anything about managing a team from this.

Ways to lose credibility as an engineer: * stonewalling and saying something is impossible * introducing technical complexity because there’s something new to use or it is something you’ve always wanted to use * working in the dark without feedback * blocking something because it isn’t the way you’d do it * delivering sloppy work * surprising people with unfinished work Engineering is all about trade offs. Nothing is impossible unless it somehow violates physics. You must be willing to understand a problem intimately and work with others to achieve a solution. We don’t exist in isolation or above anyone else. This is especially important in early startups. I’m looking for an AI engineer and backend engineer if this resonates with you. Link in the comments.

Poetry has ran fine for years. It was inevitable that I’d be unable to install Python dependencies today. Here I come uv @charliermarsh I have high expectations