Ep 40: Sean McCullough, Head of Engineering for Atlassian’s Compass

Sean McCullogh: 0:04

It's the Next Wave Podcast episode 40. I'm James Thomason here with co-hosts Dean Nelson and Brad Kirby. And joining us today in the studio is Laura Roman. We have a special guest today, Sean McCullough, who's head of engineering at Atlassian Compass software. Atlassian is the development behemoth behind other products such as JIRA, Confluence, Trello, and Bitbucket. Prior to that, she worked as an engineer at Facebook and also a Groupon, with Laura, where they collaborated to raise revenue from 2.6 billion to 3.2 billion a year. Sean, welcome to the show. Thanks for coming. Hi, thanks for having me.

Laura Roman: 0:33

Sean, I have to say it is so great to see you again. And just tell everyone really quickly in short. Sean and I worked very closely together Groupon, where we built up a very impactful Developer Relations program focused on our platform engineering, or UX website operations, data analytics, machine learning and mobile, we got 200 million downloads of groupons mobile app, the years we work together, really was incredible. We had a GitHub repository meetups, we were key developer conferences. And most of all, we have this amazing annual hackathon. And one of my favorites is the Geek On World Tour where this shirt is the gnarliest shirt ever. It's Black Sabbath meets our Iron Maiden meets AC/DC. You know, Sean is one of the most talented engineers that I know. And I will ask him to talk about what we did with re-architecting Groupon's codebase, really quickly moving Ruby on Rails to NodeJS. And Sean, over to you to say more about that.

Sean McCullogh: 1:33

Yeah, it was a really exciting project. I think for a lot of reasons. One, you rarely get to have like such a huge technical impact on an emerging company, but to every engineers dream is to take like the hot new technology and roll it out at enterprise scale. So that project was really, really fun. I think it's actually started kind of out of that geek on spirit. We had these regular hackathons there. And I just moved from Chicago to California. And I was in a brand new Palo Alto office where there's like nobody out there. And I was sitting next to an engineer Keith Norman, and he and I had this like, wild idea to move everything to JavaScript, because like, that's what all of our front end developers were using. And we had a couple of days to ship the idea during a hackathon. And we're able to kind of take that from a proof of concept, all the way up into something that you would get like sell to executives and say, Hey, this is going to make your company more agile, that's going to reduce engineering costs, it's going to reduce server costs, all this kind of stuff. And we managed to get it out there. And we were one of the first day companies to adopt new j s at that scale. At the time, it was really, really fun. I also kind of remember that that's kind of around the time that I met you or and was like, starting to go speak at conferences. And I just, I remember how much coaching you did for me just to go up. Remember my slides that have to look at notes. And that got me so prepared. It was like my first real PR boot camp. And those like practices that you taught me back then still stick with me today.

Laura Roman: 3:06

Oh, thank you. I remember we had a lot of fun together. And we did a lot of work very close work many long hours. And it's really great. It paid off, we had a lot of fun. As Dave said, we also did so much for the company in terms of really doing elevating groupons position, I think, again, is a very interesting case study in itself. Because at that point, this was just a while ago is 2013 2014, early 2015. But Groupon went from five years old at the time to multi billion dollar company. But within that one year alone, we went from, let's see 2.6 billion to 3.2 billion in one year alone. And a big part of that really was Sean's work on re architecting, the code base, and really going forward with a huge PR and marketing campaign with mobile, and the company moving from a pull model to mobile. And again, this is still early days like mobile UX, mobile engineering, what that meant and content was a big part of it. And that was great for us because we had explicit control over the good engineering blog. And so we would get it as we wanted it, SEO-ize it, publish it. And then through Google Analytics 1000s of hits on these blogs, which eventually led to then forced or wanting to do a case study with us. So we were one of the first kind of companies that had this very public analyst key study on how to do mobile.

Sean McCullogh: 4:22

Yeah, that was great. The other really interesting part about that story was that Groupon had grown up its portfolio through a bunch of acquisitions. So Groupon was kind of the primary business headquartered in Chicago serving mostly the US market. But there were city deals in Germany spread out throughout the UK. And we had different offices kind of throughout the world and actually ran independent back end architecture. But we were able to roll out a single mobile application and eventually a single website by orienting around the same API contract. So we were able to kind of push Same high quality mobile experience to a bunch of customers who had different backends. They had different credit card processing different rules on how these kind of Groupon deals could work, all that stuff. And by creating this like awesome API contract, we can build that mobile layer and then build a website that worked basically anywhere around the world.

Brad Kirby: 5:20

I think banks probably wish that they had that same kind of technological philosophy. Because if you've ever seen a bank backend through acquisitions, it's a pretty sad state.

Laura Roman: 5:30

Yeah. So think about how we kept another innovation engine, as it were, was that hackathon too, because what I forgot to mention a minute ago is that, besides the fact we had a lot of fun with the themes, the company would actually fund projects coming out of that hackathon. So there'd be a vote at the end of the week. It was a week long hackathon. And it was company wide, not just in engineering, but even like in marketing, PR, best practices. And then the idea that had the most votes would then get funding and the person would get kind of a sabbatical from their day job to develop this idea. And Breadcrumb came out of this. That's right. And Breadcrumb was the go to POS for a long time here in San Francisco, you would go into shops, and I was like, what's your POS? Breadcrumb. And I thought it was really like our sales team did a great job of getting Breadcrumb around the Bay Area.

Brad Kirby: 6:17

One thing for listeners as well, I think that maybe not everyone's participated in a hackathon before. And I think one thing that I didn't realize, until maybe a half dozen years ago, that anyone could participate in the hackathon. So I just encourage anyone that has any interest in technology to participate and get your feet wet. Because a lot of people think it's just hackers and it's development. But James is probably being like "I did one of those 20 years ago", but still it's a great concept. And I recommend to anybody who's ever participated to do one.

Sean McCullogh: 6:48

Well, and they're fun. If you participate, and you have a mission to go accomplish them. They can be a lot of fun. I think they get the word gets abused a little bit. Now, everyone was supposed to be like the cool kids running hackathons. But they're super fun if you get a chance to do it. So Sean, you work for Sri Is that right? I did yeah. I work in Sri's org. So he's the CTO and VP of engineering for Atlassian.

James Thomason: 7:10

