Episode 18 | The Art of Building Software & Running Organizations with Wade Arnold from Moov

Eiso: [00:00:00] Welcome to Developing Leadership, the podcast where I, Eiso Kant, and my co-host, Jason Warner, share our thoughts and lessons learned on engineering leadership through the years. 

Today, we have Wade Arnold on the podcast. He's the founder and CEO of Moov, the first cloud-native payment processor. Wade has been on one hell of a journey, from engineering leader running a company by day, and coding by night, to a founder flying around on jets, and now back in the builder seat at Moov. His unique path is filled with insights on balancing the role of CEO and technical leader, and understanding your customers in a world that has gotten a lot more technical and sophisticated over the years. We also touched upon how to attract great technical leaders, increasing velocity as your team grows, and whether engineering leaders should get away from the code to run their business.

Want to give a special shout out to Karma Charma for leaving a 5-star review on Apple Podcasts. We really appreciate it. If you enjoy the episode, leave a review on Apple Podcasts or Spotify, and share this episode with another engineering leader. And as always, this episode comes with accompanying [00:01:00] show notes featuring our favorite moments from the chat, and a deep dive into today's topics. Find them at developingleadership.co or link in the description. 

Hi, everyone. We're back again with another episode of Developing Leadership. Jason and I have a special guest with us today. Wade Arnold, founder and CEO of Moov. I have to say, Wade, after our short prep conversation the other day, I'm really excited for today's episode. Can I just ask you to kind of kick it off with a, a bit of an introduction about yourself and, and your story?

Wade Arnold: Yeah. Absolutely. So, first, thanks for having me on the show. You know, my background is I got into computer science and computers just as a hobby. I think of it as, like, my parents were able to wrench on cars. Uh, our generation couldn't, but we could wrench on computers and overclock pentiums, and reprogram driver's licenses so you could buy cigarettes and all that type of fun stuff [00:02:00] growing up. 

But it's always just been a passion to me to use computers and internet and technology as, as a fun, creative outlet. You know, what we build with software is, is truly art. And I, I respect the craft. That being said, you know, over the years, I've gone from undergrad as a computer science student that ended up reverse engineering the AMF format on the flash player 'cause I couldn't afford it. And so, you know, started off as a cease and desist from our friends at Macro Media, and ended up working for them. And, and releasing an opensource version of kinda the flash player to the zen framework.

So, fast forward and, and really became an entrepreneur because I thought entrepreneurship was this cool outlet to be super creative.

Eiso: Wade, when you and I were talking, you, you were kind of chronicling the time from Macro Media, you know, engineer to founder to, all of a sudden, finding yourself, I think as you said it, you know, flying around raising money [00:03:00] and having very little to do with code, to now being back in the builder's seat. Could you unpack that a little bit for us and, and tell us a little bit about that journey and, and how you changed along the way?

Wade Arnold: Yeah. Absolutely. So, at one point, I was kinda the world expert for communicating between the flash player and, and services, which were just like RPC calls. And ultimately, that led to the flash player had direct access to Adobe Acrobat, and so that's what, what got me into financial services, was if you have a checking account, you are no better off than somebody else off the street in order to fill out that loan application. So, how do you connect, you know, mainframe to web services in order to fill out account and routing number and, and all those type of tools. And so that was something that I did, you know, at Macro Media Adobe. And then that transferred into a company, Banno, that I started. We were really doing more or less the same process of pre filling these forms [00:04:00] and, and if you remember kinda the culture of Macro Media was very user experience focused. And when we were doing that, it ended up being kinda 2008. And all these banks, a year after the iPhone and Android had been released, didn't have a mobile banking app.

And because we're already in there getting balance and transaction history and address on record, and all these different things to pre populate a form, we said, well, you know, we could kind of pivot this company into doing mobile banking. That was really when the company got a lot of traction. 

So, Banno ended up, uh, serving community banks and credit unions across the nation. In 2014, we were acquired by Jack Henry and Associates. And, you know, got to work there and, and really build out their digital strategy. But their digital strategy kinda relied on bringing Wall Street along with, with that journey. So, I spent a lot of time doing everything from investor meetings, by side analyst meetings. Literally out [00:05:00] there raising 100 million dollars for a publicly traded company. And it transitioned from, you know, being this very technical person, which allowed me to explain what we did, into, you know, how do I say that so that I don't lose the entire room in order for us to, to raise capital. The last year I was there, you know, we were flying around on jets and doing all kinds of analyst meetings and shareholder meetings and it was just a, a big transition from starting off as, as writing the first line of code at Banno to about 2018 I got a text message that we finally deleted everything that you ever touched. So, you know, it, it was that kind of transition.

