LogDNA is now Mezmo but the DevOps State of Mind podcast you know and love is here to stay.

‍Liesse Jones: Sean Tierney is the DevOps lead at Athos, a company that's building better athletes through smart clothing and AI.

Sean reinforces a DevOps state of mind across the organization by building empathy between hardware and software teams and putting the systems in place to allow them to move faster as a single unit. 

Welcome to DevOps State of Mind, a podcast where we dive deep into the DevOps culture and chat with friends from small startups and large enterprises about what DevOps looks like in their organizations.

I'm Liesse from LogDNA. Join us as we get into a DevOps state of mind. 

‍Liesse Jones: All right. Welcome to the podcast, Sean. So excited to have you! 

Sean Tierney: Thank you so much, it’s good to be here.

Liesse Jones: So, if you could start just by telling us a little bit about yourself and what you've been up to in your career and kind of what led you to your current role at Athos?

Sean Tierney: Cool. Excellent. So I guess career-wise how I kinda ended up in DevOps would be, it kind of started as an interest in infrastructure programming. I had been doing your traditional web development for forever, it seems—and it just wasn't—I had the idea of being able to scale something, you know, seemingly infinitely.

It was just really exciting, kind of drew me in and being able to do these things—you know, program against systems that we didn't use to be able to program against—was really, really fun. And as I got into it, I kind of discovered that a major part of the role is driving organizational change. So there's this enormous leadership/management element to what the DevOps culture kind of is. And that really fascinated me. Frankly, it surprised me that the need was so great. But it was. And so, I have been doing full-time DevOps work for, I guess, since about 2018. So a couple of years under the belt now. It's been maybe one of the coolest adventures I think. For me, it's been really, really fun. 

So, I ended up talking to a recruiter [which] was actually how I got connected with Athos.  And for the first time in years we had an opportunity to mix your digital effort and your programming effort. You know, bring it back to the real world with the garment and the human data and all of this. So it seemed like a very kind of cool thing to do. So, I guess I'm just kind of here now, you know. So it's been really exciting. That was only—I don't know—maybe five or six months ago. But it's been—I dunno, every day is the best day of my life, Liesse. I think we can say that. 

Liesse Jones: Love it. 

Sean Tierney: Yeah. 

Liesse Jones: I also love what you said about this being an adventure. That's such a cool way to think about DevOps in general, because it's something that's always changing and growing and you're iterating on whatever you were working on the day before. And it looks different everywhere. Right?

Sean Tierney: Every organization. It's like how every marriage is different, right? There's always this human—very specific— human context that exists inside of an organization. So, maybe everybody uses the same tool, but I guarantee you that the code is not the same. 

Exactly how we do things is not the same. And then on top of that, we're never going to do the same thing twice. So we're constantly iterating and improving our ability to deliver to production. 

Liesse Jones: Absolutely. I love that. Okay, you said a little bit and I can kind of gave a teaser in the intro, but can you just tell us what Athos is, the problems that you guys are trying to solve and, for the listeners who don't know, what the actual company does.

Sean Tierney: Okay. We are leaders in a couple of really fascinating areas. We have the ability to capture human data—human electrical data—from which we can derive meaning. And we have beautiful garments that are really comfortable considering what they do. And the hardware inside the garments is also—I call it Apple-esque—I'm a huge fan of the design of the hardware. It's pretty cool. So from all of that—all the garment, all the hardware, we get this data and we can use that data to help you better understand what's happening in the body—like orthopedically. Specifically how the muscles are operating, how the muscles are operating in relation to other muscles, how the heart rate's doing.

And we have a whole data science team that can take this raw signal data and really generate some fascinating measurements out of it. And when we bring that to the sports scientists they can take that data and they can derive even more meaning from it. So one of our very good sweet spots is the ability to take a human over time and determine whether or not that human is setting him or herself up for injury. If you have one side of the body that’s working harder than the other, or one side of the body is not working very well at all—we have these muscle imbalances that our sports scientists understand the history behind these [things]—like the mechanics—and they can say, “you're on the path for an injury here.” And that really matters to a lot of organizations, to a lot of athletes. And there's really nothing like it. So, we help people get better and to stay healthier. Which, as someone who's growing older and feeling the effects of time, resonates quite well with me.

