067 - Adam Boswell’s 3 pillars of engineering excellence

Adam Boswell, Director of Engineering at Kount, explains the 3 pillars he uses to foster engineering excellence.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Speaker 1:

Hello, and welcome to All Hands on Tech. Today's episode features a conversation between Pluralsight's Josh Ruggles and Adam Boswell. Adam is the Director of Engineering at Kount, which does AI driven fraud protection for consumer and enterprise. He was kind enough to tell us all about the three pillars he uses to foster engineering excellence.

Josh Ruggles:

Well, thanks for joining us, Adam.

Adam Boswell:

Yeah. Happy to be here.

Josh Ruggles:

Great. So let's jump in. One thing I know about you is, you are interested in achieving excellent engineering, awesome architecture, and collaborative culture. So let's start with excellent engineering. How do you approach this challenge because I mean engineering excellence is sort of an easier said than done. So how do you go about beginning this journey?

Adam Boswell:

You know, those are definitely the three pillars of leadership that I focus on a lot, probably to ad nauseam of my engineers, always hearing me bring them up. But I definitely feel like engineering culture and engineers in general, we're definitely a very passion driven group of individuals. You usually think of, of engineers and you think of logical and architecture and design principles and what I would consider dark room coders. So guys that sit in the dark and drink a lot of Mountain Dew and Red Bull and hammer away on their keyboards, but really when it comes down to it, there's a lot of passion and excitement around producing really impressive, amazing engineering, right? We're engineers at heart. And we definitely find that an engineering excellence pillar comes into the ability to produce not just working code, but really well thought out designed architected engineering.

And so when we talk about excellent engineering, the principles of that really fall into discipline and design and following patterns that are obviously replicatable and the ability for engineers to engage wherever they are in levels of... We talk about best practices and things like that, but really here at Kount, one of the things that we have done and that I've been able to introduce since I've been here is the ability for engineers to kind of follow practices and patterns. And so when we talk about excellent engineering, what we're identifying there is the ability to produce code that not only works, but that you're proud of. And so, that goes through a lot of different methodologies. There's a lot of different opportunities for test driven development or design driven development, or being able to kind of sit down with your team and architect and design from a technical architecture, how you're producing solutions.

But all of that rolls up to the fact that an engineer who is proud of their work and who is able to produce what they feel like is excellent, is a benefit to them. It's a benefit to the organization. A happy engineer, always writes better code. And so the way that we approach excellent engineering is really by identifying the individual engineer's passion, things that they're excited about, the type of work that they really like to do. And then we thrive on that. We push that. So we allow for our feature teams here to be able to engage and look at features. And as a team, take a list of a large, say cross section, depending on the product that they want to work on, or the challenge that they're after. And being able to work together to pull in like, "Hey, this is what we're excited about."

Then we pair that with, we have a platform or a cloud center of excellence team that produces architectural designs, that produces solution architecting, that produces standards for those individuals to follow. And so in that gap there of here's a structure and a standard, and here's what you're really passionate about. That's where excellent engineering thrives, because you have a design where you know what success looks like. You have a definition of success and you're executing against that. And then you have the freedom as an engineer to solve the problem that's been put in front of you in a way that you're really excited about. And so that's, when we talk about the excellent engineering pillar here at Kount and just in general throughout my career, the thing that I've tried to focus on is allowing engineers to produce things that they are passionate about while giving them guidelines, tools, and structure, to be able to perform it to the best of their ability with a really well defined criteria.

Josh Ruggles:

So when you say you give them, this really defined criteria of success, how do you go about that?

Adam Boswell:

Well, that bleeds a little bit into awesome architecture, honestly. One of the biggest things that I've found that engineers look for is a good understanding of what it is that they're producing, the value that it's going to add. And so we start with our architecture design that works with product, that works with requirement gathering, and that works with kind of the vision of the value proposition. And so an engineer or rather architects, we take solution architecting very, very seriously. We take solution architecting very in depth here at Kount. And we take the opportunity to understand the problem that we're looking at to kind of follow that design of really understanding what it is that this solution will do for the industry, for the client, for our product. And then the solution architect takes a lot of time in designing and orchestrating and identifying what those success criteria are.