Looking back on it, though, when I left Jack Henry and was thinking about starting Moov, I felt like one of my secret powers that made Banno successful was frankly my ability to call bullshit and also be relatable to software engineers. And we were [00:06:00] getting these little circles of entrepreneurs and the, the biggest thing that people complain about is they can't find any engineers. And that's never been a problem for me. That's, that's actually been the easy piece, software engineers love coming and working in an environment that their craft really shines. 

And so I wanted to start a new company, but the last lingo I knew was H base and puppet and VM ware. And there's all kinds of cool things that happened from 2008 to, to 2018. And so I, I really got back into being able to write code and really thought about a lot of the things I would've done different if, if I could run Banno again and try to kind of go learn some solutions for that.

Eiso: I, I see Jason and I's eyes perking up because it's, you said, you know, what we... What you would've done differently. Kind of coming out of that experience from, you know, writing the first line of code to flying around on a jet, to going back and writing a first line of code again. 

Maybe before we dig into that, tell us a little bit about [00:07:00] Moov, what you're doing, and, and maybe then dive into, you know, what are some of those lessons that you've learned from the past that this time around you're doing differently or maybe on purposely repeating.

Wade Arnold: Yeah, absolutely. So, Moov makes it easy for software companies, really think about vertical SaaS type applications to accept, store, and disperse US dollars. So, traditional payment rails inside of the United States. And we've gone and built a platform that allows our customers to have faster access to capital. So, I can go on rants on how we do that, but ultimately it comes down to: can accept a credit card stored into our wallet, and disperse it onto a card or, or the real time payment network inside of minutes, and most of our competitors take days if not weeks in order to do that across multiple sponsor banks.

And so that's our, our kind of unique value proposition. And we think the world's changed from you have a checking account at Farmer State Bank, [00:08:00] to if you're an Uber driver or Amazon flex or dasher, that's really your center of commerce. And we think all these vertical software applications' the center of commerce is actually going to be that back office tool that they work inside.

We try and do that in a highly reliable, highly scalable way, but it's also about transparency of data. So, everything we do is event driven, which allows... You know, our customer is really serving the end user. So, we wanna be able to expose, through web hooks and, and every other means possible, all that data so they can create the best user experience possible.

Eiso: I love that, Wade. You were an engineering leader at, at Banno. Then into acquisition. And now today... How would you say you've changed since the early days versus now as a leader?

Wade Arnold: Yeah. So, so I was the, the founder and CEO, but I was also probably the principal software engineer at Banno in the... In the early days. So, I had two shifts. I was CEO during the day and I would go home and [00:09:00] maybe ride my bike and say hi to my new wife, and, and then I'd go back to work. And really do that 8:00 PM till 2:00 AM shift where I was slamming code or optimizing postgres, or, or doing all those type of things. 

And so, you know, as a tangent, you know, starting Moov, my wife had PTSD that I was going to go do both jobs again. Banno was a bootstrap company, we went and raised capital in order to do this one so that... So that I wouldn't get divorced. You know, it was really a product-led organization at Banno, an engineering-led organization. Which is kind of funny 'cause it sold into banking and most bankers don't have any value for, for all those things we just talked about.

But the transition has been really going from can you be that leader that's the most technically competent to can you create an environment where the most technically competent people wanna [00:10:00] come and lead? And I think that's been my hardest transition, is realizing, you know, maybe I can't be the best programmer, but what environment allowed me to thrive my coworkers to thrive at Banno? And now all my time is focused on how do I keep that environment in place so that they can really rip, uh, when it comes to working at Moov?

Jason: Wade you said something that Eiso and I have gone back and forth on quite a bit on this podcast, and I've probably ranted about several times, which is I hope, at some point in the future, that we start seeing more CTOs, or the technical side of the fence start taking over companies and running them. And particularly because, when you and I were younger and had less beards, I guess we could say, I imagine your experience is a lot like mine. When I was a young programmer, I started out and I was considered a cost center. Programming was the center where [00:11:00] everything needed to get done, but they thought of it as an expense as opposed to just where the value is created. Now, obviously that's changed. So I love the fact that you're, you're thinking about this and you're doing it. I love the fact that you are reck- you are able to go do this and we're starting to see this a lot more in start-ups, too.