That's awesome. You know, every now and then you have these little hot startup companies with tons of money. So Sri and I were together at a company called Ning, which was kind of a contemporary to Facebook, but it was a build your own social network platform. And so many people, that company just attracted so much talent, and so many people from it have gone on to do big things. Obviously, Sri is doing very well. As CTO of Atlassian, the former head of engineering went on to lead engineering at Facebook, little company called Facebook. Pete Webb, who worked with me went on to lead. He was also a Groupon for a time when most of Ops, I think, globally, yeah, and went on to be the head of infrastructure for digitalocean. And now a CTO of ripple, another Canadian, right? Yeah, another another Canadian turns to the dark side in San Francisco, where everywhere, he's lovely, by the way, anyone is great. Anyone should hire Pete, any day of the week, ripple, you're very lucky, and I'm jealous. In any case, it's like an exploding star, right? The bits and pieces of companies like that they spread out across all these other companies. And they go into two big things. So Atlassian is a company that I think everyone in the software development community knows, but people outside of the developer ecosystem, sometimes scratch their head and wonder what the hell does this company do? So they really got their start building collaboration tools, wikis, and bug tracking software was the first one. Yes, yes, I was a very early user of Confluence and JIRA. Way back in the day, and sometimes companies like this, the stagnate but Atlassian hasn't. So they've continued to make acquisitions, they acquired Trello, which was not a an odd Atlassian product, but it's nevertheless obviously a very popular tool and an awesome combat style tracking board. And you're working on a brand new in house project, though, right? Compass' OG started at Atlassian as an inside project, is that right?

Sean McCullogh: 9:00

Yeah, yeah. It's funny when you when you talk about the kind of brand recognition Atlassian advertises on NPR nationwide. So when I say that I worked at Atlassian. Most people were like, oh, like, company that advertises on NPR. I remember right after I joined the company, I got my kind of new hire swag bag, and I had a set of like, Atlassian socks, and I was waiting at a barber shop to get my hair cut. And I had my legs crossed, and some guy saw my socks. He's like,"Oh, you work for Atlassian? I'm a serial entrepreneur." And the first thing that I do is buy JIRA. Whenever I started a new company, it's like, which is kind of funny, because I think if you talk to developers, you get more of like the JIRA like the the internet is full of troll posts and things like that. But I think for a lot of people, we're really trying to build something like JIRA is integral to that. But yeah, cup is is you know, I think we've tried a bunch of different things in Atlassian to kind of build new things. I think what we've been really successful at is in acquiring things. So HipChat was another big acquisition that I think was a really good business for a long Time. And then we've kind of acquired portfolio things into the JIRA space. So we just bought a company that we've rebranded as JIRA VI, which is to kind of do Scrum of scrums level planning, we've kind of been able to scale around those core concepts. But we're really looking to kind of find the next like billion dollar business. And we are, I think Atlassian is really interestingly positioned in this market, because like, we are not an infrastructure tooling company, right? We don't want to run stuff on your servers, we want to help the people in your organization do technical work better. And I think a lot of times you see, tooling, companies tend to kind of go a little bit too into the weeds, they're trying to understand how people actually build stuff, and not give them tools that helps them manage whatever processes they have, right. And I think the great part about JIRA is that you can do Scrum, you can do agile, you can do waterfall, you can do combine, like we support all of the ways that you work. And we can elevate the way that you work by modeling it in a really good tool. And compass is kind of a bet that we're looking at the kind of like complements that kind of where JIRA sits in the kind of DevOps loop. So you kind of have this like build, deploy, operate, plan, get feedback, and then kind of feed back into the plan loop again, in DevOps, where you're just constantly learning about what you're doing. And one of the big missing parts of this is like, what happens after you build this stuff, right? You build all these services, you build these libraries, these mobile applications, things like that. And then they're out doing their job. And for the most part, people know that they're doing their job through the other SaaS tools that they use through your Splunk and data, dog, your analytics pipelines and things like that, right. But that's sort of like a side effect of the fact that these things exist. Most companies that I've worked at at Groupon had a version of this, Facebook had like a really intricate version of this, have something that tracks the stuff that you've built, and it's running and how it relates to the people in the organization who are responsible for it. And for the most part of these tools have always been homegrown tools. So you know, they, they work just about as well as doing sticky notes on a whiteboard, right? Like you can get some of the job done. But there's a lot of friction that comes along with with doing that. And really, to build a world class tool, you need product managers, and designers. And that very rarely happens in a software team that you spend time reflecting and learning on how people actually use this stuff. So compass is kind of our opportunity to take what we know about how to build products, and how to build cultures that work with technical teams, and apply that to the output of these kind of engineering teams. So we're kind of starting really, this is a really interesting way of working at alessian. So we have this new kind of point, a framework. So it was our way of kind of doing little startups at the company, we've had a couple of things graduate, we have team central that recently came out, which is kind of like a outward status tracking tool, we add JIRA work management, JIRA product discovery rate, but they're all kind of flavors of the same kind of core competencies that we have in the business. But compass is something really new, we're actually building it on a completely new stack completely new everything. And we're starting with just helping you track the stuff that you build, and helping you find out who owns the stuff, which in our customer interviews is a constant problem. Like most people are like, who owns the Identity Service? Where's the slack room for that service? If I see an issue with a service, how do I page those people? Usually, there's so many levels of indirection, I think if we start there, like there's so many ways that we can grow, but this is like a really big missing component in the way that software engineering orgs need to do their work. So that's fascinating, because I think probably no one outside of maybe complicated engineering teams understand the scale problem with writing code. It Well, in engineering systems. In general, we were talking about the other day that even in places like oil refineries, or manufacturing plants, the engineers that built those plants typically have all the domain knowledge, and they maybe have handwritten notes and stuff. And some of these guys are aging out there in their 70s and 80s. And the no one knows how to run the plants from an internal perspective once these people pass on. And in a way, like in the software world, it's even more confusing, right? Because people write code, the code lives on the people to write the code, they probably disappear from the organization at some point. And so they leave behind running artifacts that are actually in production. They're serving requests to other services within the platform. Maybe it's an internal piece of code that customers don't see but is integral to the way that the the software platform works as a whole. And as a small company, like as a startup. Typically, you have very good awareness of who's working on what so if you have a team of say, 510 people all the way up to 50 people. The way we accommodate this is we have little hardshell teams that work on different components. Typically that the head of development like yourself or CTO, like me, will have really good line of sight to who's working on what at a given moment in time. But at a certain point, I remember when I sold my last company to Dell, we absorbed 370 developers into our 70 developer team. And so I literally had no idea what an individual person was doing at a moment in time, there was just too many products and too many components for me to maintain that level of awareness anymore. And that's the kind of specific problem this tool is designed to address, right? How do you as an organization when you're big, and when you're distributed? You have different people in different places working on different things? How do you maintain awareness, and sort of unit cohesion between these distributed teams? And the apps? The software itself is also distributed? And that's kind of like the double bladed sword, right? Because you have people everywhere, but the components themselves run in different places, and are a different repositories different areas of domain expertise. And it really is chaotic, right? That's the world that compass seems to have been born in and is designed to address. Am I getting that right? Yeah, definitely. I would disagree that this is a problem that you only face at scale, right, guys, we talked to teams who are front end shops, right. And they create a bunch of react components that are individual NodeJS packages, right? Like that can balloon very fast. Or if you're doing something like a real microservice, architecture, or IoT, where you might have a lot of small units of work, right? Even if you have a team that is marginally responsible for it, right, like you're kind of cash per keeping these things in your mind quickly gets evicted, right, you're just moving on to the next thing. And especially if you're successful software engineer, the best code that you write is the code that you never have to think about again, and these things will get deployed out and do their jobs. And then it's not until you have a security vulnerability, or an infrastructure outage or something that you have to bring your attention back on to it. But so I think that smaller companies who are adopting more kind of micro service oriented approaches, and specifically doing a lot of DevOps, really need to do this. Because I think that, especially in a startup, you kind of just need to move on to the next thing as quickly as possible. You don't leave behind a defend team to kind of look at the infrastructure that's doing its job, you're focused on the next problem ahead of you, I think you're talking about one of the key things that we want to solve with companies is onboarding, right, just having a good catalog of stuff. Having here's a service, here are the people that are responsible for it. Here's the chat room, here's the link to the confluence stack. That is the documentation. Here's the repo, here's the dashboard here, the SLOs. Here's the onboarding guide, all that kind of stuff. Here's what your service depends on and what services depend on you like getting all that information out of an organization is really, really complicated. And you tend to see companies have homegrown solutions like this, like they'll start something like this on accomplishments, but it's a removed from their source of work, right? It's not where they go every day to do a part of their job. So you get really quick bit right on that stuff. You know, if you're constantly hiring and scaling up your teams, you can keep that stuff fresh. But you know, if six months goes by before you need to hire somebody, you go back to your onboarding guide. And you're like, man, none of this is up to date. And then the new developers spend twice the amount of time getting on boarded. So we really want to kind of build in not only just the persona of the people who are responsible for things, but also for the people who are coming into the team and learning how to discover all the things that are around them.

