I've been building products in startups and scaleups for over 10 years, and I think with a product mindset first. What matters to me is whether what we're building actually helps the company survive and grow, and then figuring out how to structure the tech so it can keep up, taking things from idea to production.

I'm a generalist software engineer who works across the full stack, but my deepest experience is in backend systems and software design. I want to understand the business problem before picking the architecture, and sit in a discovery session with product to find shared understanding of the problem space, rather than witnessing solutions emerge in isolation.

Domain-Driven Design has shaped a lot of how I think. As Brandolini says, "what gets into production is not stakeholder knowledge but developers' ignorance." DDD for me is about closing that gap: aligning what the business needs with what actually gets built. That's always been hard, and now with AI writing more code it's even more important since you're adding LLM bias on top of developer ignorance. I've applied this thinking across multiple products and teams and it keeps helping, especially when the domain is complex and the org is growing.

I try to lead by example, with servant leadership and model-first approach. I care about helping teammates grow, sharing what I've learned, listen to them, and introducing practices and ways of thinking that make the whole team better. Whether that's facilitating a design session so everyone understands the domain, pairing on a tricky problem, or just making space for someone to take on something they haven't done before. But it goes both ways: I learn a lot from the people I work with regardless of experience level, and I think the best teams are the ones where everyone pushes each other to get better.

Most of my career has been at companies going through growth. I like that environment because the problems are real and the decisions matter. You need to ship, but a lot of systems suffer from under-engineering more than over-engineering. It's about understanding the real problems, solving those, and keeping both short and long term in mind depending on where the company is at.

📫 How to reach me: via LinkedIn https://www.linkedin.com/in/lucagentile-eu/