In particular, I'm really curious how you balance. Because one of the things that I have been asked whenever I say this question is... Well, there's two things actually. One is, why would we remove you from your superpower, which I think is a false equivalence. You can use your superpower in a different capacity. Two, will you ever be able to get away from the code and run the business? 

And I'm curious, from your perspective, particularly in Moov's case, are you able to balance those two things and how you're able to do them? And let's talk about your, your superpower. Your ability to understand the code, the architecture. All of the things to a degree and depth that a normal person who does not have that sort of understanding, and how you use that to, to benefit Moov. 

Wade Arnold: When it comes to the superpower in what we're doing [00:12:00] today, to me, it's understanding the business domain first and foremost. And so, as a payment processor, understanding things like transactions per second and parallelism and network configurations and fault tolerance redundancy, scalability. Well, that's not a lot different than, you know, what you would maybe need to know if you were running Coca-Cola or John Deere in those specific verticals. So, for the vertical that I'm in, that background is highly valuable. You know, that I know what BGP plus is in order to do fault tolerance for, for, uh, payment rails. And I know that the legacy system still require an equinox data center in order to, you know, connect to the cloud. So, I think it's really important for me to do what I'm doing today to... Have had those superpowers and, and grown up, you know, racking servers and adding in more, more RAM and, you know, configuring an ISDM line into my parent's basement. Those [00:13:00] skills... Turns out that's still how the internet works. It hasn't changed.

You know, can I go get a job at Cisco? No. You know, could I go work at Google cloud? Absolutely not. I think one of the things, to your, your first question, is do I want to? And I think that's a good question to founders is, do you want to try and do both? Because I don't believe you can. I don't believe you can keep up in both being a great leader and understanding organizational behavior theory, while also keeping up with exactly what the new version of Go brings to the company. But I do think it helps having that base knowledge, especially if the domain name is highly technical.

Jason: I think that's a amazing nuance to, to, to point out here, which is there's a spectrum between understanding which package updates happen in Go and what new is happening to the language, versus understanding what Go is, why it's important, what is has done, what it has [00:14:00] unlocked. Same thing for all the various technologies. And it's one of those things which I, I, I think only engineers can fully understand. But as you abstract yourself up, it's the same, techniques that's happening. Is I don't need to know the micro details about Rust. But I can understand when Rust is applicable and when it can be used and why it's important and what it does. To apply it to the business and understand which decisions are being made. 

Good example of this is, you mentioned earlier, some of the overview of what Moov does, and then you had mentioned a couple of architectural elements, including web hooks. So, technologists out there hear this, and they're gonna understand why that's a really cool thing for a person who's dealing with money movement to do. But others are going to m- possibly miss that. And I think that's a... One of those, those things that I would like to see the industry adapt more to, is understanding why some of these things are so interesting and, and advantageous to, to have a, an overview of from a technical perspective. 

Wade Arnold: To drive into that, though, me [00:15:00] understanding web hooks is not because I need to be technical to understand web hooks. Me understanding web hooks is 'cause my buyer requires them. My buyer actually would really like it not to be web hooks, they'd really like, hey, can I expose confluent cloud and get protocol buffers streamed through here so I don't have to do retries and, and all these other things. So, you know, back to the analogy of Coca-Cola or John Deere, understanding the problem domain, for me my problem domain is, is applications that want great user experiences. The worst user experience is a payment not going through or payroll not being made. And so how do I do that in a kind of a fault tolerant way. Now it's being able to speak about these things because, because that's what the buyer is looking for and so me leading an organization that, that is focused on selling to, you know, the CTO or CPO inside of a company needs to understand that [00:16:00] lingo and, and not, not bring in sales engineer in order to decide this is important.

Jason: Exactly. The world has gotten a lot more technical and sophisticated, and the buyers become CPOs and the CTOs, and the developers lead with choice. They have... Developers can choose off the, the rack. So, when you're understanding your customer, which we talk about all the time in the industry, and you have that ability to, to speak that same language with them, just like you could speak to the engineers internally, you can speak to the engineering departments or the CTOs and CPOs externally and your customers. It's just a huge advantage.