Dean Nelson: 18:29

Yeah, to me, this comes down to good hygiene, but it's always so easy to just miss it. So like you said, I was over at Uber. When I first came in, I was just amazed they had over 3000 microservices. And then when you look at it, how do you link all these things? And then I remember outages that were happening because of code or things that were just residual. And then they realized this is connected to this. And this was connected another thing and then all of a sudden, you got a cascading effect, that I know that's a scale, but how would a company like that? Go back and apply a thing like compass?

Sean McCullogh: 18:59

So I think we're trying to figure that out? Right? I think one of the challenges that we're seeing is that while DevOps is, I think broadly understood as a shorthand for the kind of way that teams work. The implementation of that is wildly different, right? Depending on the cloud provider you're on and the observability tools that you use, and the practices that you have, like, are you fully a you build it, you run it? Do you have an SLA team that's paired with you that does a lot of the operations work? Or do you still kind of throw it over the wall and call yourself a DevOps team, right, like we see a huge spectrum of those things. What we're learning right now is like, we're really going to start small. I think part of what we're given permission to do at this point a program is to not try to swing for your enterprise level software companies. First, we really need to learn to crawl before we walk here. But a couple of things that we've learned along the way is one, that first kind of import is super cheap, right? Like it's annoying. You might have a spreadsheet you might have a compliment Start, you might have a database with a crud API or something like that, that has a bunch of new services in it. We built everything on campus with a kind of API third party first approach. So we have a rich self documenting GraphQL API that you can use to do anything that we can do with the front end, you can do to that API. And we're going to provide people some scripts and things like that to say, Well, if you have something that looks like this, if you have a CSV file, we can help you import that in. But we think that we're gonna have to get more sophisticated than that, right? Like, there's kind of two discovery lifecycles. There's like the onboarding to compass. And then there's like the constant discovery of things as they change in your infrastructure or as your org evolves. So Atlassian actually has this really exciting new plug in framework called forge where you basically you write code that we run in our infrastructure as plugins, those plugins can receive web hooks, or git push events, or they can do or things on your behalf. But they can also extend our data model and modify our data model on your behalf. So what are the things we're looking into is can we write forge plugins that would talk to AWS and Splunk, and data dog and see if we can find things that, like your infrastructure already knows about services? We definitely know. And I think Atlassian is a great example of this, that what is in our tools, and what we call a service don't completely match one to one. But we can start making some pretty good guesses like, Did you just add a new monitor to a service like, Oh, we can kind of figure out if that should link back to something that we know. Or, hey, you're at USA said that you spun up like an entire new set of infrastructure that looks like a new service to us. And then what we're designing right now is some sort of guide and triage thing. So as these infrared SAS providers come back to you with new information, we can say, what would you like to do with this? Would you like to link it to something that already exists? Or would you like to create a new service for it? So we're going to have to be really, really flexible about this, just because there is no one right way to do it. And I think we could really frustrate our customers, if we like, just spam the catalog with all the tags that we found in data dog, right, like that would be the absolute wrong thing to do. But I think also, if we can't make some smart decisions for you, we would frustrate our customers by having to do a lot of toil. So I think we're trying to find where that middle ground is that meets people's expectations.

Brad Kirby: 22:21

Right. So with obviously, you guys use "you build it, you run it" concept, which I think originated about 15 years ago with AWS and what not. So how is your experience with it? Like what kind of skill sets that you see? Are there people that that maybe aren't necessarily suited for it? Curious in terms of that principle of how you view it personally, maybe as an organization as well.

Sean McCullogh: 22:43

