One of the challenges with career development for engineering teams is that many engineers don’t believe career development applies to them. It’s because a lot of them think career development as moving upwards and getting promotions. For many engineers who are passionate about technology and doing hands-on development work, they feel that career development is non-existent for them as they do not wish to become people managers.

In this talk, I will address two key areas for career development for engineering teams; 1) mindset, ie: introducing a new way of thinking where we think of career development as lattice, instead of ladder and 2) mechanics, ie: implementing structures and strategies to achieve career development.

At the end of my talk, engineering leaders will walk away with a new mindset on career development and know-how on implementing career development for their engineering teams.

As is often the case with software development, we try to plan ahead yet we frequently fail. Here at JFrog, when we envisioned Bintray as a high-loaded distribution service, we planned for scale. And yet, when it hit us, we still had to adopt.

In this session you will time travel through two years of agile architecture – we’ll explore and share with you what components we took, what decisions we made, what stayed, what changed, and why. Through our successes, failures, and corrections we can share our lessons learnt to benefit you on current and future endeavors.

Implementing a technical strategy often requires cultural change, which can take time and careful team management. In this talk, Phil will describe technical strategy and change projects in huge enterprise and startup environments, with a focus on communication, measurement and flexibility to successfully implementing change.

Attendees will learning about structuring change, getting people onboard, refining and sharing goals, and how we can miss our them – even when people think we’ve achieved success.

The popularity of bots is taking off and Engineering teams are finding new and interesting ways to use them in our workflows every day. At Domain, what started as simple ChatOps has grown into a plethora of homegrown bots. These have varying degrees of utility from replacing common administrative tasks, to ordering coffee, to automating technical support. We’ve learned a few lessons about scaling bots, bot frameworks, bot hosting and how to get your bot to stick.

For organisations to thrive in an increasingly fast-paced and complex environment, the requirement to have a highly skilled workforce is greater than ever. For many people work is not intrinsically associated with the opportunities for learning, problem solving, independent thinking, collaboration and creativity and this unfortunate reality creates an enormous challenge for companies.

This talk examines the core competencies of the technology generalist and explores some of the approaches that organisations and individuals are taking to exercise growth mindset to continually upgrade their skills.

Many organisations wanting to adopt public cloud have regulatory and compliance requirements they must follow, such as APRA’s prudential standards, the Australian Privacy Principles, and ASD’s cloud computing guidelines. Myths regarding compliance abound, and this talk will examine some of these.

Complex problem require strong teams to address them. But many teams are globally distributed, diverse in their nature, and way harder to manage than individuals. Atlassian is one of those work environments. We wanted to harness the power of these diverse teams, and resist the temptation to add layers of bureaucracy, process, and compliance regimes to make every team member act the same.

We gave birth to the Atlassian Playbook. A set of principles, patterns (our view of healthy teams) and plays (what those teams do to be healthy), that enable us to retain autonomy, provide teams with freedom to operate in their environment, drive continual improvement, eliminate management by committee, and to ultimately provide our teams with the techniques to be efficient AND effective.

This talk will teach you how to utilize the playbook at your company so you can drive efficiency and effectiveness in your organization without adding endless policy, procedures, or mind-numbing politics that slow down your org.

Blockchain is is arguably the most significant technological innovation to emerge in recent years. In this talk I will provide an overview of what blockchain is and why it’s considered game-changing. This will be followed by a run down of the current state of play in the blockchain eco-system, before discussing key considerations for organisations wishing to work with this technology – based on my experience building a platform on top of Ethereum.

Engineering leaders are familiar with working to increase the impact of themselves and their team. But code isn’t the only thing we build. In this talk I’ll revise how engineering leaders approach high-impact technical work, and extend that to the other “stuff” we build: team, culture, products and companies.

You will learn how to make higher leverage decisions. As shepherds of a scarce and valuable resource–high-quality engineering work–we have a responsibility not only to our bosses, but also to our team, communities, and fellow humans, to build stuff that matters.

It’s 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

The role of the CTO is changing and the skills needed to succeed as a CTO are also changing. As technology continues to invade deeper into more and more organizations, technology savvy and expertise become increasingly important in the C-suite. In the past traditional organizations didn’t really have CTOs at the “big table” despite the “C” in their title. This situation is changing. This talk will describe the evolution of the role of the CTO as I have watched it both within my role at ThoughtWorks and with many of our clients.

2015 and 2016 have seen a huge number of high profile breaches in tech product security and reliability. Data loss and reputational damage have occurred, as have actual customer harm and business destruction is a real risk.

I will cover de-risking security and reliability simultaneously, since at the organisation or product management level the approach and implications are very similar (but of course security is the title sure to get more attention

In this talk I will look at why leaders need to be tough on security, and how leaders who believe they are tough on security will find reality across all aspects of their products quite different to what they might think. In this post-censusfail world escaping by pointing the finger at teams or contractors who were saying all the right things is coming to an end.

After creating a reasonable level of fear, including some very brief case studies of major public tech security/reliability failings, I will look at a case study from a recent project where security issues raised in a new unreleased product were taken seriously by the tech leadership, and the implications across as many as five different departments.