Wade Arnold: Yeah, I wanted to address your second question, though, which is do you have to stay technical? You know, you said it's a superpower, which we kinda addressed that. And, and then your second question was really about, you know, can you run the organization. And so, so for me, because Moov's most critical code paths are, are opensource, Apache 2, out on GitHub. That's, that's my area that I can kinda keep my hobby going, to... So [00:17:00] I can keep my pulse on the world of, of software. And let's be honest, every engineer just wants to work on the cutting edge new stuff anyways. So, as the CEO, it's kinda fun to, to be able to play In that area. There's no code at Moov, outside of opensource libraries that I've ever written. And I'm not in the path of a sprint, I'm not in any technical discussions on, on how we do scalability. But obviously I have my fingerprint all over the, the leadership team and who I picked in order to do those efforts. I think that comes back to, you know, having technical leaders turns out we hire more technical people than we ever were in our entire life.

Jason: That, that is true. And I think it, it... This is something I reflected on. I still talk to a lot of my coworkers from GitHub or Heroku, and one of the interesting things I remember, I was talking to a product designer from GitHub who was hyper technical and I [00:18:00] remember thinking to myself, when I was looking at some other organizations and how they compose themselves, they don't have that sort of depth, and I think that was one of the magic, one of the magic elements of some of these organizations is that they're not necessarily infrastructure engineers, but they don't need to be. But they have some depth to them in these domains. And it just kind of the organization that evolved and it got intentionally built at s- one point and then became better then evolved. And I find that fascinating that Understanding the customer led them to have that sort of orientation. I really appreciated that about those, those two organizations.

Eiso: Wade, do you think you could have built what you're building in terms of an organization? The, the talent that you're attracting, the technical leaders, if your end customer and product wasn't so developer and product oriented? What I mean by that, if it was a, a SaaS , you know, crude business where, you know, essentially inputs, outputs, and, and really not the level of complexity that you're solving? Do you think you've been able to attract the kind of talent? 

Wade Arnold: I believe that [00:19:00] the reason you're able to attract that type of talent is because you're attacking a massive problem. And the best engineers want to attack massive problems. And, I mean, it's, it's like a, a light to a mosquito or a... Or a magnet to, to iron. You go solve the gnarliest problems that, that people know about and are frustrated with. Then it's easier to attract that type of talent. And so, uh, what we're doing at Moov, everyone's just been complaining about the same problem for 15 or 20 years. I mean, it's 2022 and we're the only cloud native payment processor. Like, think about that. There's payment gateways. But actually clearing a card, the only one. It's, it's 2022. The clouds been around for a while. So, it's not as though people were [00:20:00] unaware that this problem exists. And a lot of the people that we've been able to attract have come from more front-end FinTech companies, and they were never allowed to go fix the root problem. But they experienced that problem. And so I think picking gnarly problems is, is a great way of attracting fantastic talent.

One of the things that I learned from Banno is, Banno took on gnarly problems, but we also... We're a little too academic in how we approach solving those problems, which I think is, is very much a first founder, especially first technical founder, pattern. I see it every time I go talk to other people that wanna start a company. It's... You know, sharp edges and shiny objects are the entire technology stack. And so, you know, for us to then go after this really gnarly problem, we said, well, the problem's gotta be the hardest part of what we're trying to solve here. Using antsy [00:21:00] SQL, using Go, um, using these very pragmatic tools to take on this gnarly problem was very intentional when, when we went after this. And so I think you get this balance of people that, that are focused on, you know, great engineering, but they really... They really see the root cause that they're up to solve, and they're more interested in solving that than, you know, updating their LinkedIn profile because they were able to write a new Haskell library.

Eiso: So, so I think the point you just made is, is worth emphasizing. And I'm one of those founders who made that mistake in the past, of getting sucked up in the... In the hardcore technology choices as the sexy, shiny part versus the, the end user problem. 

What you're saying, I think, is a distinction for any CTO looking to become a CEO or founder, to really hold into account, is that there is a transition that happens, and it should happen as an engineering leader yourself, as [00:22:00] this might be the sexiest or the most interesting way of solving this problem, but it is not necessarily the shortest path to the actual root cause that you're solving or the goal that you have, and it sounds like you've made that a key part of Moov's culture. As you started now hiring technical leadership, talk us a little bit through what's the size of the org right now, and how did you find those qualities, in the leaders that you're bringing on to make sure that you don't fall back in that trap? 