So yeah, I think you build it, you run, it can kind of fall on a spectrum, right? In AWS, my kind of director of my department, Zack Islaam, came from AWS and I got the sense from him that his reports had strong infrastructure knowledge, and that people really knew how to use AWS and Atlassian, that's hit or miss, right, like some people know how to use and some people don't, when I first joined Atlassian, and I was actually on the microservices team, which is our platform as a service. So we actually create a layer on top of AWS, really just using cloud formation at this point, to say, I want to run a service, give me a Docker container. And I will figure out how to do the rest for you, I will create default dashboards, I'll give you a link to your Splunk logs, I'll set up some default alerts for you. Like it kind of gives you a lot of that stuff out of the box. And I think that that makes you go that you run it a lot more approachable. I think if you have to teach everyone kind of from first principles, how to run and operate a service at scale, that becomes really challenging, really fast. So I think you have to provide some guardrails and some sensible defaults there. The other thing that I think really tend to get left out of the ability to run it is, especially for a company like Atlassian, a publicly traded company, we're going for FedRAMP, like we have all these kind of privacy obligations, like that's a big part of running a service. And you need to have basically controls built into the platform to make it easy for you to do the right thing. So not only do we have kind of a platform is a service that has sensible defaults, but we actually prevent you from doing a lot of stuff like reaching out and talking to a database and another service. Like we have network isolation and stuff like that set up between services so that they're really clean service boundaries that reinforces design principles throughout the org. So I think if you start with the sensible defaults, like you build it, you run it is a little bit more achievable. I think when you're looking at a company like Atlassian, we have an interesting lineage, like we're not a cloud company, we are really pushing to cloud. And over the last couple of years, we've moved the majority of our revenue to our cloud services, but we were primarily a server company, we gave you stuff to go run on one of your machines. We had a cloud offering for a long time that was basically we'll put it in a VM for you and run it right but we did not have proper multi tenant cloud architecture until I joined in this is actually one of the things that Shree drove when he joined the company, which is we actually forked our code bases and created a cloud first way of running JIRA and Confluence in the cloud, it took us two years to really figure out how to do it. But we finally got to that point, I think that process brought a significant chunk of the company along with them on that journey, right, they had to learn how to not only build and operate JIRA and Confluence, but also all the platform services, identity data stores, all that kind of thing. And it was a really good learning experience for that group to kind of come through that journey and come on the other side, now being responsible for, you know, these big products running on AWS infrastructure. Now, ever since then, you build it, you run it is the norm. So when you join the company, like in their first week, we have bootcamp showing you how to use our platform as a service, how to use these observability tools, your team generally has, like an SRP, who's really doing the proper like Google SRV role, helping you understand how to operate your service, how to get telemetry out of it, we have a lot of rituals that we've actually just borrowed a lot from AWS, and we do weekly techops reports for all of our services. So you sit down with the person who just went off call, the person who's going on call, you review all the events, you look at all the charts, you figure out if there's any actions that you need to take stuff like that. And I think when you combine kind of sensible defaults, really good kind of design patterns, and then a culture that reinforces those patterns regularly, through like standard rituals, you can kind of start to build that awareness. Now, I think that there's still parts of the company that are struggling a little bit with this, like, I don't think that you build it, you run it for front end is as clear, right? I think the same principles sort of apply to single page applications. But the technology and the way that you approach those things is a little bit different. So I think they're still learning how to do incremental rollouts, and feature flagging and things like that, just because they can't borrow the same set of tools that work for a back end infrastructure.

Dean Nelson: 27:05

Let me flip this around a little bit, Shawn, so I love the concepts of what you're doing for what the customer is going to see. And I love the fact you're starting small, because if you can do it right at the beginning, you can scale pretty quickly, and you're gonna have your hygiene together all the time, right, it's gonna be able to scale with you. But let me flip this back into compass itself. So what are the cool kids? We talked about this? So what are the cool kids doing regardless of the stack? In other words, what languages and frameworks are you using to write compass itself? Yeah,

Sean McCullogh: 27:30

so last name has been a Java shop for a long time. So we're pretty embedded in Java, all of compass is actually built on kotlin, which people have been pretty wild about. So last thing is basically saying at this point, like if we're going to build a new service, it should probably be on the JVM, it can either be in, you know, kind of Java 11. Or you can use kotlin, as our team has been running with kotlin. I think that's been really interesting, just because kotlin itself, I think, is a language under active development, right. And I think the tooling that's around it isn't super stable and mature, you even like the IntelliJ, support for kotlin can sometimes get a little bit wonky, which is kind of surprising given where it comes from. So that's kind of the foundation of what we're doing. On the front end, we actually have a new front end monitor repo that works for all of the products that have a new single page application infrastructure. So that's all react, we've got a lot of custom stuff going on in there. We have a couple of front end, folks from Facebook come over and take a lot of cues from the way that Facebook runs their micro repos. So we have a built queuing system and emerged queuing system and stuff that makes sure that at any one point in time like that the code is always green. There's like regular deploy trains for the stuff that goes out for the front end code. So it's, you know, it's a really different way of working with a really modern set of tools. And I think it's taking some people a little while to adjust to how that works. But I think we're seeing huge benefits from that because now, we have a design system called Atlas kit within Atlassian, who makes our buttons and nav bars and all that kind of stuff. And they can all work in the same repository. And we can see them upgrade components across all of our products all at once. And that's been a really powerful thing for us, especially when we see bugs or accessibility issues or things like that we can fix them across our entire portfolio in a pretty short amount of time. And I say one of the interesting things that we're doing is that we have Alessia is actually built its own graph store. So we're really doubling down on graph QL. But we also want to store a lot of this data in graph. So we have a team that came out of ops gt who was some really, really smart engineers and they built kind of a layer on top of dynamodb. That gives us a schema managed data, residency, data depletion, data isolation, all that stuff kind of proven out for us graph store that we can leverage. So it's kind of cool that we in a way are we're using kind of a bleeding edge technology here which has had Had some ups and some downs. I think like there's no documentation for it. So we're not enough documentation, there's no rmws. There's nothing like that we're kind of going with it all together. But it's been really useful to kind of get the teams to think in kind of graph terminology, I think, one, it benefits our scale. I think that if we wanted to throw all this stuff into a relational database, we get into a really tricky position where we're shorting these databases, or we're trying to figure out, you know, how to throw more money at Aurora to handle giant data sets and stuff like that, where the graph store really enables us to kind of model our data correctly, and scaled up and really cost efficient way. And then I think the other kind of like, interesting thing is, we're using a lot of like lambdas, and Functions as a Service. So we do a lot of event processing going on. So we've been writing a lot of lambdas, to do that kind of stuff. But our entire plug in framework is basically no GS and lambdas. So you can redraw our UI, you can deal with event streams, you can receive web hooks, you can modify our data model. And all of that stuff is expressed in JavaScript that runs kind of in a sandbox in our architecture, with all the same privacy and data restriction controls that you would expect out of us. Right. One of the problems with like extensibility frameworks in the cloud is that they have really bad security models and really bad data isolation models. And we are basically saying you can run it with us. And we will take care of the heart operation stuff, just great code that extends this functionality extends the product in a way that you need. And we are learning how to develop that. So we're, we're now actually kind of in the cloud hosting business, because we're starting to manage other people's code in our infrastructure. I wanted to pause you there because I actually have a set of questions. I'm picking from a bag here on my list, and you touched on one of them, which is serverless, you said the magic word lambdas. So I wanted to ask you, one of the cool things that the cool kids are doing is serverless. And overall move towards serverless. And event driven architectures versus kind of the old world of what is now the old world of microservices and different components that communicate. So sounds like you guys Atlassian is taking advantage of serverless? And sounds like on an increasing basis? And are you seeing that with your customers as well? Are you seeing a big uptake in in serverless? And are you contemplating serverless, as part of the scope of compass, we're definitely keeping it in mind for compass is actually kind of interesting that when people talk about serverless, the implementation actually defines the categorization rather than the technology architecture, right? So like, if you have a bunch of data, a bunch of lambdas, that are an event pipeline, right? Like they call that event pipeline, where data processing pipeline, they don't think of them as serverless, serverless. And like that, right? Or if you have things that are running at the edge, they're edge functions, right. So like, it's been interesting to see that, like, we still think micro services are services, but with a unique set of properties or scale, right. But lambdas are actually generally viewed as just stuff that sits in between other parts of my infrastructure doing that thing. And people tend to name of it and think of it in those terms, right. So when we talk to shops that do machine learning, or data pipelines or stuff like that, like they're coming to us and being like we have a bunch of stuff for data pipelines, and we don't know how to manage that. And one of those things will be