Liesse Jones: Yeah, absolutely. We will be sure to put a link in the show notes so that everybody can get a visual for what the product looks like. But, just to go a little bit deeper on what you said, it's basically leggings and compression shirts that you can wear. They have a super sleek hardware component—like you were mentioning—that you just kind of click into the apparel and then you just wear them while you're training.

So for example, I've worn the leggings before. And doing a squat or a deadlift it'll show you what muscles are working. If your hamstrings are working more than your glutes, you know that you probably need to do some supplemental work to adjust to make sure that the right part of your body is firing as it should be. 

Sean Tierney: Like, I bet your back hurts. My back does hurt. 

Liesse Jones: Weird how you can tell that just by me wearing a pair of leggings and doing a squat. 

Sean Tierney: The garment hits our phone app. The phone app is really, really neat. It's got like a live view of the electrical activity coming out of your body, kind of like this radiating sort of aesthetic to it. And as you increase the effort in a muscle group, it radiates brighter red. It's really neat if you’re into this kind of thing. It's pretty cool.

Liesse Jones: It's super cool. And then, I think the part that's really interesting talking to you about DevOps and cross-team collaboration, which we're going to get to a little bit later on, is that you get to see it from the hardware perspective and the software perspective. I don't know about a lot of our listeners, but for me at LogDNA, we are a software company. “Doing DevOps”—I'm doing air quotes for those of you who are just listening—it looks a little bit different when you're just talking to different software teams across the application life cycle then it might look if you're talking to both software and hardware teams. So I think you have a really interesting perspective on that.

Sean Tierney: It hits all of it. Doesn't it?

Liesse Jones: Yeah. 

Sean Tierney: The whole gambit. 

Liesse Jones: Definitely. And, as we get into talking about DevOps, it's interesting because it's such a broad term that encompasses a lot of different things. And I think of those different components as kind of levers and certain ones are more important depending on the problem that you're working on, or the team that you're working on. So I would love to just understand from your perspective, what does DevOps mean to you? 

Sean Tierney: Oof. 

Liesse Jones: It's a big one.

Sean Tierney: How much time you got? Yeah. All right. I think we are called upon to be the ultimate organizational stem cells. We may not know what we're doing, but we know that we need to solve a problem and we end up being the ones who are unblocking by solving the problem.

So going back to the hardware, right? I might not have come up in the hardware space (I certainly did not come up in the hardware space), but if hardware has a problem that is preventing them from delivering value, we're here to solve it. And I think a lot of us are drawn to this professional track because of that. It's not really made me a superhero, but man, if someone's having a day where they're completely blocked by something and you can come in and fix it, then you feel good about that, right? You get your people back to being productive.

Liesse Jones: You can call yourself a superhero. It's fine with me. I'll endorse you on LinkedIn if you'd like. 

Sean Tierney: Yeah, I will take that. 

Liesse Jones: Yeah. Awesome. So for you, it's helping facilitate things across teams to make sure that they can get where they're trying to go. Kind of removing roadblocks and making those connections. Is that right?

Sean Tierney: Yeah. And kind of to your lever point, we're all in the organization trying to solve the same problem. On the engineering side, you know, you've historically had maybe an Ops team who's responsible for operating an application and then you have the software team [or] the development team who's responsible for writing the code. And those two separate tracks would kind of dictate the lens through which you see the world. So, on the developer side, the developer will say, “I have this problem, I will use my code to solve this problem.” On the Ops side, generally you would have someone who says, “I have this problem, I will use my human effort to solve this problem.” So I click the button, I'll remove the logs, I'll undertake these manual steps to solve the problem. At the end of the day, both teams are responsible for, and interested in, maintaining production stability. So again, we're solving that same problem, but the worldview that we operate from would be governed a little bit by whether we're operations or whether we're development.

And then you take DevOps, and now we kind of recognize that there are two worldviews. We can use whatever worldview the situation calls for, so that is kind of neat. It can be a lot to switch that way. And of course we always want to be able to automate everything and have everything be completely good to go, but that just doesn't always work. Right? Operations teams existed for a reason. So, we can kind of push and pull on the levers, use a combination of our human skills and our development skills to help unblock the organization. 