Wade Arnold: So, the organization is 60 employees today, but it's, you know, 50 are, product/engineering, and then the rest of us are, are what Jason would equivalently call the new cost center. Right, the people that, that aren't building anything and creating any value. Outside of sales, but that's something we're, we're ramping up rapidly. 

The thing that I sought when I started to start a new organization was first and foremost engineering managers that were investing into themselves, [00:23:00] that weren't caught up on if we just do Kanban exactly like this or if we... You know, if we just go, do OKRs this way. And like software engineers have an incredible ability to bring religion into the practices. And backing that off to really what KPIs actually matter. Like, how fast are we shipping? You know, what's the churn on our code base? You know, how long does it take from a Pull Request until it's in prod? Frankly, those three numbers, I can tell you how any engineering organization is running if you give me feedback on, on what I just asked there. That's all you need.

Now, did you build the wrong thing? Did... You know, those are different questions that are more product led, but from an engineering culture Pull Request to Prod is probably the only metric you need to understand the health of the organization, 'cause everything else are how you make Pull Requests to [00:24:00] Prod faster. 

And so I really sought individuals that cared about the craft of shipping, and shipping with really quick velocity. So, that was something, you know, I do think our, demographic of our software company is a little bit older because they have more experience. And, and that's something we're now kind of combating. You think of most start-up software companies as people in their 20s. Our, ours are all in their late 30s and, uh, late 40s. So, I may be over indexed on understanding that we're here to ship product and finding individuals that believed in that mission.

Jason: There is nothing about what you just said that neither Eiso or I love. Absolutely. We find that we have the same type of conversation with particularly young founders all the time when they ask, like, how do you make a s- a start-up successful. I typically point back to just fundamentals, and I say one of the most important things that you could [00:25:00] do is understand that if you don't get your stuff in front of customers to get feedback as quickly as possible, you're, you're... That's the game. You gotta keep doing that. And I... [laughs] When you said that software engineers like to bring some religion to the job, I just started to laugh 'cause it feels, all the time, that we're trying to reconstruct all these cathedrals and these different things all over the place when, in fact, exactly what you said, we should be getting these things in front of the customers and out into production and everything else would be... Should be a support of that. It's an amazing insight, and I think one that is important for start-ups in particular, because you could over engineer your way before you've ever validated that the idea should exist in the first place. And that really boxes you in in the long run.

Wade Arnold: Yeah, I'd add, too, you need to get product in front of customers, but every start-up doesn't have enough features. It's a start-up. By definition, you don't have enough features compared to the competition. The number one way you can overcome that is show that you ship. [00:26:00] Can you go live today with what I have today? But you've seen what I release on a daily, weekly, monthly, quarterly basis, and so now you can trust me 'cause one part is selling a vision the second part is selling trust and the biggest way you can sell trust is watch how fast I ship, and you can keep a customer that may need sub feature Y or Z. But is able to go live with the key feature. Because especially as a developer tool, their team has to integrate it anyways, and if they trust that you're going to continue shipping at this crazy velocity, which by the way, as we hire increases-

 Or should increase.

 You're able-

 Should increase.

Yeah. Exactly. But that, that to me is, is another key piece of being able to not, not sell futures, but sell confident that you can deliver on the future.

Jason: I think what it does is... [00:27:00] Another way to, to maybe say this is, you're constantly in this dance when you're a start-up company of, uh, trust. Y- you're trying to gain and earn. You have a gap between what you need, what they fully 100% need or think that they need, and what you have. But the trust is what bridges that gap. And that trust is earned by the speed at which you can deliver. And also your understanding and ability to listen to them but play it back in an understanding sort of way, which is, like, we hear, we hear you... Trust us on these things. And you can do that. It's a remarkable thing. I mean, I love everything about what you just said, and I hope a lot of younger founders or maybe first time founders are listening to this and understand what we're really trying to say here.

Eiso: You said something, Wade, that, you know, as you increase your team, velocity should increase. I've now seen hundreds and hundreds of companies actual time from initial commit to prod. And I can count on one hand the amount of companies I've seen that have actually managed to [00:28:00] increase velocity as they increase their organization in magnitudes. 10 to 100, 100 to 1,000. And every single one of those companies has been a developer first, a product or an API product. 