James Thomason: 33:19

lambdas. That's really interesting that I kind of got a visual when you said that, that idea that micro services, or other or even even old, monolithic services are out there running. And there's this space between them, you know, where in quotes, stuff happens. And increasingly lambdas are filling up those gaps, right, where you have a ad hoc procedure that needs to run, maybe that's tied to a pipeline. And so the best way to do that is as a lambda, right, because you don't want a full blown service to do it. You can code them up really quickly, you can change them really quickly. They scale automatically with your load. But that's really interesting that you're seeing that kind of pattern emerge as well. Brad slides up a note here on our end when it says that kotlin is also used by Corda,

Brad Kirby: 34:00

every ass I wrote a topic because I find it interesting that Cordo, which is a distributed ledger platform that is primarily used in finance. And I have a finance background. James knows that I'm not that technologically savvy, but I'm always interested in languages. So I'm always asking dumb questions to him. I love doing it. So it was kind of curious, just because you talked earlier about Groupon and acquiring companies. And the API is bringing it into one kind of Central platform, really. And I feel like Kotlin has kind of a similar aspect into Android and iOS development. Did so did your experience at Groupon have any contribution to using Kotlin for Compass at all or my often Yeah,

Sean McCullogh: 34:43

I mean, I didn't make that call. I'm a manager of managers now. Like I leave the nuts and bolts tactical decisions are the people who have to suffer the consequences of them. So I generally support whatever they want to do. Atlassian has actually really been invested heavily invested in the JVM for a while. So I think both We also know like, I don't know, if you look at our kind of legacy JIRA and Confluence code bases, I'm sure you'll see some nightmare enterprise like software being written up there and factories that have 400 character names and stuff like that, right? Like, they're just some, I think quality of life issues that kotlin looks this up. And I think that's really what we reach for first with kotlin Atlassian, it had some experiences with Scala enclosure, which really, they promised some of the benefits of like what kotlin did, but they really had poor interoperability with other things on the JVM. And I mean, with Scala, you had all the Scala z stuff and the functional programming in this like awful compiler and a terrible tool chain and terrible ID support. But there were some like killer features that were actually useful. I think where people went wrong is when they use Scala to be a better Java, because that's not really the niche that I tried to fit. closure, you know, you can argue the merits of like whether Lisp is good or not, right. But I think that that also provided some real values of like running on top of the JVM. But I think for Atlassian, we see kotlin. The benefit of kotlin is two things. It's a much more concise syntax. But it also allows us to toy with reactive or functional programming in a much more natural way, right, like trying to do functional programming in Java is nearly impossible. Trying to like retrofit, another language or paradigm on top of the JVM is also really awful. But now that the JVM is kind of heading in the right direction kotlin as a better syntax, language, and runtime makes it easier to approach those things. So we're definitely seeing, I was actually reading a post today about immutability and using immutable data structures in a lot of our code, and how that works really well in some instances and doesn't. But all the reference code was in kotlin, right? And it just goes to show that the mindshare of where we're going is the expressiveness of kotlin helps people do their job better and communicate concepts more simply. And at this point, there's no downside to using it, right? There's no overhead, there's no compile time issues. Like there's no interoperability issues, it really is like, the next gen Java that people really wanted.

James Thomason: 37:13

Are you seeing interest or use in WebAssembly? I mean, webassembly is very new on the scene. Speaking of cool kids, being a very recent web standard, we're investing disclaimer, we're investing very heavily in webassembly of my company. But I'm wondering, are you seeing that on your side yet, with either customers or in your own stack,

Sean McCullogh: 37:30