Liesse Jones: Yeah, absolutely. I love that. Talking about skills and processes and automation. What do you think have been some of the most impactful tools or processes that you've implemented at Athos that support this kind of DevOps style of work?

Sean Tierney: So, I'm in a leadership role. It's been five or six months. So, so far my efforts in unblocking individuals have been probably the most impactful. You come in day one, you don't know anything about the software necessarily. So you think it's unlikely that you're going to step in and all of a sudden have this impact on 10 years of collective human effort. You're just one human, you know. What they want is not going to be that crazy. So, being able to identify teammates who may be blocking themselves or teammates who may need more help or just anything to help the social aspects. I think that that sort of stuff you can come in and pick up pretty quick.

So, making sure the conversations are happening that need to happen, introducing people if they haven't met. You're dealing with sometimes social circumstances that really—while they may not seem like a lot—have an unbelievable impact on how quickly an organization can operate.

That's been super fascinating for me to learn that you may have people who just block like crazy without even knowing it. And I'm a hundred percent guilty of it. I've done things like that. You know, you give vague answers or you might deflect something that you should definitely give an answer to. And you can see the people who have been around the block long enough to know like action items, go list them off before you hang up off this call. When is this going to be done? You know, “soon” might not be good enough. So, just being able to dial in those things and helping shore up the communication has been probably my biggest contribution. 

Liesse Jones:  Yup, that makes sense, communication is a super important part of the equation. Are there specific tools that you lean on to facilitate DevOps at Athos?

Sean Tierney: Well, that's a good question. I will preface it by saying the fewer pieces of context a human has to assemble in order to get where he or she is going, the better. So if we could have one tool that we use to communicate change and to manage change in the organization, let's try and get there. I've been in places where it takes six and seven different systems, different user interfaces, to kind of get where you're going.

So the one place that I would seek to go is to use your source control management system, your GitLabs or GitHubs, which are hosted Git systems in essence, and have all your change move through the social constructs introduced by Git. You have the notion of a PR or a merge request. And that is essentially my petition for change. I want something to happen and I care enough, not just to complain, but to put forth the effort to create the change and essentially petition the court for approval as to whether or not this change comes in. We have one system, we have a way of talking about the change. And if we could get everybody to adopt the Git flow and essence, I think that we would be much more efficient in terms of managing change. 

We're constantly and passionately searching out sources of events, things that we can tie into, right? “If this, then that,” when something happens we want to be able to change the world, you know? And so, get your source management events. And when you have these systems—GitLab, GitHub, there's a handful of other ones out there—they kind of give you even more. It's not just code, but also issues and all sorts of different data constructs that we can use to discuss the change. And then when we do operate on these objects, we can produce events that will allow your DevOps team to change the world. And then also you can actually transfer the—it's like a unit of state, a unit of history. I can ship this repository to you. You can go forward and backward in time from a relative place. So, it's the ability to record history. And if you need to go back and analyze it, you can. And so that's why I would say that the one tool for us as an organization that we can really use and really sink our teeth into, if we could all get around Git, business can come in and use Git, then I think that would be the one tool that we could all use. And I think we'd be really effective at it. 

Liesse Jones: That's amazing. And just to kind of parrot it back to you—having a single source of truth for people to reference, understand, take action on, and kind of see the full picture or have context for what's going on.

Sean Tierney: Yeah. And to participate in a democratic fashion. You can drive discussion there. And then, ultimately, when the community decides, you take action and you can trigger a change to any of your systems. 

Liesse Jones: Awesome. Thank you for sharing that. I can imagine joining a new company during COVID is super impactful as well. Like,  most of the company was working in the office prior to COVID and then everyone was forced to go remote overnight. What impact do you think that has on creating a culture of collaboration and the tools that you have to lean on more heavily, like GitHub and Zoom and Slack to just get those conversations going.

Sean Tierney: Yeah, that's really interesting. And along with that, how do you regulate how much energy you're putting into things? For me personally, it's much more difficult to read the room, energy-wise, because I'm not there. I can't feel it, you know, I'm just looking at the screen.

But with regard to being remote, I almost have a visceral reaction about thinking about taking two hours out of my productive day to sit in a freaking car and traffic. 

