Despite architecture not being a trendy discussion topic, I’ve run hundreds of software architecture workshops over the past decade, for startups through to multinationals, across a wide variety of vertical sectors. In this talk I’ll share my insights about the recurring challenges that organisations face. First and foremost are development teams skipping up front design and documentation in their desire to be agile? both of which can ultimately slow teams down. Then there are questions about whether architects and central architecture groups are still relevant, and how to give teams autonomy to change any line of code within the organisation without sacrificing architectural integrity.

Atlassian is one of the most successful tech companies to come out of Australia, and healthy leadership teams are critical to Atlassian’s ongoing success. These leadership teams, often referred to as triads, are responsible for driving the direction and delivery of Atlassian’s products and platforms. They are cross-functional, most commonly represented by Engineering, Product Management and Design. But it’s not all rosy. Leadership teams are vulnerable to the same problems that befall regular teams, as well as additional pitfalls that come from being in a leadership position. If a leadership team breaks down, this can have a catastrophic ripple effect across teams and projects. How can you spot the signs of a failing, dysfunctional leadership team?

In this talk, two cross-functional members of an Atlassian triad will reflect on past experience in the triad structure. We’ll provide practical advice grounded in real examples, reflecting on what has worked well, what has been lacking and what are the clear & common danger signs to look out for. You'll come away with practical takeaways to help you reflect on your own leadership team and make significant improvements.

Always wanted to speak at CTO Summit? Now is your chance. 5 minutes, no slides, a topic you would like to share with your peers. Go!

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.

What does good enough look like right now for your product, team, or project? Are you investing in features you think you’ll need in the future because going back and changing things is too hard?

As individuals and as teams, we often deliberate for days (or longer) on the perfect solution, because we can’t decide on the “right way” to build something.

However, typing code is rarely the slowest part of delivering software.

We also often get caught by surprise near the end of a project by things we didn’t anticipate. Too often the lesson we learn from this is to spend longer analysing requirements and design.

This talk will explore how optimising for learning, and having a bias for action will help you iterate towards a better solution faster.

Damian will discuss some concrete patterns, techniques, and strategies that software teams can take to get working software in the hands of users earlier, and help you build the right thing.

At Octopus we are dedicating about 50% of our revenue to R&D. This is a big bet, and as the VP of Engineering, my goal is to tip the odds in our favour by building a world-class product development team.

In this talk, I will describe what a world-class product development team looks like from our perspective. I will explore some of the cultures and practices we have adopted, along with the under-corrections and over-corrections we made along the way. If you are responsible for a development team of 10-50, this talk will have something practical you can take back home to help your team.

CTO Panel discussion - "Architecture without Architects" and other CTO challenges

Its increasingly common that teams are distributed across multiple offices, in different countries, all working on the same product or project. But how do you make this work well? There seem to be a number of readily accepted tenants of conventional wisdom to help deal with leading distributed teams, from seeming good ideas “teams must be co-located” to ones that are purely economic “offshore teams can be run at a far lower cost”.

This talk will challenge the conventional wisdom around leading distributed teams. I will explore how I have structured distributed teams at finder.com, and explain where and why I deviate from conventional practices (teams are not co-located or bounded by geography for instance). I will show how ignoring or modifying these can produce much better outcomes, happier, more productive teams, and a great culture of distributed work.

I have over 10 years experience leading geographically dispersed teams (in the US, Australia, Manila, and Europe) and growing successful high performing tech teams. I recently set up teams in the Philippines and Poland and will be drawing on that experience for this talk.

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.