Tom McLaughlin
Last week, I headed down from Boston for DevOpsDays NYC at the Microsoft Technology Center. It was a chance to learn new things and see old friends. It was also my first time doing field work for my own company.
The Ride to NYC and Getting Excited
The ride down from Boston to Penn Station via Amtrak (They also leapfrogged into serverless!) was a good choice — it’s more comfortable than planes, there’s always a beautiful view from a window seat, and it puts me right in the middle of the city. I normally drive down to the city (I have family in the area), but opted for the train this time since it allowed me to do some additional prep work ahead of the conference. I’m focusing on making the most of my time i when possible since there’s so much work to do for ServerlessOps. After this recent trip, I would definitely think about the train again for future travels.
After a good night sleep, I woke up, grabbed a bagel for the commute in via the LIRR, and got excited for the days ahead at DevOpsDays NYC. While sitting through the 2-day conference, I definitely saw an overarching theme.
The User is Part of Your System
There’s a topic in our community that I don’t think gets enough attention: our users and how they fit into the systems we build. We like to ask, “Is DevOps about the tools or about the culture?” When you step back from that debate, you realize that DevOps is about creating highly functional teams. And the reason those teams exist is to provide the greatest value to our customers — whether they’re external paying customers or internal stakeholders.
DevOps is about creating highly functional teams.
Superficially we say, “outages are bad for users” or “users don’t like it when the site is slow”. But there’s much more to how our users fit into our system than that simplicity. Unfortunately, I think we’re not doing enough as engineers to incorporate the user into our thinking and approach.
Being Mindful of Your Customer
Photo and art credit: Ashton Rodenhiser
Kishore Jalleda’s talk titled “DevOps Is More About Customer Feedback And Quick Learning Than Culture, Process And Tools”, was the second one of the first day, and it made me revisit this topic again. He asked, “How do we ensure that we’re engineering for our customers?” His answer is to start by being mindful.
Mindfulness. Be present and focus on why something matters and how it fits. #devopsdays pic.twitter.com/wwmZIQZt6i
— Tom McLaughlin (@tmclaughbos) January 18, 2018
Being mindful is asking why something matters and how it fits into the bigger picture. Look at the engineering work right now and ask, does this work really matter? Our customers have a different view of what really matters compared to us. Your customer doesn’t care about your uptime 9s or deploys per day. They care that they have a good experience with your service.
If you’re engineering just for 9s engineering metrics, you’re leaving other stories in the backlog that may have real impact to the customer. You should instead use your error budget and strive to deliver customer value. Don’t become blinded by your engineering metrics; ensure you’re identifying what really matters... the satisfaction of your users.
Your customer doesn’t care about your uptime 9s or deploys per day. They care that they have a good experience with your service.
Start with “What problem am I trying to solve?”
Photo and art credit: Ashton Rodenhiser
Randy Shoup’s talk, “Moving Fast At Scale”, touched on several similar points in his presentation. Clearly stating the problem and explaining how it relates to the business is the start of being mindful. Defining the problem and stating how the solution contributes to the business is necessary to ensure that you’re pursuing the correct solution and not producing wasted work. To start, ask yourself, “What problem am I trying to solve?”
These seven words. Ask them every time you’re thinking about building something. The solution might not be technical. #devopsdays pic.twitter.com/TKeb19MN00
— Tom McLaughlin (@tmclaughbos) January 19, 2018
But how do you know you’re doing the right work? Experimentation is the key to successfully solving problems. Figure out what metrics are important, and A/B test small changes to see the effects. Then keep repeating that process until you’ve solved your initial problem.
Mindfulness in Action
I want to mention this Kaizenops, a sponsor, because they were directly applying the concepts Kishore and Randy talked about. Most conference wrap-ups don’t mention vendors or sponsors except when they screw up. But when a sponsor stands out, they should be celebrated.
Kaizenops had product feature surveys asking what their potential users wanted. This was a company who was listening. They also wanted to ensure to the best of their ability that they would be building a product with value. Kaizenops is being mindful. When they head back to San Francisco, they’re not going to have wasted work that doesn’t have customer impact.
Along this line of thinking, I need to ensure that ServerlessOps keeps customers in focus. Right now, the focus of this company is meeting with people in the community and actually listening. That’s why I came to DevOpsDays NYC. This was my first conference since starting ServerlessOps.
I need to ensure that I’m working on the correct problems by actively engaging with the audience I’m trying to serve so I can say the work I’m doing really matters. The feedback I received about what I’m doing at ServerlessOps has been positive. But even better: it’s also forced me to identify and check certain biases I have. Continuing down this path, we can become a company that really serves its customer. ServerlessOps needs to be a mindful company.
A Few of My Favorite Ignite Talks
Mike Fielder of Parabus explained that AWS tools are great! … But there are gaps. We’re used to this. We know that when AWS releases a new service, it’s never fully formed and it will take time to evolve. Mike’s team uses serverless AWS resources like Lambda to fill some of these gaps. His story demonstrated how this technology is an enabler for us in Ops to accomplish much more.
Heidi Waterhouse from LaunchDarkly had a sly sense of humor. The DevOps world has many terms that we throw around freely, and others nod their head knowingly. Too often, people nod their head without actually knowing the meaning, but they don’t want to admit it. Heidi was happy to help!
Here are a few select definitions that were personal favorites:
- Continuous Integration: The state of never being sure you didn’t just break the build.
- Deployment: (v) When code escapes into public view. (n) The thing that just took down production.
- Mean Time To Recovery: How much a client yells at you while you’re trying to get the system back up.
- Agile: A design perspective centered on moving fast and dodging definitions.
- A/B Testing: A way to show a new bug to only half your customers at a time.
Jay Gordon from MongoDB returned to the user. His ignite focused on being a community builder for MongoDB. Having been a sysadmin for years and feeling burned out, he sought out change. As he thought about what he wanted to do and what he liked doing, Jay realized Developer Relations was the place for him.
He enjoys connecting with people. He enjoys helping people. He enjoys being a part of and building a community. This made DevRel a natural fit for him. Jay could reapply his engineering in a new way and see a user being directly affected.
Conclusion
I really loved this event. It ranks up there with one of my best conference experiences I’ve had. (I’m really, not just saying this. It rivaled last year’s DevOpsDays Austin and ChefConfs.) The people attending were amazing, and I feel lucky to have a chance to connect with old friends while making new friends.