Liesse Jones: That’s fair. 

Sean Tierney: I mean, you gotta get ready to go. You gotta go. You don't know how long it's going to take you to get there. And we're constantly being asked to schedule and be on time with things, we're constantly asked to estimate. And now I have these variables for what? I'm going to take this literal computer that I'm working on right here, put it in a backpack, drive it to another location, open it up and do the same thing? I don't know. There is a lot to be said about that small group that gets together and hacking in the garage. I believe that that is good, but I don't— two hours a day per person. And those are some of your best hours probably. 

Liesse Jones: Yeah, I guess it depends on who you're talking to. The early morning ones, those are probably my best hours, but for some others you're right, it might be those ones at the end of the day that they would've spent commuting home. Totally fair.

Sean Tierney: I think it's draining and maybe it's like the individual trying to regulate him or herself ‘cause it's like fake, you know? We don't get the actual energy coming in. We can't pull energy from our teammates. Someone walks into the room and they're firing on all cylinders, you kind of get the goosebumps and you're like, “all right, let's go!” 

Liesse Jones: Yeah.

Sean Tierney: You have the ability to bring energy into the room and pump people up. I don't know that we get that. I think maybe it might be a little bit of a different delivery or we have to go and make a real conscious effort. And I do this. I try to put as much energy and physicality into my interactions with my teammates as I can. Because, I don't really know what they've been doing. Right?

So at work, I see Charlie's sitting down the hall, he looks a little mopey, so maybe he could use a “hi, how you doing?” But we don't really get that extra context [now] it's a very regulated sort of controlled environment through which I get to see you. So being able to regulate the energy and injecting energy into your teammates to help get them going. I think that that's changed. But it's so important. Happy people do better work. I'm a firm believer of that. 

Liesse Jones: Yeah, I agree. So knowing that cross-team collaboration is so important, and what you just said about identifying blockers, even human blockers, and giving them the tools to unblock, how do you go about doing that? How do you even identify the blockers in the first place?

Does somebody need to talk to you and say, “Hey Sean, I'm trying to get this thing done, but  Joe is being a real pain in the ass and I just can't get what I need from him.” What does that look like for you?

Sean Tierney: That's those are the easy ones, you know— 

Liesse Jones: Somebody knows it and can call it out. 

Sean Tierney: Let's go find it and let's make sure it doesn't block you anymore. That's the easy one. The harder one is when you get, “how are you?” “I'm okay.” Or, “do you have everything you need?” “Yes.” You know, like it's the self blocking. Maybe I don't want to put up my hand and say, “I need additional help” or whatever it is. Those are the ones that are hard to see. And you can't get them right away, generally. You need to see the pattern and this is where different personality types come into play in your ability to be an effective communicator. You absolutely have to try to meet them where they are. Different people communicate in different ways and that's what makes us so special. You do have some people who are, I dunno, thinner skinned you could say. Like they take a little bit [and feel like] “don't just come at me like a bulldog man, I'm not here for a dog fight.” I might not like confrontation that much, you know? So you tailor your communications to try and meet them where they are and that comes to trust. It takes time to build trust. And so all of these things take time and so you just really have to be diligent about making sure that you're where you need to be to get the day that you need to be in order to start acting on it.

So it takes time to build the trust, to take time, to observe the patterns, and then you just stay on it. And that's why it comes back to kind of the fundamentals of what you do every day and every call is to inject the energy, to get people jazzed up and get them talking too. A lot of the most important things that I've gleaned from my teammates happen when we get to stand up a little bit early and we have time to talk about, you know, whatever—life.

Have these social interactions that help build the bonds of trust that they feel comfortable coming to me and saying, “hey, I need something” or, “hey, I'm blocked,” or whatever.

And they need to feel empowered to do so. I was on a team well prior to Athos where one of our junior developers said, “hey, is it okay if I give feedback?” And I'm like, “yeah, it is, of course it is!”

Liesse Jones: Yeah!

Sean Tierney: Think about the perspective of that individual who doesn't know if he or she has the social permission to participate in the bettering of the software, or the betterment of the team. You got to let people know that they have the power to participate. You know, not everybody knows that coming in. And again, getting older, having been around for a while, it's even more important for those of us who are I don't know what, middle career or something like that. You know, it's not my first year professionally. It is important for us to bring up the next generation as empowered and powerful as we can. 

