Where I failed at first startup

I left Tenderly angry. For a long time the story I told myself was about an organization that couldn’t be changed: centralized decisions, process-focused… With some distance, a lot of it was my own doing and I could have done better.

I joined and immediately jumped into code. I thought that was the most important thing for a company of that size, and I still think so. What I didn’t do was say it. I never explained what I saw, what I was focusing on, or why. Then I was surprised when I was excluded. But I never asked to be included, never showed I wanted to be, and was busy proving myself in a codebase where nobody making decisions could see it. Being right and unheard felt like their problem. It was mine.

Say what you’re focused on and why. Ask to be included. Nobody owes you a seat because you’re good at something.

I had a lot of ideas about how things should be done and very few of them landed. I thought a good argument should be enough, so I made the argument once and moved on. When it didn’t land, I read that as the organization not listening. The ideas that did land landed when someone else picked them up and carried them. I never asked what they did that I didn’t. Landing an idea is a skill, and I hadn’t developed it.

Having an idea is table stakes. Landing the idea is the job. Frame it as how things can be better, not how they’ll break.

On the building side, the suboptimal technical decisions trace back to one failure mode: I didn’t find the stakeholders and get context before building. Everything we did on the API layer was incremental when a step change was needed: user errors, a gRPC gateway, things that felt like progress and moved nothing. Node I built without enough prototyping, and we ended up with decisions I didn’t like and couldn’t find time to undo. I got involved in billing and never asked who needed what from it. In every one of these, asking not only more, but better, was essential.

Find the stakeholders and get the context before you build.

I undervalued experience and moved new people onto new problems too fast. My judgment was right often enough that I should have trusted it more. Most experienced people have the same year of experience many times over, and I let that make me dismiss experience altogether instead of learning to tell the two apart.

Learn to judge experience. And then value it.

When the VP of Engineering role came up, I wrote a document about how it could fail. It was mostly a list of what I needed authority over: org structure, roles, levels, staffing, hiring, firing, engineering processes. I was asking for autonomy before I had earned trust. I framed it as protecting the org from bad decisions, but reading it now, it reads as someone who doesn’t trust the people he’s about to work for and wants that in writing.

Autonomy is the output of trust, not an input you negotiate.

There were early things I didn’t like. I let myself get annoyed and I never really got un-annoyed. I don’t think I ever committed long term. I was into it, but I had one foot out early, and everything I saw after that was evidence for a conclusion I had already reached. You can’t build anything on that footing.

Decide whether you’re committing. If you are, commit.

I learned how to do things well at Palantir. I learned how to take shortcuts at Tenderly. Those are real lessons and I use them. The list above is mostly about patience, people, and communication, not about engineering, and that’s the uncomfortable part. I was good at building and thought that would be enough.