I lead engineering at StrongSD and write strategy reports in public, including the parts I got wrong. Most of what I know about deciding under uncertainty I learned in the field.
What I actually do
At StrongSD I launch new teams and projects, and I still write code myself: Ruby, Kubernetes and whatever the product needs. The job in one line is helping software products navigate technical uncertainty and reach sustainable delivery. It sits at the intersection of engineering leadership, software architecture, cloud infrastructure and product execution, and it works best with small teams, where technical decisions, delivery processes and team growth are tightly connected.
Over the years I've launched new products, extended existing platforms, integrated complex systems, and stabilised projects that were struggling to deliver. The point has never been the most sophisticated code or the most elegant architecture. It is helping teams make good decisions, reduce risk, and keep moving toward the business goal. Mostly that comes down to strong technical foundations, continuous learning, and the right questions asked early. The Lean Startup and The Mom Test left visible fingerprints on how I work; so did evidence-based decision making, which is what this whole site is.
On my own time I develop ESF, the engineering strategy framework behind every report here, and publish worked examples of it applied to real systems that aren't under NDA, open source first. Those reports are built entirely from public evidence: the repository, the git history, the pull requests, the funding ledgers, the blogs and podcasts. An AI agent does the data sweeping and the writing; the reasoning is mine. That division of labour is what makes an audit this deep possible in a day instead of a month.
Who it's for
Startups, founding engineers, and people who vibe-coded a product into existence and now need to know what they actually own. Run honestly, the framework reliably surfaces the easy wins; in good hands it yields a real vision. Either way, you can watch it work before you trust it; that is what the published reports are for.
Rather corrected than confidently wrong
Every report opens with its evidence base before its conclusions, carries a revision number, and keeps a decision log where many of the entries are struck through. Before a report goes live, the people it describes see it first: a courtesy window, with my hardest open questions attached.
Why poker
A single hand you can win or lose regardless of the strategy. The long run is where strategy decides. Engineering is the same shape: you cannot control outcomes, only the quality and the sequence of decisions, and quality only becomes visible across cycles. "High risk, high reward" is not a personality trait, it is a bankroll strategy, and risk that is priced, sized and survivable is the only kind worth having.
The racing
I race, and film it for Brukivka Racing, my YouTube channel. This site's ink, its orange and its geometry come from there.
Getting in touch
If you want to argue with a published report, that is the best kind of mail: every correction lands in the decision log with your name on it. Everything else is welcome too; the address is on the button below.