And I'm curious, as you say, as you're now increasing the team, velocity should increase. What, what are the struggles, what are you doing? What, what is it that's allowing you to do so? Because it's something so rare to see. 

Wade Arnold: So, let's take a computer science concept and apply it to organizational behavior.

Eiso: We love that.

Wade Arnold: Uh, to me, it's about domain-driven design. And I'm not... I'm not a micro services zealot, so don't... The size of the service should be the size of the domain is, is my personal opinion on that problem. But the size of the domain shouldn't escape 10 engineers on the team.

So, there is some kind of Conway's law slash domain theory that you can [00:29:00] apply to this. And I think it's just mission critical that, you don't have engineers disc swapping, for lack of a better term, jumping from one project to the next, but they're able to see this sub domain or the sub service, all the way through. and I don't know that adding more people to one of those domains, you know, ever increases velocity. Right? It's got... You know, the classic mythical man month. So, to me, it's how, how do you let a team get big enough? You know, that 12 to 14 people, where it starts feeling like there's too many chefs in the kitchen. But you have that next domain problem that you wanna go attack, and you split the two teams and, and you start back filling individuals into it. So, for me, that pattern is very scalable, where, where you can keep kinda those problems that you're attacking. 

I do think it requires some, some neat technology. You know, things like protocol buffers, every Reddit post [00:30:00] is about how they're faster. Uh, I kinda don't care. I like that you can code to contract. And now when you're coding to contract and you can just put that on a Kafka topic and people can work inside of an asynchronis manner, now you go change the protocol buffer, everybody's bill breaks, right? If you go change [inaudible 00:33:01] request, and by the way, if you use JSON you're probably using HTTP which means it's synchronis, which means they're tightly coupled anyway, so just might as well make it a library, that's its own rant. You know, now, now you don't break the bill. So, all this thing, like, you know, type safety and all these other tools that we, we talk about in computer science, then we go back to strings in JSON and, and kind of break everything up.

So, if, if you really apply that, I think solid computer science principles of lose coupling, domain driven design, eventing which makes things asynchronis, uh, you can always [00:31:00] bring synchronis back for performance if you need it. Really scale well into how you develop your teams as well.

Jason: This is one of the things that, whenever someone hears me get into like a soapboxy rant type of situation, I talk about quite a bit about building organizations that scale, is very similar to my background as a distribute assistant's engineer, and that's where I grew up. It's actually looks a lot like a distributed system, and some of the principles that you would take from that. It just happens to be a lossier version of it. 

But if you understand the distribute assistant's architectures and why you would use eventing systems versus accute systems, or blah, blah, blah, all the different various things, you can kinda understand what you're doing. And your point about micro services or contracts, it's exactly the same sort of meta level things as you build organizations... If you're trying to make something that scales and be robust and resilient, but also it performant and it keeps going up as you add more people, you're going to start applying some of these things. You're not gonna be into a 100% tops down hierarchical [00:32:00] structure. And you're also not gonna have this completely bottoms up thing. You're gonna have these hybrids all throughout the organization that's gonna be loosely coupled but you're gonna understand how the coupling works.

And it's one of those things that I think some engineers who have transitioned further into their career understand when you have these conversations, but it's a... It's a fascinating one, and it's one I'm... I think I'm gonna have to find a different way to articulate, so Wade, you and I are gonna have a lot more conversations about this. 

Wade Arnold: That sounds great.

Eiso: I think it, it all comes down to there is a certain size where your entire role as an engineering leader, unfortunately, becomes dependency management. And the more we can use the right technical tools, and if that's, you know, protobufs or if that's, Q or any type of, thing that you're taking from distributed systems it all comes down to how do we allow these teams to be able to move fast in their domain without actually being hold out by someone else. And often more so, it's not one other team, it becomes this graph problem where-

 nodes in the graph end up [00:33:00] affecting everyone.

Jason: I would like to point out, like, 'cause Wade pointed this out already, he talked about micro services. And there is a spectrum between monolith and a thousand micro services that every organization likely wants to fall on that spectrum, they should start out as a monolith but they should almost always never end up as a thousand micro services. End up as a collection of applications, which is, if you think about it from a on-the-screen perspective, a collection of applications is ring fenced set of services that can work with each other on these things. It's dependency management. If each one of those has to talk to 10, 15, 30 other services, it's a nightmare. Imagine getting any single change through to that. Guarantee, if there's an engineering leader listening to this podcast right now that says I can't get work done inside my organization, and you also have 50, 30, 100 plus micro services, figure out which one of those things can be sets of applications. You could probably put your throughput through the roof instantaneously. 