And so working with products and working with the clients and working with the outcome to identify these are the requirements, these are the criteria of success, and then designing a solution around that so that we can have that solution to the engineers and say, "make this a reality." And so we use a lot of documentation and UML and class diagrams and all of those fun things that nobody really likes to do or look at, to give the engineer really clear guidelines so that they know exactly when they have produced a solution, that that solution is exactly as intended of what the value is. Right? And so we give a lot of why, if you're talking about value, a lot of that why culture comes out of saying, "why is this going to be beneficial? Why does this help to client? Why does this help us as an engineer to produce this product? "

Well, here's a clear solution. Here's what it's going to look like. And here's the impact that it's going to have on the end user or on administration or wherever the tool is, or the service that's being created. And then the engineer again, has that passion around, they know what they're producing, they know what the outcome's going to be, and they have the latitude to execute that in the way that they want it.

And so solution architecting is not an edict. It's not a, here's how you do it. It's more of," Hey, here's a bunch of puzzle pieces, or a bunch of Lego pieces. Here's the guidelines like, man, if you want to use blue pieces or three pieces or two and two, instead of a four piece, like go for it, do what you want to do to create it. But at the end of this, we want a dinosaur. We need a dinosaur out of these Legos. Here's the end result, go and build it, how you see fit." And that really has produced some pretty exciting results because it gives that latitude to the engineers. But the idea of success is really well defined. So you know when you've hit it, instead of guessing.

Josh Ruggles:

Yeah, I love that. Especially the piece about the Legos you're giving them a pile of Legos and just saying here's the end goal, build it, however you see fit. And I love the part about giving them a very well defined end goal. So they have the latitude to move structurally and kind of procedurally, how do you make sure, especially with things going, everything's work from home now, how do you make sure that your team is feeling that that ability to keep moving or if they're... How do you know if they're hitting roadblocks in this process? In the development process and how do you address those to make sure you're still hitting that end goal or the why that you mentioned?

Adam Boswell:

God, collaboration has really been tough in this environment because you lose those organic conversations that just happen from sitting across from each other or sitting into a meeting and having a conversation pop up that leads to a water cooler conversation or whatever you want to call standing in the hallway. Those kind of middle ground pieces have been a little bit lax and lost during the pandemic. And during work from home. For us, we have definitely become Slack junkies. We, a while into this, before we were very long into it, I reached out to all the teams and I said, "It feels really dumb, but if you go on a file or if you walk away from your computer, if you're AFK, for whatever reason, just throw it in your Slack, in your team channel so that people know that you're not there."

And those actually have been really, really beneficial for like, "Hey, I'm off on lunch or I'm, I'm doing this thing" to kind of be these constant status updates. And an interesting thing has happened where a status update and then a return from status update has been like, "Oh, I was waiting for you to get back. Here's a conversation." And a virtual bump into, in the hallway, so to speak has started to take place during those times. That's one small example. The the other things that we have seen in being able to collaborate is having a lot of well defined structural architecture designs that are being passed off, right? And we use Lucidcharts. We love it, wonderful product, but we have a really good collaboration piece there. And they're just open. There are literally numerous is times when I can drop into a work in progress from a solution architect. And there are three or four people that are on a Zoom call working in this collaborative piece similar to white boarding.

I will admit readily that it is not quite as powerful as standing in a room and actually white boarding, but it's pretty dang close. We definitely have really good collaborative conversations. And the fostering of question asking and challenging outcomes and production has been something that has driven a lot of those ongoing conversations. We also do a lot of agile work here. We do a lot of scrum. We do a ceremonies. So daily standups, multiple refinements and planning meetings, get the teams together often. But I think more than anything, it really is those ad hoc Slack conversations that turn into another thing that I've set kind of as, again, trying to identify or foster with this collaborative culture is if at any point in time you're having a conversation, one-on-one with somebody drop the Zoom link in the team chat, say, this is what we're talking about. Here's what we're doing.

And again, interestingly enough, I was looking through a couple of team chats over the last couple of weeks, and I would say that there's probably two dozen in a 10 day period. Now for us again, Black Friday and different times, this is very active for us. But in the last couple weeks, there's over two dozen, just Zoom, random meetings that are these side conversations that are happening, that's keeping the teams connected. That's not to say that we're not feeling the separation we definitely are. And there's a different culture in remote work than there is in the office and kind of being forced to mend or to meld into that has had the challenges. But my teams seem to have adjusted pretty well to that movement. And so that's where we're finding a lot of the collaborations, we're finding a lot of the conversations happening is that teams are taking personal responsibility of the solutioning and making sure that they don't do anything in a vacuum.

Josh Ruggles:

You brought up Black Friday a couple times, and I'm interested in that, because I mean, I assume you are really busy during Black Friday because you're dealing with a lot of broad issues at that time. I'm curious what that looks like for you and your team. I mean, I'm sure it's probably sometimes fire drills and things like that, but I'm... Just lay that out for me a little bit. How you prepare for this once a year type of thing, where it's sort of crunch time.

Adam Boswell:

So we actually, one of the things that I joined Kount just under two years ago and one of the things that I came on to do was to help to move us from on-prem dedicated systems and data centers to cloud, right? So we've been doing a very heavy push into AWS. We have an entire new platform and we're looking at this upcoming year of kind of solidifying more of our payments processing system into the cloud platform that we have built over the last year. But one of the things that we see is Black Friday's big, it's definitely a big deal, but we actually have multiple of these throughout the year. We have a couple pretty large clients. We have Riot Gaming, which they do their annual League of Legends tournaments that have spikes that make Black Friday pale in comparison.

And then we've got a couple of other things. And so really, as we engage and we prepare for that historically it has been all hands on deck. It has been a massive over provisioning, literally spinning up new boxes, making sure that all the DBAs for our Oracle system are on hand, ready to go, watching the system like a Hawk so that we don't ever go down. This year, we were fully engaged in a number of our large scale services that have been transported and that have been migrated over to cloud native, right? So we've done full re architecture of a lot of these services. Some of them have just been lift and shift, some just been replatformed, but the majority of them have really been rearchitected and designed and we saw spikes of thousands of TPS that ran for hours on end and the architecture design and structure held up like a champ.

And so we actually had everyone kind of ready to go and we encountered zero fires this year, and it's really a tribute to the platform teams and to the orchestration of the cloud native move that we've been doing that really resulted in just some amazing opportunities for us to load test, stress test on the fly. Again, we've had a couple of these earlier in the year, but we try to make sure that as we encounter these types of things that observability is on point, making sure that we can see what's going on in the systems and we do, we watch it. And we trust our systems. We trust our engineers. We trust the work that they've done to be able to produce that. And this year that trust was well rewarded because it went off fantastically. We had great observability, we had great monitoring and really good structuring where before anything really had any issues, we knew about it way beforehand. And we'd leverage a lot of cloud native services around auto scaling and et cetera, et cetera. And it went great, man.

Josh Ruggles:

That's great to hear. And that kind of is a good segue just about this awesome architecture. I mean, you've kind of touched on this at multiple points, but I want to break that down a bit more, just how you go about this. You start with the why, why it's needed, why it's going to help, how does it progress from there? And what's the feedback loop like in the case that priorities shift or that sort of thing?

Adam Boswell:

Sure. And that absolutely happens all the time, right? In a fast moving business, you have a lot of what you thought the solution was yesterday is maybe not the solution today. So I think that I'll start this off with a phrase that I didn't come up with, but has been branded on me since I've been here. And that is a few hours of architecture saves weeks of coding. And that is our core, man. We live by that pretty heavily. We definitely believe that a critical thinking session and an opportunity to explore all of the components and designs that we anticipate coming up, we anticipate seeing and doing the best to identify what it is that the solution needs to look like and what impacts that's going to have on the other components of the other systems is of utmost importance.

And it has proven out this year and in the last year and a half to two years to be worth its weight and gold, so to speak. So, we approach architecture as an opportunity to identify what a solution should look like, what the impacts and dependencies are. And we go through that forethought beforehand. One of the things that has really driven us to be really awesome in our architecture is we have a blended model here at Kount. And so almost half of our engineers are overseas in India. And we partner with a local company called In Time Tech. And we call those individuals, our KI members, our Kount India members. They're such an integral part of our team, and they're such an amazing player inside of our engineering that we don't consider them outsource engineers. They're part of the team.

They are absolutely here and they work really, really hard and do a really good job for us. But one of the things that I've really focused on in my career is how to best leverage these blended models. How do you leverage remote work and how do you make sure that that work is getting done appropriately? And I've really come down on this awesome architecture pillar. That the important part is that you deliver the clear identifiable success criteria from the architecture, from the very beginning, you have those critical conversations and that critical thinking, and you design that in a way that is visually very, very clear. Execution plans, class diagrams, again, UML structuring, it feels very heavy handed in architecture, but like I said, hours of architecture saves weeks of coding. And that continues to be true over and over and over again.