There's been a couple of little research spikes to kind of make some of our really complicated front end ork get offloaded to things in orkers, and that they found hat like writing and managing ll that stuff in JavaScript ecomes really tedious. So if e're able to, like write omething in Go, or Rust, and hen compile it down to ebAssembly, that we can get a ot more efficiency out of that. o we've been talking about like nalytics data sets, and like, an we just throw a bunch of ata at the front end, throw it nto a worker thread and do omething with it, we're not eally looking at that much. On he back end, I have seen here's actually a an experiment ecently about using some ebAssembly stuff to do kind of n the fly translation of avaScript bundles, so that we an kind of use a much faster ngine to parse those bundles on ike a per customer or per equest basis. Because one of he things that I think Atlassian products are, we're constantly dealing with is the kind of usability of the UI both from the amount of JavaScript that we load on the page, but also the kind of design of it. And if you want to do A-B testing and things like that, oftentimes that means you have to load a lot of JavaScript in the browser, which can really slow things down. So we have been experimenting in some of those areas. But it's not really making its way into kind of big parts of our production stack yet. Not yet. Not yet. That's fascinating. Thank you. And, you know, we try to strike a balance on this show between technical and business and sort of make it relatable as a layperson. And we've spent a good 15 minutes now sort of into deep tech, doo doo. I wonder if we might back this up just a little bit to you personally, and your career trajectory, I think, very commonly, when you get someone who's very technical, who can also speak to other human beings outside of the technical community, they get, inevitably or inexorably sort of pushed into what you said earlier, being a manager of managers or a person, a person who can translate between business people, customers, and technical people in one way or another, and push so to speak up the management stack yourself. And so I wonder if you might comment a little bit on your career trajectory, and how did you start and how did you become a manager of managers? Yeah, so I actually started I don't have a CS degree. I have a degree in Latin and Philosophy And that started is kind of happy accident. So I wa actually reminiscing thi morning. I don't remember wh kind of an adult shower though of how the first website that built like, I remember I got i Red Hat five set of floppy disk that I put onto an old 46. And was like kind of just fascinate with like running Linux on machine when I was 12, or 1 years old, I built my firs website, I think the thing tha popped up to me is like I sa something about SQL injectio attack. And I was thinking bac to that website, which must, think I wrote a SQL injectio attack as a feature, that yo could just go in and write query to do whatever you wanted As I conduct probably was a ba idea. Back then, I've been kin of interested in computers an technologies since I was a kid I started off going to Rutger and I remember sitting down t take my entrance exams a Rutgers. And I was like, yo know, I wasn't an awesom student in high school, but was in like, college pre calculus or something like that And they handed out thre different years of the entranc exam and promised to us tha they were all the same. Bu surprisingly, only about a thir of the people in that room passed the exam. So my firs kind of fight with a massiv bureaucracy was trying to ge them to read, let me retake th entrance exam, which the didn't. So I was put int remedial math class, like a zer level math class, to basicall pre algebra. And I would hav the final exam for every one o those classes up until I hi calculus, which is prerequisite for me to start m CS degree that would have take so the first two classes woul have been with no credit. An then I would have to do an extr year of math before that. S wouldn't it be restart my C degree until my junior year, s I got Wow, so frustrated wit that, like, at the time I wa going to go work through it. An I actually got a job at company in Central New Jersey close to Rutgers, where I wa just writing pro scripts t scrape financial data fro websites. So basically, we were it was a platform that helpe headhunters for traders basically, you could identif who would like the most hig profit traders were in a marke or given a government, a industry or something like that And then we'd sell that data t recruiters so that they could g steal top talent from othe companies. And I remember tha job. I was like, in a windowles room writing Perl scripts o like, scraping FTC websites. An I was like, I don't know if thi is for me by colleges want me t do this, this job kind of sucks Like, I was learning a lot. Bu I was like, this doesn't soun fun. So then I transferre schools and moved to Chicago. got my degree in Lati philosophy, which is great Like, I think that tha education taught me about an Oh, Brian McAllister, he was English major, right? Like, he' been a very successful engineer too. And I think what I'v learned one, I thin communicating and writing i something that just kind of go drilled into me. But I think th second thing is, especially wit Latin philosophies, you're kin of constantly forced to teac yourself, right, you are no just handed a piece of paper an say, Go memorize this, right It's like, we're talking abou meta ethics, right? Like here i the corpus of authors, here's bunch of work that you need t read. And like, you need t learn how to synthesize all tha information, digest it, and b able to kind of spar it wit other ideas, right. And lik that discipline of jus learning, the ability to teac myself over and over and ove again, was super valuable. Also Latin was like really useful just because it gave me kind o an appreciation for language Right. And I think one of th things I was liked abou programming was like the wa programming languages work right? They all have their ow personality and almost like set of values that are codifie into them, right. I was a bi Perl head for when I wa younger, I don't know what tha says about me, probably nothin good. But like the fact tha that language was just s flexible, you could do reall whatever you wanted with it, an the especially to get work done fast. That's what it says about you. Yeah. Well, I think in the spirit of Latin, it's just being able to say incredibly dense things in incredibly short ways. The elegant one liner is definitely something that you find a lot in the classics. But basically, I graduated from school, and I was saddled with a bunch of debt. And I was in Chicago at a really interesting time. And I was like, I was actually working at a record store. And their record store was basically all online. It was this fun console record store called dusty groove in kind of Wicker Park neighborhood of Chicago. And I remember going in there and kind of being awed by how they ran their business. So this one guy basically wrote an entire packaging and picking system using Visual Basic for Applications. On Windows NT. Basically, every computer in that company had to be frozen to Windows 98, because like the version of Office they built against and the version of access they built against, they couldn't upgrade it. And they wrote a PHP script that every night, scraped the database out, generated a bunch of static files on their website, uploaded it to the website, and then the shopping cart for that website was all in cookies. So you could only buy 30 records at a time because that's I was the closest that they could pack it down within that limit. And you'd see multiple orders where people do buying 30 items at a time because of that, and I remember like, being there, and that maybe it was like my post-collegiate arrogance, or maybe just kind of getting a little bit restless with a tedious job, but being like, I think you can build a better website, right? I think I gained like, maybe contribute something here. So they actually brought me on to go work. And my first taste of like, modern web development was writing an Ajax type ahead picker for their website, because their search was just like a dumb bar, you just typed in something, you went to the search page, which was awfully slow. I think it was also because PHP, like static text, my sequel engine, and they had like, millions of records in their database. So it would always be broken. And I found a way to like, make that search a little bit better. And I was like, Alright, I think this is maybe a time to go try something new. So I was looking around and I, of all places my first job, my first proper programming job came off of Craigslist. So a guy was looking for somebody to do some coding for $25 an hour, which at that time was like, Yeah, $50 more an hour than I was making. I was like, yeah, hell yeah, let's go to this. And basically, he wanted me to prove that I could code in Ruby on Rails. So remember, I actually went out, I got the O'Reilly rails book in the cookbook. And I at the time, I had just an old PC that I had plugged into like a tiny monitor that I was using as a TV. I remember sitting over it for like, two or three days in a row to build my first rails hello world website in a VM on this machine. Because I was running Windows at the time. He gave me like a couple more challenges. And he's like, All right, I'll bring you on. And Dustin, Dustin Anderson, thank you so much for that first opportunity. And basically, from there, I got on with this company, Elias and media, we built mobile applications. We started contracting for design kitchen, which is like a design and advertising agency in Chicago. And through that network, I kind of got brought into Groupon. So it was kind of like this wild ride over the course of a couple of years where I was not only like learning how to code, but also doing a lot of like, customer interaction. Basically, they were lending me out to these agencies. And I would figure out the contracts, figure out the terms of service fingertec figured out all this kind of stuff. And I was like 24 years old. So I got kind of a really good experience at doing both at that time. And then Groupon was the first job where I was just like, I came in heads down just to do software engineering work.

Dean Nelson: 47:38

I just love these stories about where people came from Sean. So I want to give a shout out to Dustin Anderson as well. Because if he had not given you a shot back in the day for you to go put something on Ruby on Rails, you'd be teaching Latin right now most likely, or something totally different.

Sean McCullogh: 47:55

Well, I know whatever I'd be doing, I'd still have a big bundle of student loan debt. And, yeah, I always kind of felt like I was going to get back into technology and one way or the other. But like that guy, even if I could believe that I would have gotten myself there. He gave me a massive opportunity and a massive hand up into that world. And he moved to Groupon, he actually recruited me over to Groupon later on. So it kind of started me on this like realm of connections that have maintained through the rest of my career. Each of you have these shout out people, right, like Tom day was the guy who gave me my shot,

Dean Nelson: 48:31

and engineering at Sun Microsystems. So Laura, who was the person that gave you your shot at the beginning,

Laura Roman: 48:37