Wade Arnold: Absolutely. And, and something that, you know, we [00:34:00] talk about a lot at work is software engineers like to talk about CICD. So, take that same paradigm further. So, we like to say, if it's not documented, it doesn't exist. If we haven't told people about it, it doesn't exist. And so some of those bigger change log types odd items, that then flow through CD, our actual marketing team and communication team is tagged inside of GitHub before they can merge into prod.

So, you go change an API or you add a new feature. Now we're wondering, hey, does docs.moov.o have that? Because that's a dependency that's necessary. But we're leveraging automated tools in order to, to have that communication happen throughout the organization. And as a 60 person, 100% distributed organization, it's really nice to have that CD pipeline which literally has an event off of GitHub action in the slap to tell the marketing team [00:35:00] the change log's coming through and we need to make sure the docks and the social media and all those other things are out there.

Because what I see happen too often is that new feature gets released, nobody uses it, oh, I guess the feature sucks. You know, we gotta refactor this feature. But you never... You never actually got to that definition of done, which is it's on social media, it's communicated to customers, your CS team knows about it, your sales organization knows about it, and it's pushed all the way through, not just new bits on a server, but the entire process. And so I think we can continue to use... To what Jason said, some of these computer science concepts and paradigms. We're really just talking about automation. You know, for us, it was, why doesn't the rest of the organization follow these same, automation principles, in order to make that, that effort happen?

Eiso: I love what you're saying here, Wade, because essentially the DevOps pipeline or CICD [00:36:00] pipeline shouldn't and doesn't stop with engineering. Right? It's just one more part of, at the end of the day, we wanna bring value to a customer, and I like what you're mentioning, and I've seen this in a couple organizations, that the moment you start plugging in every non-engineering team into that process, you will... Besides running things in parallel, you're actually also signaling to the engineering org is value comes from the end user using the feature and actually getting the value from it.

I'm curious to kind of come back to an earlier question. You've recently started hiring some more engineering leadership, including a CTO. What were some of the things that, that you were looking for, for somebody to, to bring all these things together as the engineering org scales?

Wade Arnold: For me, hiring a CTO, that, that was a painful exercise. Because I needed to go find somebody that I thought was going to treat the culture the way that I did. And so ultimately, you know, we, we... I hired a gentleman, Joel Tosi who, who I [00:37:00] can actually remember the moment I knew that I was going to hire him. I said, "hey, if we have a production outage, what are you going to do about it?" And he said, " I'm gonna answer the phone, I'm gonna tell my team everything's okay, order them pizza and beers and tell them to fix it, and I'll take all the fire from the customer." And I thought, here's an individual that understands what it means to create a culture and an environment where engineers can be successful versus somebody who wants to open a bridge and get everybody on it and let the customers yell at our engineers.

So, for, for me, first and foremost, it was does he have the mindset to protect the culture? To protect the craft? And he did. Now is it, is he competent? Right? Has he run large organizations, does he understand payments, does he understand PCI and all those other things? But you write a job description and it says, you know, understand SOC2, PCI, ISO, you know, blah, blah, blah, blah, blah.[00:38:00] but what you really want is somebody that's going to protect the craft and invest into those people so they can do the best work of their life. And then be able to understand, you know, what it takes to do that is, is almost secondary. There's more people that are qualified for the... For the actual technical skillset then there are people that, that have that kind of servant leadership mentality.

Jason: I couldn't agree with that point more. I get calls all the time now from recruiters or friends who are looking for CTOs and they just always say, "hey, we're looking for another one of you, is there another Jason that is five, five years younger or 10 years younger earlier in their career and they can grow into it?" And I said, "well, what side of the fence are you looking for? You looking for the technical? You looking for the, the organizational? You looking for the combination?" And they also start down the, "well, we... They need to be technical." And I say, "you can find 10 of those people tomorrow that are technical like I am in that way. But it's the combination of the others, other things that is the more unique aspect of it." 