And so when we engage across those things, like you mentioned, we come across changes and when something changes, when you go back, you could think of it kind of like a large gate, right? If you go to the large gate and you want to make a change, the closer you are to the radius of the pivot point, right? The smaller you have to engage there, that makes a huge cascading effect. And so we go back to the very core architecture and when something needs to change, we now have the entirety of what the solution looks like laid out in front of us. So those changes are easy to implement and to engage across. Now, sometimes they take a lot of time and they take a lot of effort, depending on how far down that path you are. But the reality is you are not guessing from the moment of change, you go back to the core, you have the design and you have the structure and you can make those change at the solution architecture and push that back out.

And you're solving again for a problem that you know what the solution is, you know what the end result needs to be. And so those adjustments end up being much more palatable than changing mid-flight what you're trying to accomplish. You're able to go back and say, what impact does this have? And that again has proven out to be pretty efficient. We had a engagement with Big Commerce and P and G a little while ago that our initial estimate and design for that was going to be a couple of months of work to get that out and done. We sat down, really applied some strenuous architecture and design, put that on our new platform and what initially would've taken us what we thought was a couple of months, we were able to accomplish in a matter of weeks.

And there was numerous changes through that process. But each time we had those changes, we went back to the core architecture diagram and we were able to make it so that that didn't exponentially extend the deadline or the structure or the work that had to be done because, again, we had the end in sight, we knew what it looked like. We were able to apply that architecture paradigm shift inside of there and quickly make adjustments. And, and it went spectacular to be honest. And it was really, really big success around here because it applied to all of our new thinking and all three of those pillars really went into effect there and really shined through.

Josh Ruggles:

That makes sense. And I like that one question I have is how do you know, I mean, when the criteria shift, is it something that you find out through... I mean, there's just a lot of back and forth with the developer and the project manager? Or what's a good indicator? Or is it something where if you feel that there is too much back and forth on a ticket or something that you just pull it out and say, "Hey, okay, we got to take this back to the core solution we're trying to figure out?"

Adam Boswell:

This is actually an iteration that we have gone through a couple of times. So when we very first began inside a solution architecting and kind of an architecture driven solutioning, we were doing a lot of handoff, right? We'd have the architects engage and then we'd reengage with them as we felt necessary. As we've moved forward, we've kind of put those solution architects on the forefront of continuing to drive the execution through the entire thing. So they're involved a lot less during the middle parts where code is actually being developed, but really heavy on the front and pretty heavy on the back end, but they're engaged the entire time. And so they're part of those conversations where product is coming back and saying, "Hey, we, did a demo and this is the feedback we got. What does that mean?"

And instead of asking the engineer who wrote the code, we are now having the engagement with the architect at the time, who again, has that high level vision of what success is supposed to look like and can make those adjustments. And so we learned pretty quickly that having that engagement from the engineer and from the architect together, during those moments where we're like, "Hey, does this have any impact?" Was significantly faster than queuing it up, pushing it back and working through that. So now when a solution architect is responsible for creating a solution and handing it off to a team, he's always involved, or she's always involved through that time period. And we make that they are there from creation or from concept to production. And so that is something that we had to learn and something that we picked up on, but feedback can come from anywhere.

We don't run entirely lean methodologies, but we definitely have a feedback loop that involves engineers, involves product managers, product owners, as well as architects. So everybody's involved as they're watching this solution go. And then even once it's out, we inject feedback, we get things, we get feature enhancements and add-ons, and that all comes from any of those sources. We're very account... We have a motto of being open and honest and fearless, and we try to imply that, apply that to all of our engineering. So you see something that you think could be done better, just say something right. Talk to the architect, talk to the product owner. But we have these open conversations as often as we possibly can to produce those kinds of things. But yeah, we definitely see it's an iterative process. It comes and goes, but we try to reduce the interaction time, right? So getting everybody involved, making sure they're at the right place at the right time that those conversations can happen.

Josh Ruggles:

And that's the perfect sort of segue into this collaborative culture. I mean, it sounds like at any time you can pull it back into the architect and bring them in, and it's more of just a conversation of, "okay, these things changed. How do we move forward?" Let's break that down a little bit more. How do you define this collaborative culture and what are some specific ways that you implement that?

Adam Boswell:

So, definitely a collaborative culture is intended to extend out through all of IT and then through all the organization. And so one of the things that we do is we try to have just conversations, what we call just conversations and a jut conversation is whenever we identify one department or one group kind of leaning towards like, "Hey, just do this, just make this button work or just create an API or just do these things." It's kind of a trigger for us that we need to have better stations to understand what each... What do we do? What does everybody do here? How are we interacting? And why is it that we feel like the things that we're asking is so simple that we can use that word, it's a bit of a trigger for us.

But on top of that, the collaborative culture really comes down to, first of all, is your team. And so here, at Kount. We have feature teams. This is a new design for us. We moved from when I first got here, when we were running in service teams that were kind of siloed. So we had vertical reporting across software engineering, DevOps or SREs, and QA. And we've blended those into singular teams that now work all together, report up to the same structure, work as a single team across the feature and making sure that that team is a cohesive unit, has a lot of collaboration. So we do a lot of team building a lot of fun stuff, but beyond just the team building is we allow for that feature team, again, to engage across the architecture, we have them talk to sales, we have them talk to customer support.

We make sure that there are no boundaries that are off limits for communication and collaboration inside of the organization. And that really, again, starts with the team itself having those conversations. Injecting the architects into that has proven to be a pretty beneficial tool as well for us, just because we're having those technical discussions. And we always include product into those. Sometimes they glaze over and, glazed eyes, so to speak and not exactly excited about the conversation of API latency, but we have those conversations. We make sure that they're involved because we find that that just context inside of those teams really fosters a collaboration of the ownership, right? Taking ownership of that feature, taking the opportunity to say, "we own this. We work on this together, and this is our product." The other thing that we do for that collaborative culture is we make sure that when something is produced and when something gets out to production, that the team that has produced that knows the impact across the board, what this does for customer service, what this does for sales, what this does for our customers.

And we have those conversations. We have those conversations internally, where we say, "look, you have produced this thing. It's generating revenue to the organization. It's doing this for... It's allowing sales to get into better deals and to have better RFIs and to get better results and responses, customer services benefited by this because of X, Y, and Z." And so we make sure that the value you of any given feature or any given product is understood, and that we foster those conversations outside of just IT, within the organization. And that really has been a top down approach. You know, our CEO sends out weekly updates of life stories, things that are going well in the organization, things that aren't going well in the organization, how we can do better, what our metrics look like. And it's been throughout this year and throughout the pandemic, something that he's done that has really brought us together to just, again, that context of what's going on in everybody's lives.

On top of that, there's always fun parts to a collaborative culture. We make sure that we do team building events, even in the pandemic. There's been a couple of times that we've done Zoom pizza parties. So we send out coupons so everybody can buy a pizza on us, on Kount. Everybody gets on the Zoom. We all sit around, have our kids jump in front of the screen, scream and dogs jumping everywhere and all kinds of stuff going on. And yeah, we've done half a dozen of those. And so we are making sure that we continue to engage as individuals with the rest of the organization, with each other and making sure that we foster and hold those conversations and those opportunities open. And sometimes it works out great, sometimes not so great, but we continue to try. And it's definitely been a challenge to have that collaborative culture during the pandemic and during things that are going on and remote work. But we try to be clever. We try to find good ways to do that and to make sure that everybody's engaged to the best of their ability.

Josh Ruggles:

That mention of the just conversations, I think that's awesome. A good way to avoid this scope creep of just, "oh, we just want to add this little thing." But how did that, how did that come about? I mean, was that something that you started or was something that was an organic development? I'm just curious, because that's kind of a good way of creating a real conversation of what this actually means when you say just this.

Adam Boswell:

So the Genesis of that is before working at Kount a while ago, I used to be the CTO of an organization called Black Box Code. And at Black Box, we did a just training for executives with an idea geared towards kind of executive leadership when they talk to engineering or into IT. That that word indicates a lot of misunderstanding of what it is the work is done, what it takes to get those things done and that it generates an unhealthy amount of resentment and disrespect unintentionally by saying "we have this project, you just need to get it done. Here's the timeline." And really dumbing down kind of the effort and energy of an entire organization, I think because it's where I come from in IT, I'm particularly sensitive to that being brought up. But it feels like that's a pretty big area, right?

Sales comes in and they're like, "Hey man, just finish this feature so that I can sell stuff." Customer service comes in and says, "just get this thing out the door so that we can get it done. "There's a lot of that, that terminology and a lot of that conversation that does come into IT. And so when I was at Black Box, we held these trainings for a lot of our clients. We were at the time a migration in AWS, as well as small custom services that we would build for companies. And one of the parts of the services is we didn't just build solutions or we didn't just do migrations so to speak. But we also did a lot of executive training because one of the biggest things we found from a migration standpoint is that almost every successful migration dealt with more than just the technology. Almost every successful migration that we ever did was the emotional and mental EQ so to speak of the executives, onboarding with the new way, the new functionality, the new thought process of moving from on-prem to cloud native and the different things that come along with that.