Liesse Jones: Absolutely. You just said something that I think is so important when thinking about DevOps, especially for some listeners who are early in their journey to adopting DevOps styles of work, which is trust has to be the foundation. And I think it's important for a couple of different reasons that you touched on. One is having that foundation of trust in one-on-one and group conversations to say, “hey, I can raise my hand. I can contribute. I know that I can share ideas and throw things out there that I think will help because we're all working towards the same goal,” which is super, super important. And also trust knowing that if something is going on you can reach out and say, “I need help. I don't even necessarily know what's blocking me, but I'm just doing okay.” Or, “I'm having a hard time accomplishing this thing that I think is really important.” And knowing that they can collaborate with you, with their teammates, with other teams in the organization and just say, “can you help me talk through this, or work through this and see if I’m even looking at the problem in the right way? Or am I so hyper-focused on one area of it that I think is the way to solve it, that I'm actually missing this complete other thing that's a huge part of what's going to make this successful?” And that is important and it's actually so rare to find in companies.

I think Athos—I know quite a few people who work at Athos—I will say that I've observed that it's a really special culture. One great proof point of this is just how long people have been there. Like, there are many teammates who have been there for eight years, which is unheard of in the startup world. But also what you said earlier, like every day is the best day of your life. That's amazing.

Sean Tierney: Yeah, it is. But that's also not an accident, you know? I mean, you kind of got to take some ownership of it and you know, some days you realize that you don't have forever on this planet so you really want to get the most out of it. You know?

Liesse Jones: Yeah. 

Sean Tierney: There's no reason to do it any other way, I think. But  literally, every day is the best day of my life. 

Liesse Jones: I love it. I love it. So having worked in other companies before, where maybe you didn't have the hardware component to the offering, how different do you think it is fostering that collaboration and that problem solving across software and hardware teams together.

Sean Tierney: I think one thing that may affect it [is that] proximity is going to be the linchpin here. So, if hardware has really long cycle times and very infrequent tooling changes, they may not need you that often, frankly. And that means that we might not have as much time to interact.

They might not know exactly what we do, and that presents a problem for us. A latent problem in that they may not know to reach out to us and Athos is not a big company but there might be people on that team who I haven't talked to. That's not their problem, that's my problem. Everybody in the organization needs to know if you have a problem you need to call us, hit us up on Slack and know that you can do that. You don't need to file a JIRA ticket and not say anything to anybody. 

I'm very much a proponent of starting the automation journey with first solidifying the human social interactions that we look to codify and automate. I don't want the first thing that you and I talk about to be something impersonal because we cannot build trust that way. So I think the infrequency with which they need us would probably be the biggest problem for the DevOps team, again, because we just don't work together that often. So they may spin their wheels far more than they need to. 

Liesse Jones: Yeah, that's fair. You just mentioned automation, which I think is an interesting thing to get into. It's a big part of DevOps for most people, but I think automation is kind of a catch 22. Like on one hand, you need to have that foundation to be able to move fast. And on the other hand, it's hard to automate processes when they're constantly evolving and you're constantly trying to change and do better and introduce something new. So, how do you think about balancing that when you are trying to automate processes?

Sean Tierney: That is a really good, good, good, good question. Good topic. And I like to think of automation in the workplace like I like to think of automation in my airplanes. At the end of the day, I still kind of want a pilot up there. Maybe he or she doesn't have to hit all the buttons they used to have to hit, but if something goes wrong he or she better know how to fly that plane. You know? So automation, all this is—I say this as an opinion too, you don't have to agree with it—but every automation should begin it’s life as a well-documented manual step. If it’s important enough for us to do again, and again and again. Okay, then it is important enough for us to automate. You’ve got to have a well-defined problem and you have to have somebody knowledgeable enough to grab the steering wheel if there's a problem. So, starting from a perspective of manually operating a system and generating very good documentation from that manual effort, now we can start to automate. And what this does is it's actually critically important to the operations of an organization. It gives us a good dataset from which we are training both bots and humans. That is fundamentally important in terms of efficiency. You may have gone to an organization and you see not the best documentation, no documentation, or you have the human process that works one way and the automated process that works in a completely different way. So now the people who are responsible for maintaining that knowledge set have to basically maintain two sets of documentation. 