I don't think that we do [00:39:00] that well enough in the industry. We don't serve the emerging engineering leaders well enough to say it's not about the emotional intelligence, yes, you need those things and you need to care for your teams and all those things, I absolutely agree with it, but it's the combination of the technical, the organizational, and the business that are gonna take you to those, those very stages where people think of you in a certain stratosphere. There's always going to be somebody who's technical enough to run something, but it's the other things that are going to take them from an average to an above average to an excellent.

Eiso: Wade, let throw one more thing at you, and as always, Jason, I, I think this is an episode where we are nodding our heads in agreement with everything Wade is saying. Wade, what is something that you believe about software engineering, engineering leadership that most often gets you discussion or debate from other people?

Wade Arnold: So, I'll reflect on a previous self. For me, I was a academic computer scientist. You know, I, I just wanted to go work at Thoughtworks and build incredible, you know, papers and, [00:40:00] you know, when I was an undergrad, I spoke at Uppsala and all, all the fun stuff, right? If it's not small talk, it's crap. So, for me, though, the craft was always about, uh, the computer science problem. Solving hard computer science problems. And so you look at Banno. I think the Banno team, my, my previous company, is the largest contributor to CATS, which is the functional framework for Scala. Very cool. Would've been even cooler if that framework just existed and, and we were able to use it. 

When I started Moov, everything in Moov was written in Rust. Cause Rust was like a better version of Closure without the JVM and our first ACH library and all this type of stuff was written in Rust and, I really stopped myself I realized I'm, I'm recreating that same problem. I'm recreating kinda the academic versus the pragmatic side of computer science. And the industry needs [00:41:00] both. I don't know that a start-up needs both. 

I'm very thankful Rust exists. But as a programming language to get started with, now you need style guides and you need all these other tools. I mean, le- let's take Go, which is what we write in now. And this is the most boring language I've ever used in my life. And at most, there's two ways of doing almost anything, but there's usually the clear way to do it. May not be the most performant way, but the clear way that every Go programmer is able to attack a problem. 

And so you, you kinda look at our organization now, which is really ANSI SQL, you know, Kafka, and I'll, I'll come back to the Kafka thing in a second. Does run on top of Kubernetes, but, but you know, we were going after a really hard problem where we wanted scalability and slow down a little bit on, on cloud lockin. 

But the programming language is something that I [00:42:00] think the younger version of me would've gotten in a war over, to your question. And the war that I'm willing to fight now is not that it doesn't have generics or closures, because turns out the CPU doesn't have generics or closures anyways. But for the next 10 years, when people reread that code that took one day to write and they're going to reread it 10,000 times, can people read it? And can people comprehend it? If a much more, you know, dollars and cents, you know, it, it would take us four to six months to get somebody up to speed in our Scala code base at Banno. 

Well, people are committing two prod week one at Moov. So, very pragmatic, you know, very comprehendible code base to go after. And so that's something that I think is maybe just a maturity thing, is why did I start Moov? Because I, I have a pet project and, and I have these [00:43:00] academic inclinations that I wanna fulfill some ego with, or do I wanna change the fucking world of payment processing? And that's what I wanna do. And so what's the best tool today to go do that, that work?

I did say Kafka. I, I do think that's an interesting piece for us where, when we started, Google has, a Go library called, web events. And so, one implementation of that eventing structure is a Go channel. But you could, over time, replace that with Kafka. And so, when we built our system, it was... It was very much a monolithic application and we were utilizing web events. But behind the scenes, they were just Go channels. 

Then as we scaled and we brought on more customers, then it was like, "okay, go through the entire code base, you know, rip out that abstraction and implement Kafka topics." We're doing that, you know, over the last quarter [00:44:00] in order to get transactions per second up and all these other things. That wasn't, "does the system work?" It's a very conscious, you know, here's a seam that we can cut open in the future and add a more performant layer to it, that we didn't need to do day one and, you know, negotiate a confluent cloud contract and who here knows Kafka, right? You know, nobody.

So, all of those things, I think, lead back to, I believe computer science, uh, and and how I, I do it today is like, you know, when I was 10 years old and, just trying to build something new. You know, computer science to me is a tool. For a period of my life, it became very academic, so my organization was academic, and I, really do feel like I'm back to my roots of, this is a tool to change, frankly, how humanity works.

Eiso: I think that's a fantastic place to leave it here today, thank you so much, Wade. 

Wade Arnold: Well, thanks for [00:45:00] having me.