when I segwayed from academia into tech full time. Otherwise, I was doing tech PR on the side for a long time when I when I taught rhetoric at Stanford. One quick thing about your Latin background, though, is that I think it's interesting are seizing on the whole idea of methodology and rules. That's quite true, because I don't remember this. But as you were honing your own speaking style, we did talk a lot about quintilian and institutio, oratoria 12 volumes, how to learn oratory, but it's true, but there are rules and templates to work from. So it's not that people are really born great speakers. I think that, you know, in short, some personalities are more guys than others. But there really there's a foundation, there's still platform to build on that you remember that I think it was really inherent to to kind of take that platform and then run with it in terms of articulating you know, are no dist or at the time. But an answer to your question, Dean, that is great. And I would say it was opposite the CIO at HP. And Randy Mott and Craig flower in particular, who were put it into Randy. So long story short, I grew up in Silicon Valley and family of engineers. My passion, though was so disparate from my families. I did not pursue engineering, computer science, like my brother, I went off and I loved narratives and stories and did my doctorate in English. And when I came back to teach at Stanford, big long term goal is always to do what I'm doing right now, which was to do tech PR full time, but toward that, you know, I did tech PR a little bit when I was in grad school back in England and then back here and I had my own consulting business at Stanford. I was consulting for Or HP and this whole time what came up the Office of the CIO and they approached me about it. I hadn't even thought at that point if I was ready to give up Stanford academia, etc. I was so much invested in my academic career at that point and I made this leap and it was so magical because I learned from the best and I'm still in touch with all those guys. They are great friends of mine know Randy Mont who was CIO of Dell, cio, Walmart, Craig flowers, customer operations it we did like it for hp.com I remember like when you're like when hp.com crashed during Black Friday with from the IT side is the is the CIO really the CMO? I just learned so much from those guys. I did this you know, I wrote direct content for Randy to the CIO CEO roadshow with Mark Hurd. God rest his soul at the time. P girl check some other love those guys really, a lot of them are Austin based, actually. And they would just follow Randy like Randy, they all work with Randy Adele, then they all worked with Randy at Walmart, then they all came to hp. And we did very quickly. This is huge it transformation right. So I team business hate each other. It's like the montagues and Capulets. Like they just it never moves faster to for business. But my job then this was a mentored role to come in and communicate to the internal stakeholders what the transformation meant from optimizing it perspective, I've been to the external world tie, we were doing a transformation that was in record time, like something of that magnitude and level for a company HP size would be like six years, we did it. And just under four years, we all got little medals. At the end, it was a badge of honor medal, which I still have somewhere but absolutely love those guys. And I was hooked. You know, first time I learned about load balancing the whole thing. And so really getting to cut my teeth.

Dean Nelson: 51:46

I saw was Tom day, and it's funny. I was in manufacturing during component level debug, and he was an engineering and he gave me a shot to come over and start doing something engineering. He took a chance on me. And I think that was kind of the point. You know, he saw something I allowed that to happen. I ended up hiring two of his sons multiple times throughout my career. Isn't that interesting? Where is he now? I think he's retired and join his woodshop

Sean McCullogh: 52:11

I think it was like one, not just to ignite this industry is small, right? Like you will run into people over and over again in your career, but to I think like it is beholden on all of us, who have the ability to create opportunities for people to do that as regularly as you possibly can, right? Like I am. And I've seen that happen so many different times to so many different people who have launched their careers in that way. And, you know, it's unfortunate that like these kind of gatekeepers still exist, but if you're, you're in a position to be a gatekeeper, be a really generous one and help people out. I think gatekeepers Are you can have a really good gatekeeper right over a series of them. And I'm fortunate in that respect as well, because everyone who took a chance on me was taking a different kind of gamble than betting on a graduate from lab studies and, and philosophy, like I was a kid and like I was a 13 1415 year old kid in tech. And the first guy that gave me a shot was named Randy Kruger of Randy's computers, you don't have to go to computer store. And he put me on the assembly line. And when I figured out I basically figured out convent on my own as a kid. And so when I increased his production and cleared all of his, he had a six week build queue and I took it down to a one week build queue and about four weeks. And so after that he put me in a service department and I cleared his six month service queue, and about a month. And so I owe him I owe a guy named clay Evans, who ran Southern network services. So he threw me into networking when I knew absolutely nothing about any networking technology. And I pulled the cable through fiberglass insulation to get started. And then BB Jagdish who hired me from Alabama into Silicon Valley when I was only 1617 years old, move me across the country because by then I didn't know networking. I knew I knew how to route packets for food. And was only a handful of people know how to do that. And by the end of the road, yeah. I joked I joked in the.com bubble, the bubble burst, I was actually going to do that stay on the road will route out pee for food. So it wasn't just any one person. There's a succession of people and I think everyone who's, who's been around in their career has had people who push them up. And certainly that's the case with me, I would be nowhere without those three gentlemen, there's, there's others too, who just gave me a nudge and push here and there whenever I needed to go. And I I'm proud to say that I've mentored a lot of people out of various positions, and they've gone on to do big things. I'm proud to know when I've worked with each one of them. And you're absolutely right, Sean, you have to take the opportunity and the time to mentor wherever you can. And that's me for 1000s of years. That's that's the way of the world apprenticeship and mentorship is the way of the world. And it's a real shame that we today put so much emphasis on credentials versus experience and mentorship. I think it leads to better results when honestly, actually my first proper boss I was 14, I got a job at my local ISP during support on the weekends. And then he gave me my first programming job. I think the summer before my junior year of high school, writing more Perl scripts, he just reached out to me on LinkedIn, I haven't thought about him for a long time. But it was really relevant to this conversation that, you know, one of the guys who gave me a shot when I was a kid, doing local South Jersey, ISP tech support is still kind of in your network. And they will definitely agree with you about the credentialism like not to say that gay kids are coming out of these top tier universities aren't whip smart and something like that. But I do think that it's not sufficient, right? You need more than that. And you need, like, I think alumni networks can help and things like that. But really, you need to come into an organization that wants to support you. And I always tell my new grads like this is a marathon, not a sprint, like you hopefully will be doing this for 20 or 25 years of your life, right? pace yourself. And also don't burn bridges, right? Like it's very easy to be an asshole in this industry and think it's tolerated way more. But I think that people who are kind and supportive, they get those kind of opportunities more easily, but then they're much more likely to turn around and kind of create that network around them. So that's

Laura Roman: 56:12

a good chance to jump into what you're doing that last year and and how you're managing the project like compass, right meeting expectations of the business stakeholders and customers, while delivering the technical capabilities and features on schedule. So what's been your personal approach to managing that process? How you keep things on track, or even some things that you've learned in context of this, how you've been mentored that you are, in turn, how you're approaching management, your leadership?

Sean McCullogh: 56:38

