In this episode, we cover:

00:00:00 - Introduction
00:02:45 - Adopting the Cloud
00:08:15 - POC Process
00:12:40 - Infrastructure Team Building
00:17:45 - “Disaster Roleplay”/Communicating to the Non-Technical Side
00:20:20 - Leadership
00:22:45 - Tomas’ Horror Story/Dashboard Organziation
00:29:20 - Outro

Links:

Productboard: https://www.productboard.com
Scaling Teams: https://www.amazon.com/Scaling-Teams-Strategies-Successful-Organizations/dp/149195227X
Seeking SRE: https://www.amazon.com/Seeking-SRE-Conversations-Running-Production/dp/1491978864/

Transcript

Jason: Welcome to Break Things on Purpose, a podcast about failure and reliability. In this episode, we chat with Tomas Fedor, Head of Infrastructure at Productboard. He shares his approach to testing and implementing new technologies, and his experiences in leading and growing technical teams.

Today, we’ve got with us Tomas Fedor, who’s joining us all the way from the Czech Republic. Tomas, why don’t you say hello and introduce yourself?

Tomas: Hello, everyone. Nice to meet you all, and my name is Tomas, or call me Tom. And I’ve been working for a Productboard for past two-and-a-half year as infrastructure leader. And all the time, my experience was in the areas of DevOps, and recently, three and four years is about management within infrastructure teams. What I’m passionate about, my main technologies-wise in cloud, mostly Amazon Web Services, Kubernetes, Infrastructure as Code such as Terraform, and recently, I also jumped towards security compliances, such as SOC 2 Type 2.

Jason: Interesting. So, a lot of passions there, things that we actually love chatting about on the podcast. We’ve had other guests from HashiCorp, so we’ve talked plenty about Terraform. And we’ve talked about Kubernetes with some folks who are involved with the CNCF. I’m curious, with your experience, how did you first dive into these cloud-native technologies and adopting the cloud? Is that something you went straight for, or is that something you transitioned into?

Tomas: I actually slow transition to cloud technologies because my first career started at university when I was like, say, half developer and half Unix administrator. And I had experience with building very small data center. So, those times were amazing to understand all the hardware aspects of how it’s going to be built. And then later on, I got opportunity to join a very famous startup at Czech Republic [unintelligible 00:02:34] called Kiwi.com [unintelligible 00:02:35]. And that time, I first experienced cloud technologies such as Amazon Web Services.

Jason: So, as you adopted Amazon, coming from that background of a university and having physical servers that you had to deal with, what was your biggest surprise in adopting the cloud? Maybe something that you didn’t expect?

Tomas: So, that’s great question, and what comes to my mind first, is switching to completely different [unintelligible 00:03:05] because during my university studies and career there, I mostly focused on networking [unintelligible 00:03:13], but later on, you start actually thinking about not how to build a service, but what service you need to use for your use case. And you don’t have, like, one service or one use case, but you have plenty of services that can suit your needs and you need to choose wisely. So, that was very interesting, and it needed—and it take me some time to actually adopt towards new thinking, new mindset, et cetera.

Jason: That’s an excellent point. And I feel like it’s only gotten worse with the, “How do you choose?” If I were to ask you to set up a web service and it needs some sort of data store, at this point you’ve got, what, a half dozen or more options on Amazon? [laugh].

Tomas: Exactly.

Jason: So, with so many services on providers like Amazon, how do you go about choosing?

Tomas: After a while, we came up with a thing like RFCs. That’s like ‘Request For Comments,’ where we tried to sum up all the goals, and all the principles, and all the problems and challenges we try to tackle. And with that, we also tried to validate all the alternatives. And once you went through all these information, you tried to sum up all the possible solutions. You typically had either one or two options, and those options were validated with all your team members or the whole engineering organization, and you made the decision then you try to run POC, and you either are confirmed, yeah this is the technology, or this is service you need and we are going to implement it, or you revised your proposal.

Jason: I really like that process of starting with the RFC and defining your requirements and really getting those set so that as you’re evaluating, you have these really stable ideas of what you need and so you don’t get swayed by all of the hype around a certain technology. I’m curious, who is usually involved in the RFC process? Is it a select group in the engineering org? Is it broader? How do you get the perspectives that you need?

Tomas: I feel we have very great established process at Productboard about RFCs. It’s transparent to the whole organization, that’s what I love the most. The first week, there is one or two reporters that are mainly focused on writing and summing up the whole proposal to write down goals, and also non-goals because that is going to define your focus and also define focus of reader. And then you’re going just to describe alternatives, possible options, or maybe to sum up, “Hey, okay, I’m still unsure about this specific decision, but I feel this is the right direction.” Maybe I have someone else in the organization who is already familiar with the technology or with my use case, and that person can help me.

So, once—or we call it a draft state, and once you feel confident, you are going to change the status of RFC to open. The time is open to feedback to everyone, and they typically geared, like, two weeks or three weeks, so everyone can give a feedback. And you have also option to present it on engineering all-hands. So, many engineers, or everyone else joining the engineering all-hands is aware of this RFC so you can receive a lot of feedback. What else is important to mention there that you can iterate over RFCs.

So, you mark it as resolved after through two or three weeks, but then you come up with a new proposal, or you would like to update it slightly with important change. So, you can reopen it and update version there. So, that also gives you a space to update your RFC, improve the proposal, or completely to change the context so it’s still up-to-date with what you want to resolve.

Jason: I like that idea of presenting at engineering all-hands because, at least in my experience, being at a startup, you’re often super busy so you may know that the RFC is available, but you may not have time to actually read through it, spend the time to comment, so having that presentation where it’s nicely summarized for you is always nice. Moving from that to the POC, when you’ve selected a few and you want to try them out, tell me m...

DevOps With Better Marketing With Pete Cheslock