We’ll cover the basics: how do you know when you genuinely need an Ops team, and when you just need your developers to step up and do a better job? Operations engineering at scale is a specialized skill-set, not “software engineering lite,” and you don’t need an Ops team until you have hard operational problems.

We’ll also talk about how to interview and hire strong Ops candidates, whether you personally know much about Ops or not. We’ll examine some good interview questions and bad interview questions, dig into strengths-based hiring, and give special attention to what qualities you particularly need in your founding hire for any new team.

Finally, we’ll talk about what comes next. How do you keep your shiny new operations engineering team happy and challenged? How do you create a healthy, mutually-thriving DevOps culture? Whether you’re a startup founder or a manager or an early stage employee, there is nothing more powerful than having a valley full of ex-coworkers who want to work with you again, and culture is key.

100% uptime is impossible. Modern architectures are designed around failure but what does that mean for the human aspect of incident management? This talk considers how to prepare for outages, how to structure the response, and how those experiences and techniques differ for small and large companies.

Usually when we say the word "empathy" there's an underlying "woo-woo let's talk feelings" undertone. Perhaps you think empathy is a waste of time; or maybe you think it's important, but you don't really understand how to apply the technique professionally.

Empathy is a tool you can use to understand what motivates your team; to spot blockers before they become a problem; and to get a "health check" on the projects you oversee. Sounds useful when you read it from that definition, doesn't it.

This session will be broken into three parts:

Level 1: "Caring just enough." The basic human skills you know about, and use, outside of work. This section is most relevant to team members who want to promote a healthy workplace culture.
Level 2: "Thinking strategies." Using your team’s motivators to help them succeed. This section will be most useful to those who manage people and team leads.
Level 3: "Imagination." Learning to complain from the other person’s perspective. This section will be most useful to those who manage people and team leads.Even if you still aren't comfortable with the "e" word by the end of this talk, you will have a better grasp on how to apply work-place appropriate, tangible techniques to produce higher functioning, happier teams.

How to keep your passengers calm when the wings falls off the plane Part of doing our jobs well as DevOps folk is staying calm and collected when the servers are misbehaving. Sometimes it’s our fault, and sometimes it’s not, but the process is the same regardless. As pilots know all too well when things aren’t operating properly: aviate, navigate, communicate.​Order matters here, but we’re going to talk about the still­important third item. How do you keep your passengers calm with the wings fall off the plane?

Our dear sponsors will have a few minutes each to tell us more about them and why they are at OperabilityIO

Having a small set of authentic, opinionated, collaboratively formed core values can be the magic ingredient to building a high performing, happy team. In this talk you'll hear the story of how, in the space of a few short months, the Intercom Ops team went from doing OK to AWESOME. We'll tell you about our core values, our values for creating values, our happiness metrics and finally, about how this approach can be applied to other teams.

The way in which many (most?) software teams use logging needs a re-think as we move into a world of microservices and remote sensors. Instead of using logging merely to dump out stack traces, our logs become a continuous trace of application state, with unique-enough identifiers for every interesting point of execution. We also use transaction identifiers to trace calls across components, services, and queues, so that we can reconstruct distributed calls after the fact. Logging becomes a rich source of insight for developers and operations people alike, as we 'listen to the logs' and tighten feedback cycles to improve our software systems.

How much time do you spend managing the operating system that's running your application? How much of the software you're running is part of your operating system rather than your application? The last year or so has seen a number of projects look at what the future might hold for the operating system, from Project Atomic and CoreOS to VMware Bonneville and the Unikernel movement.

This talk will:

* Introduce some of the new breed of operating systems; in particular looking at shared characteristics and ermeging patterns
* Discuss Unikernels and what happens when your application and the kernel are the same thing
* Ponder what this means for operations in the future; what changes and what stays the same for people managing these systems

Expect introductions to a number of new operating system projects along with speculation about the impact of cutting edge technology on the role of operations.

Security is becoming quite the thing now days, everyone wants to have one of them. The mantra that things should be built with security in mind and can't be plastered on later is a very important one, if you're based in Silicon Valley and are about to write "teh new hotness", but what happens if your company is older than say, 6 months. You already have some legacy systems and code. I'll be talking about how it's possible to unearth some of these things. What happens when you do uncover these things. How to stop them happening. And coping strategies for dealing with them.