Oh, yeah, I would say this is this has been the hardest job that I've ever had, mostly because we were kind of founded in the team was put together in November. So height of Coronavirus, blues, a spirit like all across the world, teams have been working home for you know, eight plus months, really, really burned out. My team is split. So my leadership group, my pm design and program management counterparts are in Sydney. And my PMM and chief architect and me are in California, I have one of my engineering teams in Sydney. And then the rest of her distributed throughout the US like it is a very, very tough team to get to get together and like trying to found a product and do all the kind of like high bandwidth communications like over zoom, during that narrow overlap between the US and city is brutally hard. Really, really hard. And, you know, I think this job kind of taught me a couple of things, right. And I think it's kind of just solidified, would have known a lot in the past like one, I think, especially in tech, you can feel this, like ever growing burden of the work that you have to do, it never goes away, right. It's about prioritizing, and doing what you can do in the day, and getting a sense of accomplishment from just like moving the ball forward and making sure that the people around, you know that too, right? That there's always going to be there. And you know, I really preach kind of prioritization over everything else, right. And making sure that taking care of yourself is a big part of that priority. Like I've seen so many really brilliant people work themselves to the point of burnout into the point that they just can't contribute anymore, or they don't like their jobs anymore. And that passion to their job is gone. And I've been there myself, right. And I think trying to create an organization that has that baked in to our values has been really important to me. And it was honestly necessary, right? Like, kind of starting this during one of the darkest times in like modern human history. Like I think we all needed to have a little bit more compassion for what we're going through at that time. And kind of set some more reasonable boundaries about you know, how many hours a day you can work and how many hours you can just stare at a zoom screen in a row. The second thing is trust enough harmony, right? Like, I lead with a lot of trust and autonomy, like this role has me meeting with Mike cannon Brooks, like one of the founders of the company, with various levels of like senior management with customers and stakeholders and stuff like that all the time, right? Like I have a very broad scope of things to do. And there's a lot of attention on this job. So I need to trust not only my managers, my principal engineers, but the engineers on their team and my product and design counterparts and my program manager counterparts to do the right thing, right, I have to set them in the right direction, but I can't micromanage them, I have to empower them to do the right thing. And then trust them that they'll get it done. Right. And that means sometimes things don't go the right way. Right. But that trust needs to be earned by giving people that leash. It's not by micromanaging to them to the point that you feel confident that they can go do it that that's never really accessible way. I don't think that it was an option for me in this role to do that. And then I think finally is that I got into management because I realized that most of the problems that I was solving, especially on the it are permanent. I worked on a Groupon for people problems, not technical problems, right? Like, there were two interesting technical things that happened on the ITF project. Like we, we ran into some concurrency limits a node, and we found some holes in our load balancing infrastructure. Like while we were rolling it out, right? The rest of it was, how do I train people on this new sack? How do I get management to buy in to doing a product freeze for six months while we replatform? The whole product? How can I get the essary organization bought into the fact that I'm going to make their lives easier? Not harder, right? How am I going to get like my manager to advocate for building out a big enough team around me to get this kind of work done, right? And that I realized that I am effective at doing those things. But really, like if you want technical outcomes, the first gatekeeper are people and personalities that are in your way, every once in a while you get actually get a really juicy technical thing that you can go run with. But most of the times that kind of collaboration. And actually remember, I had this team that was working in South America, one of our teams was like rewriting our billing page. And like the relationship with them was going terribly. Right. They were just in a different timezone. They didn't speak English very well, they didn't really understand the problems that cross. So we actually flew down to our Santiago office, and I ran a hackathon for them to like, start using this technology, I flew my entire team down there with them, to basically just show them like we were there to support them. And that we would give you our full attention for a week to get whatever you needed to get done, done. That set off just a kind of shining light in my mind, which is like when you start with empathy, a lot of other problems go away, right? And sometimes, you can't just throw documents across the Atlantic Ocean and be like, just read the documents, man, go figure it out. Like you need to build that trust within an organization for people to feel comfortable that they can learn new skills and do new things.

Dean Nelson: 1:01:55

I got to wrap up and like is everything you just said there is so poignant. So first up, like leading through micromanagement fear will only accelerate attrition. You know, rtfm just doesn't offend me remember that acronym, but read the frickin manual. If you don't go back and inspire and boost talent, you're gonna basically just lead to attrition. And so leading by example, that's what I'm seeing with what you're talking about here. And it sounds like you're there. Right? You're real, you're honest. If you do that, you get amazing results, like what you're seeing at your company right now.

Sean McCullogh: 1:02:26

Correct? Absolutely. And I think even when I think about the people around me, like I you never see good people stick to micromatic. Right? Like they flee those environments as fast as possible. And that new for me, I always want to work with great people. And I know that I've always been attracted to people who give me that level of autonomy. And in that vein,

Dean Nelson: 1:02:47

Brad, you did tell us who your inspirations were, who were the people gave you a shot?

Brad Kirby: 1:02:50

I had different roles over my career in tech, but not directly. So really, I got a credit john Cowan and James Thompson edge x for giving Oh, come on tech startup. I mean, really, in terms of murky furniture.

Dean Nelson: 1:03:04

That's awesome. All right.

Sean McCullogh: 1:03:07

That's the formula. It's totally.

Dean Nelson: 1:03:08

So we definitely want to thank the gatekeepers. I mean, if you think about it, they all gave us our shots. So Dustin Anderson, Tom day, Randy mod Craig flowers Randy Kroger's. Right Krueger, Clay Evans, BJJ D, BB, Jackie's. And of course, john Callen. And James Donaldson, thank you for making a meaningful difference in our lives. Pretty amazing.

Sean McCullogh: 1:03:28

There's like another 100, though, I could I could go down without

Dean Nelson: 1:03:30

Yeah, totally.

Sean McCullogh: 1:03:31

Long, long list. Shawn. Great advice. And thank you so much for taking the time to be on our show. We're at our little over an hour mark. And I know you've got to be incredibly busy in your role. It's funny, you're sitting you're describing like, what your day to day life is and how difficult is to manage the team through the limited bandwidth, you have to get to a certain like, I'm so grateful. He's, he's taking an hour out of his day to talk to us because I think I know I got a lot out of it. And I know the audience will too. So thank you so much for being here. Yeah. Thanks for having me. It's really nice to meet you all. And thanks for for the opportunity to come talk to you. Of course, folks, if you enjoy shows, such as this one where we bring you the best, brightest, biggest minds in tech, and they share their real world experiences with you and us. Please do give us a like helps us expand the audience. This show is sponsored Of course by infrastructure masons whose uniting builders of the digital age. Learn how you can participate by going to the web to AI masons dot o RG and by edge x creating the new edge computing platform for the world of things. visit us on the web at Ed g x that i o that's Ed j x