In many software teams, decision-making is driven by habits, blindly following best practices, or the latest trends - rather than a clear understanding of the problem. Microservices are a perfect example. Teams often break systems into smaller services because it feels like the “right” approach and everyone else is doing it too. Before a single service is deployed, the architecture is already overcomplicated - not because of bad intentions, but because we never stopped to ask: what problem are we actually trying to solve?

Through real-world examples, we’ll discuss how to think critically about the way decisions are being made in your company. We’ll introduce concepts like participation theater—when people perform the rituals of decision-making without making real decisions—alongside problem restatement as a tool to uncover the real challenge at hand. We’ll also examine different types of decisions (reactive vs. proactive, reversible vs. irreversible) and why recognizing them early changes how you should approach them.

This talk is a call to slow down to speed up your decision-making. Whether you're an engineer, architect, or tech lead, this session will challenge you to pause before reaching for Kubernetes (or other technologies) and instead ask: what problem am I really trying to solve?

The word ‘product’ is everywhere these days. There are so many different definitions out there, that is getting confusing. There is this belief in the software community that, in order to build good software systems, everything needs to be a product. That this is the best way to deliver value to your customers and that projects are no longer useful in the context of software development. But is this really true?

In this talk, I will explain my understanding of what a product is and what it isn’t in the context of software development. I will introduce a new concept called ‘streamlet’ and explain how it can help you with thinking in products and teams. I will clarify how Domain-Driven Design helps you with product vs project decisions.

Coffee or tea? One sugar or two? Should we use Event Sourcing or does CRUD seem good to you?

Our brains are designed for making quick decisions, but quick does not always mean good… We make thousands of decisions each day but never stop to wonder: how did we come to this conclusion? Were there more choices than we realised? Did we focus on the right thing? Did we pick the right option? Are there other methods we can use to reach a better outcome?
If we improved our decision making by just 1%, overall we would achieve a massive improvement in every area of our lives, from happiness with our family to success at work. Everybody should learn decision making heuristics, yet nobody does. Let’s fix that.

We’re going to take a close look at a variety of key decision-making heuristics including "problem restatement", "devil’s advocate", and "the wizard". Through provocative exercises, we’re going to uncover the heuristics we currently use and we’re going to teach ourselves when to apply certain decision making heuristics to improve our chances of getting the results we want.

Like many companies, our main code base is a C# monolith. Although there is a lot of domain knowledge captured in it, using C# wasn't always the best choice to solve our domain problems. When we discovered F#, we realised that it was a better fit for some of the features we were currently implementing in C#. However, rewriting everything at once in F# would be ineffective. The manual says C# and F# play nice together. So we tried that out, pushing it as far as we could.

In this talk I will show you how we used F# in our existing C# monolith. I will talk about the positive and negative effects of our decisions, what I would do differently in the future and whether or not C# and F# do indeed play nice together.