Want to up-level your reliability program? Let's start by identifying your opportunities for growth.
How much time are engineering teams spending on incidents?
Are you trying to set your engineering team free to do their best work? Read our new case study to learn how Blameless can help you do that.

Why I Joined with Chris Hendrix, Engineering

|
11.3.2020

It’s only in looking back at life that you can draw a throughline; it’s only hindsight that lets you see the hidden patterns that have guided your journey. Joining Blameless has provided me an opportunity to again look backwards in search of a semblance of order. What I’ve found is that I’m driven by teaching emerging best practices: like a surfer chasing the biggest swells I’m drawn to the waves of new paradigms that have the capacity to transform the way the world works. That is why I’m so excited to join Blameless as a Staff Software Engineer. With its authority and advocacy of Site Reliability Engineering (SRE), and its productionalization of emergent best practices in DevOps, Blameless is the vanguard for the next revolution in the software development lifecycle.

What Brings Me To Blameless

I grew up in Miami, Florida, in a family that had immigrated from Cuba in the mid-20th century. We came to the United States looking for a better life, and education was our family’s trade: my great-grandfather was a teacher, my sister is a teacher, my brother was a tutor, and my biggest role model–my mother–was a college professor and administrator. I was a bookish child and I took to the computer quickly; my love of puzzle games segued into teaching myself the puzzle-solving of computer programming. I strayed away from computer science in college to pursue a degree in Materials Science and Engineering, but returned to programming for my first job, where I programmed in Ruby on Rails and managed a group of interns who were hungry to learn how software development happens in the industry, away from algorithms on whiteboards. I was to be their new teacher, even as I was learning myself!

Falling into this role of teacher-as-student led me to the first big paradigm shift in my career. To give the interns the best possible learning opportunity we started a book club together, reading classics like Practical Object Oriented Design in Ruby by Sandi Metz, Refactoring by Martin Fowler, and Agile Retrospectives by Derby, Larsen, and Schwaber. We also turned those learnings into action, experimenting with new practices like pair programming, Agile, and test-driven development. These blew my mind. When I compared the new ways we were working to the rest of our company, we were faster, more focused, delivered software with higher guarantees of quality, and had more fun doing it.

I was so enamored with these new best practices that I joined the industry-leading Pivotal Labs. There I began consulting, teaching other software developers about Pivotal’s unique approaches to balanced team delivery which blended and iterated upon Agile, Scrum, and Extreme Programming. It was my job to go beyond preaching internally about the benefits of pair programming and strong facilitation. Now it was my career to guide other organizations through the murky anxiety of their own digital transformations.

My second paradigm shift occurred when the Google SRE book was released. Reading it caused a familiar hair-raising feeling; at the end of a chapter my mind was filled with possibilities. Reinvigorated, I was excited to implement its principles and practices into our processes. Now that I’m at Blameless, life repeats itself. It’s once again my career to guide other organizations through the murky anxiety of their transformations, this time implementing the principles and practices of Reliability Engineering.

It’s once again my career to guide other organizations through the murky anxiety of their transformations, this time implementing the principles and practices of Reliability Engineering.

SRE is All Natural

One of the major trends in software engineering is to center the user and their experience. Before, software teams were parts of an IT organization—separate from the business—and many many layers removed from interacting with a company’s customers. Nowadays, cross-functional software delivery teams regularly interact with customers to learn about their problems by observation and to get solutions into their hands for quick feedback. This user-centeredness in product development is expanded by SRE thinking into the realm of service reliability. Perhaps most visibility, operations teams are being plucked from IT departments and embedded in balanced software delivery teams. We’re slowly replacing continuously monitoring pages and pages of disconnected, unary metrics with targeted, customer-centric alerting. We have a quantified understanding of key user journeys (codified as Service Level Indicators), and we have a quantified understanding of our customer’s expectations for reliability (codified as Service Level Objectives). These are natural extensions of the principle of user-centeredness.

Another major trend in software engineering is iterating to enable continuous improvement. Lean and industrial engineering initially brought continuous improvement to the world of manufacturing, and it has been heartily embraced by the software industry, boosted by how relatively quick and cheap it is to change software. Sprint retrospectives often ask folks to look at a slice of time, reflecting on improvements to team processes and technologies. SRE extends that once again to the incident retrospective. In the world of the future–where failure is not only expected but celebrated–targeted retrospectives bring all the right people together to see the system of failures that caused a customer impacting incident.

SRE extends that once again to the incident retrospective. In the world of the future–where failure is not only expected but celebrated–targeted retrospectives bring all the right people together to see the system of failures that caused a customer impacting incident.

Why Blameless

When I got an email from a recruiter for Blameless, I was impressed by everything I saw. Blameless is squarely situated in an important and growing market. It is an SRE product from the ground-up, integrating workflows that span the journey from reliability alerting to incident management to incident retrospectives. It’s not just an SRE bolt-on to a company’s other monitoring applications or on-call support software. It’s got an amazing set of investors. And most importantly, it has really great people.

I was drawn to Blameless by its people and their culture of warmth, openness, transparency, and improvement. My very first day, I attended a company All-Hands meeting where the CEO walked through the responses & action plans derived from the most recent company-wide listening tour. Our values are demonstrated by our actions more than our words, and here was a company that forefronted talking about its imperfections and challenges to the new guy. And more than talking, leadership held themselves accountable to making concrete changes.

Psychological safety is quickly becoming a buzzword, but research from Amy Edmonson and later by Project Aristotle at Google shows how important it is to organizational effectiveness. In my years of teaching about psychological safety, its definition is often misunderstood. Psychological safety is not that nothing bad happens and the team is always happy; that is a fundamentally impossible and inhuman expectation. Psychological safety is that people feel safe to discuss challenging subjects, including failures, without fear of retribution or negative repercussions. Psychological safety is demonstrated, practiced, and strengthened by doing just that: discussing challenging subjects–including failures–as they happen, without personal blame (i.e. Blameless), without retribution or repercussion.

My experience here, beginning from day one, confirmed to me that Blameless is committed beyond the principle of psychological safety to its practice.

Since then, I’ve seen how every part of the organization is interested in continuous improvement. When I’ve challenged existing tools and processes, I’m met with attentive ears and open hearts. I’m even leading a book club of Shape Up by Basecamp to bring alternative perspectives on product management and software development practices to our quickly growing company.

I was nervous to change jobs as a Staff Software Engineer; it’s unnerving to move away from a company where you’ve built up expertise in search of new opportunities. I’m so glad I did, and that I’ve landed here at Blameless. If you’re also interested in a change, check out our available careers.

Psychological safety is not that nothing bad happens and the team is always happy; that is a fundamentally impossible and inhuman expectation. Psychological safety is that people feel safe to discuss challenging subjects, including failures, without fear of retribution or negative repercussions.
Resources
Book a blameless demo
To view the calendar in full page view, click here.