Liesse Jones: Yeah.

Sean Tierney: Again, this is not necessarily a recipe for success. So automate, automate, automate. Yes. But what exactly are we automating? And if you're only going to do something once, does it really make sense to automate it? If it's going to take me a hundred hours to get this automation down,  you know, exercise, test it and all that, for a problem that we're never going to solve again, is that a good use of my time? So I think that we need to be really deliberate in where we really start to operate. 

Liesse Jones: Awesome answer. That's a really good way to think about it. I love the airplane analogy, that's great. 

The last thing I think I would like to dive into is just how you think about DevOps in a small company versus in a larger organization. The way that you are able to find blockers and remove them across a small team or small group of teams is really different than how a company like, you know, Google, might have to think about it.

So what do you think are the benefits of working with a DevOps mindset for a small company? And what do you think the alternative is?

Sean Tierney: The benefits of the mindset are, we could say, a happier, healthier workplace where more people feel empowered to do more and to be more. At the end of the day as a business owner, that's kind of what you'd want, right? As a stakeholder, you want an organization to be happy and healthy. A good DevOps mindset and a good DevOps approach to work, I think is somewhat contagious because it is empowering. We can get better and maybe I don't have to do this stupid task again and again, maybe I can figure out a way to do my job better. Now I will say this with regard to human history in the workday—being empowered to do your job, deliver your value without regard to, let's say an eight hour workday, are you going to be rewarded for doing better and delivering more value in a shorter amount of time? Or will you be punished for it? That is another thing that I understand why it happened. I've been in enough companies and enough different industries to know that that was the only way they could really measure whether or not the person was doing their job. But I don't think that's always the case now. And certainly not in a high-tech company does it need to be that way. And we'll fill the work day, right? If my test for delivering value is whether or not I can sit in a chair for eight hours a day, regardless of what I can actually get done, think about what that does to your mind. And think of it, that it takes your energy from really driving hard to solve a problem. You just mellow out, you know? I've got a hundred units of energy to give a day. I can either solve this problem today with this a hundred units or I can peter them out across the whole day and kind of maybe do something. You just turn into a slug and that's just the natural consequence of having that be the determining factor as to whether or not you're doing your job.

Liesse Jones: Yeah, I think that's also kind of tied to the startup mindset. Like the tasks that you accomplish are more closely tied to business outcomes. And you understand that the thing that you're working on right now has a direct correlation to how the business does for the quarter, how many customers you have, how happy they are, what is their churn rate. And I think that can easily get lost in huge organizations unless they're super diligent about it, or unless they adopt practices—you know, DevOps is a great example of a way to do this in larger organizations where tasks are tied more to product delivery or business outcomes. Instead of just saying, you work in this silo, you focus on the specific task and when it's accomplished you move on to the next specific task without having context for it. And without feeling proud of the contribution that you made, which is so important to just being happy and fulfilled. And maybe that's why people stay at Athos for eight years. 

Sean Tierney: I'm really thankful that they did. 

Liesse Jones: Yeah. Awesome. Awesome. Well, Sean, thank you so much for a great conversation. Really, really excited to have you as one of the first guests on the podcast. And, loved just hearing from your experience why trust and collaboration are so important to creating a good DevOps culture. So, appreciate it. 

Sean Tierney: Thank you. 

Liesse Jones: Yeah. Thank you. 

On the next episode of DevOps State of Mind, I'll explore what developer relations and advocacy look like in one organization and how it can contribute to a DevOps culture. Joining me for the conversation is senior developer advocate, Joe Karlsson from SingleStore. 

I'm Liesse Jones. Thanks for listening to this episode of DevOps State of Mind, brought to you by LogDNA. If you'd like to hear more about the DevOps culture, subscribe to the show and then pop over to LogDNA’s website at logdna.com to learn how to be more productive in a DevOps world. Links and information about today's episode are in our show notes.

DevOps State of Mind was produced and edited by Pamela Lorence from Studio Pod Media. Thanks for listening.