And one of those trainings that I designed and put together there at Black Box was this just training. So I brought that here because a lot of the times we don't identify that we're using words that, again, are a little bit demoralizing or that build resentment or that identify that we are having a misunderstanding of the level of effort and work that an individual does. And so we have a litmus test of just that you just watch up you watch how you use the word, you watch how you engage with each other. Because as a front end engineer knows back in API connections are a lot of work and a backend engineer knows that a lot of work is put on say angular and putting things together.

And a lot of the times you'll come to able to be like, "Hey man, just write me a stub and get me the API working." And it's like, "Hey, you know what? That actually takes me a lot of work and a lot of effort and energy, I don't want to demean what you do. And I don't want you to be able to demean what I do. Let's have a better conversation than that."

And so those are the types of things that for sure, identify for us kind of these, like I said, a litmus test of how are we communicating with each other? Because we want to collaborate. We want to work together. We want to be on the same page and I want to respect you. And I want to feel respected as an engineer it's important, right? We design and develop things that most of the time, we're pretty passionate about. Rarely are you going to get an engineer who writes code that he doesn't care about or that she's not interested in how it works. That's just not the case. We're always interested. And we have a lot of emotion tied to our results and to how things work. And so we want to make sure that we hold that respect for each other.

Josh Ruggles:

I wanted to give you a chance to address anything that you feel like we missed or anything that you want to just boil down into advice that you would give your peers.

Adam Boswell:

I think that one of the biggest things that we've found has been really, really successful outside of, again, these three pillars of engineering excellence or excellent engineering, awesome architecture and collaborative culture, I think is really driven guidelines and has given us the opportunity to go back to a framework, right? I think that one of the biggest things as engineering directors and leaders that we need to really focus on is keeping in mind that we are all engineers, right? And so understanding what success looks like, understanding the paradigm in which success is defined and having a framework to have those conversations, as silly as it is being able to have a jargon or a speak or something that triggers that we're on the same page has been phenomenally helpful.

And so in the time that I've been here at Kount and in previous organizations, one of the things that I find in kind of holding to these leadership pillars, if you will, is that I can go into a room and say, "Hey guys, we really need to focus on our excellent engineering. We're doing a good job, but here we can do better." And I don't have to unpack that. I don't have to take us amount of time to continue to drive what that means. I can push those principles and we can have those conversations. And we know what it means, right? It takes some time to develop that it takes time to get everybody on that same page. But, I go back to this same thing, man, it's design, it's predesign, it's architecture, minutes of architecture saves you hours of coding.

It's true across all principles, not just software development, this is true across leadership, this is true across mentoring, across management, and even down to structuring and budgeting. Take a little bit of time, take time for yourself to go and to look at how you can create that space of critical pre-thinking. Put things down, design it, see what it's going to look like, know what success looks like, and then you can drive towards that so much more efficiently. And so we definitely have seen really, really good results. We've gone through pitfalls. We've had challenges. This is not a silver bullet. We definitely like the fact that we can take something that is an architectural design principle and apply that across the entire organization, inside of IT. And again, for engineering minds, it makes sense. And it works out well, I don't know that I would apply the same thought process to sales, but inside of IT, it's something that has worked well for us and served us well.

And I think that it's the advice that I would give to anybody who's running an engineering organization is sometimes it feels like getting stuff out the door as quickly as you can, is the right answer. But in the net large scope of things, definitely taking time to critically think, to identify what your success looks like, and know what you're driving towards. It's almost always the right answer. It's almost always the right way to go. And yeah, served us pretty well. We're doing pretty good and we're pretty excited about the upcoming year and what we have going for us.

Josh Ruggles:

Awesome. Well, thanks Adam Boswell, Director of Engineering at Kount. We appreciate the time. It was really great to chat through this and get your insights on this excellent engineering. Much appreciated, sir.

Adam Boswell:

Yeah. Thank you for taking time. I appreciated the conversation.

Speaker 1:

Thank you for listening to All Hands on Tech. To see show notes and more info, visit pluralsight.com/podcast. Thanks again, and have a great week.