Prevent Heroism: How to Work Today to Reduce Work Tomorrow

Production is down, again, and The Lone Engineer worked all day and night to save the business! Overtime so routine that's it's no longer "over", it's "expected". We create these scenarios by supporting strenuous environments and rewarding Save the Day behaviors. So let's discuss how to change that.

Reactive work is a massive time and value sink, but unfortunately existing gaps in team structure and/or metrics don't capture "what's missing". For example, how do you track calls not placed, outages that never occurred? Traditional structures and metrics don't necessarily capture this shift, yet everyone benefits from a better user experience - i.e. the unplaced call or outage. In this talk I'm going to discuss:

- Level set: explain the concept "upstream work", as defined by Dan Heath in his book Upstream
- Explain why this focus is important
- Discuss how teams can start to shift from reactive work to proactive work, i.e. move upstream; including shifting reward structures away from Heroes
- Cover how to use metrics to support this shift in practice

Sensory Friendly Monitoring: Keeping the Noise Down

The ability to monitor infrastructure has been exploding with new tools on the market and new integrations, so the tools can speak to one another, leading to even more tools, and to a hypothetically very loud monitoring environment with various members of the engineering team finding themselves muting channels, individual alerts, or even alert sources so they can focus long enough to complete other tasks. There has to be a better way - a way to configure comprehensive alerts that send out notifications with the appropriate level of urgency to the appropriate persons at the appropriate time. And in fact there is: during this talk I’ll be walking through different alert patterns and discussing: what we need to know, who needs to know it, as well as how soon and how often do they need to know.

Spearited Guidance: Learning About DevSecOps

DevSecOps is how you apply DevOps principles to security. That is to say, if your org has implemented DevSecOps then security should be "de-silo'ed" from the end of the software development lifecycle. But what does it mean to implement DevSecOps, and what do you need to do to support it? After listening to this talk, participants will:

* Understand what DevSecOps is
* Learn about how Dev, Ops, and Security teams can develop practical empathy for one another
* Learn what it looks like to shift security left in their organization

The Silo of Security - it is what we make it . When we design and write code only to vault it over to security at the end of the chain, we set ourselves up for redundancy and added labor. When I was researching this I learned about how we implement DevSecOps - considering security at every stage of the software development lifecycle.

Unquantified Serendipity: Diversity in Development

Learning how to write software, architect infrastructure, and automate deployments is cognitively taxing. So much so, we probably spend a great deal of energy learning how to learn, learning how to retain, learning how to apply, learning how to be efficient, that learning how to be with each other gets lost in the mess.

Straight to the point: Computer programmer. Software developer. Production Engineer. When you read these terms, a picture probably starts to form in your mind’s eye - a sort of default for what a person behind these titles looks like. Maybe also how they sound - what language do you expect them to speak? How do they speak it?

Most likely, when you read those titles, you visualize a white male. He speaks English fluently with a local accent. If you pull up the photo behind an anonymized résumé, you might be surprised to find a Muslim woman wearing a hijab. Or perhaps you see someone who doesn’t speak fluent English, speaking instead with their native Mexican accent.

A lot of the imagery that’s been produced for software developers intentionally or inadvertently reinforces this vibe - the notion that the default developer is a white male, even when history and globalization show that that’s probably not the case. Yet because this is the view when women and other minorities join our ranks, they are given advice that encourages them to behave socially and linguistically like white men.

In this talk, I’ll explore how we can solve problems together as a diverse group, quite literally just by sharing space. I’ll discuss ways that we can be better allies to each other by fostering understanding, and highlight the positive impact of normalizing the appearance of minorities in the field.

How to Advocate to Not You - Non-Technical Considerations for our Technical Tools

One of the things I struggled with as an SRE was being able really grok what non-engineers/non-devs like my manager, whomever they reported to, and various chains in my employer’s business, cared most about when it came time to tool selections. A specific example that I will anonymize and discuss is when a past job of mine decided to migrate from Tool A to B - the decision wasn’t based on B necessarily being a superior tool for our specific technical needs, it was mostly based on other management criteria like license consolidation. Depending on the size of the employer, startup to enterprise, there are increasing numbers of non-engineering folks who have decision making power over the team’s tools. Thus, as devs, ops, etc. we cannot keep our focus on just the technical aspects of different tools and frameworks or we’ll miss the opportunity to appropriately make our case to these other stakeholders. In this talk, I’ll be discussing what these other groups need to know to help them make a decision in your best interest.

Pitch: Whether it be via merger or internal need, at some point we need to advocate for the tools we need to stakeholders who are not necessarily affiliated with engineering. In order to help with this, I'll be walking through the decision tree of how management determines "should I pay for this tool".