Anton Levitsky

I love writing software, but code is a means, not the point. I write it to solve a real problem for a real user. If the code is elegant and the user problem is unsolved, the work hasn't started yet. Every architecture decision, every hire, every sprint goal traces back to whether it makes the customer's life better. Otherwise it's just craft, and craft on its own doesn't ship value.

People mistake speed for typing fast. Speed is the whole loop: how quickly you move from a question to a researched answer, from a scope to a shipped change, from a customer signal to a learning. Moving fast is the most reliable way to learn fast, and learning is what compounds. Slow teams don't lose to fast teams because they ship less code. They lose because they learn less per quarter.

I'm AI-native, and I use AI in nearly every part of my work: research, scoping, code, writing, decision support, agent infrastructure for the team. Not as a gimmick and not because it's the trend, but because it changes the loop above. The leaders who'll build the best engineering orgs over the next five years are the ones who treat AI as a default tool in their thinking, not a feature on a roadmap. That said, I'm skeptical of AI as a default answer. Most production AI failures are upstream of the model, in the data, the trust budget, and the operational discipline around it.

Most engineering leaders treat people work as overhead. I treat it as the actual product. Build the team like a product: hiring frame, levelling, on-call, performance, the rituals around it. Everything the team ships is downstream of how the team is built. A great codebase produced by a broken org will not stay great, and a clear, well-sequenced org will produce great code almost as a side effect.

Zero tolerance for bullshit. Useless rituals, theatre meetings, decks that exist to be presented, status updates nobody reads. If you spot it, the job is to name it and replace it, not route around it. Time spent on bullshit is time not spent on the user, and the team feels it long before leadership does. The same applies to disagreement: speak up before a decision, not after. I want pushback on the table when it can still change the outcome. Once we've decided, we commit, and we don't re-litigate in the execution. The courage I look for is the courage to challenge, not the comfort of going along.

The last thing, the one most senior leaders get wrong: most of my value is removing decisions, not making more of them. Decisions about platform choices, architecture defaults, what good looks like. When teams have to escalate small calls upward, the system isn't designed well enough. The job is to design the system so the team can move without me, then get out of the way.