Gil Tene, CTO and co-founder at Azul Systems, will share his personal experience affecting company, product, and technology directions. Some reflection and hindsight may be involved.

The role of a CTO varies greatly among organisations. But it almost always includes the responsibility to understand technology trends and how they are likely to impact the organisation. Alan Kay famously said, “The best way to predict the future is to invent it.” What does that mean? Does it apply to your organisation? Is it actionable? Let’s talk about how to start the process of inventing the technical future of your organisation.

CTOs often make high-stakes architecture decisions under conditions of uncertainty, with insufficient information, and too little time. At other times it is prudent to take the time to carefully make trade-offs and weigh options. This talk will touch on different decision making models and when they are appropriate, as well as some differences between expert and non-expert decision makers. And we’ll argue that by instilling a culture where everyone is more intentional about their architecture and design heuristics that your organisation will be poised to grow future technical leaders.

From leancoffee.org: Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. The format for a Lean Coffee is intentionally very simple. It is meant to be the least structure necessary for a coherent and productive meeting.

Ideas are generated individually, then pooled with those on your table to be then grouped, voted on, and discussed in a timebox. Detailed instructions and explanations will be provided on the day and we will have a few experienced facilitators handy to make sure things run smoothly.

This session will be a great opportunity to dig deeper into those "aha" moments or questions that arose from the morning's talks, and discuss your current challenges or ideas with your peers at the table.

Simon Raik-Allen will chair a revolving panel discussion on topics ranging from strategy to ethics

Zendesk has been struggling with reliability from it’s beginning - in many ways it has been a victim of its own overnight success. Over the last few years we’ve had to take drastic measures to address major outages, such as implementing company-wide change freezes.

These measures hurt when you have 1000 engineers in 120 product development teams across the globe, and in many ways create more risk when the freeze begins to thaw.

In order to avoid these freeze’s we have recently moved to implement concepts from the Site Reliability Engineering (SRE) discipline, specifically implementing Error Budgets along with SLOs/SLIs. The aim of this is to “scope” the freeze to those systems that have more reliability issues.

We’ve had some wins in introducing this approach, but are still very much at the beginning of this journey. This talk will tell the story of this journey along with providing some practical suggestions around tooling and practices to implement.

How does a small Australian email company like Fastmail compete with such dominant players like Google or Office 365 or Apple who have the clout and market presence to do what they like, forcing everyone else to conform to their whims?

Come and hear a tale of David vs many Goliaths. Learn why we decided to build a new email standard - JMAP - and the process of getting that turned into an RFC. You'll hear about the pitfalls and joys of navigating the standards body IETF to get the standard ratified, and the challenges we still have ahead.

Maybe you, too, have something you'd like to turn into a standard?

As we level up in technical roles, often we find ourselve thrust into team leadership and management. This sneaks up on us and we can be left without the skills to adequately understand, engage with and lead our teams. This inevitably has a negative effect on our teams and this effect is multiplied as you scale.

What if we could reach into our toolbox that we use to understand technical problems – software architecture and distributed systems theory – to help us understand our teams? Could we learn to better manage people through this metaphor?

We will explore the dynamics of teams and how they map to our understanding of distributed systems. Using this understanding we can apply distributed systems theory to help unpick some of the dynamics of our teams and how to optimise them for scale.