Netflix is a company that innovates on not only technology, but also company culture. The Netflix culture deck, now a memo, has had over 18 million views, and describes an environment of "freedom and responsibility", "context not control", and "highlight aligned, loosely coupled". In this session, Brendan will summarize the Netflix culture, and describe personal experiences of it in practice from the viewpoint of an engineer. Takeaways include aspects that may be useful to adopt at other companies.

Your startup has been very successful, it is growing very quickly and it is putting a lot of pressure on your team to meet the needs of the market. It is a really good problem to have. You added more people to your development team but you noticed that you are not getting the same ROI as you did in the past, in fact, it is a declining ROI, you are just not getting the outcome that you look for.

Operating a 10 people engineering team is different to 50 people engineering team. It is different to operating 100 people engineering team. In this talk, Herry will tell the story on how he scaled the engineering team in Campaign Monitor from 20 to 70 engineers in order to unlock growth.

Building a distributed team is hard. As you hire engineers in other locations, processes that used to work start to fall down: alignment suffers, code reviews slow down, teams start to block on decisions, and the only person who knows how to fix the bug is currently asleep!

Of course, there's a better way. To make a distributed team successful requires commitment and thoughtfulness. Changes in behaviour are required by all parties, not just those outside HQ, i.e. those "with the accent".

In this talk, I will share experiences from being Google Australia's first engineering hire, cofounding Twitter's NYC engineering office, lessons learned building a distributed team at my previous startup, Lexy, and early insights from Canva's approach to global teams. I will discuss strategies to empower and include your distributed team, from communication style to engineering process to hiring.

• What should you think about, with respect to the org design before you break a piece of functionality from the monolith into its own service?
• Why is a deployment pipeline a must have for any and every service?
• What tasks should be automated?
• Is there such a thing as too much automation?
• What types of testing are needed in a microservices architecture?
• What about monitoring and scaling? Why is this harder with a microservices architecture when compared with a monolithic architecture?

There was a time when protecting the perimeter was the primary means of defending your organisation’s digital assets. Keeping the firewall patched and managing and auditing the firewall ruleset was right at the top of the list of security priorities. Intrusion detection and prevention was all the rage. Today, more and more of our digital assets are moving out beyond the company borders. Flexible working means access from home, public wifi hotspots, airport lounges and now even from 30,000 feet above the oceans. VPN tunnels into the company was all that was required to enable remote access, but today key data resides outside of the company, rendering the VPN tunnel virtually useless.

Cloud technologies provides incredible agility and scale and the ability to roll out new products and services at a pace that was simply not achievable twenty years ago. Those that are not embracing these technologies risk being left behind in the ever more competing landscape. However, as with all new technologies, new challenges arise and cyber security in the new world is no different.

In this talk, we’ll look into the differences between cyber defence before and after the cloud. We’ll look into just how much of your data exists beyond the firewall, even for companies that believe they have not yet moved to the cloud. We’ll look at what can be done holistically to protect your data and discuss technologies that are specifically designed to address cloud security challenges.

A social contract is how individuals become a team. Whether your teams know it, they’re already working under an implicit social contract – but until it’s made explicit there’s no way to be sure whether everyone has the same understanding of what it is.

By using social contract theory, you can build a how-we-work agreement that is clear, visible and jointly owned by everyone on the team. This is a great way to reinforce the aspects of teamwork that you want to hold to as you scale, and provide a platform to launch into high-performance mode.

This talk will give you some clarity about how you can apply social contract theory in a way that works with groups of engineers. It looks at how to explain the value proposition in a way that gets buy-in from even your most technically-focused people, and also consider how the process and outcome can address some common dysfunctions of engineering teams.

The session will leave you with effective techniques for leading your engineers through the process of building and maintaining a social contract (with real-life examples).

Since Taylor's theories of scientific management in the early 20th century, most management has focused on improving performance by changing behavior, and changing behavior by changing motivation. Turns out, people are more creatures of habit than they are of motivation or calculation. Psychological safety, engagement, and caring about people are all important for the leader of an organization, including a technical organization. To take that a step further and get a high performance team, most engineering organizations need to be de-bureaucratized. Most attempts to improve engineering efficiency focus on process. That's difficult and boring. Fortunately, you can get better results by making actual engineering decisions that restructure organizational decision-making, turning normal teams into high performance teams.

Depending on my needs and requirements, an architecture can quickly become complex and cost more in terms of investments maintenance in operational condition, skills, scalability, etc.

What does it cost in practice to have an infrastructure with the right levels of acceptance according to the risks involved? Do I have the right people in-house? Tomorrow, should I launch my XaaS platform / my log well / my redesign towards infra as code? Do I really need everything? In what order?

As we move into agile and devops world, silos need to be broken down between different stages and different roles. Testing needs to shift left to remove the biggest barrier that having dedicated people/dedicated phase to do testing, which means “Developer need to do more testing”. DevOps requires continuous testing (automation) to provide fast quality feedback. With the majority testing work shifting left on Developer’s shoulder, and less needs for manual testing, traditional QA’s role needs to be reinvented.

What exactly organisation can do to transform legacy Dev and QA team to embrace these changes? This session will share Gumtree’s bidirectional transformation journey – How we change people’s mindset and skillset and the way of working in stages, introduce the tools built along the transformation journey to support the changes, eventually take away the role from their job title to bring them together as a truly “one team”.

Fairfax media is a 186 year old media publisher and one of the largest in the Australian media landscape. Publishing household names such as Sydney Morning Herald, The Age & The Australian Financial Review.

Over an intense period of 12 months, Fairfax re-platformed and re-oriented itself on a competitive footing. Reshaping it’s technology capability & product offerings ‘from scratch’, it started with incubating a new culture - taking the lessons of industry disruption and re-imaging the role that Technology, and a dynamic team culture plays in getting the right stuff done, quickly.

What does it take to initiate a ‘180’ large scale culture change? What happens when you are considered ‘legacy’ and do disrupt yourself? Can a large business move swiftly, on startup timescales? Where are the traps? What is the collateral damage along the way? What mistakes were made and lessons learnt? Seeking a radical transformation in capability, Fairfax focused on getting its culture right - not just its technology. Discover the steps taken, and how we build up symbols, identity and purpose in a way that serves organisational goals and also just happens to be, by the way, be a great place to work.

Like most of you, I've been a student and practitioner of improving the velocity of product / service teams for my 20 years in the industry. We'd all agree velocity is important, but there are many ways to define and improve it. Is it story points? Is it successful feedback or metrics? Is it the popular developer vote? How does it scale to a cross functional team and a growing organisation?

This session will be practical. I'll share anecdotes, principles and practices on team velocity that I've picked up over years of hard lessons and different contexts. We will look at velocity from the angles of technology, process and culture. We will consider how velocity changes in environments of significant architectural change, organisational change and team growth. Ultimately we'll define a balanced view of velocity as it relates to customer value and summarise principles for effective and sustainable improvement.

We engineer our systems to be reliable. The profession has maintained a keen focus on approaches to testing to best ensure that everything goes right. We expect our people to think through potential failures and architect them to be resilient regardless. But despite our best efforts, unexpected failures will always occur.

This talk discusses ‘safety engineering’ – the design of IT control systems for when unforeseen circumstances arise. Drawing on the experience of implementing a safety program within a HFT company the talk will cover where safety systems sit in the overall architecture, what they do, and when to invest in them. Finally, the talk will cover the practical aspects of implementing a safety regime within a company.