The best engineers don’t just ship code. They ship outcomes.
But most engineering content won’t help you get there. It’s either tutorials (how to code X) or career advice (how to get promoted). Value Driven Engineer lives in the space between: the decisions, tradeoffs, and judgment that turn technical work into business value.
Big tech engineers write great content BUT their context is different. They have dedicated platform teams, mature infrastructure, and problems of scale.
I write from 15+ years in startups and scaleups, including a successful exit. In the past I have: built integration systems handling millions of weekly transactions: identities, payments, messaging; built teams from zero, introduced and automated processes to resolve business bottlenecks, and worked with C-level to shape business direction.
I’ve hired, fired, and promoted engineers into leaders and successors. I’ve made enough mistakes to write a book about it.
If you want to make engineering decisions that actually matter—for your customers, your company, your team, and your career—this newsletter is for you.
What you’ll get:
Decision-making frameworks that work with constraints, not despite them
The judgment that separates good engineers from indispensable ones
Honest takes on navigating startups and scaleups
Who this is for:
Software engineers applying their work in startups and scaleups
Tech leads making decisions without a playbook
Anyone who wants to think like an owner, not just an executor
I’m Milan Latinovic. I’ve been doing this for 15+ years. My works has been mostly in SaaS, with some consulting for the public sector and independently on backend and infrastructure. I started as an engineer, became a leader, and somewhere in between I also spent a few years teaching software development and databases at university. Over 500 students sat through my classes. I hope most of them found it useful.
I did a BSc and MSc in Computer Science, published at HICSS and IEEE PerCom, and learned pretty quickly that academia and the real world have very different definitions of “working software.”
Everything I write comes from that gap between theory and practice, between good intentions and actual outcomes, between writing clean code and shipping something that matters.
A quick note on advice
Everything I write here comes from my own experience building software, leading teams, and making plenty of mistakes along the way. It’s what I’ve seen, what I’ve learned, and what I’d tell a colleague over coffee. It’s not professional career, legal, or financial advice. Your company, your team, and your situation are different from mine. Use the frameworks, challenge the ideas, but make your own calls. Your decisions are yours to make. Keep growing and have fun along the way.
